SteveManley
New member
May I ask for some advice please? Let me start by briefly summarizing the problem. I’ve designed a control board to drive 350 WS2812B LEDs. The board is designed to accommodate either a Teensy 3.2 or Teensy 3.6 (to provide more I/O Pins). The board also includes a number of other chips, including an audio codec. Everything works great with the Teensy 3.2, but the display starts to flicker and glitch horribly when I swap in a Teensy 3.6, even though nothing else has changed and they are pin compatible (for the pins I’m using).
*
Here's a link to a video showing a crude demo of the display with a Teensy 3.2 followed by a Teensy 3.6 glitching*https://youtu.be/faKecpwiOI0
*
I’ll pose my questions here just in case you loose interest in reading the more in depth summary that follows them:
Q1. Would anyone have an explanation as to why the Teensy 3.2 seemingly works flawlessly, but the 3.6 causes LED display glitches?
*
Q2. Is it possible to implement DMA with this combo of libraries (Teensy Audio, Octo & FastLED)? If so, I seem to be unable to find out how, so please can someone offer some guidance?
OK, here’s the story in a little more depth. I’m an amateur electronics enthusiast with an interest in controlling RGB LEDs using a microcontroller, with Teensy as my main choice in MCU’s. I am able to code to some extent, but by no means am I an expert.
*
I have been developing a 10 by 21 segment Victorian style RGB alpha numeric display (along with some other folk). Each display has 35 LEDs, and the displays are wired in pairs, so I have 5 LED strips each 70 LEDs long, totalling 350 LEDs.
*
The main purpose of the display is to show date and time information, along with text messages and audio visualizations.*As part of this I designed a custom control board to drive the display. This board uses a DS3231S RTC chip as I originally wanted to run the display this from a Teensy LC, so its still included.
*
The control board also currently uses the Teensy Audio & OctoWS2811 libraries, as well as the FastLED library. The board has a 74HCT245 buffer for the standard 8 Teensy Octo outputs, and a SGTL5000 audio codec chip configured in the same way as on the Teensy Audio breakout board minus the SD card reader, audio output, and additional memory capability. I wanted the control board to be able to utilize either a Teensy 3.2 or a 3.6 MCU, so the control board is able to accept either device.
*
Until recently, I was using a Teensy 3.2 to drive the LEDs using the OctoWS2811 and FastLED libraries. So far so good. Using the Octo outputs rather than a single 350-LED string cut the display refresh rate down from about 11ms to a little over 2ms. I’m assuming I’m not benefiting from DMA as my code appears to wait around for the FastLED.show() to complete.
*
I added in the Audio library and managed to get the display to perform a VU meter and an FFT visualization based on the Teensy Audio library examples using the mic or line-in inputs.*
*
Up to this point, everything has been working as I planned, despite the FFT output not appearing very responsive at the higher frequencies (I think this is because my scale is linear at this time and it needs to be exponential).
*
The issue I hit was when I swapped the Teensy 3.2 for a 3.6 and uploaded the same code. The display became incredibly glitchy, whereas it was as steady as can be on the 3.2 (maybe more by luck than judgement).
*
My friend Clive “Max” Maxfield has the same setup, and he was the one who discovered the issue with the Teensy 3.6. His setup also works well with the 3.2. The reason for the 3.6 is that Max has plans to use a lot more I/O than I, else we would stick with the 3.2.
*
After some experimentation on a 3.6, I can significantly reduce but not totally eliminate the glitching by setting the Audio mixer inputs, Audio Mic Gain, and Audio Volume all to zero values. I also applied the AudioNoInterrupts() command, which eliminated the glitching altogether, but that obviously blocks the audio visualizations from working until re-enabled.
*
This indicates to me that the Audio library interrupts are interfering with the FastLED.show() calls, and that I’m definitely not benefitting from DMA for the display updates.
I have uploaded the main INO file which has all the important config. There are several H files with categorised functions, but there are quite a few of them. I can always add them later if need be.
Thanks,
Steve
*
Here's a link to a video showing a crude demo of the display with a Teensy 3.2 followed by a Teensy 3.6 glitching*https://youtu.be/faKecpwiOI0
*
I’ll pose my questions here just in case you loose interest in reading the more in depth summary that follows them:
Q1. Would anyone have an explanation as to why the Teensy 3.2 seemingly works flawlessly, but the 3.6 causes LED display glitches?
*
Q2. Is it possible to implement DMA with this combo of libraries (Teensy Audio, Octo & FastLED)? If so, I seem to be unable to find out how, so please can someone offer some guidance?
OK, here’s the story in a little more depth. I’m an amateur electronics enthusiast with an interest in controlling RGB LEDs using a microcontroller, with Teensy as my main choice in MCU’s. I am able to code to some extent, but by no means am I an expert.
*
I have been developing a 10 by 21 segment Victorian style RGB alpha numeric display (along with some other folk). Each display has 35 LEDs, and the displays are wired in pairs, so I have 5 LED strips each 70 LEDs long, totalling 350 LEDs.
*
The main purpose of the display is to show date and time information, along with text messages and audio visualizations.*As part of this I designed a custom control board to drive the display. This board uses a DS3231S RTC chip as I originally wanted to run the display this from a Teensy LC, so its still included.
*
The control board also currently uses the Teensy Audio & OctoWS2811 libraries, as well as the FastLED library. The board has a 74HCT245 buffer for the standard 8 Teensy Octo outputs, and a SGTL5000 audio codec chip configured in the same way as on the Teensy Audio breakout board minus the SD card reader, audio output, and additional memory capability. I wanted the control board to be able to utilize either a Teensy 3.2 or a 3.6 MCU, so the control board is able to accept either device.
*
Until recently, I was using a Teensy 3.2 to drive the LEDs using the OctoWS2811 and FastLED libraries. So far so good. Using the Octo outputs rather than a single 350-LED string cut the display refresh rate down from about 11ms to a little over 2ms. I’m assuming I’m not benefiting from DMA as my code appears to wait around for the FastLED.show() to complete.
*
I added in the Audio library and managed to get the display to perform a VU meter and an FFT visualization based on the Teensy Audio library examples using the mic or line-in inputs.*
*
Up to this point, everything has been working as I planned, despite the FFT output not appearing very responsive at the higher frequencies (I think this is because my scale is linear at this time and it needs to be exponential).
*
The issue I hit was when I swapped the Teensy 3.2 for a 3.6 and uploaded the same code. The display became incredibly glitchy, whereas it was as steady as can be on the 3.2 (maybe more by luck than judgement).
*
My friend Clive “Max” Maxfield has the same setup, and he was the one who discovered the issue with the Teensy 3.6. His setup also works well with the 3.2. The reason for the 3.6 is that Max has plans to use a lot more I/O than I, else we would stick with the 3.2.
*
After some experimentation on a 3.6, I can significantly reduce but not totally eliminate the glitching by setting the Audio mixer inputs, Audio Mic Gain, and Audio Volume all to zero values. I also applied the AudioNoInterrupts() command, which eliminated the glitching altogether, but that obviously blocks the audio visualizations from working until re-enabled.
*
This indicates to me that the Audio library interrupts are interfering with the FastLED.show() calls, and that I’m definitely not benefitting from DMA for the display updates.
I have uploaded the main INO file which has all the important config. There are several H files with categorised functions, but there are quite a few of them. I can always add them later if need be.
Thanks,
Steve