Add support for ESP32 Architecture

[esven]

This commit is tested with the 16x32 RGB Panel and an ESP32 NodeMCU Development Board.

Signed-off-by: Sven Ebenfeld sven.ebenfeld@gmail.com

[ladyada]

neat! can you verify this still works with an AVR/SAMD board after the changes? we dont want to break backcompatibility!

[esven]

Unfortunately I do not have those boards available at the moment. But my changes should not affect the compilation of either architectures. I'll try to generate a proof for that.

[esven]

I have tried to compile the changes for Arduino UNO and Adafruit METRO M0 Express with and without my Patch. The compilation works in all cases. (For both boards with and without the patch).

Then I tried to check if my patch changed the compilation output (The .elf file) Unfortunately, it did. Probably, because some line numbers changed in the files. After removal of the "-g" parameter in the platform.txts, the compilation process created identical output with and without my changes.

For all the steps, I used the plasma16x32 example.

4529b396f4919699741fb368b3e130e24d7734da uno-before_plasma16x32.ino.elf 4529b396f4919699741fb368b3e130e24d7734da uno-after_plasma16x32.ino.elf

02f2c53627b05bc5d70e0c0d90d7584c87810f6f samd-before_plasma16x32.ino.elf 02f2c53627b05bc5d70e0c0d90d7584c87810f6f samd-after_plasma16x32.ino.elf

This is imho the proof, that my patch does not break or modify existing architectures in the library.

[esven]

Just for information, it works for me if I use the following configuration and pinout:

#define CLK 4 // USE THIS ON ESP32
#define OE   0
#define LAT 2
#define A   12
#define B   13
#define C   14

const uint8_t rgbpins[] = { 17,18,19,21,22,23 };
// Enable double buffering
RGBmatrixPanel *matrix = new RGBmatrixPanel(A, B, C, CLK, LAT, OE, true, (uint8_t *)rgbpins);

[esven]

When will you be able to review this pull request?

[ladyada]

no ETA but when its tested we'll merge it in! :)

[marcmerlin]

@ladyada to be clear, by "tested" you mean that you still would like to run it on your own hardware to verify that it didn't break anything even though @esven already checked that his patch didn't change a single byte of the binary for uno and samd?

[ladyada]

yep! you'd be surprised how code that 'obviously should still work' ... sometimes doesnt :)

[esven]

Great, thank you! Will you create a new release of the library or shall I modify the examples to work with ESP32 as well? I've not used the Featherwing as it does not contain level shifters. But I could check if the Pinout would work as well.

[ladyada]

esven, you could add an example just for ESP32 and submit a new PR - ideally getting it tested aginst the featherwing would be best!

[esven]

I've checked compatibility to the FeatherWing with the HUZZAH32 Feather. Unfortunately, it is not compatible out of the box with my patch as the color and address pins are spreaded over both GPIO output registers. I think it would work with a little modification so that both output registers are set with each clock cycle. But there is still the issue with the 3.3V logic level of the ESP32 vs. the 5V logic level of the Matrix. Do you think it will work anyways?

I will have a look into that within the next days. This would also remove the constraint that the data pins need to be on the same PORT (or GPIO register).

I will also have a look into the formatting of the code.

[ladyada]

esven, that would be really helpful because it would be a plug n play solution. we find that for most matricies, 3.3v logic works fine 😁

[esven]

I just tried to make the code compatible to HUZZAH32 Feather and the RGB Matrix Featherwing. Unfortunately, it is not possible without hardware modification. The B & C Address pins are routed to GPIO 36 and GPIO 39 of the ESP32. But the API Reference says "GPIO34-39 can only be set as input mode and do not have software pullup or pulldown functions."

I've modified the code, so that it should be working with the RGB pins spreaded over the two output register. Do you have an Idea how to easily solve this issue?

[marcmerlin]

@esven what is the highest resolution you've been able to get with this library on ESP32? SmartMatrix tends to top out at 128x64 on ESP32 for RAM reasons and with teensy it can reach 128x128 (but very barely) if you use ABCDE panels. Given that this library uses less RAM and bpp, I'm expecting it can go to higher resolutions than SmartMatrix that is geared on quality (and uses 24bpp instead of 16bpp)

[marcmerlin]

Just in case you wonder, it's because I have http://marc.merlins.org/perso/arduino/post_2019-04-08_Clubbing_-EDM-Festival-and-Burning-Man-LED-Pants-and-Shirt-v4-on-ESP32-with-RGBPanels-and-SmartMatrix_GFX.html which works on ESP32 with SmartMatrix and SmartMatrix::GFX compat layer I wrote, but 64x96 is my current limit RAM-wise. I'll probably have a version with 192x128 in the future if I can find P2 RGBPanels in 128x64 that flex a bit (like my existing 64x32 panels in that page), but that's totally not going to work on SmartMatrix for RAM and refresh reasons. My next option is to switch to rPi, but I was curious to see how far this library would go on ESP32