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. |
platformio.ini
Outdated
| @@ -461,3 +461,19 @@ build_flags = ${common.build_flags} ${esp32s2.build_flags} -D WLED_RELEASE_NAME= | |||
| -D HW_PIN_MISOSPI=9 | |||
| ; -D STATUSLED=15 | |||
| lib_deps = ${esp32s2.lib_deps} | |||
|
|
|||
|
|
|||
| [env:esp32dev_hub75] | |||
There was a problem hiding this comment.
I will require this to be moved into sample file. I want platformio.ini clean and only used for default official builds.
|
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. |
| @@ -344,7 +392,7 @@ struct BusConfig { | |||
| { | |||
| refreshReq = (bool) GET_BIT(busType,7); | |||
| type = busType & 0x7F; // bit 7 may be/is hacked to include refresh info (1=refresh in off state, 0=no refresh) | |||
| size_t nPins = Bus::getNumberOfPins(type); | |||
| size_t nPins = OUTPUT_MAX_PINS; | |||
There was a problem hiding this comment.
We are using the "pins" in the config file for more than just GPIO, so always copy the full array
There was a problem hiding this comment.
That may/will cause out of bounds access.
There was a problem hiding this comment.
I have checked the places the array is created and replaced the magic number 5 with the proper constant
There was a problem hiding this comment.
If I don't change, then we would see an out of bounds as the number of GPIO pins used is 16 but there are only 3 "pins" used in the config
netmindz
requested review from
blazoncek,
softhack007,
willmmiles and
DedeHai
|
There are many more config options that the library supports that are not (yet) exposed through the WLED UI, but my feeling is to merge what is there, then have a later follow up PR(s) that tackle specific items, like non-horizontal layout of multiple panels |
|
... and a label indicating which pinout configuration is active. But that's blocked by the pr that deals with the extra ledType data from the bus |
wled00/bus_manager.cpp
Outdated
|
|
||
| fourScanPanel = nullptr; | ||
|
|
||
| if(bc.type == TYPE_HUB75MATRIX_HS) { |
There was a problem hiding this comment.
Please use space between if and (.
I would also encourage the following form:
if (condition {
...
} else if (condition2) {
...
} else {
...
}| // let's adjust default brightness | ||
| display->setBrightness8(25); // range is 0-255, 0 - 0%, 255 - 100% | ||
|
|
||
| delay(24); // experimental |
| } | ||
| } | ||
|
|
||
| void __attribute__((hot)) BusHub75Matrix::setPixelColor(uint16_t pix, uint32_t c) { |
There was a problem hiding this comment.
Perhaps a standards version of [[gnu:hot]] may be better choice. I'm not sure but I think the attribute is needed in declaration, not in definition.
| uint32_t BusHub75Matrix::getPixelColor(uint16_t pix) const { | ||
| if (!_valid || pix >= _len) return IS_BLACK; | ||
| if (_ledBuffer) | ||
| return uint32_t(_ledBuffer[pix].scale8(_bri)) & 0x00FFFFFF; // scale8() is needed to mimic NeoPixelBus, which returns scaled-down colours |
There was a problem hiding this comment.
The reasoning is false. This function should return original value the setPixelColor() set.
The behaviour of NPB has to be reverted and is done so in BusDigital.
wled00/bus_manager.cpp
Outdated
| display->setBrightness(_bri); | ||
| } | ||
|
|
||
| void __attribute__((hot)) BusHub75Matrix::show(void) { |
There was a problem hiding this comment.
Does not need to be hot. Called at 23ms intervals.
|
|
||
| #include <ESP32-HUB75-MatrixPanel-I2S-DMA.h> | ||
| #include <ESP32-VirtualMatrixPanel-I2S-DMA.h> | ||
| #include <FastLED.h> |
There was a problem hiding this comment.
I think adding FastLED to bus manager is not appropriate.
There was a problem hiding this comment.
Was added for one of the functions or possibly CRGB. I'll check if it's still needed
There was a problem hiding this comment.
Yes it's still required - see the usage of CRGB
wled00/bus_manager.h
Outdated
| class BusHub75Matrix : public Bus { | ||
| public: | ||
| BusHub75Matrix(BusConfig &bc); | ||
| bool hasRGB() { return true; } |
There was a problem hiding this comment.
Please add override attribute.
There was a problem hiding this comment.
You can't actually override as inline, bu that suggestion helped find and fix that bug
| @@ -344,7 +392,7 @@ struct BusConfig { | |||
| { | |||
| refreshReq = (bool) GET_BIT(busType,7); | |||
| type = busType & 0x7F; // bit 7 may be/is hacked to include refresh info (1=refresh in off state, 0=no refresh) | |||
| size_t nPins = Bus::getNumberOfPins(type); | |||
| size_t nPins = OUTPUT_MAX_PINS; | |||
There was a problem hiding this comment.
That may/will cause out of bounds access.
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.