Using objects to help multiple connected props choose the correct program and run it.

Clock Loop · 2013-07-30 03:53

See post #4 for final solution.
http://forums.parallax.com/showthread.php/149399-SPIN-file-order-rules-for-SECTIONS-and-pathway-selection-using-pin-input.?p=1198517&viewfull=1#post1198517

Is it possible to run two seperate paths in a spin file... I need to set pins as different labels in the CON section depending on say, if P0 is high at boot.

So If I were to place code before the first con section would it work?
Or would I need a beginning con section for at least the clock info, and then insert my logic to determine program path? How would I set up multiple pathways in one spin file?

I want to do this because I plan to make a single spin file run multiple pathways depending on prop pins state.
Does a spin file need to start out with con? If you have two con sections, and set two different variable names to the same pin,...

I would imagine that all sections merge no matter the order and two sets of everything just helps organize it all, this means the data it all takes up is doubled.
The extra chunk of data just dosen't get used, and it dosen't really conflict because the spin pathway never let any cog grind the path.

Really, if I understand spin properly, one could pile a bunch of spin programs into one spin file, and then make the prop run any one of all the seperate programs by simply jumping to the MAIN program, due to all CON sections, VAR, DAT, PUB, PRI they all get compiled and put into the eeprom.

Does order of the sections even matter? The only concern being label conflicts?

Anyone know any tricks that can be used in spin files? does it need every section? does CON have to be first? etc?

localroger · 2013-07-30 05:26

No, CONs are constants defined at compile time; there is no way to change them at run time. In general, except for the first PUB being the one that's run by default when the top object starts, the order of sections in a Spin object doesn't matter much.

You will need to reserve DAT or VAR storage for things that can do different things at runtime, and you can assign them from different CON sources when the program runs depending on inputs and so on.

JonnyMac · 2013-07-30 08:29

I wrote a program for the EFX-TEK HC-8+ that checks the state of a pin on power-up and runs code accordingly. To top things off, before it looks at that pin it opens a serial port and waits half a second to see if it's connected to a PC and the PC is requesting test mode (used for production testing).

This program, in fact, has three distinct sections. Of course, the IO pins are what they are on the board, and several methods are common to the three operating modes.

Here's a simplified version of my start-up code

pub main 

  term.start(RX1, TX1, %0000, 115_200)
  pause(10)

  term.rxflush                                                  ' remove start-up trash

  check := term.rxtime(500)
  if ((check == "t") or (check == "T"))                         ' test mode requested?
    test_mode
  else
    term.stop

  if (ina[RUN_MODE] == 1)
    run_mode_1
  else
    run_mode_0


pub test_mode

  repeat
    ' test code here


pub run_mode_1

  repeat
    ' mode 1 code here


pub run_mode_0

  repeat
    ' mode 0 code here

Clock Loop · 2013-07-30 19:01

I guess just dealing with dual pin configurations for the same prop eeprom is to have a base set of ID pins, (P0, P1) be id, if you only have a few props that need immediate ID.

After thinking about it... why not just program the configurations like each configuration is a spin object.
And run then like that too.

So the configuration is launched like an object......

' =========================================================================
'
'   File...... Hardware.spin
'   Purpose...  To run code depending on current hardware config.
'   Author....  Clock Loop @ parallax forums 
'   E-mail....  thereisnoelectron@gmail.com 
'   Started...  Jul-2013
'   Updated...  Jul-2013 
'
' =========================================================================
CON

  _clkmode = XINPUT + PLL16X
  _xinfreq = 5_000_000

  ID0         = 00    
  ID1         = 01  

OBJ
  Payload          : "HProg1 "    'Prop with pins in config 1 Payload is considered the prop that uses most pins and repeats most. P0, P1 should have weak pull downs on them for ID0 at initial boot.
  Caboose          : "HProg2 "    'Prop with pins in config 2  Caboose is the terminator prop that houses the pullup/down resistors, or other props that need ID.
      
PUB Start

  If Ina[ID0] == 0
    If Ina[ID1] == 0
      Payload.Start
  ElseIf Ina[ID0] == 1
    If Ina[ID1] == 1
      Caboose.Start

I just tested this method and it works perfectly, I tested it with 11 seperate props in one of two hardware configurations.

Using objects to help multiple connected props choose the correct program and run it.

Comments