Marc's Public Blog - Arduino Hacking


All | Aquariums | Arduino | Btrfs | Cars | Cats | Clubbing | Dining | Diving | Electronics | Exercising | Flying | Halloween | Hiking | Linux | Linuxha | Monuments | Museums | Public | Rc | Sciencemuseums | Snow | Solar | Trips



Table of Content for arduino:

More pages: March 2020 January 2020 May 2019 April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011




2020/03/16 Framebuffer::GFX, Choosing between its 3 2D APIs: FastLED XY(), NeoMatrix, and LEDMatrix, and detail of its many supported hardware backends
π 2020-03-16 01:01 in Arduino

Why Framebuffer::GFX?

After rewriting multiple related libraries, it became confusing to people how they fit together, Adafruit::NeoMatrix, FastLED::NeoMatrix, SmartMatrix::GFX, where does Framebuffer::GFX fit in?
Is Adafruit::GFX still there/needed?
How about LEDMatrix, isn't it a better 2D lib?
What hardware backends are supported?

How the modules/drivers fit together

I made this little graph to summarize everything:
  • the left shows the hardware drivers supported: FastLED, SmartMatrix, ILI9341, SSD1331, ST7735, rpi-rgb-led-matrix (for ArduinoOnPC on Raspberry Pi), FastLED_SDL (for ArduinoOnPC), and X11/Linux (also ArduinoOnPC)
  • The 2nd column is the list of drivers I wrote for all those hardware drivers
  • All those drivers I wrote inherit from FrameBuffer::GFX wihch stores the actual framebuffer in FastLED CRGB 24bpp Format
  • FrameBuffer::GFX implements (and replaces) Adafruit::NeoMatrix panel mapping, inherits from Adafruit::GFX while converting back and forth between GFX 16bpp RGB565 and 24bpp CRGB RGB888 (see color management in https://github.com/marcmerlin/Framebuffer_GFX).
  • LEDMatrix is an alternative to GFX that is mostly compatible, but offers its own extensions. I you wish to use it, I modified it so that it doesn't store the CRGB array within itself, but accepts an externally generated one (so that it can be shared with SmartMatrix if this is the ultimate backend, and allocated via malloc and not a global array, which is required on ESP32 for bigger sizes). More on whether you'd want to use it, later.
  • Low Level Drv|Glue Driver for FrameBuffer::GFX FastLED - FastLED_NeoMatrix -------------\ FastLED CRGB Array SmartMatrix - SmartMatrix_GFX -----------------\ 24bit FB storage API Support ILI9341 \ \ CRGB methods like SSD1331 |--- FastLED_SPITFT_GFX ----------------\ scale8/fadeToBlackBy ,FastLED API ST7735 / | | / (XY 2D to 1D mapping) | |
    ArduinoOnPc-FastLED-GFX-LEDMatrix arduino - FrameBuffer::GFX------ Adafruit::NeoMatrix + emulation for linux / Raspberry Pi: | | \ Adafruit::GFX APIs ---------------------------------- / Adafruit::GFX \ : rpi-rgb-led-matrix - FastLED_RPIRGBPanel_GFX ---/ LEDMatrix (optional) `LEDMatrix API ArduinoOnPC X11/linux - FastLED_TFTWrapper_GFX / . FastLED_SDL (linux) - FastLED_NeoMatrix -/ .

    Which 2D API: FastLED XY(), Adafruit/FastLED::NeoMatrix, vs LEDMatrix

  • Old FastLED demos use an XY() function, to access leds[XY(x,y)] to do 2D to 1D mapping. Framebuffer::GFX supports this in a way that you can both read and write while supporting full rotation and tile mapping from NeoMatrix. This is honestly no reason to do this today, you would effectively rewrite the much better XY functionality that's in FastLED::NeoMatrix/Framebuffer::GFX. However, if you have code that uses an XY function, it's fully supported, simply use matrix->XY(x, y) to let NeoMatrix do the real mapping for you without having to worry about writing/rewriting the mapping function for each potential array.
  • The better and most commonly used API is Adafruit::GFX. Honestly I recommend it because of the sheer number of hardware devices supported by it. It has the downside of only being 16bit color, but if you use it in FrameBuffer::GFX, can you can use 24bit color with it. Its 2nd downside is that on its own, it has no framebuffer, so it is write only. Obviously with Framebuffer::GFX, it does have a framebuffer (which can be a downside on some slower hardware at higher resolutions, see TFT below). To learn more about how to use the GFX API, see https://learn.adafruit.com/adafruit-gfx-graphics-library?view=all
  • LEDMatrix is a better API with more fancy functions than GFX and native 24bpp color, but it's only meant to work on FastLED, and its matrix tiling support and rotation is pretty non trivial to use compared to NeoMatrix. I would only use it if you need its added functionality. On the plus side, Framebuffer::GFX allows you to run LEDMatrix code on any hardware backend, so you aren't limited there anymore. LEDMatrix pluses are
    • more primitives, including some flip/mirror screen options
    • Table_Mark_Estes is just that good, that it's worth having LEDMatrix for
    • LEDMatrix has Fancy Font Support. In my opinion it's more fancy than most people will need, and Adafruit::GFX built in front support is more than plenty, but it's there if you want it.
    • LEDPSprites is nice if you need sprites, see my LEDSprites-Pacman demo

  • The SmartMatrix library has its own 2D API, it is quite fancy and includes layers, but it is not supported by FrameBuffer::GFX, so unless you're writing a SmartMatrix only project (which means you won't be able to upgrade to RGBPanels on rPI if you need a higher resolution), I recommend against using it. Technically, someone motivated could make the API work with FrameBuffer::GFX and allow rendering on another backend, but I haven't done that work and don't have the need to do so. If you'd like to contribute that, please do.
  • The good news is that if you don't want which one to choose Framebuffer::GFX allows you to run all 3 at the same time, thanks to the work done in neomatrix_config.h which while not required, I greatly recommend so that it'll setup everything for you and make it trivial to change from one hardware backend to another one.

    If you would like an example of each API, please go to https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/ and check the demos in each per API directory.

    If you would like to read images from SPIFFS/FATFS (ESP8266/ESP32) or SDcard, see https://github.com/marcmerlin/AnimatedGIFs

    Supported hardware backends

    https://github.com/marcmerlin/FastLED_NeoMatrix/

    64x64 with Neopixels was 2 weeks of build work and 160 Amps at full power!
    64x64 with Neopixels was 2 weeks of build work and 160 Amps at full power!

    https://github.com/marcmerlin/SmartMatrix_GFX/

    FastLED::NeoMatrix in 32x32 and 24x32 vs SmartMatrix::GFX 96x64
    FastLED::NeoMatrix in 32x32 and 24x32 vs SmartMatrix::GFX 96x64

    https://github.com/marcmerlin/FastLED_SPITFT_GFX (SSD1331, ILI9341, and ST7735 TFTs)

    Small SSD1331 in 96x64
    Small SSD1331 in 96x64

    The same exact resolution between RGBPanels and SSD1331
    The same exact resolution between RGBPanels and SSD1331

    comparison of TFTs
    comparison of TFTs

    after extra work to support PSRAM on ESP32, ILI9341 320x240 became possible on ESP32
    after extra work to support PSRAM on ESP32, ILI9341 320x240 became possible on ESP32

    almost the same resolution than my huge RGBPanel driven by rPi
    almost the same resolution than my huge RGBPanel driven by rPi

    https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX (Glue driver for https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix/ that allows displaying a matrix on RGBPanels using https://github.com/hzeller/rpi-rgb-led-matrix )

    My first rPi Display at 192x128
    My first rPi Display at 192x128

    Even bigger, 384x192
    Even bigger, 384x192

    https://github.com/marcmerlin/FastLED_TFTWrapper_GFX (Emulate a TFT screen on linux for https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix/ )

    This is probably the most useful driver I wrote out of all of them, the ability to write your code and debug on linux, without any hardware:


    Dealing with pushing bigger framebuffer sizes to TFTs like ILI9341

    For long the highest resolution target for arduino chips has been the ILI9341 TFTs. With a resolution of 320x240 over SPI, they push the limits of Framebuffer::GFX a little bit, because it's a lot of pixels to push. Unfortunately, the TFT seems to only support about 14 frames per second for a full refresh, which is needed with the framebuffer approach, and by the time you add required use of PSRAM on ESP32, which is slower than regular RAM but required because ESP32 does not have the required contiguous 224KB of RAM, frame refresh falls down to 8fps. Worse, still, once you add computation of data being sent, demos actually run closer to 5fps.
    This is far from ideal, but it's good enough or some uses still, and generally still cool that Framebuffer::GFX can be pushed so far on arduino-like chips. Using RGBPanels does not help there on arduino chipes, because there is no arduino like chip that can run such a resolution on RGBPanels (Raspberry Pi can barely do it though, but that's also pushing the limits of the underlying hardware refresh capabilities).

    It this ends up being a problem, but you made the decision to stick to the Adafruit::GFX API, you always have the option to remove FrameBuffer::GFX and write directly to the TFT, without having to do full framebuffer refreshes.

    If you'd like nubmers, I gathered as part of a test between SPI speed, raw TFT speed (empty frame push), loop to push data not from PSRAM, loop to push data from PSRAM. Actual speed in demos is still lower given that it takes time to generate high resolution frames to PSRAM (double PSRAM penalty, one to write, one to read), before they can be pushed.

    ILI9314: 80Mhz: TFT 40fps, NO PSRAM: 32fps, PSRAM show: 12ps  => unstable, no display
    ILI9314: 40Mhz: TFT 25fps, NO PSRAM: 21fps, PSRAM show: 10fps => unstable, no display
    ILI9314: 39Mhz: TFT 18fps, NO PSRAM: 16fps, PSRAM show:  9fps => unstable, garbled
    ILI9314: 30Mhz: TFT 18fps, NO PSRAM: 16fps, PSRAM show:  9fps => still a bit unstabled, garbled
    ILI9314: 24Mhz: TFT 14fps, NO PSRAM: 12fps, PSRAM show:  8fps => stable
    ILI9314: 20Mhz: TFT 14fps, NO PSRAM: 12fps, PSRAM show:  8fps
    

    ST7735_128b160: 80Mhz: TFT153fps, NO PSRAM:104fps, PSRAM show: 45fps => unstable, no display ST7735_128b160: 60Mhz: TFT 93fps, NO PSRAM: 73fps, PSRAM show: 38fps ST7735_128b160: 60Mhz: TFT 96fps, NO PSRAM: 52fps ST7735_128b160: 40Mhz: TFT 68fps, NO PSRAM: 56fps, PSRAM show: 32fps ST7735_128b160: 20Mhz: TFT 53fps, NO PSRAM: 45fps, PSRAM show: 29fps

    ST7735_128b128: 60Mhz: TFT117fps, NO PSRAM: 90fps, PSRAM show: 48fps => unstable, garbled ST7735_128b128: 40Mhz: TFT117fps, NO PSRAM: 90fps, PSRAM show: 48fps => unstable, garbled ST7735_128b128: 32Mhz: TFT 84fps, NO PSRAM: 70fps, PSRAM show: 41fps => stable ST7735_128b128: 20Mhz: TFT 66fps, NO PSRAM: 56fps, PSRAM show: 36fps

    SSD1331: SWSPI: TFT 9fps, NO PSRAM: 9fps, PSRAM show: 8fps => stable

    Now it's your turn, write your own 2D demos and contribute them back

    https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos would love your code, please contribute :)
    2020/03/13 RGB Panels, from 192x80, to 384x192, to 384x256 and maybe not much beyond
    π 2020-03-13 01:01 in Arduino
    This started with some 64x32 panels that Azerone nicely had amazon send me as they were returned by customers as not working. I also was not able to get them working with either, so I opened a bug with both libraries SmartMatrix or rpi-rgb-led-matrix. Thankfully some nice folks were on it, and eventually found a fix.

    victory, first time I got those new panels to light up
    victory, first time I got those new panels to light up

    I ended up getting 15 such panels from the nice folks at Azerone, because they were returns as other people couldn't use them due to lack of FM6126A support in the open source drivers at the time:

    if only I had proper mounting hardware, this would be a decent 192x160 array
    if only I had proper mounting hardware, this would be a decent 192x160 array

    Ok, after writing this blog, I ended up getting a recommendation for rails, which weren't built for this but worked well enough:

  • rails with holes mostly in usable places: https://www.homedepot.com/p/Everbilt-1-3-8-in-x-36-in-Zinc-Plated-Punch-Flat-Bar-800337/204325640
  • M3 screws and washers: https://www.amazon.com/gp/product/B07FCN64HV/ref=ppx_yo_dt_b_asin_title_o05_s00
  • you'll need something to cut the rails that are too long. I used a set of bolt cutters I had, some saws may work too, but the rails are pretty thick
  • holes don't all match, but enough of them do. Note that I put the panels in Z pattern
    holes don't all match, but enough of them do. Note that I put the panels in Z pattern

    adding power
    adding power

    on my first try, the metal cut the ribbon cable, so I removed the top loop to avoid having it go towards the metal
    on my first try, the metal cut the ribbon cable, so I removed the top loop to avoid having it go towards the metal

    Now, I had an expected problem that hzeller/rpi-rgb-led-matrix did not support panels stacked vertically, never mind if every panel was upside down. I ended up writing a new mapper that allowed both vertical stacking and zig-zag. After that, success was had, end result was about 300Hz for 31K pixels with the active-3 board:




    That said, while that bigger matrix with those 15 panels was 192x160, I had bigger plans. I got distracted due to other work, but then P2 panel appeared (2mm per pixel). The downsides of those panels is that the copper traces are so small that pixels come off easily, including during shipping:


    even pixels that don't pop off can be partially failed
    even pixels that don't pop off can be partially failed

    This was probably the first working demo on rPi of FM6126A at 128x128 with 128x64 P2 Panels from Azerone:

    In no time, I was able to make a display of 192x128 with 3x 64x128 panels and it was the same size as my existing 96x64 screen for my LED shirt:

    using the active-3 board with 3 chains of one panel each on rPi3
    using the active-3 board with 3 chains of one panel each on rPi3

    The first issue was that the newer 128x64 panels were FM6126A, which didn't work with default libraries as they need a special init. Thankfully this was added to rpi-rgb-led-matrix. Next issue was that refresh rate was going to suffer, and that's where the rPi solution is great: it allows for 3 channels in parallel thanks to the nice Electrodragon active-3 board.

    Chow He from Electrodragon was super nice, and sent me some boards with angled connectors (at my request) so that I could make the whole board more flat for my wearable application. I was really hopeful that I could put the connectors under the board for low profile after cutting the notch and moving it to the other side of the connector:


    However, wire routing was such that pins were in the wrong order and it was impossible without re-routing all the wires on the board, so I did the next best thing and put the connector on top of the board, which is still more flush than when it was pointing up:

    before (blue), not working (right), and after (left)
    before (blue), not working (right), and after (left)

    bottom is not possible, even after moving the notch
    bottom is not possible, even after moving the notch

    Still, 192x128 is a very nice display that happens to be the same size as my old 96x64 display using P4 panels, but since I ordered spare panels to get around the falling pixel problem, I had enough panels to make a 9x9 array of 384x192. I first tried with with rpi-rgb-panel's video viewer and it worked quite well:



    During that time, I did a lot of work on 2D APis for Arduino and lots of backends, and wrote the base class, FrameBuffer::GFX. In a nutshell, it allow talking to a lot of hardware displays, now both on Arduino and Raspberry Pi:

    Low Level Drv|Glue Driver for FrameBuffer::GFX
    FastLED     - FastLED_NeoMatrix  -------------\     FastLED CRGB Array 
    SmartMatrix - SmartMatrix_GFX -----------------\    24bit FB storage        API Support
    ILI9341 \                                       \   CRGB methods like
    SSD1331  |--- FastLED_SPITFT_GFX ----------------\  scale8/fadeToBlackBy   ,FastLED API
    ST7735  /                                         |        |              / (XY 2D to 1D mapping)
                                                      |        |             
    ArduinoOnPc-FastLED-GFX-LEDMatrix arduino - FrameBuffer::GFX------ Adafruit::NeoMatrix + emulation for linux / Raspberry Pi: | | \ Adafruit::GFX APIs ---------------------------------- / Adafruit::GFX \ rpi-rgb-led-matrix - FastLED_RPIRGBPanel_GFX ---/ LEDMatrix (optional) `LEDMatrix API ArduinoOnPC X11/linux - FastLED_TFTWrapper_GFX
    FastLED_SDL (linux) - FastLED_NeoMatrix -/

    Given that work, it was time to try my arduino code on this panel, using my freshly written FastLED_RPIRGBPanel_GFX on top of ArduinoOnPc-FastLED-GFX-LEDMatrix as explained my page Running FastLED, Adafruit::GFX, and LEDMatrix code on High Resolution RGBPanels with a Raspberry Pi:

    it's pretty big :)
    it's pretty big :)

    This first demo of simple demo code that scaled up pretty quickly, explaining some of the challenges of scaling past 256 pixels in any dimention and 64K pixels total which hits a FastLED uint16_t limit:

    This is an early demo of my shirt code running on a display that is so much bigger than what it was built for:

    After some work to find a couple of crash bugs that came from scaling up, I was able to run Mark Estes' fantastic demo code I was able to scale up to such big displays without too much trouble. See Table_Mark_Estes1 and 14.








    Table_Mark_Estes:

    Table_Mark_Estes14:

    Just put back an idea of scale between my first panel at 24x32, all the way up to 384x192. Yes, those are the exact same sprites with LEDSprites:

    While 384x192 is starting to push the physical refresh limits that are acceptable for a 3 parallel chain setup, I'm going to try 384x256 for fun once I can get the pixel mapping to be correct. Bigger than that will require multiple control boards and synchronization by some network:

    this was my first attempt, panel mapping didn't work, I'd have to write my own
    this was my first attempt, panel mapping didn't work, I'd have to write my own

    Interestingly, SamrtMatrix adds panels in the vertical direction by default, while rpi-rgb-led-matrix adds them horizontally. This means I had to write a new Mapper for it: V-Mapper, which allowed me to make 3 parallel horizontal chains. The end result is not great as refresh rate is only 100Hz, but it works:

    success!
    success!

    that was a lot of work for a low resolution screen :)
    that was a lot of work for a low resolution screen :)

    video still plays
    video still plays


    New pictures of Table_Mark_Estes in the higher resolution:




    As above, thanks again to Chow He from Electrodragon for the great and cheap active-3 boards, and big thanks to Hongren Su from Azerone for selling me the panels I have used so far. You can find the Azerone store on amazon for panels you can buy and the 128x64 P2 Panels here.
    On the software side, many people to thank, but obviously I wouldn't have gotten started with Adafruit, Louis Beaudoin for SmartMatrix on arduino chips, and Henner Zeller for rpi-rgb-led-matrix of course.

    Now, I have no excuse (well, still a lot of work actually) for not doing an even more fancy LED shirt display (read all about this silly hobby here)

    2020/01/24 Running Arduino code with 2D FastLED, Adafruit::GFX, and LEDMatrix displays on Linux
    π 2020-01-24 01:01 in Arduino
    As part of writing my driver/port to run 2D FastLED, Adafruit::GFX, and LEDMatrix on RGBPanels using a Raspberry Pi, I ended up improving ArduinoOnPc to support X11 or SDL and serial input support on linux.
    In the process I added drivers/configuration in neomatrix_config.h to support 3 more display drivers supported by my fork of ArduinoOnPc

  • LINUX_RENDERER_SDL uses ArduinoOnPc's built in FastLED Emulation which allows running native FastLED::NeoMatrix
  • LINUX_RENDERER_X11 uses a quick and dirty driver I wrote: https://github.com/marcmerlin/FastLED_TFTWrapper_GFX
  • Both allow running your basic 2D code written either of Adafruit::GFX, and LEDMatrix, or 2D FastLED on your linux computer:



    There is basic serial input/output emulation to allow you to interact with serial debugging on your arduino code when run on linux, and of course you can run the code under gdb.

    You can find all the code and installation/usage instructions here: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos

    2020/01/14 LCA 2020 Talk, ESP32 Memory Management, Neopixels and RGBPanels
    π 2020-01-14 01:01 in Arduino
    As part of LCA 2020, I gave a quick talk at the Open Hardware Miniconf about a year's worth of work in ESP32 and upgrading my Shirt from 24x32 neopixels (P10) to 64x96 in RGBPanels (P4), giving me almost 10x more pixels.
    Running lots of demo code at 96x64 in 24bpp, storing 2 framebuffers for page switching, plus bitplanes for PWM, it ended up significantly stressing the amount of fragmented memory available on ESP32, so this talk deals with what I learned and how to get around the limitations.

    Then, I also brought a demo of my next version using Raspberry Pi and displaying a framebuffer of 128x192, using FastLED_RPIRGBPanel_GFX I wrote for the occasion :)


    Demo of 64x96 with ESP32 and 128x192 on Rasberry Pi
    Demo of 64x96 with ESP32 and 128x192 on Rasberry Pi


    Talk video below:

    2020/01/14 Linux.conf.au Open Hardware Miniconf 2020: Dingo Car with Tensorflow Video Analysis v2
    π 2020-01-14 01:01 in Arduino, Electronics, Linux
    Another LCA, another Open Hardware Miniconf. This year was an improved version of the Dingo Car from last year.

    Jon, presenting the miniconf as per how many
    Jon, presenting the miniconf as per how many





    Raspberry Pi running the car
    Raspberry Pi running the car



    This year's dingo car, controlled by the rPi
    This year's dingo car, controlled by the rPi

    All done
    All done

    Andy presenting the software side of the car
    Andy presenting the software side of the car

    We then trained our cars' neural network by manually driving them arount the track:


    and before long, I got my car to drive around on its own
    and before long, I got my car to drive around on its own

    Here is a video of my car driving on its own, including how it learned to drive:

    During the miniconf, I also gave a talk on my recent LED panel/ESP32 work and brought my recent RGBPanels:


    2020/01/01 Running FastLED, Adafruit::GFX, and LEDMatrix code on High Resolution RGBPanels with a Raspberry Pi
    π 2020-01-01 01:01 in Arduino
    RBGPanels are a pain to drive, they require constant refreshing and it becomes more of a problem when you aim for higher resolutions (128x128 and above), as they require more horsepoewr and memory than either a teensy 3.6 or ESP32 can reasonably provide (the two top of the line chips supported by SmartMatrix)

    Another issue is that SmartMatrix, while better than all the other libraries on arduino, doesn't support all kind of weird panels out there, specifically the AB and AC panels that you often end up getting when you get higher resolutions like 128x64.

    Using Neopixels would work better of course, but they caan't reasonably be had in less than P5 (0.5cm/LED) while RGBPanels go down to P2. Also, neopixels are about 10X more expensive per pixel, if not more.
    So, the solution is to use a rPi to drive RGBPanels of size 128x128 and larger (a single Pi with 3 parallel channels can reasonably run up to 256x256. After that it gets harder and you need multiple microcontrollers).

    This is where the excellent https://github.com/hzeller/rpi-rgb-led-matrix driver comes in. It's the most feature complete RGBPanel driver for microcontrollers

    Ok, but you have all this arduino code, maybe written for a FastLED::NeoMatrix or Adafruit::NeoMatrix array using the Adafruit::GFX API. Or maybe, you used the FastLED API with an XY mapping function, or maybe even you're using the LEDMatrix API for FastLED. None of those work on rPi, and you don't want to change/rewrite your code.

    Well, there is good news: you can use https://github.com/ChrisMicro/ArduinoOnPc to run arduino code on PCs, and therefore also rPi. It is however designed to display in an X11 windows, which is not what you'd want. So, instead, I forked it for you and wrote a rPi glue driver for my FrameBuffer::GFX base class: https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix

    You therefore end up getting access to those 3 arduino graphics APIs, and you can render on rPi using a much faster and the more feature complete https://github.com/hzeller/rpi-rgb-led-matrix driver

  • https://github.com/marcmerlin/Framebuffer_GFX is the base class you need for access to the 3 APIs I mentionned
  • https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX is the driver that glues rpi-rgb-led-matrix with ArduinoOnPc
  • https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix is my fork that adds a few fixes and git submodules for required libraries and demo code.
  • And this is what the end result, looks like with a cool resolution of 128x192 with 3 panels of 128x64 run in parallel with the active-3 board from https://github.com/hzeller/rpi-rgb-led-matrix/tree/master/adapter/active-3




    By using these driver options, I get about 400Hz refresh rate on rPi3, lowering the amount of pwm bits:
    ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-bits=7 --led-panel-type=FM6126A -D0

    Those variables are assigned when you create "rgb_matrix::Canvas *canvas", which is fed into matrix->setCanvas(). See this example code:

  • https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/022257656e2f1beabe327e88bb96747c0fc955f9/neomatrix_config.h#L262
  • https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/022257656e2f1beabe327e88bb96747c0fc955f9/neomatrix_config.h#L697
  • With rPi, especially with the active-3 board you can drive resolutions of at least 256x256. Here is an example of 128x192, 4 times bigger than the highest resolution I was ever able to drive on ESP32 (64x96). Here is a video natively playing on rPi:


    Well, actually 2 months later, I was able to get to the probably max achieveable resolution, 384x256, see RGB Panels, from 192x80, to 384x192, to 384x256 and maybe not much beyond

    384x192 resolution with 9 panels
    384x192 resolution with 9 panels

    384x256 resolution with 12 panels
    384x256 resolution with 12 panels

    2019/05/26 FastLED_SPITFT::GFX on top of Framebuffer::GFX for SPI TFTs like SSD1331 or ILI9341
    π 2019-05-26 01:01 in Arduino
    Show me the code! Sure:
  • https://github.com/marcmerlin/FastLED_SPITFT_GFX (SSD1331, ST7735, or ILI9341 on top of FastLED CRGB 2D Matrix)
  • https://github.com/marcmerlin/Framebuffer_GFX
  • Framebuffer::GFX

    After writing my 3rd backend glue driver (SSD1331 SPI TFTs) that supports Adafruit::GFX, FastLED CRGB's primitives (nblend, dim, etc...) and matrix mapping via XY() function, and LEDMatrix which is another GFX like API on top of FastLED, I realized that I had to factor that out into a new base class I called Framebuffer::GFX:
    https://github.com/marcmerlin/Framebuffer_GFX

    That new base class takes all the GFX glue and color support I mixed (GFX RGB565, FastLED CRGB structs (RGB888 24bit), and uint32_t backed 24bit RGB888 colors, and creates a virtual framebuffer compatible with FastLED and SmartMatrix (which thankfully can use the same 3 byte per pixel array type).
    Framebuffer::GFX in itself is only a framebuffer storage and method holder, but it contains so much common code that my 3 drivers that use it are only a few dozen lines of code after inheriting from it.

    Here is the list of drivers I've written against Framebuffer::GFX:

  • https://github.com/marcmerlin/FastLED_NeoMatrix
  • https://github.com/marcmerlin/SmartMatrix_GFX
  • https://github.com/marcmerlin/FastLED_SPITFT_GFX (SSD1331 and ILI9341 TFTs)
  • Here is an example of code ultimately running on top of Framebuffer::GFX with FastLED::NeoMatrix on ESP8266 (24x32 and 32x32) and SmartMatrix::GFX on ESP32 (64x96):


    Below is the same code again now running on top of FastLED_SPITFT::GFX on an SSD1331 96x64 TFT screen:


    FastLED_SPITFT::GFX

    SSD1331

    FastLED_SPITFT_GFX, the last driver I wrote, takes any Adafruit SPI TFT object (like SSD1331 and ILI9341), and a FastLED CRGB array. You then tell it the size of each (it's up to you not to make mistakes or you can create buffer overruns), and the overloaded show() method will send the framebuffer to the TFT (it is done line by line with an SPI copy method):
  • FastLED_SPITFT_GFX(fb, 96, 64, 96, 64, ssd1331, 0) for unrotated
  • FastLED_SPITFT_GFX(fb, 64, 96, 96, 64, ssd1331, 1) for a 90 degree rotation
  • Here is the end result, an ESP8266 running LEDMatrix code rendered in Framebuffer_GFX, downsampled from 24bit color to 16bit color, rotated and copied line by line to a SSD1331



    Here is a video of Jason Coon's Aurora in 64x96 rotated to the SSD1331 96x64 resolution:

    It's ironic that normally Neopixel matrices look like they have huge pixels compared to RGBPanes, but here my 64x96 RGBPanel looks huge compared to the same resolution on SSD1331:



    rotating 3D cube with temporal fade
    rotating 3D cube with temporal fade

    Table from Mark Estes Video Demo:

    ST7735 or ILI9341

    Thankfully Adafruit wrote other TFT drivers like ST7735 and ILI9341 against the same Adafruit_SPITFT object from Adafruit-GFX, so I was able to target that tft object in FastLED_SPITFT::GFX and get the same code to work with other TFTs without any modifications.

    As a result, all you need to do is to pass the different tft object, display size, and everything else works.

    Adafruit_ILI9341 *tft = new Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST);
    or
    Adafruit_ST7735 *tft = new Adafruit_ST7735(TFT_CS, TFT_DC, TFT_RST);
    FastLED_SPITFT_GFX *matrix = new FastLED_SPITFT_GFX(matrixleds, mw, mh, mw, mh, tft, 0);

    For comparison, SSD1331 vs ST7735 128x128, ST7735 128x160 from 2 different vendors and slightly different chips, and ILI9341 with a full 320x240 which stretches the limit of this library since it requires 225KB for that many pixels and that only fits on a teensy 3.5/3.6:

    the SSD1331 screen is off as it's not compatible and requires different code to turn on
    the SSD1331 screen is off as it's not compatible and requires different code to turn on

    ST7735R vs ST7735S chip revisions show a few differences
    ST7735R vs ST7735S chip revisions show a few differences

    brightness is also different
    brightness is also different




    code for the 128x128 ST7735 doesn't mis-display the same on the two 128x160 displays
    code for the 128x128 ST7735 doesn't mis-display the same on the two 128x160 displays

    Some demos showing 128x128 and 128x160 on multiple size screens (for physical size comparison):

    7 months later, I was also able to make Framebuffer::GFX working on ESP32 after adding PSRAM support as the fragmented ESP32 memory didn't have the 224KB of required contiguous RAM. It was barely working on teensy 3.6 which didn't have this problem, but it was still very low on RAM to run anything while storing such a big framebuffer. The other issue is that it's slow to push a framebuffer of that size over SPI at 24Mhz, in real life I'm only seeing 5fps or so on ESP32 due to the delays of reading from PSRAM. With more optimizations, it could maybe reach 12fps or more (the actual TFT can do 25fps at 40Mhz and maybe 40fps if wiring allows for 80Mhz):

    ILI9341 is slightly compatible with the ST7735 screens, shown for scale here
    ILI9341 is slightly compatible with the ST7735 screens, shown for scale here

    ESP32 Pro with PSRAM needed to store the ILI9341 framebuffer. Display not too compatible with ST7735
    ESP32 Pro with PSRAM needed to store the ILI9341 framebuffer. Display not too compatible with ST7735

    zoomed in ILI9341 is very nice resolution
    zoomed in ILI9341 is very nice resolution

    Hopefully this is useful to you and by using the FastLED_SPITFT::GFX API, you can re-use your code on TFTs, FastLED::NeoMatrix and SmartMatrix::GFX.

    2019/04/27 Comparing FastLED::NeoMatrix and SmartMatrix::GFX with PixelMatrix Aurora and Table ME Demos
    π 2019-04-27 01:01 in Arduino
    Comparing is a misnomer, both libraries pretty much offer the same exact APi (which is the point).
  • https://github.com/marcmerlin/FastLED_NeoMatrix
  • https://github.com/marcmerlin/SmartMatrix_GFX
  • pretty much work exactly the same except for how you init them, but if you use https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/master/neomatrix_config.h , you can just include that and your same code will work on both FastLED backed matrices and SmartMatrix backed matrices, even though they are totally different technologies.

    RGBPanels do use less power even when corrected for amount of brightness generated (my estimate is at least 3 times less), they can be a lot more dense, they're cheaper, but they're a pain in the ass to drive since they require constant refreshes at high speed. That being said, as long as you don't exceed 128x64, which is more or less the practical limit on teensy 3.6 and ESP32 due to memory limits due to how SmartMatrix works (a different implementation could push things to at least 128x128 by sacrificing quality for memory use).

    The demos I used for the pictures below are

  • Aurora: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/tree/master/GFX/Aurora
  • Table from Mark Estes: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/tree/master/LEDMatrix/Table_Mark_Estes
  • Here are some shots of Aurora in 32x32 and 32x24 with FastLED::NeoMatrix vs 64x96 with SmartMatrix:





    Video:

    And then shots of Table from Mark Estes in 32x32 and 32x24 with FastLED::NeoMatrix vs 64x96 with SmartMatrix:






    Video:

    2019/04/08 Clubbing, EDM Festival and Burning Man LED Pants and Shirt v4 on ESP32 with RGBPanels and SmartMatrix::GFX
    π 2019-04-08 01:01 in Arduino, Bm, Clubbing
    ===>>> See this full article on the why and evolution of my LED outfit <<<===

    Show me the code:

  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR (same code than my previous shirt, but upgraded for the higher resolution)
  • https://github.com/marcmerlin/SmartMatrix_GFX (API on top of SmartMatrix from Louis Beaudouin, without which this new shirt wouldn't have been possible)
  • https://github.com/marcmerlin/AnimatedGIFs (also original from Louis Beaudouin).
  • https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos (includes Aurora from Jason Coon, and Table code from Mark Estes)
  • Related pages:

  • Shirt V2
  • Shirt V3
  • SmartMatrix GFX I had to write (including Teensy with SmartMatrix v4 shield vs ESP32)
  • Using FatFS on ESP32 to store Animated GIFs
  • Diffusers for RGBPanel
  • Details: After version 3 of my shirt with a neopixel matrix, I had good fun, but was hoping to do more. Its resolution was only 24 x 32 pixels, enough to display fun patterns, but it's really not a lot of pixels.


    After months and months of work, here is version 4:


    Video demo:

    Sadly, going up in resolution with addressable pixels, is not that easy. While in theory you should be able to fit at least 2 addressable pixels per centimeter (aka P5). Currently my premade panels are P10, which is the only thing I could buy pre-made.

    What allowed me to switch were those flexible P4 RGB Panels from Azerone: https://amazon.com/gp/product/B07F87CM6Y


    With their P4 resolution, I'm able to fit 96x64 on my body using 3 panels of 64x32 chained together. The 3rd panel is then chained to the 2nd set of 3 panels in my back:


    On the old shirt, I put the rear panel inside the shirt, using the shirt as a diffuser, but with the RBGPanels, they were too thick for this to be practical, so I had to put them on top of the shirt. As a result, I ended up uing a black shirt which matches the color of the panels. I had to attach velcro to the new shirt, and confirmed that supergluing them was so much faster than sawing, and worked just as well:


    I unsoldered the power connectors that were too thick, and used small metal wire to connect the panels together (see top middle of the picture). Turned out those metal wires were a mistake as they can cause shorts on the LEDs on the other side of the board:


    Another thing I learned was that the holes I was using to put a metal wire to carry the panels over my shoulders, can't actually take the load, and the wire can cause damage to the copper trace that is just next to the hole. As a result, I replaced the metal wires with fishing wire and didn't use the bigger holes for load bearing:


    Speaking of removing thickness from the board, I removed the top of the ribbon connectors to make them a bit thinner. Sadly, RGBPanels still require 15 wires to send the video signal:


    I then took one panel and covered it with defusing foam (the rear panel, so that it's not too sharp and blinding to people behind me), while the front panel only has the plastic cover to protect the panels and offer a bit of extra diffusion:




    you can see the difference between the diffusion levels
    you can see the difference between the diffusion levels

    I then protected the rear of the panels given how much electronics were exposed:


    Small details had to be solved, like making sure I had enough amps going through the wires (use thicker wires). Without that, my brightest pattern that uses 8 amps, didn't quite make it:


    For fun, I made a pattern that scrolls my C++ scrolling code on the screens:


    As for the CPU that runs it, I picked the ESP32 since it's dual core and can do refreshes on one core while running code on the other core. My SmartMatrix::GFX page has more details on using ESP32 with SmartMatrix


    I went from a breadboard prototype to Jason Coon's ESP32 level shifter board, much more tidy
    I went from a breadboard prototype to Jason Coon's ESP32 level shifter board, much more tidy

    This video shows how things are wired from the ESP32 to the panels:

    Here is what the whole power system looks like:

  • 2 4S Lipos, 5Ah, 80wh, giving a total 160Wh of energy
  • Amp meter in line with the lipos and cell tester with low voltage warning buzzer
  • On off/switch
  • Amp gauge with timer to know how much energy flowed from the batteries (you can't run lipos down or they'll die)
  • Tobsun DC-DC converter to take voltage down to 5V
  • 2nd voltage regulator to bring the voltage further down to 3.3V for the El Wire glasses
  • 5V goes to RGBPanels via separate thick wire to carry the amps
  • ESP32 with level shifters from 3.3V back up to 5V for the RGBPanels (6 channels for the colors to level shifters, 4 address lines to do 16 scan line refreshes). CPU runs SmartMatrix::GFX and NeoMatrix-FastLED-IR
  • 16th data line is used for the Neopixel strips on my arms and legs, running the same code than the previous shirt
  • Walk through video:

    I have around 60 demos running on the panels, including some Animated Gifs on ESP32 FFat with the library I was able to improve:





    Here is an example of 3 levels of diffusers, including a raw set of panels with no diffusers:










    After going to Luminosity Beach Festival, a underpaid and undertrained security guard at the entrance freaked out at the wires, so I made boxes to hide the wires and hopefully remove the "OMG, it's a bomb" reflex that some people might have:

    2 batteries, fuse, meters and output
    2 batteries, fuse, meters and output

    adapter box that takes 16V down to 5V and measures current used while distributing power
    adapter box that takes 16V down to 5V and measures current used while distributing power

    both boxes together are bigger than my previous setup, but looks a bit better
    both boxes together are bigger than my previous setup, but looks a bit better

    You can see a demo of the outfit being worn:

    The flexible panels sadly kept breaking, Azerone was super nice in offering to fix them, see the thin patched wires they added, expert work I'm not capable of:



    I first tried strenghtening them with light wood, but it still wasn't solid enough, and a waste of time, they still ended up breaking:


    I ended up switching to hard panels, I should have used them for the start, They've been a lot more solid:

    after vs before
    after vs before

    After switching to the hard panels, which are indeed a bit thicker but not unbearably so, everything has been rock solid.

    If you don't have time for all this, and are ok with 64x64, you can try this backpack from gearbest with everything built in and a very thin board. Just not fun for me because I can't run my own code on it:



    2019/04/01 SmartMatrix, SmartMatrix Shield v4 for Teensy, ESP32 shield with level shifter, and SmartMatrix::GFX
    π 2019-04-01 01:01 in Arduino

    Less blah-blah, more code

    Sure, there you go: https://github.com/marcmerlin/SmartMatrix_GFX

    What is it?

    https://github.com/marcmerlin/SmartMatrix_GFX is a zero copy, zero extra buffer frontend to Smartmatrix, which is the best arduino API driver for RGB Panels.
    It supports these 4 APIs seemlessly and concurrently in the same code:
  • Adafruit::GFX https://github.com/adafruit/Adafruit-GFX-Library
  • FastLED https://github.com/FastLED/FastLED
  • LEDMatrix https://github.com/Jorgen-VikingGod/LEDMatrix
  • SmartMatrix https://github.com/pixelmatix/SmartMatrix
  • Give me Examples

    Sure: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos

    This page that shows how I built my EDM Festival and Burning Man LED Pants and Shirt v4 on ESP32 with RGBPanels and SmartMatrix::GFX using this library.

    More blah-blah & rationale for SmartMatrix::GFX

    Last year, I wrote FastLED::NeoMatrix to let me run Neopixel Matrices made out of pre-made panels arranged as a bigger panel. This was the end result: http://marc.merlins.org/perso/arduino/post_2018-04-23_FastLED_NeoMatrix-library_-how-to-do-Matrices-with-FastLED-and-Adafruit_GFX.html

    This allowed me to do my Party shirt v3 based on a NeoPixel Matrix

    However, the main problem I had was the limited pixel density of those neopixels and the price per pixel given that each pixel has a very small computer chip attached. My shirt was only 768 pixels per side (32x8x3) which cost $80 per side. While my shirt looked cool (i.e. better than nothing), 32x24 resolution isn't that much to display cool stuff. I made the best of it, but I knew that I wanted more pixels.
    While it's technically possible to get 0.5cm pitch (i.e. P5) with nepixels, there is no such panel I could buy today and I wasn't really interested in fabbing my own, so I switched to RGBPanels.

    What allowed me to switch were those flexible P4 RGB Panels from Azerone: https://amazon.com/gp/product/B07F87CM6Y


    RGBPanels are a totally different technology based on row scan technology, pretty much like the 8x8 matrices I wrote a scanning driver for but with a built in shift register to load up all the column for each color, multiplied by 2 as for historical reasons you can update 2 halves of the panel separately.
    With 32x64 panels, or even 64x64 panels, that's a lot of pixels to push serially via shift registers and address lines to select the line you've currently pushed all those columns for. The LEDs need to be refreshed very quickly to avoid visible flickering.
    This limits the list of reasonble CPUs for higher resolutions to teensy 3.6 and ESP32, which also removes the multiple slower and/of inefficient drivers out there. Options I looked at and weren't suitable:

  • https://github.com/adafruit/RGB-matrix-Panel/ (the adafruit driver is actually efficient, and recently got ESP32 support, but does not support panel chaining past very basic chaining)
  • https://github.com/mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA/ (not well tested for larger chained panels, but efficient with DMA and offers Adafruit::GFX API. It also supports page level refresh instead of line level, so flickering is more manageable on it)
  • https://github.com/2dom/PxMatrix ( supports ES8266, but is 6 times slower than normal drivers by shifting all 6 colors onto a single wire ( https://community.pixelmatix.com/t/has-anyone-used-https-github-com-2dom-pxmatrix/384 ) ).
  • https://github.com/NeoCat/ESP32-P3RGB64x32MatrixPanel is an alternate driver with DMA support and apparently unsupported. This driver seems unsupported and probably not worth your attention when you have SmartMatrix (teensylc branch) or mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA
  • This leaves us with the most complete driver of them all, Smartmatrix. The main pluses are:

  • Great support from the author on https://community.pixelmatix.com
  • Best support for chaining panels (up to 128x128 on teensy, and maybe 64x128 on ESP32 before it runs out of DMA RAM)
  • High color depth 24bpp or higher (which honestly is more than I need, 24bpp is more than most panels can probably reasonably show and 16bpp would likely be enough for my use). I still wouldn't mind if SmartMatrix offered 16bpp in exchange for a higher refresh rate or lower resource and memory utilization (also allowing for a higher resolution on a given CPU)
  • Support for the 2 fastest common arduino like microcontrollers: teensy 3.6 and ESP32 (teensy 3.1/3.2 is not fast enough to refresh 64x64 well enough, and teensy 3.5 is slower than 3.6, so no reason to buy one)
  • Very powerful API with multiple layer support (great if you can use it, although I'll admit that I only need drawpixel thanks to Adafruit::GFX)
  • So, SmartMatrix is great, but I have all this code that relies on one or more of those APIs:

  • Adafruit::GFX https://github.com/adafruit/Adafruit-GFX-Library
  • FastLED https://github.com/FastLED/FastLED
  • LEDMatrix https://github.com/Jorgen-VikingGod/LEDMatrix
  • I have a reasonble collection of demos I've gathered (a few I wrote myself), here: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and they use a combination of those 3 APIs.
    The goal was for me to be able to re-use that code and make it work on both FastLED backends and SmartMatrix backends, which why I wrote SmartMatrix::GFX
    https://github.com/marcmerlin/SmartMatrix_GFX offers a GFX compat layer that is virtually identical to my FastLED::NeoMatrix library and allows you to run the same code onto of either FastLED or SmartMatrix supported panels.

    Hardware, Teensy 3.6 and SmartMatrix Shield v4

    The easiest way to use SmartMatrix is to use the SmartMatrix Shield v4 from Louis Beaudoin.
    If you are going to drive 64x64 and above, skip the teensy 3.0/3.1/3.2 and go directly to teensy 3.6. It costs more, but you'll want the extra CPU speed (teensy 3.1 can barely run 64x64 with an ok-ish refresh if you overclock it, if you must use the older chip).

    Here is what the SmartMatrix shield looks like with a small patch I made to take USB power and send it to the panel (my laptop can output 2A over USB). Note that this is not safe with teensy v3.1/3.2 as it's not meant to pass that much current from its USB connection, but teensy 3.6 can do it fine as its fuse is located after the V+ connection on the chip:

    Originally I used the APA connector to send power to the panel
    Originally I used the APA connector to send power to the panel

    2x 32x64 chained P4 panels with a sad cable extension I had to make, vs pre-made 64x64 P3 panel
    2x 32x64 chained P4 panels with a sad cable extension I had to make, vs pre-made 64x64 P3 panel

    SmartMatrix basic demo
    SmartMatrix basic demo

    The main problem with RGBPanels is that if the refresh rate isn't fast enough, they look bad on pictures. This is the main reason I switched to ESP32 which is dual core and can push a higher refresh rate via DMA than teensy can:


    Chained panels giving mirrored output on a total display of 128x96:


    Teensy v4 is still work in progress, read here: https://forum.pjrc.com/threads/60337-LED-Matrix-driver-for-T4-0-using-FlexIO-parallel-out-FlexPWM-DMA-amp-SmartLED-shield

    Hardware: ESP32

    As mentioned above, ESP32 is dual core, so it can update the panel on one core using DMA, while the other core can run your code. It is more efficient, however, it runs out of DMA memory around 64x128 resolution (I run 64x96 myself and had to optimize code to make things fit)..

    Here are shots of what it looks like with Jason's shield:

    it's reasonably compact, 15 IO's for SmartMatrix (14 are really required), IR connected to port 34, and IO 16 connected to a NeoPixel strip
    it's reasonably compact, 15 IO's for SmartMatrix (14 are really required), IR connected to port 34, and IO 16 connected to a NeoPixel strip

    This shows my flexible P4 96x64 panels I bought on amazon from Azerone, 3 tied together, one shown upside down for scale, a blank shield from Jason Coon, how I cut a 16 pin IDC ribbon cable and made it an in line row of pins I can connect into Jason's shield after having added a riser, and a patched board with IR connector on the back, and a yellow wire to redirect the pin Jason's board connected to RX which I use for debugging, to unused pin 27 instead:


    While Jason's board is not perfect for this use, it's much better than my self made protoboard full of wires to connect the 74hc245 level shifters:


    Here's a quick video summary that shoes the wiring and layout:

    Tips for ESP32 and memory:

  • Do not use arrays, ESP32 does badly with array allocation for complicated reasons and bugs ( https://github.com/espressif/arduino-esp32/issues/2567 )
  • See also https://community.pixelmatix.com/t/esp32-runs-out-of-some-ram-when-using-64x96/394 for more background
  • And how SmartMatrix will crash if it can't allocate enough DMA RAM at startup (again, switch your code to use malloc and allocate after you've ran SmartMatrix init): https://community.pixelmatix.com/t/cant-get-enough-dma-memory-on-esp32-assertion-matrixupdateframes-1-null/406/19
  • SmartMatrix.begin(xxx) lets you force SmartMatrix to use less RAM and use more lsbMsbTransitionBit which makes display worse but can help
  • More details on what memory is available on ESP32: https://github.com/espressif/esp-idf/issues/1934#issuecomment-389087100
  • Another ESP32 corner case bug I found if you use global static arrays: https://github.com/espressif/esp-idf/issues/3211
  • Do not even think about using local arrays in functions, that's worse as they go on the stack and will smash the stack (I think you're limited to around 8KB)
  • ESP32 has SPIFFS to use its flash to store data like Animated GIFs. You will find it unacceptably slow if you store 1MB or more and seek across a bunch of files, Instead, use FatFS as explained here:

  • http://marc.merlins.org/perso/arduino/post_2019-03-30_Using-FatFS-FFat-on-ESP32-Flash-With-Arduino.html
  • https://github.com/marcmerlin/esp32_fatfsimage
  • Make sure you use FFat.begin(0, "", 1) to save RAM
  • SmartMatrix Support:
    Louis Beaudoin added ESP32 support in this branch https://github.com/pixelmatix/SmartMatrix/tree/teensylc .
    You'll want to look at this file for how to wire your ESP32: https://github.com/pixelmatix/SmartMatrix/blob/teensylc/src/MatrixHardware_ESP32_V0.h#L62
    While you can apparently get away with no using a level shifter (at least with some panels), I chose to use one. First, I did it the hard way with a protoboard and level shifter chips, and then I switched to Jason Coon's 16 output ESP32 shield.
    I then used a HUB75 ribbon, cut the end, and made a straight connector that went directly into the IO pins coming fromthat shield

    Here are pictures of what it looks like:


    Hopefully in the near future, one will be able to buy a pre-made ESP32 SmartMatrix shield.

    End result

    Here are some demos of https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and https://github.com/marcmerlin/NeoMatrix-FastLED-IR on top of SmartMatrix with 2 chained subpanels of 64x96 (each made out of 3 64x32 panels):













    As a side note, RGBPanels look better when you have a diffuser sheet in front, so here is a page on that.

    Transition to Hard Panels

    The flexible panels sadly kept breaking, Azerone was super nice in offering to fix them, see the thin patched wires they added, expert work I'm not capable of:



    I first tried strenghtening them, but it still wasn't solid enough, and a waste of time:


    I ended up switching to hard panels, I should have used them for the start, They've been a lot more solid:


    after vs before
    after vs before


    More pages: March 2020 January 2020 May 2019 April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011

    Contact Email