I've included a part of the data sheet below.
It shows the >= 50 uSec "Reset" delay that is required between sequential transmissions to the LEDs.
The data value is also listed in a table of timing information.
But until one actually works with the LEDs, it is very easy to overlook this!
Although the information is in the data sheet, the data sheet doesn't make a big point about it.
Most of the time one sets the LEDs and moves on with other code.
So the timing requirement is not an issue.
I had a Line-Following-Robot that had 8 IR Sensors to watch for the line on the track.
I had 8 LEDs mounted across the back of the Bot.
Each IR sensor's data was shown on its own LED.
All of the LEDs were Blue, except the ones that detected the line, they were Red.
As the Bot wandered off the line, (and had to correct its steering), the Red dot would move back and forth along the Blue line.
One could see the IR data in real time as the Bot traveled down the course, and watch it make corrections to the steering.
The way the code was structured, I was often trying to update one or two LEDs faster than allowed, (no 50 uSec delay), and it failed.
It took me forever to figure out the problem!
Now, back to on-topic:
[b:82334586e7]I would suggest that you simply put a comment in the Rainbow Help.[/b:82334586e7]
Perhaps in several places, the Config, and every command that writes to the string.
I would prefer NOT to have a blocking delay in the library.
That time, as you already mentioned, can be used for running other code.
I would prefer that it NOT use any HW Timer/Counter.
I don't want to have to design my projects around the HW that the compiler is using.
JC
[img:82334586e7]https://www.mcselec.com/userpix/8443_WS28B12_Reset_Delay_Timing_1.jpg[/img:82334586e7]
↧
