Hi all,
I’ve dabbled with FastLED several times, and always had great success with it, so now I’m trying something else. Unlike my previous adventures though, this involves more LEDs, and I’m trying to use a smaller controller; and that’s where my question/problem comes in. I’m attempting to use a pro mini, and I’m intending to drive roughly 360 pixels (WS2812b), but I can’t seem to get anywhere close to that without exceeding the 2k of memory in the pro mini. In fact, to be exact, 237 seems to be the absolute max that will compile, and that that uses 99%, so it isn’t really even an option.
Searching around the web seems to indicate, that I should have been able to get up to 500, so I figured I was safe at 360. Guess not.
As I see it, that leaves me a couple options …
Have someone here that’s more experienced tell me why the FastLED.addLeds line is blowing the top off my memory limit, and if there is a more efficient call, … or to simply use another controller.
I opted for the Pro Mini’s because I already have a slew of them on hand, and because of the form factor. My alternatives are a Teensy 3.2, or something based on an ESP8266 (or whatever else someone might toss in the ring here). I’ve never used anything non-arduino so any recommendations would be greatly appreciated. I’m leaning towards the Teensy, but since I’m going to need at least 6 to 10 of these things, the price point of the other is hard to ignore despite the mixed reviews I keep finding.
The Teensy LC might be an option for you. 4x the speed and approximately double the memory. And only a tiny bit more expensive then the Pro Mini. https://www.pjrc.com/teensy/teensyLC.html
And if you get a Teensy 3.2 you’ll have tons of memory.
Oh, forgot to add, working with the Teensy boards is just as easy as working with the Arduino boards. After installing the Arduino IDE you then download and install Teensyduino which gets added into the Arduino IDE and allows you to select Teensy boards from the list boards to compile and upload to. https://www.pjrc.com/teensy/td_download.html
I considered the LC, but I leaned towards the 3.2 for the 5V support, and I’m feeling to lazy to deal with the voltage differentials; though I might reconsider.
As far as the code for my project goes, it’s pretty non-existent; at this point I was just experimenting with the fire2012 example, and boosted the value of NUM_LEDS. It seems like each defined pixel consumes ~8k, but I thought I saw mention that each was only supposed to use 3 … so my memory is either off, or that info was just wrong.
It depends if you’re going to need non-blocking performance. If blocking is ok, which is the norm with WS2812 on pretty much all boards, then LC should be plenty.
Blocking means other libraries can’t really use interrupts during the time when those WS2812 LEDs update. If you have incoming serial data, or a wireless module, or IR remote control, blocking can be a real pain. It also comes into play if you’re playing, synthesizing or analyzing audio, but for sound processing you’d want 3.2 anyway.
Until recently, the solution for blocking usually meant switching to APA102 or WS2801 LEDs with both clock and data signals. That’s still a strong option. You can now have non-blocking WS2812 output, but it costs much more memory. 360 is probably a little beyond LC’s memory with non-blocking performance. 360 and even 500 fit easily if you can live with the normal interrupt blocking.
With 3.2, you get plenty of memory for non-blocking with a long strip of 500 WS2812 LEDs. You can also use OctoWS2811, which is non-blocking, to control up to about 5000 LEDs using 8 parallel outputs…
Might also be worth mentioning the Cortex-M4 processor in 3.2 is far more powerful, about 3X faster at the same clock speed. There’s a reason 3.2 can do all that amazing audio stuff, but LC can’t.
@Randy_H lc has no 5v tolerant pins, is powered from 3.7-5.5vdc.
I may be misunderstanding but regarding level shifters and ws2812b your talking about 5v output for data signal. Teensy Lc has 1 5v output for this purpose. 3.2 does not.
Ok … that’s a lot of good info; so here goes.
Firstly though, I found the reference to the fact that FastLED uses about 3k per pixel … it was actually Paul’s own recent blog post on PJRC about his non-blocking library where it’s mentioned … So that makes me wonder why I’m seeing about 8k per Pixel, or if I simply misunderstood the reference point being used the post … at 3k per pixel, I should be well under budget here. Initially, I’d second guessed my recollection on that because I thought I might have seen it in an outdated source, but since that post is only a week old, so its pretty darn fresh.
Paul’s blocking comment is on the mark that the project will be using wireless in addition to the Pixels, so I had considered potential issues with blocking, as my plan was to use nrf24l01 modules for this. The implementation though, does not involve/or rely on streaming of data, but just occasional variable updates (i.e. to set a base color, or something which would fit in a single packet; so that all the fixtures would know to start using to red), with all of the logic happening locally. So my assumption (from what I’ve read) was that the module would handle the receipt and buffer the frame until the CPU got back to reading it, and for this project, it’d be a non-issue if it was delayed due to the CPU being busy at that instant (first time using these modules as well, so that could be completely wrong, and I’ll need another plan there).
As far as the voltage goes … the specs for the LC indicate that it can be powered by 3.3V ONLY, despite having a 5V output. Whereas the T3.2 indicates it can be powered directly with 5V. With that in mind, since my LED strips are also 5V, my thinking was to power the board and the strips directly with a 5V supply, and simply use digital outputs from the T3.2 to control them … that way I need a single 5V supply, and can simplify the power requirements. (After struggling for a week with the nrf24l01, I couldn’t get them to work reliably without the 5V base adapter that has the built in 3.3V regulator, so now they’re using the 5V also). If, however, the T3.2’s digital output can’t signal the pixels directly … I may need to re-think things and go with the LC instead.
@Randy_H We won’t be able to help with checking to see if there’s something in your code using up extra memory unless you share it. http://gist.github.com
Found my mistake … apologies. I was confused … that page doesn’t actually mention the boards input voltage, and the voltage input line was what jumped out at me there … I did find it elsewhere in the pinout diagrams that they can both powered by 3.7-5.5V. My fault.
Hi Marc … I’ve already stated, there is no project code yet. I simply boosted the number of LEDs in the sample code of the Fire2012 example (though I think think it was actually Fire2012withpallete to be exact). I’m very early on and was simply trying to prove I could even drive the 360 LEDs from the pro-mini before getting deep into it, and that seemed like a reasonable test. So far, it’s not looking good there.
I have ordered an LC, and a T3.2 to play with, however, if the memory issue magically gets resolved, I’ll probably still lean towards the pro mini for this since I have about 20 of them in a box from a project that never happened :).
I have four 16x16 WS2812B LED matrix panels (linked below) running on a Teensy 3.2 and it works great. If you watch you can tell it’s bogged a little with those four panels, when it’s down to one or two panels this thing screams. I tried an Arduino Mega/Uno and constantly ran out of memory but not with the Teensy 3.2.
Hi all,
Just an update … I revisited this today, and decided to take the example code and go line by line through it. I started a new sketch, set the num_leds to 100, and copied the example code to the new sketch and recompiled after copying each line one-by-one to see the exact memory impact and where things were going awry. I got to the end, and everything was fine. I then increased the number of leds and everything was still fine and then I even increased it all the way to 360, and things were still fine (using just 89% of the memory now). So I went back and jacked up the number of leds in the original sketch to 360 again, and everything worked fine there too. At this point, I have zero clue what caused the initial memory problems I was seeing, but whatever it was, it was local to my setup … several days/reboots later, I’m seeing the expected 3KB/led that I was initially expecting and not the 8 I was getting.
I had just installed the IDE and all the libraries on this computer that day … perhaps there was a contributing factor there. I had reproduced the issue at least dozen times, and narrowed in on the magic number of 237 before posting the question, and now I can’t recreate it at all. What I find interesting though, is that the new maximum number that I can compile into the pro mini with the example sketch is 474 … exactly double the 237 limit I was seeing before.
Despite the fact that I can compile now and run the example with enough LEDs, it’s obvious the pro mini is going to have insufficient memory for the project as a whole, once I ask it to do a bit more. So I appreciate the input and recommendations on alternative boards, as well as all the other feedback regarding my memory mystery.
@Chris_Rees Right now nothing is dynamic. I am only uploading sketches via USB to the teensy 3.2 set to serial in the Arduino IDE and the LED_PIN is set to 6 in my sketches so far. In the future, I want to try a Bluetooth or Wifi module to push new functions/animations. I am also very new to all this and I have just pieced stuff together I have found online and from help from this awesome group/ I hope that helps a little, but please ask if you have any other issues!!!
I have had 768 pixels on a Leonardo (Atmel 32u4) with 2.5k of RAM, including a Conway’s Game of Life implementation. It was pretty tight though, and all the animations were done “in place” in the leds backing array.