But what syntax should I use for turning off an LED with "strip.set"?
I have tried declaring a variable as byte in var, then giving it a value of 000000, but that still doesnt work.
I have also tried strip#black, strip.color(0,0,0), strip.colorx(0,0,0,0) without results
I think you better post your code.
The color method returns the color value as a long. It's doesn't directly change a LED.
JonnyMac's driver uses a buffer to store the color value of each LED in the strand.
long rgbbuf[MAX_LEDS] ' rgb buffer
You can retrieve the address of this buffer by using the "address" method.
Here's the code from my NeoPixel wheel project (I posted a link to the project earlier).
addr := strip.address
Once you have this address in the top object, you use longmove and longfill commands to move the values and change the values of the buffer.
Let's set LED #10 red.
long[addr][10] := strip#RED
Another way to turn all the LED off would be to use:
longfill(addr, 0, strip#MAX_LEDS)
Or do you want them all green?
longfill(addr, strip#GREEN, strip#MAX_LEDS)
You can use longmove to rotate the buffer. I have a "Rotate" method in the code I posted. Even though there's a lot of what looks like rotating my the video of the NeoPixels, I never end up call the "Rotate" method since the "Mirror" method does bulk of the long manipulations in the method. If I hadn't had the colors continually changing, I would have used the "Rotate" method to "spin" the colors around the wheel (or 16 longs of the buffer).
By having the address of the buffer, you can manipulate the longs as you like without needing to call any methods in the driver. Most of the methods in the driver are a convenience for manipulating the longs of the buffer.
There are methods in the object that handle filling all or a contiguous block of pixels with the same color.
pub set_all(rgb)
'' Sets all channels to rgb
'' -- rgb is packed long in form $RR_GG_BB
longfill(@rgbbuf, rgb, striplen)
pub fill(first, last, rgb)
'' Fills first through last channels with rgb
'' -- rgb is packed long in form $RR_GG_BB
if ((first < 0) or (first > last)) '
return 0
last <#= striplen-1
longfill(@rgbbuf[first], rgb, last-first+1)
I really need to go through my WS2801 and WS2811/12 drivers and unify all the method calls -- that way the same program could use either type. While commenting above, I decided I should all the first and last values to come in either order, hence I'm changing fill to this:
pub fill(first, last, rgb) | swap
'' Fills first through last channels with rgb
'' -- rgb is packed long in form $RR_GG_BB
first := 0 #> first <# striplen-1
last := 0 #> last <# striplen-1
if (first > last)
swap := first
first := last
last := swap
longfill(@rgbbuf[first], rgb, last-first+1)
I really need to go through my WS2801 and WS2811/12 drivers and unify all the method calls -- that way the same program could use either type.
That would be great. I had to make several changes when using a method from a WS2801 project in my WS28912 project. It wasn't a big deal though. It sure was a lot easier than writing the drivers myself (which I like to think I could have done, but I'm glad I didn't have to find out).
Awesome, I have a much better understanding now! That answered all my current Q's and probably the next few I was going to ask as well.
Thank you Thank you
I was able to easily accomplish the previous task of turning off the led's in reverse order of the rainbow method.
I am going to add more colors to the chakras and make a few more methods.
I might start working on unifying the calls, I see now how how this works
You are a very talented coder
Someday I'll get some time to learn a little asm, seems like that is the key to controlling time on the prop
Actually... one thing I am still trying to figure out.
how the final long package for the 24 bits is encoded.
previously I remember hearing the WS2811 reads by GGRRRBB.
From the wheelx method I see it is giving a 1-255 value to r,g & b... ie red value of $FF = 255 (full brightness) = 8 bytes
So the wheel/wheelx methods are packing this into a single long value and the asm code is interpreting this to the final signal?
How does the signal work to differentiate the different 2811 chips? for example how do you identify chip #38 in the chain? I see the explanation in the parent:
' Shifts long in colorbits to WS2812 chain
'
' WS2812 Timing (slot is 1.25us for 800kHz)
'
' 0  0.35us / 0.80us
' 1  0.70us / 0.60us
'
' At least 50us (reset) between frames
'
' This routine manipulates the value in colorbits so that elements are
' transmitted GRB as required by the WS2812. Rearrange-on-the-fly code
' trick by TonyP12 in the Propeller forum.
'
' Entry $00_RR_GG_BB
' Step 1 $BB_00_RR_GG
' Step 2-24 $GG_BB_00_RR - when nbits == 24
' $BB_00_RR_GG - after sending GG
' Step 2-16 $RR_GG_BB_00 - when nbits == 16
' $GG_BB_00_RR - after sending RR
' Step 2-8 $BB_00_RR_GG - when nbits == 8
So each chip is simply identified by extending the first pulse by 35us? i.e. chip #10 is 350us followed by 24 color bits, each bit separated by 1.25us?
That timing can only be accomplished with asm it seems?
There is no addressing in the data as the WS28xx chips are self addressing. After the reset period, the first device connected to the master will accept the first 24 bits in the stream and move those bits to its color registers. It then switches data in (and clock in for the WS2801) to the output so that the next device gets the stream. This will continue until the next reset period where all devices will be looking at their input(s) again.
The point is the devices are daisy-chained, they are not multi-drop.
[Master]---->[#0]
>[#1]
>[#2]
>[#3]----...
BTW... all of this this information is available in the data sheet(s). If you really want to understand the parts you should download and read them. I, like most programmers, don't waste time be rehashing every detail of the data sheet in my comments.
Actually... one thing I am still trying to figure out.
how the final long package for the 24 bits is encoded.
previously I remember hearing the WS2811 reads by GGRRRBB.
From the wheelx method I see it is giving a 1-255 value to r,g & b... ie red value of $FF = 255 (full brightness) = 8 bytes
So the wheel/wheelx methods are packing this into a single long value and the asm code is interpreting this to the final signal?
JonnyMac and others (myself included) use various RGB LED types which don't all pack colors the same way. Rather than rearrange the way colors are packed each time the control chip is changed it's easier on us humans to make the Propeller do the work of switching the colors around and just always pack them red, green, blue within the high level code. I've seen WS2801 strips with three different color packing orders (the colors are consistent within the strip though).
So JonnyMac packs the colors RRGGBB in the Spin code and lets the PASM portion shuffle the bits as needed (there's a thread about this). You can see his "color" method to see how the colors are packed in Spin. I have a method "BustColors" that stores the red, green and blue components of the color in three separate variables. I separate the colors to make them easier to manipulate individually. My "MergeColors" method comes up with an arbitrary set of transitional colors between any two starting colors. These transitional colors are generated by transitioning each of the individual color components.
The WS2811 chip doesn't have independent brightness control so the brightness needs to be done by proportionally reducing the values of all three colors. If your white is $FFFFFF, the half brightness white is $7F7F7F. You end up losing color depth by dimming the LEDs this way. For example what it you were really picky about how you wanted your white to look and decided $FFFFFE looked better. Now you want this new white displayed at 1/4 brightness. $FF/4 = $3F in integer math but $FE/4 also equals $3F. So what numbers to you use to display your new favorite white at one quarter brightness? Do you use $3F3F3F or $3F3F3E? $3F3F3E isn't the same color as $FFFFFE. I you use $3F3F3E, the dimmer white will have proportionally more red and green than the bright version ($FFFFFE) however is you use $3F3F3F, then the dimmer white will have proportionally more blue than $FFFFFE. This problem becomes more noticeable with very dim colors.
How does the signal work to differentiate the different 2811 chips? for example how do you identify chip #38 in the chain?
I'm don't know if this answer it true, but I'd be very surprised if it's not. Edit: See JonnyMac's post above. The answer below is correct.
The WS2811 uses the first 24-bit it receives and sends the rest on through to the next LED in line. This is the way many(most) shift registers work and many SPI devices can be daisy chained this way. Whenever the WS2811 sees a "reset" time of 50us, it knows to use the next 24-bits and any other bits it receives without a reset pause, it just passes on through.
So if you only want to change the color of LED #100 of your stand, the Propeller has to send the old color information to the other 99 LEDs while it's sending the new color information to LED 100.
So each chip is simply identified by extending the first pulse by 35us? i.e. chip #10 is 350us followed by 24 color bits, each bit separated by 1.25us?
That timing can only be accomplished with asm it seems?
No, all the pulses will be either 0.35us or 0.70us long. The chip will use the first 24-bits and pass the rest of the bits on to its "out" pin.
So if you only want to change the color of LED #100 of your stand, the Propeller has to send the old color information to the other 99 LEDs while it's sending the new color information to LED 100.
This is why I tend to make my drivers auto-refresh; it allows me to change the buffer at will and not worry about anything else. BTW, this is how DMX works, too (though that does use multi-drop hardware): in every frame all channel values, whether they've changed or not, are broadcast.
This is why I tend to make my drivers auto-refresh; it allows me to change the buffer at will and not worry about anything else. BTW, this is how DMX works, too (though that does use multi-drop hardware): in every frame all channel values, whether they've changed or not, are broadcast.
I do this as well with my LED projects where I've written the driver. The lower level code just keeps reading the same section of memory and whatever colors are in the memory are displayed. The high level code just takes care of putting colors in these memory locations.
That timing can only be accomplished with asm it seems?
I forgot to mention, I have some links to PASM tutorials in post #3 of my index.
I finally started understanding how to use PASM with the Propeller from working through some of JonnyMac's example code in his SpinZone articles. Once you've flashed a LED with PASM, you'll be on your way to unleashing the power of PASM on the Propeller.
That timing can only be accomplished with asm it seems?
Yes, the only way to do sub-microsecond timing is with PASM, but the Propeller makes it easy (once you understand the Propeller and PASM, that is). You should see the hoops and contortions Arduino users go through trying to drive the WS2811/12 -- and they don't get auto refreshing!
trying to figure out how to increment a hex value, or convert a decimal value to hex so I can do fading without having to call strip.color or strip.colorx
trying to figure out how to increment a hex value, or convert a decimal value to hex so I can do fading without having to call strip.color or strip.colorx
Hex and decimal values are just for us humans. They're just different ways to display the same number. The Prop doesn't store them differently.
The exception to this rule is floating point numbers. Floating point numbers are packed in a long differently than other numbers but you don't need to worry about that here.
Hex are useful since a single byte can always be displayed as two digits and a long is always eight digits. It's easier on us humans to read $FF0000 for red than trying to figure out what color 16,711,680 is (it's the same color).
My NeoPixel ring code should work on your ring of LEDs. I hope you give it a try. You just need to change a few constants to match your configuration.
trying to figure out how to increment a hex value, or convert a decimal value to hex so I can do fading without having to call strip.color or strip.colorx
Nice job! I can't wait to get mine setup. I just received two Neo Rings from Adafruit.
WS2812 strip are cool. I'm using a load of them in my projects. But at 144 In series, not sure you'll get the refresh rate of the strip high enough to light paint. You may want to split the strips serial line into two or three, to improve performance. It would be good to know if you achieve good results at 1 continuous strip.
I recently did a project with 180 WS2801 LEDs -- which are slower than WS2812s -- that had a refresh rate of 300Hz. No problems. It was for a costume for Limp Bizkit guitarist, Wes Borland, and is touring the world now. Yes, the Propeller goes on stage with Limp Bizkit.
I have this list (mostly from others) in my WS2812 driver.
con
' borrowed from Gavin Garner's TM1804 LED driver
' -- additional colors by Lachlan
' -- some alterations by JM
' RR GG BB
BLACK = $00_00_00
RED = $FF_00_00
GREEN = $00_FF_00
BLUE = $00_00_FF
WHITE = $FF_FF_FF
CYAN = $00_FF_FF
MAGENTA = $FF_00_FF
YELLOW = $FF_FF_00
CHARTREUSE = $7F_FF_00
ORANGE = $FF_60_00
AQUAMARINE = $7F_FF_D4
PINK = $FF_5F_5F
TURQUOISE = $3F_E0_C0
REALWHITE = $C8_FF_FF
INDIGO = $3F_00_7F
VIOLET = $BF_7F_BF
MAROON = $32_00_10
BROWN = $0E_06_00
CRIMSON = $DC_28_3C
PURPLE = $8C_00_FF
For another project I'm teaching myself to program in Processing. One of my target ideas is a little WS2812 controller app that allows one to experiment with color and brightness in real time.
I have this list (mostly from others) in my WS2812 driver.
For another project I'm teaching myself to program in Processing. One of my target ideas is a little WS2812 controller app that allows one to experiment with color and brightness in real time.
[Edit] I see that Duane types faster than I do.
In real time hey? You know that is what we do with Tachyon right out of the box. Change patterns,speed, colors,brightness, and directly manipulate the buffer, all interactively and in real time.
I have this list (mostly from others) in my WS2812 driver.
OK, you guys(jonnymac and duane) got me, I did not dig deep enough into the code to find it! Thanks for pointing out what I should have seen.
Jim
con
' borrowed from Gavin Garner's TM1804 LED driver
' -- additional colors by Lachlan
' -- some alterations by JM
' RR GG BB
BLACK = $00_00_00
RED = $FF_00_00
GREEN = $00_FF_00
BLUE = $00_00_FF
WHITE = $FF_FF_FF
CYAN = $00_FF_FF
MAGENTA = $FF_00_FF
YELLOW = $FF_FF_00
CHARTREUSE = $7F_FF_00
ORANGE = $FF_60_00
AQUAMARINE = $7F_FF_D4
PINK = $FF_5F_5F
TURQUOISE = $3F_E0_C0
REALWHITE = $C8_FF_FF
INDIGO = $3F_00_7F
VIOLET = $BF_7F_BF
MAROON = $32_00_10
BROWN = $0E_06_00
CRIMSON = $DC_28_3C
PURPLE = $8C_00_FF
For another project I'm teaching myself to program in Processing. One of my target ideas is a little WS2812 controller app that allows one to experiment with color and brightness in real time.
I'm sure this is just the tip of the iceberg on what's been done with Spin (and C) for real time control.
Though I suspect Forth may off some advantages since (as far as I know) one doesn't need to compile a program (other than Forth itself) to start manipulating the hardware (and apparently buffers?).
Sorry Duane, I caint read them there numbers because them shiny round whosy mawatchits jus dun burnt out ma eyeballs from der sockits
Are you competing with Jon in doing show props too?
The difference between doing the "same thing" in Spin and other "languages" compared to Forth is that Forth is target resident and already has the command shell built in and so every little function is individually accessible by name and able to be built into higher level functions. The buffer manipulation is a given in that we can read, edit, fill, and move any part of memory from the command line or from "macros" which are of course just higher level functions built upon the lower levels. So many times I will create a quick one-liner just to test out some part or idea and then refine it bit by bit, all within seconds. When you get this kind of instant and responsive feedback it really adds to the experience, both in learning, and in enjoyment. Tachyon allows "compile time only" constructs such as loops to be executed straight from the command line, so there isn't even any need to define a word and invoke it, just type and hit enter.
BTW, Tachyon drives the LEDs from the same cog as the command shell, there is no need to dedicate a cog for this like we have to in Spin.
In real time hey? You know that is what we do with Tachyon right out of the box. Change patterns,speed, colors,brightness, and directly manipulate the buffer, all interactively and in real time.
When you write a book on programming the Propeller in Tachyon -- and demonstrate full applications (which I know you can) -- I'll start using it. Until then, it's an interesting oddball that I cannot find the time to master.
The difference between doing the "same thing" in Spin and other "languages" compared to Forth is that Forth is target resident and already has the command shell built in and so every little function is individually accessible by name and able to be built into higher level functions. The buffer manipulation is a given in that we can read, edit, fill, and move any part of memory from the command line or from "macros" which are of course just higher level functions built upon the lower levels. So many times I will create a quick one-liner just to test out some part or idea and then refine it bit by bit, all within seconds. When you get this kind of instant and responsive feedback it really adds to the experience, both in learning, and in enjoyment. Tachyon allows "compile time only" constructs such as loops to be executed straight from the command line, so there isn't even any need to define a word and invoke it, just type and hit enter.
With respect, saying "Tachyon is the answer to your ills...." is like saying "Swahili is easy!" in Swahili to a non-Swahili speaker. I think you take for granted how much you know that isn't obvious to others, having created the language from scratch. If you want others to use Tachyon (which seems to be the case as you promote it as a useful tool), I hope you spend some energy teaching us to use it as opposed to throwing out and example and saying, "Here, reverse-engineer this."
BTW, Tachyon drives the LEDs from the same cog as the command shell, there is no need to dedicate a cog for this like we have to in Spin.
But what if I want to use a separate cog? My impression is that Tachyon is somewhat dictatorial in its approach. I could be wrong. Again, I want to learn to use Tachyon, but at the moment, anyway, I see it as an interesting novelty instead of a tool that I can use to solve real problems.
Putting my money where my mouth is, I just ordered a print copy of the latest edition of "Thinking Forth." Next up, I want, "Working with Tachyon"
I have never worked with Forth before,
and have learnt most of my PASM while reading the Tachyon kernel source.
I have to admit for a 'infix' programmer it takes a while, especially the explicit dealing with the stack.
But what you can accomplish is really fantastic.
I have a dynamic webserver with JSON running on top of Peter's base system.
So don't wait for the BOOK. Start with the INTRODUCTION
And the forum is here for you as well ;-)
The difference between doing the "same thing" in Spin and other "languages" compared to Forth is that Forth is target resident and already has the command shell built in and so every little function is individually accessible by name and able to be built into higher level functions. The buffer manipulation is a given in that we can read, edit, fill, and move any part of memory from the command line or from "macros" which are of course just higher level functions built upon the lower levels.
You were too fast. I had hoped to delete the post before anyone saw it.
I had a feeling you weren't just boasting of "real time control" of the LEDs.
When you write a book on programming the Propeller in Tachyon -- and demonstrate full applications (which I know you can) -- I'll start using it. Until then, it's an interesting oddball that I cannot find the time to master.
With respect, saying "Tachyon is the answer to your ills...." is like saying "Swahili is easy!" in Swahili to a non-Swahili speaker. I think you take for granted how much you know that isn't obvious to others, having created the language from scratch. If you want others to use Tachyon (which seems to be the case as you promote it as a useful tool), I hope you spend some energy teaching us to use it as opposed to throwing out and example and saying, "Here, reverse-engineer this."
But what if I want to use a separate cog? My impression is that Tachyon is somewhat dictatorial in its approach. I could be wrong. Again, I want to learn to use Tachyon, but at the moment, anyway, I see it as an interesting novelty instead of a tool that I can use to solve real problems.
Putting my money where my mouth is, I just ordered a print copy of the latest edition of "Thinking Forth." Next up, I want, "Working with Tachyon"
That's an idea, "Working with Tachyon Forth" and publish it in Swahili as "Kufanya kazi na Tachyon Forth"
I find any language a challenge first off, but like learning to ride a bike once you get the hang of it then the rest comes naturally and it gets easier and easier. Although Tachyon is a dialect of Forth because it is Propeller specific it is still Forth and there are books out there that help with the basics. I did do the intro page as training wheels if you like for learning to ride this Tachyon bike much like I learnt Spin and PASM from the tutorials in the early Prop manuals. But like a lot of this material it really needs feedback on what can be added and improved from a learners point of view, and that is something I have waited ready to act on but have for all practical purposes not received. That is where questions in the forum help me to add or change sections in this intro.
As for full applications I have been forth-coming in this regard and taken a few select working apps and published them. I did this as I find many "demos" rarely live up to a user's expectations as there are all kinds of limitations. Even though I have some images and diagrams in these documents along with many comments I guess the apps could also do with a "user manual" and overview. But unless I get some feedback I find it difficult to push myself to spend time on something that nobody is interested in.
You know that I promote Tachyon in the same way that all of us promote the Propeller. We find the Prop such a powerful chip, fun to use, quirky perhaps, especially to the uninitiated (wot! no interrupts!). When we know more, shall we say "fun" ways of doing things, then we like to share that with others. Fun is more fun when others are having fun too. The fact that I developed Tachyon is almost personally immaterial to me but I get to have fun with this language-O/S first and then I share it not only for fun but also in response to the frustrations and limitations I come across on the forum. Blinkys and Hello Worlds are instant and practical networked apps are not only feasible with limited resources but are of course a reality rather than a novelty.
BTW, of course you can run the WS2812 driver in its own cog the same way you run it in the main cog, so unlike Spin which is dictatorial in that "YOU MUST RUN THIS IN ANOTHER COG", Tachyon allows you to choose.
BTW, "Thinking Forth" is a great read for writing programs in any language as it stresses choosing simplicity over complexity when considering functionally equal approaches, and like one of the cartoons in there it puts the dog in the cage rather than ourselves, not just in terms of security, but in terms of control.
You know that I promote Tachyon in the same way that all of us promote the Propeller.
That wasn't a criticism on my part -- I really want to master Tachyon.
I was recently in a discussion with a guy who builds movie props (for major blockbusters that you've probably seen). After setting him straight on what the Propeller is, he got very excited and at one point in our conversation mentioned it would be cool if he could program it in Forth. "You can!" I exclaimed, and told him the little I understand about Tachyon.
The most humorous part of our conversation was when he told me in several cases he had to link three or four of his little PIC boards together, and it was a big headache. I responded with, "So you're not against multi-core, you'd rather just do it the hard way!" Thankfully, my jest elicited the laugh I had hoped for, and I think in future he will be using the Propeller. I designed a smallish (5cm x 5cm) version of my Propeller Platform that I'm hoping will strike his fancy.
Comments
I think you better post your code.
The color method returns the color value as a long. It's doesn't directly change a LED. should turn off LED #10
should turn off all the LEDs.
You can retrieve the address of this buffer by using the "address" method.
Here's the code from my NeoPixel wheel project (I posted a link to the project earlier).
Once you have this address in the top object, you use longmove and longfill commands to move the values and change the values of the buffer.
Let's set LED #10 red.
Another way to turn all the LED off would be to use:
Or do you want them all green?
You can use longmove to rotate the buffer. I have a "Rotate" method in the code I posted. Even though there's a lot of what looks like rotating my the video of the NeoPixels, I never end up call the "Rotate" method since the "Mirror" method does bulk of the long manipulations in the method. If I hadn't had the colors continually changing, I would have used the "Rotate" method to "spin" the colors around the wheel (or 16 longs of the buffer).
By having the address of the buffer, you can manipulate the longs as you like without needing to call any methods in the driver. Most of the methods in the driver are a convenience for manipulating the longs of the buffer.
pub set_all(rgb) '' Sets all channels to rgb '' -- rgb is packed long in form $RR_GG_BB longfill(@rgbbuf, rgb, striplen) pub fill(first, last, rgb) '' Fills first through last channels with rgb '' -- rgb is packed long in form $RR_GG_BB if ((first < 0) or (first > last)) ' return 0 last <#= striplen-1 longfill(@rgbbuf[first], rgb, last-first+1)pub fill(first, last, rgb) | swap '' Fills first through last channels with rgb '' -- rgb is packed long in form $RR_GG_BB first := 0 #> first <# striplen-1 last := 0 #> last <# striplen-1 if (first > last) swap := first first := last last := swap longfill(@rgbbuf[first], rgb, last-first+1)That would be great. I had to make several changes when using a method from a WS2801 project in my WS28912 project. It wasn't a big deal though. It sure was a lot easier than writing the drivers myself (which I like to think I could have done, but I'm glad I didn't have to find out).
Thank you Thank you
I was able to easily accomplish the previous task of turning off the led's in reverse order of the rainbow method.
I am going to add more colors to the chakras and make a few more methods.
I might start working on unifying the calls, I see now how how this works
You are a very talented coder
Someday I'll get some time to learn a little asm, seems like that is the key to controlling time on the prop
how the final long package for the 24 bits is encoded.
previously I remember hearing the WS2811 reads by GGRRRBB.
From the wheelx method I see it is giving a 1-255 value to r,g & b... ie red value of $FF = 255 (full brightness) = 8 bytes
So the wheel/wheelx methods are packing this into a single long value and the asm code is interpreting this to the final signal?
How does the signal work to differentiate the different 2811 chips? for example how do you identify chip #38 in the chain? I see the explanation in the parent:
So each chip is simply identified by extending the first pulse by 35us? i.e. chip #10 is 350us followed by 24 color bits, each bit separated by 1.25us?
That timing can only be accomplished with asm it seems?
The point is the devices are daisy-chained, they are not multi-drop.
[Master]---->[#0]
>[#1]
>[#2]
>[#3]----...
BTW... all of this this information is available in the data sheet(s). If you really want to understand the parts you should download and read them. I, like most programmers, don't waste time be rehashing every detail of the data sheet in my comments.
JonnyMac and others (myself included) use various RGB LED types which don't all pack colors the same way. Rather than rearrange the way colors are packed each time the control chip is changed it's easier on us humans to make the Propeller do the work of switching the colors around and just always pack them red, green, blue within the high level code. I've seen WS2801 strips with three different color packing orders (the colors are consistent within the strip though).
So JonnyMac packs the colors RRGGBB in the Spin code and lets the PASM portion shuffle the bits as needed (there's a thread about this). You can see his "color" method to see how the colors are packed in Spin. I have a method "BustColors" that stores the red, green and blue components of the color in three separate variables. I separate the colors to make them easier to manipulate individually. My "MergeColors" method comes up with an arbitrary set of transitional colors between any two starting colors. These transitional colors are generated by transitioning each of the individual color components.
The WS2811 chip doesn't have independent brightness control so the brightness needs to be done by proportionally reducing the values of all three colors. If your white is $FFFFFF, the half brightness white is $7F7F7F. You end up losing color depth by dimming the LEDs this way. For example what it you were really picky about how you wanted your white to look and decided $FFFFFE looked better. Now you want this new white displayed at 1/4 brightness. $FF/4 = $3F in integer math but $FE/4 also equals $3F. So what numbers to you use to display your new favorite white at one quarter brightness? Do you use $3F3F3F or $3F3F3E? $3F3F3E isn't the same color as $FFFFFE. I you use $3F3F3E, the dimmer white will have proportionally more red and green than the bright version ($FFFFFE) however is you use $3F3F3F, then the dimmer white will have proportionally more blue than $FFFFFE. This problem becomes more noticeable with very dim colors.
I'm don't know if this answer it true, but I'd be very surprised if it's not. Edit: See JonnyMac's post above. The answer below is correct.
The WS2811 uses the first 24-bit it receives and sends the rest on through to the next LED in line. This is the way many(most) shift registers work and many SPI devices can be daisy chained this way. Whenever the WS2811 sees a "reset" time of 50us, it knows to use the next 24-bits and any other bits it receives without a reset pause, it just passes on through.
So if you only want to change the color of LED #100 of your stand, the Propeller has to send the old color information to the other 99 LEDs while it's sending the new color information to LED 100.
No, all the pulses will be either 0.35us or 0.70us long. The chip will use the first 24-bits and pass the rest of the bits on to its "out" pin.
This is why I tend to make my drivers auto-refresh; it allows me to change the buffer at will and not worry about anything else. BTW, this is how DMX works, too (though that does use multi-drop hardware): in every frame all channel values, whether they've changed or not, are broadcast.
I do this as well with my LED projects where I've written the driver. The lower level code just keeps reading the same section of memory and whatever colors are in the memory are displayed. The high level code just takes care of putting colors in these memory locations.
I forgot to mention, I have some links to PASM tutorials in post #3 of my index.
I finally started understanding how to use PASM with the Propeller from working through some of JonnyMac's example code in his SpinZone articles. Once you've flashed a LED with PASM, you'll be on your way to unleashing the power of PASM on the Propeller.
Yes, the only way to do sub-microsecond timing is with PASM, but the Propeller makes it easy (once you understand the Propeller and PASM, that is). You should see the hoops and contortions Arduino users go through trying to drive the WS2811/12 -- and they don't get auto refreshing!
http://youtu.be/MHSLtuAXanY
trying to figure out how to increment a hex value, or convert a decimal value to hex so I can do fading without having to call strip.color or strip.colorx
You're hooked now.
Hex and decimal values are just for us humans. They're just different ways to display the same number. The Prop doesn't store them differently.
The exception to this rule is floating point numbers. Floating point numbers are packed in a long differently than other numbers but you don't need to worry about that here.
Hex are useful since a single byte can always be displayed as two digits and a long is always eight digits. It's easier on us humans to read $FF0000 for red than trying to figure out what color 16,711,680 is (it's the same color).
My NeoPixel ring code should work on your ring of LEDs. I hope you give it a try. You just need to change a few constants to match your configuration.
Nice job! I can't wait to get mine setup. I just received two Neo Rings from Adafruit.
[video=youtube_share;ZTBjf-bPCJg]
Jim
Jon's driver includes a list of colors.
There's obviously a typo on his "WHITE". I imagine it should be "$FF_FF_FF".
Is this what you had in mind?
For another project I'm teaching myself to program in Processing. One of my target ideas is a little WS2812 controller app that allows one to experiment with color and brightness in real time.
[Edit] I see that Duane types faster than I do.
In real time hey? You know that is what we do with Tachyon right out of the box. Change patterns,speed, colors,brightness, and directly manipulate the buffer, all interactively and in real time.
Sorry Duane, I caint read them there numbers because them shiny round whosy mawatchits jus dun burnt out ma eyeballs from der sockits
Are you competing with Jon in doing show props too?
The difference between doing the "same thing" in Spin and other "languages" compared to Forth is that Forth is target resident and already has the command shell built in and so every little function is individually accessible by name and able to be built into higher level functions. The buffer manipulation is a given in that we can read, edit, fill, and move any part of memory from the command line or from "macros" which are of course just higher level functions built upon the lower levels. So many times I will create a quick one-liner just to test out some part or idea and then refine it bit by bit, all within seconds. When you get this kind of instant and responsive feedback it really adds to the experience, both in learning, and in enjoyment. Tachyon allows "compile time only" constructs such as loops to be executed straight from the command line, so there isn't even any need to define a word and invoke it, just type and hit enter.
BTW, Tachyon drives the LEDs from the same cog as the command shell, there is no need to dedicate a cog for this like we have to in Spin.
When you write a book on programming the Propeller in Tachyon -- and demonstrate full applications (which I know you can) -- I'll start using it. Until then, it's an interesting oddball that I cannot find the time to master.
With respect, saying "Tachyon is the answer to your ills...." is like saying "Swahili is easy!" in Swahili to a non-Swahili speaker. I think you take for granted how much you know that isn't obvious to others, having created the language from scratch. If you want others to use Tachyon (which seems to be the case as you promote it as a useful tool), I hope you spend some energy teaching us to use it as opposed to throwing out and example and saying, "Here, reverse-engineer this."
But what if I want to use a separate cog? My impression is that Tachyon is somewhat dictatorial in its approach. I could be wrong. Again, I want to learn to use Tachyon, but at the moment, anyway, I see it as an interesting novelty instead of a tool that I can use to solve real problems.
Putting my money where my mouth is, I just ordered a print copy of the latest edition of "Thinking Forth." Next up, I want, "Working with Tachyon"
see last line of Peter's footer ...
I have never worked with Forth before,
and have learnt most of my PASM while reading the Tachyon kernel source.
I have to admit for a 'infix' programmer it takes a while, especially the explicit dealing with the stack.
But what you can accomplish is really fantastic.
I have a dynamic webserver with JSON running on top of Peter's base system.
So don't wait for the BOOK. Start with the INTRODUCTION
And the forum is here for you as well ;-)
You were too fast. I had hoped to delete the post before anyone saw it.
I had a feeling you weren't just boasting of "real time control" of the LEDs.
That's an idea, "Working with Tachyon Forth" and publish it in Swahili as "Kufanya kazi na Tachyon Forth"
I find any language a challenge first off, but like learning to ride a bike once you get the hang of it then the rest comes naturally and it gets easier and easier. Although Tachyon is a dialect of Forth because it is Propeller specific it is still Forth and there are books out there that help with the basics. I did do the intro page as training wheels if you like for learning to ride this Tachyon bike much like I learnt Spin and PASM from the tutorials in the early Prop manuals. But like a lot of this material it really needs feedback on what can be added and improved from a learners point of view, and that is something I have waited ready to act on but have for all practical purposes not received. That is where questions in the forum help me to add or change sections in this intro.
As for full applications I have been forth-coming in this regard and taken a few select working apps and published them. I did this as I find many "demos" rarely live up to a user's expectations as there are all kinds of limitations. Even though I have some images and diagrams in these documents along with many comments I guess the apps could also do with a "user manual" and overview. But unless I get some feedback I find it difficult to push myself to spend time on something that nobody is interested in.
You know that I promote Tachyon in the same way that all of us promote the Propeller. We find the Prop such a powerful chip, fun to use, quirky perhaps, especially to the uninitiated (wot! no interrupts!). When we know more, shall we say "fun" ways of doing things, then we like to share that with others. Fun is more fun when others are having fun too. The fact that I developed Tachyon is almost personally immaterial to me but I get to have fun with this language-O/S first and then I share it not only for fun but also in response to the frustrations and limitations I come across on the forum. Blinkys and Hello Worlds are instant and practical networked apps are not only feasible with limited resources but are of course a reality rather than a novelty.
So Jon, how about submitting an outline of contents for "Kufanya kazi na Tachyon Forth" ? (Here is a link to a document anyone can edit)
BTW, of course you can run the WS2812 driver in its own cog the same way you run it in the main cog, so unlike Spin which is dictatorial in that "YOU MUST RUN THIS IN ANOTHER COG", Tachyon allows you to choose.
BTW, "Thinking Forth" is a great read for writing programs in any language as it stresses choosing simplicity over complexity when considering functionally equal approaches, and like one of the cartoons in there it puts the dog in the cage rather than ourselves, not just in terms of security, but in terms of control.
That wasn't a criticism on my part -- I really want to master Tachyon.
I was recently in a discussion with a guy who builds movie props (for major blockbusters that you've probably seen). After setting him straight on what the Propeller is, he got very excited and at one point in our conversation mentioned it would be cool if he could program it in Forth. "You can!" I exclaimed, and told him the little I understand about Tachyon.
The most humorous part of our conversation was when he told me in several cases he had to link three or four of his little PIC boards together, and it was a big headache. I responded with, "So you're not against multi-core, you'd rather just do it the hard way!" Thankfully, my jest elicited the laugh I had hoped for, and I think in future he will be using the Propeller. I designed a smallish (5cm x 5cm) version of my Propeller Platform that I'm hoping will strike his fancy.