Here are symbols used for the two counters. JimsThree 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
'**********************************************************
'* 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)
return
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 ...for counter3 = 0 to 717 step 3
'for counter3 = 0 to 239
:
ptr = counter3
It seems to work the same when I test it in PE6 simulation and in a 20X2.BUG in For-Next
It works fine in the Simulator, but not when you prog. a Chip.
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 JimSIt 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... 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. JimSI'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.
for green = 6 to 1 step -3
blue = 10 - green
@ptrinc = green
@ptrinc = blue
@ptrinc = red
counter3 = counter3 + 3
next green
Perhaps you missed post #7 ?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
Thank you, Hippy...I understand it now and it works in my code. Good help!! JimsApologies 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.