Using a Teensy 3.2 and Huzzah ESP2866; how to divide tasks?

Status
Not open for further replies.
T

THX1138

Member
I have a project where I want to use FastLED, a Teensy 3.2, an OctoWS2811 adapter and a Huzzah ESP2866 to control addressable LEDs over Wi-Fi. The LEDs will be in the form of 18 strips of 47 SK6812 LEDs which can be connected in configurations such as six sets of 141 LEDs.

There is a guy who has done something similar using a Witty Cloud which has an ESP2866. I was hoping I could use his code which appears to be written for the Arduino Core. I'll be using a Teensy 3.2 which I think uses the Arduino Core already but the Huzzah ESP2866 uses MCU/Lua by default. Would it be easier for me to switch it to Arduino Core? Alternatively, I think it's possible to make it use something called AT commands. Alternatively, maybe the ESP2866 should be running the show and delegate tasks to the Teensy 3.2? The guy in the YouTube video says the ESP2866 can serve a webpage which is then used as the means to control the lights via phone or PC. I suppose the Teensy could host it just as well and pass the AT commands to Huzzah?

I have no idea what I'm doing!

Thanks for any insight.
 
I've got a project that's using FastLED and Arduino on just an ESP8266 board without Teensy. Works great. I'm using the WeMos D1 Mini, but I don't see any reason why you couldn't use the Huzzah board, flashing it with an Arduino firmware image, replacing the NodeMCU/Lua firmware it comes with.

The benefit of the WeMos D1 is that it's got the USB port built-in so you don't need to mess with a serial cable for the initial flashing.

And if you add it to your firmware, you can do over-the-air firmware updates to the ESP8266 later on...
 
2nd for ESP-8266 using Arduino. Worked well as far as I went with it. I re-posted a github link to my findings again recently. Wired up Serial to ESP and used it to program them until the OTA was online - search mywebserver should find my post.
 
The gains from the Teensy are ability to throw lots of pixeles (thousands) quickly and the CPU horse power to generate patterns onboard.

For this use case as noted above it may be possible to drive the eight hundred odd LEDs directly, and if the aim is to just stream network data the onboard processing load would be low, and keeps everything in one place.

Possible gotcha's:
Need to confirm the ESP board you have can actually fit ~800 pixels into RAM
That the ESP board can reliably produce the WS2811 waveform while doing your network stuff (needing to process data in). The wavefrom is self clocking so interrupts longer than the wave form time will glitch pixels. This may be less of a problem if it works synchronously, stream in new array, then send message to update and make sure nothing goes to the ESP to distract it until the pixels are updated, either timer based or actually sending 'I'm done' responce.
You will need a level converter, since the ESP is 3.3V
 
GW makes good points, as shown I'd just use the ESP for web and communication. I suppose the huzzah has 4 MB so it should have 3 for web and even led data on a SPIFFS image
 
Thanks for all your responses!

Do you know how computationally intensive the animations can be? I'm interested in the KnifePallete animations and one called Fire 2012 among others. I don't know whether the arrangements of the LEDs make a difference but since my application is going to use six strips of ~47 in three separate tubes I want the animations to be able to run independently so each of the three tubes (each containing six strips of ~47) could be doing something different. Perhaps that takes more complex calculations than running a single animation over three times as many LEDs?

Why do people want framerates in excess of 200 FPS? When I used a CRT monitor I was perfectly happy with a 60 Hz refresh rate. This page gives four different refresh rates at the bottom. Isn't the point to use the same refreshrate (e.g. 66 FPS) with a larger number of LEDs rather than the same number of LEDs with a higher refresh rate? https://github.com/FastLED/FastLED/wiki/Parallel-Output
 
High refresh rate is critical for POV projects but I think neopixels internally run at 400hz so 200FPS would be slightly overkill for them even if you engineered everything else to do it. For a POV project if you have a spoke spinning at 1 rev a sec then 200fps gives you only 200 pixels on the X axis to work with.

The issue with effect processing is that the Octolibrary uses DMA to produce to waveform automatically, pretty much leaving the CPU time free to go prep the next frame. With just the Huzzah you will be bitbashing the waveform so loose the frame send time out of the processing budget along with the network overhead.

My guess would be that you could run a single repeated effect but you may find you are pushing things to run multiple different ones to a fair number of pixels. If you can unload your processing to the parent PC this doesn't really matter since the Huzzah is just a pipe, but if it's getting pattern generation commands to execute then some experimentation would be wise.
 
GremlinWrangler said:
High refresh rate is critical for POV projects but I think neopixels internally run at 400hz so 200FPS would be slightly overkill for them even if you engineered everything else to do it. For a POV project if you have a spoke spinning at 1 rev a sec then 200fps gives you only 200 pixels on the X axis to work with. .
Click to expand...
I think that there is a difference in understand what framerate means. A whole frame is the total image, whereas the what is quoted above is the strip refresh rate. The strip refresh rate of ws281* is slow, and is a limiting factor in creating high density images in moving arrangements. The above is a description of refresh rate giving pixel density, rather than framerate, which would be entire image reproduced x times per second.

Hope that helps
 
mortonkopf said:
I think that there is a difference in understand what framerate means. A whole frame is the total image, whereas the what is quoted above is the strip refresh rate. The strip refresh rate of ws281* is slow, and is a limiting factor in creating high density images in moving arrangements. The above is a description of refresh rate giving pixel density, rather than framerate, which would be entire image reproduced x times per second.

Hope that helps
Click to expand...

I'm not really sure what you mean, tbh.I don't understand the difference between the strip refresh rate and the rate at which the frame changes. I'm thinking of using either SK6812 3535 or APA102 2020 LEDs though, not WS2812. The SK6812 have only one data pin while the APA102 have a data pin and a clock pin.

GremlinWrangler said:
High refresh rate is critical for POV projects but I think neopixels internally run at 400hz so 200FPS would be slightly overkill for them even if you engineered everything else to do it. For a POV project if you have a spoke spinning at 1 rev a sec then 200fps gives you only 200 pixels on the X axis to work with.

The issue with effect processing is that the Octolibrary uses DMA to produce to waveform automatically, pretty much leaving the CPU time free to go prep the next frame. With just the Huzzah you will be bitbashing the waveform so loose the frame send time out of the processing budget along with the network overhead.

My guess would be that you could run a single repeated effect but you may find you are pushing things to run multiple different ones to a fair number of pixels. If you can unload your processing to the parent PC this doesn't really matter since the Huzzah is just a pipe, but if it's getting pattern generation commands to execute then some experimentation would be wise.
Click to expand...

I've also had someone recommend to me using the Feather HUZZAH ESP2866. I think that has more power than the plain ESP8266. Would that be much simpler than trying to make the HUZZAH ESP8266 work with the Teensy 3.2?

Also how many ESP8266 GPIO pins can be used to send data to the LEDs? Couldn't I use two or three pins at once to run in parallel? Doesn't the Teensy have at least eight output pins? I would think that would make the OctoWS2811 redundant so it must not be the case but why?
 
Last edited:
You possibly need to be looking up more of the library docs on how this stuff fits together. This is a serious project that involves a number of moving parts that will not be plug and play. You have making arduino do ethernet, generating patterns and driving a non trivial number of LEDs with resultant wire and power complications. This project is more ambitious than anything I've built, so I'd be budgeting lots of hours to look at code, build sub assmeblies (software and hardware) and then come up with a final design. Not saying this to stop you but be aware going in that this is ambitious and you need to assume:

You will learn something new in a cloud of smoke (have spares)
It will take much longer than you think
You will need at least two protoypes to get to where you need to be, budget for them
In making those prototypes will will have at least one 'I can't get there from here' moment and re-design.

This is the fun of this sort of project, but deadlines suck the fun out right quick. Is there one?

Going back to your original questions, OctoWS2811 is several parts. It's the board that is nothing more than a level converter and convenient header setup, it's the core library and it's the add ons people have used so be careful in reading which part people refer to, since the Octo PCB gets used for other level converter duties for instance. Taken together you get a video card for your arduino in that all the complex wave form for 8 streams of pixels is happening in the background of the DMA unit in the Teensy, leaving the CPU to generate the next frame, and the PCB makes it far easier to get the signals right first time and at the right voltage levels. And because it's a standard of sorts you can find lots of code that produces patterns for the Octo library.

If you go to the Huzzah you loose a lot of this and initially it looked like that wasn't a problem. The Huzzah has no DMA engine that can stream parallel pixel data without the CPU, so while it has lots of pins it can't stream data to more than one of them easily. You could have multiple strips and update them one at a time, but all of this eats your time budget.

Going to the SPI LEDs (two signal API102 and relatives) gets you more control over the way things get updated, and in some cases you can leverage the hardware SPI to unload the CPU a bit but you will still need to convert to 5V, and still need to work out where your pattern is being generated in the first place. Also if using the single hardware SPI port be aware you can't send the signal between strips more than 30cm or so (1 meter tops), so you would need a careful strip layout to keep the ends in the right places.
 
GremlinWrangler said:
You possibly need to be looking up more of the library docs on how this stuff fits together. This is a serious project that involves a number of moving parts that will not be plug and play. You have making arduino do ethernet, generating patterns and driving a non trivial number of LEDs with resultant wire and power complications. This project is more ambitious than anything I've built, so I'd be budgeting lots of hours to look at code, build sub assmeblies (software and hardware) and then come up with a final design. Not saying this to stop you but be aware going in that this is ambitious and you need to assume:

You will learn something new in a cloud of smoke (have spares)
It will take much longer than you think
You will need at least two protoypes to get to where you need to be, budget for them
In making those prototypes will will have at least one 'I can't get there from here' moment and re-design.

This is the fun of this sort of project, but deadlines suck the fun out right quick. Is there one?

Going back to your original questions, OctoWS2811 is several parts. It's the board that is nothing more than a level converter and convenient header setup, it's the core library and it's the add ons people have used so be careful in reading which part people refer to, since the Octo PCB gets used for other level converter duties for instance. Taken together you get a video card for your arduino in that all the complex wave form for 8 streams of pixels is happening in the background of the DMA unit in the Teensy, leaving the CPU to generate the next frame, and the PCB makes it far easier to get the signals right first time and at the right voltage levels. And because it's a standard of sorts you can find lots of code that produces patterns for the Octo library.

If you go to the Huzzah you loose a lot of this and initially it looked like that wasn't a problem. The Huzzah has no DMA engine that can stream parallel pixel data without the CPU, so while it has lots of pins it can't stream data to more than one of them easily. You could have multiple strips and update them one at a time, but all of this eats your time budget.

Going to the SPI LEDs (two signal API102 and relatives) gets you more control over the way things get updated, and in some cases you can leverage the hardware SPI to unload the CPU a bit but you will still need to convert to 5V, and still need to work out where your pattern is being generated in the first place. Also if using the single hardware SPI port be aware you can't send the signal between strips more than 30cm or so (1 meter tops), so you would need a careful strip layout to keep the ends in the right places.
Click to expand...

Thanks for the advice Gremlin. I hope it will be easier for me because there's some code I can use introduced here. That post links to a GitHub with some code to use. The code is specifically for the ESP2866 and not the Teensy so I guess it would only complicate things if I need to move of the ESP2866. I have discovered that there is no difference in the processing power of the Feather and non-Feather version of the HUZZAH ESP2866 or any other kind of ESP2866 - the only difference is the additional features like a USB interface, battery connector or some voltage protections or whatever.

Is there any way I could simulate ~800-900 addressable LEDs so I can see what it would look like within the limitations of the ESP2866?
 
Since the LEDs have no feedback to the CPU to say they exist, you can code as many LEDs as you need and the code will 'drive' them fine and out of memory and speed issues will hit as they would in the final design. Having a couple of LEDs there is helpful to confirm nothing is corrupting your patterns as you push out the LED count.

Only real difference is the power demands, and possibly some problems with data integrity in long runs (more than a couple of meters)
 
GremlinWrangler said:
Since the LEDs have no feedback to the CPU to say they exist, you can code as many LEDs as you need and the code will 'drive' them fine and out of memory and speed issues will hit as they would in the final design. Having a couple of LEDs there is helpful to confirm nothing is corrupting your patterns as you push out the LED count.

Only real difference is the power demands, and possibly some problems with data integrity in long runs (more than a couple of meters)
Click to expand...

Oh right, okay, that might work. I have ordered a couple of sticks of WS1288 LEDs each with eight one. Maye I could order a few more and use them for my simulations. Thanks again Gremlin :)
 
Status
Not open for further replies.
Back
Top