@DiverBob Would you mind giving this version of the driver a try? I really want it to be color compatible with my other pixel drivers, so I changed to 8-bit colors, and I store the longs in the buffer in the order of $RR_GG_BB_xx. Under the hood, the movbyts instruction fixes the order (this is really cool), and then a shift right of the long reduces the color bytes to seven bits. The sync bits are added after, so no clean-up is required for the bits that move from bit0 of one byte to bit7 of another.
There is a set of color constants in this driver.
Thanks for trying this. I checked it with the logic analyzer and it appears to be working properly.
-- Jon
I ran the driver using the previous demo file you sent. It appears to still be working OK. It's hard to test all the color combinations as the blue LED is very faint but it does activate. The red and green are bright as long as they are the only ones active, if red and green are active then the green led is fairly faint. I wonder if this might be a +5v power draw issue coming off the eval board.
Anyway it does work, great work again!
Sorry, what I forgot to tell you is that this driver uses 8-bit colors going in -- the driver shifts them right by one bit to get back to 7 bits. I did this so that I can use the same color table as in my other drivers (WS2812, etc., and APA102c). If you have custom colors in your demo code, shift the color bytes left by one bit and things should be okay.
Also, the color order is like the other drivers: $RR_GG_BB_xx. I found the movbyts instruction today and it takes care of fixing the order to what the pixels want in a single line of code. It's fantastic.
Full red is $FF_00_00_00 into this driver; full green is $00_FF_00_00, blue is $00_00_FF_00. You get the idea. Thanks for trying the new code.
Comments
I ran the driver using the previous demo file you sent. It appears to still be working OK. It's hard to test all the color combinations as the blue LED is very faint but it does activate. The red and green are bright as long as they are the only ones active, if red and green are active then the green led is fairly faint. I wonder if this might be a +5v power draw issue coming off the eval board.
Anyway it does work, great work again!
Also, the color order is like the other drivers: $RR_GG_BB_xx. I found the movbyts instruction today and it takes care of fixing the order to what the pixels want in a single line of code. It's fantastic.
Full red is $FF_00_00_00 into this driver; full green is $00_FF_00_00, blue is $00_00_FF_00. You get the idea. Thanks for trying the new code.