Simple Spin Question

Kirk Fraser · 2013-09-05 12:37

Why does this code execute only once and not repeat?

''Turn on LED at pin
PUB LedOn
   dira[4] := 1 
   dira[5] := 1 
   dira[27] := 1 
   repeat              
     outa[4] := 1           
     outa[5] := 1                   '
     outa[27] := 1

Thanks.

doggiedoc · 2013-09-05 12:45

Hi Kirk!

To get code to repeat you'll need instruction for a loop. Spin has a built in command 'repeat' that works nicely. I'll find you a link to the synopsis.

Doc

EDIT: I missed the REPEAT in the middle of your code. Doh! Let me come up with a better answer.

doggiedoc · 2013-09-05 12:49

It appears to be repeating fine. It looks like you need to set the pins to low and high again with enough pause between to visualize the repetitions - assuming an LED at each pin.

Hope this helps.

JonnyMac · 2013-09-05 12:57

As Doc points out, you're not making the pins go high and low. Here's another approach

dira[4] := 1
  dira[5] := 1
  dira[27] := 1
  repeat
    !outa[4]
    !outa[5]
    ![outa[27]
    waitcnt(cnt + (clkfreq >> 1))

This toggles your bits and inserts a 1/2s delay in between (so you can see it).

BTW... try to avoid the bad habit of using pin numbers in your code like this; used named constants instead. Easier to read, update, and troubleshoot.

Kirk Fraser · 2013-09-05 13:46

I don't care if I see flashes, solid on is fine.
This works on all 3 pins when executed separately:

PUB LedOn                          ' Method declaration
                                        
    dira[5] := 1                   ' Set P to output
    outa[5] := 1                   ' Set P high

    repeat                         ' Endless loop prevents program from ending

But this appeared to work once or twice but more often fails to repeat and seems to revert to an old program stored in EEPROM after it runs once. I must have a short somewhere, sorry. Any idea what short would cause that behavior?? Thanks.

PUB LedOn

  dira[4] := 1
  dira[5] := 1
  dira[27] := 1
  repeat
    !outa[4]
    !outa[5]
    !outa[27]
    waitcnt(cnt + (clkfreq >> 1))

Or possibly another problem. When I try to run the combined 3 pin program it appears to do nothing for a while then pin 4 flashes for a while with the others off. Then when I run the individual program they all work fine. Then when I run the 3 pin program same story.

So it can't be a simple short since it's on a table and nothing wiggles during or between runs. Is it a bug in my Prop? How could it choose to switch between working and not working repeatedly for these two programs with no hardware changes?

Ariba · 2013-09-05 14:08

Sounds like a hardware problem. Which board do you use?

If the program in EEPROM is started then you had a Reset. The reason may be that the supply voltage goes too low when all 3 LEDs are on. (low Battery?).

Andy

tonyp12 · 2013-09-05 14:10

>This works on all 3 pins when executed separately

You can NOT have repeat (forever) inside PUB Subroutines.
Only the master routine can repeat forever.

doggiedoc · 2013-09-05 14:38

If your goal for the subroutine is just to turn on the LED as an indicator - you don't need to have a repeat. Sorry I assumed you wanted it to flash. The pin will remain high after you set it that way-- until it is set to low or to an input somewhere else in the program.

Doc

Duane Degn · 2013-09-05 14:44

doggiedoc wrote: »

If your goal for the subroutine is just to turn on the LED as an indicator - you don't need to have a repeat. Sorry I assumed you wanted it to flash. The pin will remain high after you set it that way-- until it is set to low or to an input somewhere else in the program.

Doc

Or if the program runs out of code.

You'll want a repeat somewhere in the code to keep it alive (all of the programs Kirk posted so far include a repeat so this shouldn't be the problem).

Kirk, you might want to load the programs to EEPROM (F11) while testing. Sometimes a PC can cause a Prop attached via USB to reset without a good reason.

Bean · 2013-09-05 14:57

Possibly you are drawing too much current from the propeller pins and causing the propeller chip to reset (erasing your program from RAM).

Do you have resistors on the LEDs ?

Bean

Kirk Fraser · 2013-09-05 15:46

Yes guys I think that's it, a low voltage drain off the pins with the other hardware. When running the single pin program on the Propeller Project Board, it has enough juice on the USB to drive the extra LED's (w/o resistors) but when running the 3 LED program control must flow to each iteratively so there is less constant power on each pin and that probably causes the reset which then runs the EEPROM program with poor brightness on one LED and none on the others. When I applied 12V to some of the rest of the circuit to test some transistors, the program in EEPROM appears to work nicely with the LED's.

Now I have to keep tracing as nothing is showing on my transistor LED's which have resistors. Could be i need to put them on 24 volts to see anything or keep debugging.

Thank you all.

tonyp12 · 2013-09-05 15:53

You should put a 470 ohm resistor on each pin, as 5mA is good for most LEDs.

Duane Degn · 2013-09-05 16:06

Kirk Fraser wrote: »

When I applied 12V to some of the rest of the circuit to test some transistors, the program in EEPROM appears to work nicely with the LED's.

Now I have to keep tracing as nothing is showing on my transistor LED's which have resistors. Could be i need to put them on 24 volts to see anything or keep debugging.

Kirk, It would probably be a good idea to post a schematic (or at least a good description) of how your transistors are connected.

tonyp12 wrote: »

You should put a 470 ohm resistor on each pin, as 5mA is good for most LEDs.

As Tony mentioned, you want to use resistors when powering LEDs from a Prop I/O pin. I generally use 100 ohm since that's what the tutorial I read suggested. A single Prop pin shouldn't source or sink more than 40ma. There's also a limit for the overall current (which I don't recall).

__red__ · 2013-09-05 20:18

tonyp12 wrote: »

>This works on all 3 pins when executed separately

You can NOT have repeat (forever) inside PUB Subroutines.
Only the master routine can repeat forever.

Is this really true? Seems like a weird limitation.

If it is, I can't find a reference to it in the Manual (I'd expect to see it on P189)

Duane Degn · 2013-09-05 21:40

__red__ wrote: »

Is this really true? Seems like a weird limitation.

If it is, I can't find a reference to it in the Manual (I'd expect to see it on P189)

Tony should have said only one repeat forever per cog.

Each cog can only execute one branch of code at a time so it can't be running two continuous loops at once. A single cog can pause one loop and execute a second for a while and then continue with the first but the loops have to occur one at a time inside a single cog.

You can have up to eight continuous loops at once by using other cogs.

Could you imagine how crippling it would be for a microcontroller to only be allowed one continuous loop? How limiting.

Heater. · 2013-09-07 06:13

Of course you can have repeat loops in any routines you like. It just means they will never return and whatever code you think should be happening next will not happen.

For example you might have a method that sets up a load of stuff and then for whatever reason calls another method that contains the repeat loop ("forever loop") of your application. Or you might have the initialization in its own method and you end up with something looking like:

init()
run()  ' This never returns.

Simple Spin Question

Comments