Rainbowleds delay

EDC · Joined: 26 Mar 2014 Posts: 1169

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: 637 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: 6270 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: 637 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

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

I was about to update the help. But i see something odd.

The help says :
"The entire memory of the active channel is filled with the specified color.
This statement will not update the LED's. This means that you need to use RB_SEND to update the LED's. Or use RB_FILL which will update the LED's as well."

In the example the RBSEND is missing.
When i check the lib.

[RB_FILL]
;DESCRIPTION Set SRAM and Stripe
;PARAMETER RGB(R16..1 Cool

;USE X
$external RB_STRIPE
RB_FILLColors:
CLT
RJMP RB_Fill0
RB_FILL:
SET
RB_Fill0:
;RCALL Parameter3
LD R16 , X+ ; R
LD R17 , X+ ; G
LD R18 , X ; B
#IF _RB_RGBW=4
LD R19 , X ; W
#ENDIF
RB_FILL1:
RCALL RB_LoadStripe
RB_FILL2:
ST X+, R16 ;store red
ST X+, R17 ;store green
ST X+, R18 ;store blue
#IF _RB_RGBW=4
St X+, R19 ; white
#ENDIF
* SBIW R24,_RB_RGBW ; 3 or 4 done
BRNE RB_FILL2
BRTC +2
Rcall RB_Send
Ret
[END]

When RB_FILLColors is called it will use CLT to clear the T flag in SREG
And this code :
BRTC +2
Rcall RB_Send
will skip the call to rb_send when T is cleared.
So i wonder how the stripe can even show something?
RB_Fill does not set T and will update using RB_Send.

So was this actually tested with the sample above?
Can it be re-tested?
And when it updates the rgb, can you remark the line with Rcall RB_Send by placing a ; before it?
Then save, recompile, prog and test.
If the code is right it will show the same behavior with remark on without remark.
If the code is not right it will not update.

The routine works on the memory only so i do not see how it can update the rgb.

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

Hi Mark,
I apologize; I have not (yet) tested the SNAP with Ver 2.0.8.7 from within Bascom.

The test below is using Ver 2.0.8.6.
I am using the SNAP programmer and the MPLab IPE to program the Arduino Nano, (M328P).
(My AVR Studio quit working with the SNAP after an update a year or two ago.)

I think you are asking whether the RB_Fill command will actually update a string of WS2812B LEDs.
Using Ver 2.0.8.6 and the RainbowBSCN.lib library, this DOES update the actual LEDs.
One does NOT need to use the RB_Send command after the RB_Fill command.

Note that the WS2812B Digial LEDs do require the 50 uS delay between sending new commands out the I/O pin
to the LED string.

The program below was tested on real hardware, today, and works correctly.

I prefer to put the delay in MY code, so I don't need it at all if I am executing other instructions between the
Digital LED update commands.

Take care,

Jay

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

Thanks for the answer.
I does not matter if you use 2086 or 2087.
Can you edit the lib section [RB_FILL] and remark the line :
Rcall RB_Send
by placing a ; before it ?
;Rcall RB_Send

then save and recompile/reprogram.

it would be odd if it would update.

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

ignore that. i see what is wrong. i think the wrong entry point is called so it will always update.
i need to look into it. but the cause is clear now.

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

I need better glasses. I thought that rb_fillColors was used but rb_fill is used which will indeed update the RGB.

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

It is a good feeling, however, when you track down a "bug" and find the actual problem and solution.

This is true even if the "bug" is in our thinking, and not in the code itself!

I did verify, on real hardware, that:
RB_Fill array
Will update the memory and write the data out to the LEDs.

RB_FillColors array
Will update the memory, but NOT write the data out to the LEDs

RB_FillColors array
RB_Send
Will update the memory, and then write the data out to the LEDs.

When the name of the array is color() it can easily be mis-read by your brain!

If you are updating the Help for the Rainbow instructions, then perhaps it would be reasonable to add a paragraph that states that there needs to be a >= 50 uSec delay between successive writes to the WS2812B LED. This is to allow it to correctly recognize the end of one instruction and the start of the next instruction. This delay can be inserted with Waitus 50 if one has several instructions in a row that write to an LED (or LED string). The Waitus50 is not needed if other instructions are being performed that take >= 50 uSec to be executed.

Thank you, again, for your continued work on Bascom!

Take care,

Jay

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

Yes solving puzzles gives a good feeling.
I misread the color() variable. So all is working as expected.

I have added to the help:
A small delay of 50 uS is required between updates/writing new data with successive writes. The ws2811/2812 needs a small delay so it can recognize the end of data. Other RGB chips might not require it. Just check the specs.

EDC · Joined: 26 Mar 2014 Posts: 1169

Im happy that this quirk has led to such constructive solution.