[sdiy] Coloured LEDs

[rsdio at audiobanshee.com]

On Feb 21, 2017, at 9:26 PM, Vladimir Pantelic <vladoman at gmail.com> wrote:
> On 20.02.2017 21:51, rsdio at audiobanshee.com wrote:
>> On Feb 20, 2017, at 12:41 PM, "Byron G. Jacquot" <thescum at surfree.com> wrote:
>>>> So this NRZ signal can be generated with a SPI port? How is this
>>>> done?
>>> 
>>> By clocking at 8X the bit rate, and turning each bit of output into
>>> a byte that's shaped like the expected code, such as 0b11000000 and
>>> 0b11111000.
>> 
>> You could almost get by with 4X the bit rate, but that just barely
>> falls within the +/-150 ns window. 5X would be almost dead on, at
>> least as good as 8X, but more difficult to calculate the code
>> translation.
> 
> 4x works fine

Not sure why I said 8X would be "at least as good," since 4X would be exactly the same.

The example of 0b11111000 is incorrect. It should be 0b11110000 to meet the 48% duty cycle requirement. Since both codes have an even number of 1 bits, the 4X version would have exactly the same ratios.

>> Meanwhile, my quick scan of the data sheet leaves me with the
>> impression that this chip must be fed data constantly or it will be
>> reset. I suppose you could leave the data line high to avoid reset.
>> If it must be fed constantly, then that's an even greater load on the
>> CPU.
> 
> no, reset means that the protocol "resets", the RGB values stay put.

Thanks.

Closer reading of the data sheet reveals that they point out how none of the chips update their RGB outputs until the RESET event (of a long, 50 microsecond low). This allows long strings of LED units to be updated without flickering of LED units in the middle of the chain as they pass through settings destined for the other chips downstream.

>> Must be a really cheap part for people to put up with the strange
>> communications.
> 
> in my case controlling 53 LEDs with just 2 CPU pins and very little CPU
> overhead is worth it.

I see, with SPI you can update a long string without glitches, so long as you control the dead time between updates to be at least 50 us. Total time for you would be 1.64 ms for a total update, assuming 800 kHz mode, allowing up to 609 Hz refresh rate (at 4X).

These chips don't look so bad after all.

Brian