Propeller code help
scurrier
Posts: 32
Hello all,
I am new to the Prop and trying to make a simple program to help me understand variables, addresses, duty cycles, and cogs.
I am trying to make an object that makes a series of LEDs in a row chase each other with a light pattern. I am using the LED setup with pins 4-9 that the PE kit uses. My intention for the object is that it would start as many cogs as the number of LEDs requires counters for (one per LED) to drive duty cycles. Then, the main method just updates the variable addresses of the variables that drive the FRQ for each counter. This enables the main object to easily control how bright each LED is almost directly. But, when I run the following test code below, when I use more than one cog, I find that the LEDs whose duty cycles I am trying to adjust stutter a bit. The duty cycle seems like it is working but it seems like there is some other frequency superimposed on top of it. The LEDs also seem to be a bit dim. Does anyone see why this might be? I suspect it has something to do with my repeat loops but I am new to the Prop and I can't find the problem. Thanks for helping me out. I am loving the Prop so far!
Thanks,
Shaun
I am new to the Prop and trying to make a simple program to help me understand variables, addresses, duty cycles, and cogs.
I am trying to make an object that makes a series of LEDs in a row chase each other with a light pattern. I am using the LED setup with pins 4-9 that the PE kit uses. My intention for the object is that it would start as many cogs as the number of LEDs requires counters for (one per LED) to drive duty cycles. Then, the main method just updates the variable addresses of the variables that drive the FRQ for each counter. This enables the main object to easily control how bright each LED is almost directly. But, when I run the following test code below, when I use more than one cog, I find that the LEDs whose duty cycles I am trying to adjust stutter a bit. The duty cycle seems like it is working but it seems like there is some other frequency superimposed on top of it. The LEDs also seem to be a bit dim. Does anyone see why this might be? I suspect it has something to do with my repeat loops but I am new to the Prop and I can't find the problem. Thanks for helping me out. I am loving the Prop so far!
Thanks,
Shaun
''DutyStream.spin CON _xinfreq = 5000000 _clkmode = xtal1 + pll16x OBJ Debug: "FullDuplexSerialPlus" VAR long stack[100], ledDutyCycle[14] PUB Main | size, index, cog[7], led[13], scale Debug.start(31, 30, 0, 57600) waitcnt(clkfreq*2 + cnt) Debug.tx(Debug#CLS) size := 6 'Specify the total number of LEDs, max of 14 (2 counters per 7 cogs) scale := 16_777_216 long[@ledDutyCycle][0] := 3000000000 long[@ledDutyCycle][1] := 3000000000 repeat index from 0 to 1 cognew(LightTwoLEDs(4+index*2,@ledDutyCycle[0],4+index*2+1,@ledDutyCycle[1]),@stack[index*20]) repeat repeat index from 0 to 255 long[@ledDutyCycle][0] := index * scale waitcnt(clkfreq/128 + cnt) PUB LightTwoLEDs(pina,dutyafreq,pinb,dutybfreq) | ratea, rateb 'Sets 2 LEDs to light with the specified duty cycle repeat ctra[30..26] := %00110 ' Set ctra to DUTY mode ctra[5..0] := pina ' Set ctra's APIN frqa := long[dutyafreq] ' Set frqa register dira[pina]~~ ctrb[30..26] := %00110 ' Set ctra to DUTY mode ctrb[5..0] := pinb ' Set ctra's APIN frqb := long[dutybfreq] ' Set frqa register dira[pinb]~~
Comments
A couple of things first off: When modifying local variables, as in your Main, you do not need to use long[@ to change the variable to the new number.
Just refer to it like this: ledDutyCycle[0] := 3000000000
When you get to the Repeats that will actually do the counter modification, it is not necessary to include the dira, ctra in the repeat, you can park those at the top so they run only once to start the counter and set the direction of the pin. Then, just repeat the frqa which is all that needs to get updated after the counters are launched.
Did you try getting the code to work on one cog before trying to run it on more?
Others will likely have some ideas well.
In my own troubleshooting, I did try to only run it on one cog (i used the index from 0 to 0). The problem did not occur when I did this. Strange, right? I am not sure why doing this on two cogs would be different from doing it on one.
FWIW, I ran this on the demoboard with 4 cogs (8 LEDs) and I couldn't observe any kind of stutter compared to a single cog run. What kind of LEDs are you using? I seem to remember (i.e. there was a thread about this) that blue LEDs behave slightly different from yellow ones in terms of DUTY response. Other than that there is no reason why it shouldn't work.
This is definitely separate from the different duty cycle response among colors. I have noticed that too and this is a separate phenomenon. I am using 2 each of 3 colors for reference. That is what came with my kit. If I wanted to get really fancy I'd make a map that would map each brightness to a duty cycle for the individual colors, but once my propeller development board comes they are all going to be blue so there will be no need.