Using SmartMatrix and Wifi on ESP32: choose your esp32-arduino version carefully

When upgrading from from 2019/05 to today’s version, my code stopped working and more debugging showed that 55KB were lost in the bloat that was added in the last year.

me-no-dev says that it’s mostly IDF bloat, although my git bisect found the first CL that took an extra 14KB of RAM for wifi (there are more changes that took 40KB later, but I didn’t bisect them)
If anyone else finds that they’re running out of RAM with SmartMatrix (55KB lost is a big deal), see

Just revert back to f4acac4c2bf83d76f49241489e24fc1d6bbb64e7 from ue Aug 20 16:18:09 2019 +0200 and you’ll get memory back.
For the future, I was told that this won’t get fixed in arduino-esp32, and that I should be using esp32-idf with the arduino layer.

Need to see how that’ll work with vscode I just switched to, and whether I need to switch to platformio which is also more work.

This is an FYI for at least @rorosaurus and Ravefurret:

Thanks for the heads up Marc, yet another reason why I don’t think the ESP32 and SmartMatrix Library are a good match for the average user

To be fair, this is using Wifi. Teensy doesn’t have that problem because it doens’t have wifi at all :slight_smile:
ESP8266 was actually supposed to be a wifi chip you connected to another uC, and it only did wifi, nothing else. If you really care, you can still connect an ESP8266 in wifi mode to a teensy or an ESP32 :slight_smile:

Yeah, aside from the added cost and size, I think a good distributed solution might be to use a Teensy 4 for the main CPU, external ESP32 for refreshing the HUB75 panel (the product I’m working on), external ESP32 for WiFi (Adafruit Airlift)

True, either you use a teensy to have enough RAM with no fuss and no slowdown, or you can use an ESP32 with PSRAM, in which case you get a whopping 4MB of RAM, although that RAM is a big slower (but probably won’t matter if the display is offloaded).

Question for you: people occasionally ask me why I’m doing something silly like driving those panels with a uC when they were clearly meant to be run by FPGA, and that I should just write an FPGA driver in an afternoon or somesuch (the afternoon part is a complete lie of course, I know that much :slight_smile: ).
Is there a reason why you didn’t consider an FPGA for your setup so that you could drive up to 128x256 on a single chain? No offense, but 128x64 seems a bit small when an rPi can do 384x256 on a single chip with 3 chains.
Sure, a Pi is not as small, but by the time you’re using 3 uCs to run only 128x64 with wifi, a Pi may not seem so bad anymore? :slight_smile:

Sure, if someone wants to use a Pi, there’s very little stopping them

I wasn’t familiar with what was recommended, but a little googling brought me here:

If anyone is using SmartMatrix Library with ESP32-IDF, can you share how it’s working for you?

Nice to read about your project, you’ve almost reached the 128x64 limit, well done.
As for FPGA, I know little about them, but I’m sure they cost more for sure.
At the same time, I’d pay $40 for an FPGA solution (or a bit more) if it gives me 256x256 or better, afterall it’s not that much more money than a beefy teensy :slight_smile:
Note that I’m not saying you should have used an FPGA, but was more asking because people are asking me from time to time, and I don’t have a good answer.

As for me, the best part of libraries like this, is that you can do something working with esp32 without too much hassle. If I would want to drive many panels at once, I would probably just buy a driver board from chinese.

What driver board would you pick/use that doesn’t take VGA/HDMI input?