Rainbowleds delay

EDC · Joined: 26 Mar 2014 Posts: 1130

Today Im working on some project where Rainbowleds are used.
I have two Rainbow_sripes in this project. One of them is ring:

After Rb_clearcolors and Rb_send I cant light first or whatever LED on the strip again without a delay.
So I must add special Waitms 1 and then everything working fine.

Maybe this will shorten develop software for someone Very Happy

I dont test how exactly I must wait because here it is not strictly time-dependent application.

JC · Joined: 15 Dec 2007 Posts: 626 Location: Cleveland, OH

Hi EDC,

I agree, a short delay is needed.
My copy of the data sheet shows that a delay of >= 50 uSec is required between the new LED update commands.
This is, I think, so that the LED can recognize the start of a new command.

My simple test program below shows this.
With a delay of Waitus 50 it works fine, toggling between Red and Blue.
With a delay of 30 uSec, it fails.

In the past I spent HOURS (or was it days...), looking for a bug in a couple programs, wondering why the LEDs were not updating correctly, before I learned that the delay was required.

In many cases, one's program will have a delay for processing other code between the updates.
But a loop rapidly updating the LEDs will fail without a short (50 uSec) delay.

I have a short test program, below, to demonstrate this.
This test / demo uses only one string of WS28B12 (3-color) digital LEDs.
This program does NOT use Interrupts (which could, if used, interfere with the output string timing).

I understand that the Waitus X command is an approximation, I have not O'scope the actual delay time.

This program sets the strip of 5 LEDs to all Blue.
It then sets the strip of all 5 LEDs to all Red.
It alternates back and forth in a loop.

The human eye will see a blended color, (off white), not the actual Blue then Red then Blue, etc., because the colors change faster than the human eye can perceive them.
If they are changing, however, one will see an off-white color.

If the command is failing, one sees that the colors are all Blue, and the strip is not updating.

With delay of 50 uSec the LEDs update correctly.
With a delay of 30 uSec, the update fails.

Perhaps Mark could add a comment in the Config Rainbow command's Help with the 2026 update as a reminder to everyone.

Take Care,

JC

Robert77 · Joined: 29 Sep 2016 Posts: 9

albertsm · Joined: 09 Apr 2004 Posts: 6180 Location: Holland

did not knew this. always worked in my tests. but they were only basic.
i wonder what the best solution is. add it to the lib so it will wait 50 us? or that the user add it.
the downside of the user adding it is that it uses more code. but... a lot of other code can run in those 50 us.
an option would be to use a timer that would wait if needed. but i am not a fan of using hardware that can be used otherwise or by the user.

JC · Joined: 15 Dec 2007 Posts: 626 Location: Cleveland, OH

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.
In the photo, the IR sensors are hidden by the front of the PCB, and one can see the black line, (on a white floor), extending out the in front of the Bot.

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:
I would suggest that you simply put a comment in the Rainbow Help.
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

Robert77 · Joined: 29 Sep 2016 Posts: 9

I agree with JC: Hints in the help are sufficient.
Please don't add the delay to lib and don't attach a HW-Timer to it.
I often have time-critical code or run out of timers, so changing the lib would cause more problems than benefits. Confused