Add HUB75 support #3777
Add HUB75 support #3777
Conversation
|
(I'm not a WLED maintainer. My comments mean nothing.) Wow! I'm shocked at how cleanly that slots in. Nice. I have both a Matrix S3 and a Mesmerizer (nightdriverled.com) so I may try spinning a build. What kind of frame rates are you seeing on the 2D animations? (We have a lot of the same effects in NightDriver and I've flirted with using the Faptastic HUB75 layer, too...) Why are ESP32_FORUM_PINOUT, ARDUINO_ADAFRUIT_MATRIXPORTAL_ESP32S3, etc. compile-time flags (and not defined in a derivation of esp32dev_hub75) and not runtme-selectable flags like APA102 vs. WS2814 vs WS2812, etc.? Given how differently -S3 and -Nothing have to be built, can you really rely on board = esp32dev? Or is this a "draw the rest of the owl" that needs to have another custom_platform_mps3.ini written that derives from an appropriate S3 with the 8MB flash, 2MB PSRAM combination? (https://github.com/platformio/platform-espressif32/blob/master/boards/adafruit_matrixportal_esp32s3.json ?) Do you need help with that, perhaps? Would this be likely to plan nicely with the Virtual Display (chained panels - limited only by color depth and refresh rates) and UDP/DDP inputs and such? You can see I'm pretty excited to see this as I've traveled a lot of similar paths. I'm a bit engaged in the short term, but may be able to help land this if you need extra eyes and fingers on it. |
|
|
||
| // mxconfig.driver = HUB75_I2S_CFG::SHIFTREG; | ||
|
|
||
| #if defined(ARDUINO_ADAFRUIT_MATRIXPORTAL_ESP32S3) // MatrixPortal ESP32-S3 |
There was a problem hiding this comment.
As mentioned in another comment, this should in fact be a runtime option.
I know it will/may be a lot of work/selection options, but I hate the idea that such configuration is compile-time based.
There was a problem hiding this comment.
I'm a bit surprised by this comment as I messaged you during the development and specifically discussed the challenges relating to the usability of configuration when so many pins are needed and that they are non configurable if you are using one of the ready made boards such as the Adafruit Matrix Portal S3
There was a problem hiding this comment.
I'm sorry if I forgot, I interact with several (possibly in range of 50) users and developers at any time.
So things may slip my mind and I do not heave the time to revisit all communication made. I apologise.
Nevertheless users may build clones or try their own PCBs following HW layout of the existing boards. So it would be more natural to select any Hub75 compatible board instead of compile-time choice. Similar as it is with Ethernet.
After all, the only difference I can see is in GPIO allocation.
There was a problem hiding this comment.
The ideal solution would be a total refactor whereby the front-end requests what config the bus requires, rather than the current mess of having a large number of elements that you then need to work out what to hide for that bus type. Then you can remove all the isType calls.
But this is of course a big change and should be a PR in it's own right
There was a problem hiding this comment.
I agree that it is a mess. Still, a little better than it was.
|
|
||
| this->_len = (display->width() * display->height()); | ||
|
|
||
| pinManager.allocatePin(mxconfig.gpio.r1, true, PinOwner::HUB75); |
There was a problem hiding this comment.
There is also an allocateMultiplePins() method available.
There was a problem hiding this comment.
Yeah, now I've swapped to this library for the implementation, it supports config of pins by array so I can flip to that and then use the multi call
There was a problem hiding this comment.
It's a struct for the gpio pins, not array so can't really swap over easily
| @@ -280,6 +280,9 @@ | |||
| #define TYPE_LPD8806 52 | |||
| #define TYPE_P9813 53 | |||
| #define TYPE_LPD6803 54 | |||
|
|
|||
| #define TYPE_HUB75MATRIX 100 // 100 - 110 | |||
There was a problem hiding this comment.
This may need revisiting as it somehow clashes with @Aircoookie 's bit oriented approach.
There was a problem hiding this comment.
Can you explain this comment further?
There was a problem hiding this comment.
I tried to hide the fact that this was a bitmasked value in 0.15 macros (check marcos in 0.14 or previous). But I would still like it to follow the original idea of particular bit defining LED type if possible.
There is no need for you to do anything at this point. It was more of a reminder for myself.
| @@ -23,6 +23,20 @@ | |||
| function isD2P(t) { return t > 47 && t < 64; } // is digital 2 pin type | |||
| function is16b(t) { return t == 26 || t == 29 } // is digital 16 bit type | |||
| function isVir(t) { return t >= 80 && t < 96; } // is virtual type | |||
| function isHub75(t) { return t >= 100 && t <= 110; } // is Hub75 type | |||
| function hideHub75() { | |||
There was a problem hiding this comment.
I would prefer the other way around. Instead of hiding Hub75 types, insert them into SELECT.
It will require more effort in xml.cpp and some modified code here but should allow for enhancements in the future.
I will tackle this problem and push modifications when I'm done and the solution is viable. No need for you to do anything.
|
IMO, I'm OK with custom boards requiring source changes. Nobody wants a
screen to manually configure a dozen plus pins.
I Do think it's preferable to be able to choose between a trinity and a
matrixs3 from a menu option, just as we choose between WS2812 and SK6218
from a single binary build. So I'd vote for the #ifdefss to ve moved to a
runtime selection but I'm perfectly happy to treat the collection of pins
like a molecule (we COULD split it, but let's not) instead of an atom (with
16 different runtime choices). The level of granularity I'd like to see is
menu option for a board with the fallback that if cracked open a soldering
iron (OK, breadboard) and wired one up yourself that you're capable editing
source and rebuilding.
Also, if you have PSRAM (and what new ESP32 doesn't these days?) are you
really limited to one panel? The ESP32-S3s always have octal PSRAM and can
DMA to and from it, lifting two major limitations from the ESP32-Nothings
where PSRAM could be too slow to feep the panels and still have goofy rules
where you effectively needed bounce buffers (hello ISA network cards in
system with > 16MB of memory where you had to allocate in 'low memory', DMA
to/from, and then copy to the real destination). Faptastic (Mr. Fap?) has
some writeups on that and the ESP32-Nothings were pretty terrible for
multi-panel use where the -S3's are less terrible.
Then again, if we say a single panel is all we want to mess with, this is
still a super cool develoment!
…On Tue, Feb 27, 2024 at 4:44 AM netmindz ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In wled00/bus_manager.cpp
<#3777 (comment)>:
> + mxconfig.gpio.b = 19;
+ mxconfig.gpio.c = 5;
+ mxconfig.gpio.d = 17;
+ mxconfig.gpio.e = 18;
+
+#endif
+
+
+ DEBUG_PRINTF("MatrixPanel_I2S_DMA config - %ux%u length: %u\n", mxconfig.mx_width, mxconfig.mx_height, mxconfig.chain_length);
+
+ // OK, now we can create our matrix object
+ display = new MatrixPanel_I2S_DMA(mxconfig);
+
+ this->_len = (display->width() * display->height());
+
+ pinManager.allocatePin(mxconfig.gpio.r1, true, PinOwner::HUB75);
Yeah, now I've swapped to this library for the implementation, it supports
config of pins by array so I can flip to that and then use the multi call
—
Reply to this email directly, view it on GitHub
<#3777 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YZGDB7QMJWNR6U5ALYVW2HZAVCNFSM6AAAAABD2ZGHFOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMBTGE2TQOJQHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
PSRAM is slow. Too slow for anything LED related. |
|
That was true on ESP32-Nothing.
All the ESP32-S3's using the ESP-WROOM modules (breaking their own naming
convention. Again.) like the N8R2 and N16R8 are populated with Octal
PSRAM. (Boards doing their own thing like LUATOS or some of the
Sparkfun/Adafruit class boards will often use QSPI and, well, they are what
they are.) 120Mhz configurations are "soon" with existing hardware
according to
https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-guides/flash_psram_config.html#all-supported-modes-and-speeds
, but 80Mhz is here now and is the norm on $5 boards.
Waiting for the bus arbiter to swing has a cost, so you don't want to
traverse a linked list to another linked list in psram if you can help it,
but block copies like a frame buffer work really well and you really can
get about 80-90MB/sec in the real world doing a single-directional block
move (not a RAM->RAM copy, but shoving it out a DMAC) (DDR * 1b/xfer *
leading + trailing edge would say 160, but I've not seen that.)
It's not as awesome as having LPDDR5 or something and it's admittedly a
house of cards to hit those rates, but it's less terrible than it used to
be. We know that HUB75 can burn bandwidth at high frame rates and color
depths, so there are still some tradeoffs, but don't dismiss the idea based
on being burned by the ESP32-Nothings.
I think that even at QSPI (like on the LUATOS boards I have) that the
wheels come off pretty easily...
…On Tue, Feb 27, 2024 at 5:04 AM Blaž Kristan ***@***.***> wrote:
Also, if you have PSRAM (and what new ESP32 doesn't these days?) are you
really limited to one panel?
PSRAM is slow. Too slow for anything LED related.
—
Reply to this email directly, view it on GitHub
<#3777 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD32TRKTCZTJ52BLX7L3YVW4TJAVCNFSM6AAAAABD2ZGHFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGMYDGOJYHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I'm having real issues with wifi with the Matrix S3, so will be interesting to see if you see the same.
If you are using the matrix portal, you can't change the pins, so no point asking the user to enter 14 pins. For other boards, just lazy ;)
The example env just shows what options you need to enable this feature. If you aren't using a regular esp32 then you need to add the extra options to the env for your board
In theory yes you could use DDP then Hub75 output or mix of Hub75 and other output types
Great |
You are not limited to single panels. At the moment it will allow you to select up to 4 panels of 32x32 in horizontal configuration. We can add other layouts later
The library being used does allow PSRAM use |
|
Rats. The email gateway ate my response: I finally tried to check this tree out and build it for MatrixS3. I may fumble with WLED and GitHub, but I'm not an inexperienced dev, so please stick with me. $ gh repo clone netmindz/WLED hub75-wled $ pio run -e adafruit_matrixportal_s3_hub75 npm run build
node:internal/modules/cjs/loader:1146 Error: Cannot find module 'inliner'
I don't do Node, so I'm stumped on that one. (I have built WLED directly for another S3 board from teh main repo about a month ago...) If I restart it, it starts to chow down on the CPP code: I agree. There is an assert.h there and it's trying to include an <sdkconfig.h>, but none is in the system header path. If I look at all the sdkconfig.h's on my entire system, I think the pattern is "projects built with idf.py, not platformio", but I'm not certain of that pattern. If I change strategies to: and the C++ compilles until it gets to But that same assert.h is still trying to include a sdkconfig.h that still doesn't exist, so there must be something else going on. I suspect we're getting the wrong assert.h I see adafruit_matrixportal_esp32s3.json in .platformio/platforms/espressif32/boards so I don't think this board is too new to be supported by platformio, but it would be totally on brand for them to not print "something not found" and just blunder on with the wrong one if they did. (My relationship with PlatformIO is strained.) OTOH, it's clearly finding at JSON because it's expanding out the full name: So I guess this is a three part question:
As a sanity check $pio run -e esp32dev_hub75 has the same issue with html_ui.h and with node, but does find a happy assert.h. So I think I just have startup blues. Should this be expected to build from this basic recipe? Is this perhaps divergence from the two wled trees? Thanx for the hand. |
|
The simple option @robertlipe would just be to use this ready-made bin https://github.com/netmindz/WLED/actions/runs/8056668690/artifacts/1276931005 |
|
If you are trying to build from source, you need to run
To have the right modules installed needed for |
|
Thanx.
npm install helped get through the first issue. The actual cpp code still
fails.
<command-line>: warning: "ARDUINO_USB_CDC_ON_BOOT" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "ARDUINO_USB_CDC_ON_BOOT" redefined
<command-line>: note: this is the location of the previous definition
Compiling
.pio/build/adafruit_matrixportal_s3_hub75/lib7c9/FastLED/hsv2rgb.cpp.o
In file included from
~/.platformio/packages/toolchain-xtensa-esp32s3/xtensa-esp32s3-elf/sys-include/sys/reent.h:503,
from
~.platformio/packages/framework-arduinoespressif32/tools/sdk/esp32s3/include/newlib/platform_include/sys/reent.h:17,
from
~/.platformio/packages/toolchain-xtensa-esp32s3/xtensa-esp32s3-elf/sys-include/stdio.h:60,
from
~/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal.h:25,
from
.pio/libdeps/adafruit_matrixportal_s3_hub75/FastLED/src/platforms/esp/32/led_sysdefs_esp32.h:2,
from
.pio/libdeps/adafruit_matrixportal_s3_hub75/FastLED/src/led_sysdefs.h:42,
from
.pio/libdeps/adafruit_matrixportal_s3_hub75/FastLED/src/FastLED.h:51,
from
.pio/libdeps/adafruit_matrixportal_s3_hub75/FastLED/src/FastLED.cpp:2:
~/.platformio/packages/framework-arduinoespressif32/tools/sdk/esp32s3/include/newlib/platform_include/assert.h:20:10:
fatal error: sdkconfig.h: No such file or directory
Does pio run -e adafruit_matrixportal_s3_hub75 work for you?
pio run -e esp32dev_hub75 runs to completion.
It's definitely the board = adafruit_matrixportal_esp32s3 line that's
croaking it. Changing that to match the other makes it happy, so there's
something about this board configuratino tha tmakes platformio grumpy,
though it's clearly recognizing it.
Will test the prebuilt binary soon...
…On Mon, Mar 4, 2024 at 6:20 PM netmindz ***@***.***> wrote:
If you are trying to build from source, you need to run
npm install
—
Reply to this email directly, view it on GitHub
<#3777 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YRLQ5OLGPUJE25NNLYWUFWVAVCNFSM6AAAAABD2ZGHFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXG4YTQMRQGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@robertlipe - I suspect the wrong version of the platform is being used. We have the option to build on V4, which is what I use for the MoonModules#108 |
|
Thanks @netmindz. I also have Adafruit MatrixPortal S3 board. I will try this. |
Should I use the following command to flash Adafruit MatrixPortal S3 board?
|
Not sure about that, I just tend to goto the manual ota page of an existing WLED install and upload the bin |
Which firmware file did you use for WLED install before going to the manual ota page and upload your HUB75 version?
|
Ah, for the matrix3 I didn't actually try a regular install, just went directly to building from source. Does the web installer give a basic working setup? https://install.wled.me/ |
|
@netmindz |
|
Any news about this PR? I have 5 pcs led matrix board |
|
There is support for hub75 in the latest MoonModules builds, just use V4_S or V4_M builds As for support in AirCookie, @blazoncek said he would be updating the PR to address an issue he thought was a blocker to accpeting |
blazoncek
added
enhancement
keep
|
@netmindz I've tried to come up with a better solution regarding conditional UI elements for setting options for Hub panels. I can see 2 ways forward as a result of this: a) make Hub 75 panels regular option and not a conditional compile or b) not support Hub 75 at all For a) that would probably increase code size which most users would rather see used by other usermods instead (current flash utilisation is already above 95% while we are still with ESP32 core 3.5.0, newer cores add substantial amount to this). There is of course still possibility to keep PR as is and hide Hub panels in 99.9% of installations at the expense of few wasted bytes for never used UI elements. I cannot decide either way so I'll leave the decision to @Aircoookie. I have marked the PR with For anyone else interested please upvote this PR so we can see how much interest is there and decide upon it. |
|
Swapping to add the options to the drop-down rather than removing is the smaller problem to solve. As we have discussed, the bigger issue is that of the pin configuration. The "proper" fix would be for the UI to query the bus manager to ask what the config choices should be. This would both remove the need for the UI to selectively hide/rename the config choices and also mean that adding new options like say which predefined combination of pins you are using for hub75 could come from the specific bus type class |
Yes, that's what I was referring to. There is no such way ATM (to query) and hence needs hardcoded info in HTML files. The other problem is also the increase of binary files themselves as mentioned which must not be underestimated as there are several enhancements in the pipeline that require quite a few more bytes. |
Add support to drive HUB75-compatible LED matrix panels. It's a great way to get started with 2D effects in WLED at very low prices.