Question about LED parallel output. Any support on AVR controllers? Any plan for support on AVR controllers? I have an uno that’d I really like to be able to drive 3 or 4 thousand WS2811’s at 40hz.
Any recommended MCU’s to do that? Looking for something reasonably priced, with Ethernet support.
No, there isn’t any support for parallel output on the AVRs - it mostly requires higher clock speeds to be able to pull off. I do have some notes on how to do 4-way parallel output on the AVR, but it falls more into the realm of stunt coding and less in the realm of actually useful.
Parallel output is supported on the teensy 3.0 and later devices, the esp32, and the esp8266. I believe the arduino due has parallel output support as well, but it’s the weakest of the supported platforms.
For 40hz refresh rate, you need to spend less than 25ms per frame. However, that 25ms is both preparing your frame and writing data out. So, ideally you want less than 13ms per frame. At 30µs per LED for WS2811, that means that you want your strands of leds to be no more than around 400ish leds (433 if you’re being picky).
So, even 8 way output might not be enough - the teensy 3.x does support 16-way output as options.
(You also don’t define what you mean by “reasonably priced”)
I would be interested in seeing the notes. I’m not looking for any of the fancier feature of fastLED other than parallel output. If you can do 4-way reliably, that sounds plenty useful. In the past I’ve used Adafruit’s library for it’s simplicity.
As for timing, we would just be pulling data from the ethernet buffer and pushing it to the fastLED buffer. That shouldn’t take a meaningful amount of time - right? I was figuring around 20mS to drive the LEDs would be acceptable, which gives us a useful 600 pixel length.
2.4kPx on a controller would be acceptable.
Alternatively, I have some esp8266’s around. They’d meet the definition of reasonably priced.
The notes wouldn’t be useful, they’re a scribbled shorthand I use when laying out asm timing/register usages. I’m not even sure that it would work 
2.4kPx on a controller is going to be wanting over 7k of ram - so again, the AVRs are out. The mega might work ram wise, but i’m not sure that would work well with the ethernet side of things. You’re going to be transferring about 480kbytes/second for 4000 leds, 288kbytes/second for 2.4k leds. From what I remember - good luck getting more than 70k bytes/second to an uno with the ethernet shield : )
Ahh, my plans are foiled! What’s the point of a 100Mb/s ethernet shield that can’t even hit close to 10Mb/s?
Anyways, are there any good Ethernet adapters for the esp8266 that could meet that 480kB/s without an issue? How about the teensy? I don’t know anything about the teensy, but the 16ch ability would justify it’s seemingly higher cost. But are they going to get hit by an SPI bottleneck as well?
Honestly, ethernet with these MCUs has been enough of a pain in the ass that I mostly stopped paying attention to what was happening with it. I did use wifi for a project with the esp8266 and it worked out pretty well.
If all that you’re doing is pushing frames to the controller to then turning around and push out led data, have you looked at something like fadecandy - which is geared/directed towards doing that? (For the most part, with FastLED, i’ve focused on supporting on-MCU generation of animation data – streaming raw data from off device to then send out isn’t something I’ve put a lot of time into - even the esp8266 setup I did, I used wifi for sending sync data not full data frames).
For that kind of job esp8266 would be fine but may I suggest the esp32? If you want to stream. You can still control a large amount of leds and more than anything let the second core handle the displaying while you buffer the next frame on core 1. I have personnally got 23fps out of this setup
https://plus.google.com/+YvesBAZIN/posts/ExUYP9RgoJW?iem=4&gpawv=1&hl=en-BE
Hmm. I’ve tried streaming with wifi on the esp8266. With a wireless router within a few feet, throughput and stability was OK, but the esp locked up frequently (Using someone else’s project).
Fadecandy is interesting - I haven’t seen that project before. The project, it native form anyways, isn’t quite what I’m looking for. 512px max, 64 per string isn’t going to cut it. Curious if it could be modified to work though. But I was also hoping to pull in data via sACN E1.31 protocol, which it also isn’t designed for.
The 2 cores on the esp32 is very compelling - probably going to have to get a few ordered.
I guess the previous question still stands: does anyone know of a way to get good throughput with Ethernet and an esp?
As long as you have an MCU that doesn’t have onboard Ethernet you’re going to have the problem of transferring the data from the external Ethernet controller to the MCU - which is mostly done via SPI - which is going to mostly cap you at a 20mhz data rate, give or take, then it becomes a question of how efficient the transfer/command protocol between MCU and Ethernet controller will end up being. (I suppose an MCU that could use a usb based Ethernet controller might be an option - but not sure that combination exists in the real world)
Another option for your specific use case might be pixel pusher - http://www.heroicrobotics.com/products/pixelpusher
Makes sense. Do you know of any MCU’s that have built-in ethernet and are supported by arudino IDE?
As for the PixelPusher, it’s product page reads like you need an app that will bridge E1.31 and their protocol. I need something that supports E1.31 directly, and that controller is a bit on the high side of what I’d like to pay. I’m more into a DIY solution, that I can potentially make available to others as well. For reference, the SanDevices E682 is basically the device I’m working to beat, both in terms of price and pixel capacity.
http://sandevices.com/product/e682-kit/
I don’t know, offhand, of any MCU’s that have onboard ethernet. In theory, the teensy 3.5/3.6 does - but I don’t know what the state of drivers/code for it are - and in one thread about it Paul commented that the teensy 4.x is more likely where that hardware is going to be functionally useful/exposed.
With some work you could probably use a pi (for the ethernet and CPU heft to deal with the incoming E1.31 frames) and then push led data to a teensy 3.x over USB - look at the fade candy firmware and some of Paul’s other example code for how to do high speed USB transfers.