for/next question
- Thread starter jims
- Start date
inglewoodpete
Senior Member
Three differences.
- The variable used for 0 to 717 must be a word. 0 to 239 can fit in a byte variable.
- Inside the loop (and on exit), the value in the loop counter differs (0, 3, 6...717 Vs. 0, 1, 2...239). Often the program will use the value in the counter for some purpose.
- The two commands (Next and For) occupy 9 bytes when using the byte variable option while the word version takes 12 bytes
Here are symbols used for the two counters. Jims
symbol counter1 = w6
symbol counter2 = w7
westaust55
Moderator
As I recall, with a FOR NEXT loop on exit the value in the index variable is one increment/step grater than the final value in the FOR line
I don't like to post a lot of code, but here's the program that gives a different result depending on the previous "for/next" statement. JimS
Code:
'**********************************************************
'* Picaxe 20x2 controls a 60 LED DotStar RGB strip.
'* Uses HSPI & Macros from Picae Technical sample programs.
'**********************************************************
; 20X2 +5V -.- Light strip
; .-----__-----. |
; | | `--> RED +V
' | B.7 |-----> SCK --------> YEL CK
; | C.1 |-----> SDO --------> GRN DI
; | | .--> BLK 0V
; | | 0V _|_
' | |
' | B.0 |<-------- CLICKER
' | B.1 |--------> OLED
' .------------.
Symbol OLED = B.1 'Pin 17.
symbol counter1 = w6
symbol counter2 = w7
symbol counter3 = w8
symbol red = b20
symbol green = b21
symbol blue = b22
Symbol HOW_MANY_LEDS = 60
'**************
'*** Macros ***
'**************
;** Initialise the HSPI interface
#macro init()
hspisetup spimode00, spifast
#endmacro
;** Send a four byte packet out via HSPI
#macro sendPacket( n1, n2, n3, n4 )
hspiout( n1, n2, n3, n4 )
#endmacro
;** Send the start of data header
#macro head()
sendPacket( $00, $00, $00, $00 )'#endmacro
#endmacro
;** Send a LED controlling command
#macro send( red, green, blue )
sendPacket( $FF, green,blue, red )
#endmacro
;** Send the end of data tail
#macro tail()
sendPacket( $FF, $FF, $FF, $FF )
#endmacro
#picaxe 20x2
settimer 1
pause 500 'Pause to Initialize system.
PowerOnReset:
init ; Initialise the HSPI interface
head ; Turn all LED modules off
for w0 = 1 To HOW_MANY_LEDS
send( $00, $00, $00 ) ; 1 to last = Off
next
tail ; Send the end of data tail
b20=1:b21=0:b22=0
Main:
do
call RunColors
stop
loop
'***************************************
'** Runs groups of colors thru strip &
'** changes color pattern in each group.
'***************************************
RunColors:
hspisetup spimode00, spifast
hspiout (0,0,0,0)
pause 100
hspiout (10,10,10,10,10,10,10,10,10,10,10,10)
'** Load values into scratchpad memory.
pause 100
gosub initlight 'send "head".
counter3 = 0
ptr = 0
for red = 6 to 1 step -3
green = 10 - red
@ptrinc = green
@ptrinc = blue
@ptrinc = red
counter3 = counter3 + 3
next red
for green = 6 to 1 step -3
blue = 10 - green
@ptrinc = green
@ptrinc = blue
@ptrinc = red
counter3 = counter3 + 3
next green
for blue = 6 to 1 step -3
red = 10 - blue
@ptrinc = green
@ptrinc = blue
@ptrinc = red
counter3 = counter3 + 3
next blue
counter1 = 0
counter3 = 0
start: '** Loop thru program.
for counter3 = 0 to 717 step 3
'for counter3 = 0 to 239
pause 50
gosub initlight 'HEAD
ptr = counter3
for counter2 = 0 to 60 'Sets where next gruop begins.
hspiout (255, @ptrinc, @ptrinc, @ptrinc)
next counter2
next counter3
tail
goto start
initlight: 'Sends "head".
hspiout (%00000000,%00000000,%00000000,%00000000)
returnelektriker
New Member
BUG in For-Next
It works fine in the Simulator, but not when you prog. a Chip.
testet whith 08M2.
#terminal 4800
symbol X=w5
symbol N=w0
for x=0 to 60000 step 10000
sertxd("N= ",#N," ",#x,cr,lf)
inc N
next x
sertxd(" END ",cr,lf)
end
It works fine in the Simulator, but not when you prog. a Chip.
testet whith 08M2.
#terminal 4800
symbol X=w5
symbol N=w0
for x=0 to 60000 step 10000
sertxd("N= ",#N," ",#x,cr,lf)
inc N
next x
sertxd(" END ",cr,lf)
end
That's probably where the problem is; ptr will be pointing some place else than it ought to, and then ptr is used to output data, hence different results. You can probably fix that with ...
ptr = counter3 * 3
It seems to work the same when I test it in PE6 simulation and in a 20X2.
It is more a feature of the PICAXE than a bug. The problem is that, with a 60000 value, adding 10000 takes it beyond 65535 which causes 16-bit roll-over and results in a value which is in the 0-60000 range which keeps the FOR-NEXT looping. However, a few loops later it should end up with a value greater than 60000 which terminates the FOR-NEXT loop.
Hippy...would you be willing to try my code (above) on your DotStar setup and use both iterations of the for/next to observe what is happening?? Thank you JimS
I'm not sure it's worth doing that given the nature of the problem.
If you have values A, B, C, D, E, F stored in scratchpad from location zero up, in the 'step 3' case the data initially sent to the first LED will be A,B,C the data to the second LED will be D,E,F. Next time round the data sent to the first LED will be D,E,F ( ptr starts at 3 )
In the other case, the second time round the data sent to the first LED will be B,C,D ( ptr starts at 1 ).
In the first case the LED colours should step towards the first LED. In the second I imagine there are some pretty odd colour changes happening.
If you have values A, B, C, D, E, F stored in scratchpad from location zero up, in the 'step 3' case the data initially sent to the first LED will be A,B,C the data to the second LED will be D,E,F. Next time round the data sent to the first LED will be D,E,F ( ptr starts at 3 )
In the other case, the second time round the data sent to the first LED will be B,C,D ( ptr starts at 1 ).
In the first case the LED colours should step towards the first LED. In the second I imagine there are some pretty odd colour changes happening.
Hippy... The thing that I don't understand is why with the (for counter3 = 0 to 717 step 3) statement, the group of colors steps smoothly from the outboard end of the strip toward the driven end; and with the (for counter3 = 0 to 239) statement they move in a very different jerking motion. JimS
lbenson
Senior Member
Code:
for green = 6 to 1 step -3
blue = 10 - green
@ptrinc = green
@ptrinc = blue
@ptrinc = red
counter3 = counter3 + 3
next green
premelec
Senior Member
@jims - I've been playing with 14M2 driving APA102 strip and the code from sniper887 didn't quite translate to my my bit banging output but I've gotten interesting results... I think part of the confusion is if you write over existing latched data in APA102 chips or start over or after blanking. I haven't tried an X2 chip yet. Good luck with it!
Perhaps you missed post #7 ?
The data for each LED is three bytes, so when ptr is being stepped to point to the first set if data to output it also has to step in increments of three ...
0 : A B C
3 : D E F
6 : G H I
To output A,B,C then ptr must be 0, to output D,E,F then ptr must be 3, to output G,H,I then ptr must be 6.
Apologies if the earlier post wasn't clear. Not having the light come on isn't a lack of smartness, more often just not seeing what's being said or, from the other side, a failure to explain fully or in a way which can be understood. I've been on both sides of those fences.
I am guessing you have figured it out now but if not do please say and I and I am sure others will do their best to help further.
I am guessing you have figured it out now but if not do please say and I and I am sure others will do their best to help further.
Thank you, Hippy...I understand it now and it works in my code. Good help!! Jims