I do not know if there is a 16bit version of the chip but I wonder why you need more steps (meaning more MCU power hungry code).
Aren't smooth enough the 256 steps?
Ioannis
I do not know if there is a 16bit version of the chip but I wonder why you need more steps (meaning more MCU power hungry code).
Aren't smooth enough the 256 steps?
Ioannis
Don't know about a 16bit version but I just stumbled across the LDP1886 which is a 3x12bit LED driver.
That's 4096 levels per channel or 68.7 billion colors.
I have not looked at the datasheet to see if it's otherwise compatible with the WS2801 etc series.
/Henrik.
256 steps are alright for color mixing and for big fades but quite often I'll have the lights down to number 3. They are very dim but they can't really fade out with just 3 steps and it looks a bit odd.
Processing power isn't much of a problem. I use PIC24FJ64GA004 chips to control them which are 16-bit anyway and have plenty of RAM/cycles.
I've got another one of these that can read 8 x 16-bit 44.1KHz WAV files from an SD card at the same time, mix them with 8-bit volume control and output to 4 x 16-bit DACs.
The lighting controller has 36 outputs (12 x RGB) but the refresh rate is much lower.
Thanks for the LDP1886 suggestion 12-bit would still give me 24 steps instead of 3. I'll have a read up on them.
Hmm, I see. For high lumen, high power, sure you need more steps.
Interesting.
How are you programming the dsPIC? In C?
Ioannis
PIC24 isn't dsPIC. PIC24 can be programmed in proton basic. I have dongle, but newer try it....
Or in microbasic, but I don't recommend it. I fon't have nice experience with it.
Sorry, you are right. I misread the PIC having in mind sound applications.
For MikroBasic I heard a lot, although it is quite impressive by the specs.
Anyone with experience on Proton about PIC24 is welcome to commend.
Ioannis
I helped friend with project for university. It had 4 counters(<2Hz, 50% duty) and 4 timers, 16x2 LCD and it was problem to fit all that code in microbasic on pic16f877. Simple code, I thing PBP version had less than 4K.
It has a lot of futures built in. Also TCP/IP works out of box on dev board, but again lot of overhead code. I have done similar things in PBP, with much less code space.
I thing that they work a lot on supported futures, so it is really easy to implement lot of things.
I work a lot with low power stuff(battery operated sensors, etc) and small code that PBP generate is almost always enough to achieve product life as long as battery shelf life. If not, then I do it in ASM.
So even if I have powered stuff, I'll do it in PBP because I use to it, and it is good enough.
MicroBasic support string, floating point by default. But I can use simple include for PBP to get just that. Also string functions are really easy to implement using arrays.
So I don't see benefit by buying MicroBasic. That is my opinion...
Bookmarks