Mega 2560 Hardware Serial drops data with FastLED

Projects Programming
1

I've finally determined why my 9600 baud Serial3.read() (connected to an HM10 BT device) would intermittently lose bytes while reading a string I sent from a remote BT device. If I'm running a lightshow using FastLED and calling FastLED.show() every frame (432 LEDs) Serial3 will drop bytes. If I disable the lightshow, I have no issues. FastLED is using an output pin of PIN_A0.

pinMode(PIN_A0, OUTPUT);
CFastLED::addLeds<WS2812, PIN_A0, GRB>(LEDs, 432);

Is there anything I can do to eliminate the dropouts? I'm not sure why the hardware serial would miss bytes.

Thanks!

2

The FastLED creates a pulse train for the ledstrip. To get the right timing for that pulse train, the interrupts are temporarily disabled. Everything that relies on interrupts will get into trouble.

There are solutions. There are Neopixel libraries that use DMA. The Raspberry Pi Pico has programmable hardware (I don't know if there is FastLED code for those programmable blocks). You could even add an extra Arduino board for the FastLED.

The best solution is a ledstrip with data + clock signal.

2 Likes
3

It misses bytes because the processor is so busy pumping your LED Data out, it doesn't notice that interrupt that tells it to grab the incoming byte from the UART before the next incoming byte overruns the first one.
You have a problem, because FastLED, and other pixel drivers, don't play nice with interrupts.
What's the source of the serial data? Can you slow it down to, say, 2400 baud? Reducing transmission speed reduces the interrupt frequency for byte reception.

4

Or, write your own driver for the pixel string that briefly enables the interrupt, grabs the incoming char, and buffers it.
Not for the faint of heart, but quite possible if you've got 'the chops' for it.

1 Like
5

Thanks @Koepel & @camsysca ! I'll manage the interrupt myself as suggested.

6

Suggestion - dig deep into the Serial and FastLED or Neopixel libraries, look at how they do it. It's pretty simple. If you're not into porting to a thousand different hardware platform varieties, what you need to do can be distilled to a couple of pages of code. I unwrapped FastLED and pinned a piece of it to the end of the interrupt routine in Servo.h to update two pixels per servo handled(adds about 1.2 ms to the end, equivalent to adding a 13th servo), and I don't think it would take much to interleave a quick 'peek' at serial as well within the pixel update loop if you were careful. The pixel update specification has a pretty 'sloppy' reset timing window, so you'll have to watch out for that.

7

Awesome - thanks again! Before I dig in, is there an alternative LED library that's async and doesn't interfere with hardware serial? TY

8

You could switch to APA102-LEDs (aka Adafruit DotStar) that interface with a SPI SCL / MOSI pair. The library will then no longer need to disable interrupts during updates.

You could also switch to a Teensy 3.x or 4.x board. PJRC has a library that links into FastLED and blasts data to WS2812-type LEDs over a UART port using DMA. Again, interrupts don't need to be disabled. Your Mega does not have DMA.

9

This is about the DMA driven SPI bus for Neopixels: https://learn.adafruit.com/dma-driven-neopixels/overview

10

As I noted above, @fordfanboi's Mega 2560 board doesn't have DMA.

11

My Servo-pixel solution is working on a Nano. It's good enough for me, but I'm NOT doing dynamic display on the pixels, so indeed, YMMV. I don't think it's impossible, or I wouldn't suggest it, but I do think you'll get some mental strain along the way. I don't have suggestions for other LEDs or libraries.

12

That did the trick. Thanks for the guidance!

			// while(--count)
			{
				// Loop beginning
				DNOP;
				LOOP;

				sei();
				while (Serial3.available() > 0)
				{
					BLEMessage += static_cast<char>(Serial3.read());
				}
				cli();

This is all I had to add to FastLED\src\platforms\avr\clockless_trinket.h showRGBInternal()

13

I won't argue with success, but...String???!!!??? Surely, no.

1 Like
14

Sorry - that was from determining why the hardware serial was dropping data. lol

static_cast<char>(Data);
1 Like
15

Of course, now that the door is open... Why fix it for just one Serial...!!!

16

:joy: Yeah - this is just proof of concept code. I hate modifying libraries so I'll try to come up with a MACRO or something to clean it up.

1 Like
17

Did you test it?

1 Like
18

Yep - works great. A week to find the issue and 5 minutes to fix it lol (with great guidance from y'all!)

19

You don't have any problem with the LEDs when inserting that much code into the code that generates the LED data stream?

There should not be a need to actually read the data from the serial port inside the FastLED library, just enable and then disable the interrupt, so that the serial hardware interrupt is processed to place the received character into the Rx buffer. With 432 LEDs, at 9600 baud, there will only be about 13 characters received.

1 Like
20

I tried the following, but it didn't work. :frowning:

				sei();
				//while (Serial3.available() > 0)
				//{
				//	BLEMessage += static_cast<char>(Serial3.read());
				//}
				cli();