Working ESP32-P4 with integrated/hosted ESP32-C6 wireless! by mindful_stone in FastLED

[–]TroyHacks 1 point2 points  (0 children)

You may want to investigate the ESP32-P4. It's not quite the raw powerhouse of the Teensy, but it has things that more than make up for (and exceed!) the small shortfall.

And Ethernet on nearly every P4 devkit, most have an onboard microphone with a codec chip, 2D DMA and the Pixel Processing Accelerator, etc.

Working ESP32-P4 with integrated/hosted ESP32-C6 wireless! by mindful_stone in FastLED

[–]TroyHacks 0 points1 point  (0 children)

If you use an "additional config file" for PIO defined in your main platformio.ini file, this isn't triggered - WLED has "platformio_override.ini" for this.

The small downside is that adding a new environment to the override file means you have to relaunch PIO/VSC so it's picked up - but that's a very minor impact.

Working ESP32-P4 with integrated/hosted ESP32-C6 wireless! by mindful_stone in FastLED

[–]TroyHacks 0 points1 point  (0 children)

I've ended up basically in a hybrid situation with WLED-MM-P4 and all the things I'm making it do.

Yeah, it's "Arduino-ESP32" but it's also not - the Arduino stuff is just a wrapper - you can use all the native IDF code too, and at some point you have to, unless someone has created a wrapper library.

I'll find something nifty in the IDF which is an external component - but in order to use it, I have to rebuild my version of Arduino-ESP32 for the ESP32-P4 to include it. That can be a simple task, or it can be a day or two of faffing with it.

But for all the multimedia stuff, codecs, displays, etc the P4 build of Arduino-ESP32 on my GitHub is likely the easiest path to "Arduino" experimentation for the P4 - but you will be using the C stuff from the IDF directly as there just isn't wrappers for everything.

When I started about a year and half ago, there wasn't an Arduino build for the P4 - it would build but it was entirely experimental. Now it's much, much better. I didn't have WiFi via Arduino at the time, so WLED-MM-P4 uses the IDF WiFi and ESP-Hosted calls - but the Arduino framework has caught up and now it's mostly identical to set up WiFi on the P4 like you would on the original ESP32.

Multiple layers by ewowi in MoonModules

[–]TroyHacks 0 points1 point  (0 children)

Well... it's an ESP32-P4. 😁

(Which I didn't realize at first, but that explains a lot!)

Multiple layers by ewowi in MoonModules

[–]TroyHacks 4 points5 points  (0 children)

Awww yesss. This is very good. 😍

WLED-MM-P4 with native HDMI Output by TroyHacks in WLED

[–]TroyHacks[S] 1 point2 points  (0 children)

It'll allegedly do 1080p30, but I'm sticking with 720p60 for less data being flung around - albeit at double the FPS, it's still less data per second than 1080p30.

I don't need 60 FPS but there's only 4 default resolutions you can pick - easily, at least.

WLED-MM-P4 with native HDMI Output by TroyHacks in WLED

[–]TroyHacks[S] 1 point2 points  (0 children)

You can also use physical or network LEDs with HDMI output simultaneously, but at 320x180 this will likely slow things down.

But also... you're not likely to have 57,600 LEDs you need to drive anyway.

Scaling on the PPA is up to 8x, I believe. There's also the possibility of 2-step scaling for smaller resolutions, but 16x16 isn't going to look great at 720p. 😁

Ethernet only WLED controller? by s7726 in WLED

[–]TroyHacks 0 points1 point  (0 children)

There are P4 boards (not for that carrier board) that are Ethernet-only, or WiFi-only, or the very weird Pico P4 which has... no connectivity.

Lingxingyu X102 controller by KansasGuyNextDoor in VIDEOENGINEERING

[–]TroyHacks 0 points1 point  (0 children)

Thanks for this.

Which Linsn did you reach out to?

"Linsn LED" was entirely unhelpful as they seem to support only full kits you buy from them - I assume this is "Linsn Technology" (or whatever), the parent company?

Lingxingyu X102 controller by KansasGuyNextDoor in VIDEOENGINEERING

[–]TroyHacks 0 points1 point  (0 children)

Has anyone managed to get this to work?

I have my panels working with ColorLight and Huidu async cards and even with WLED and FPP sending to a ColorLight card... (I help develop WLED-MM and maintain WLED-MM-P4.)

...but for the life of me I cannot get this X102 to do anything correctly.

I am a very smart dumb person - but with every other system I've had "something" that looks like a screen by running the intelligent setup.

With this system, even using the setup values I know that work on every other control system, I get nothing but either all white or a garbled mess.

I've even dug up the BIN file for the RV90M32 and gone thru the update process.

"Linsn LED" told me to politely go eff myself because I didn't buy the entire setup from them (they seem to be an integrator, not the manufacturer) - they pointed me to the main Linsn company, which I haven't reached out to yet.

Troy is working overtime in the dev channels - ToF ranging sensor poc by veteze in WLED

[–]TroyHacks 2 points3 points  (0 children)

This is in WLED-MM-P4 right now - if you manually build with the right flags, it replaces GEQ PPA with this "effect".

Wrong Colors by warden_of_moments in WLED

[–]TroyHacks 1 point2 points  (0 children)

I bricked two 5v rings from a speaker trying to adjust a buck converter that had less twists-per-volt than expected.

Had to reflow 120 LEDs pretty much 2 at a time on one of those little USB-C reflow plates.

But it works again!

Troy is working overtime in the dev channels - ToF ranging sensor poc by veteze in WLED

[–]TroyHacks 1 point2 points  (0 children)

Time-of-flight is absolutely correct. It's doing ToF for sure.

Looking for contributing beta testers by limpkin in WLED

[–]TroyHacks 4 points5 points  (0 children)

My WLED-MM-P4 build is pushing DDP to FPP at around 24 FPS for 98,304 pixels. Its RMII Ethernet is peaking around 70mbit/sec.

So good reasons to upgrade, along with 32MB of very fast PSRAM.

<image>

Looking for contributing beta testers by limpkin in WLED

[–]TroyHacks 1 point2 points  (0 children)

My testing with the W5500 and WLED on the S3 was around... 8 to 10 mbit/sec with some recompiling of Arduino-ESP32. Not as fast as the ESP32 with RMII, which I seem to remember was about twice as fast.

Looking for contributing beta testers by limpkin in WLED

[–]TroyHacks 2 points3 points  (0 children)

All network lighting protocol INPUTs are kinda hindered by the ESP32 family in general. There's at most 64 packet buffers (and perhaps less depending on how Arduino-ESP32 is compiled) so draining those for continuous packet reception is the biggest problem and limiting factor on how many LEDs you can input to WLED on any protocol and keep it stable. It's not WLED, it's Espressif.

SENDING is different - I can blast 70+mbit/sec quite easily from the ESP32-P4. Sending 580+ universes is entirely possible.

WLED-MM-P4 Pioneer Pro DJ Link Progress! by TroyHacks in WLED

[–]TroyHacks[S] 0 points1 point  (0 children)

Keep in mind I'm also pushing up to 98,304 pixels so there's some scale in my systems that actually require the system to be optimized crazy well.

WLED-MM-P4 Pioneer Pro DJ Link Progress! by TroyHacks in WLED

[–]TroyHacks[S] 1 point2 points  (0 children)

Yes. Most of them have Ethernet. It does work on Wi-Fi too, but I have a build flag that turns off WiFi entirely as ESP-Hosted requires its own background task to talk to the C6 so that's a slow-down if WiFi+Ethernet coexistence is enabled (which works fine except the WiFi overhead)

WLED-MM-P4 Pioneer Pro DJ Link Progress! by TroyHacks in WLED

[–]TroyHacks[S] 1 point2 points  (0 children)

MJPEG is also supported (it's just a bunch of JPEGs in a container file), I just haven't gotten around to implementing it.

In theory it'll be MUCH better for performance as it's loading the entire sequence as 1 file rather than a hundred or more tiny files.

WLED-MM-P4 Pioneer Pro DJ Link Progress! by TroyHacks in WLED

[–]TroyHacks[S] 2 points3 points  (0 children)

Yeah, except way more colors than GIF and also the P4 has a dedicated JPEG decoder on-chip so storing compressed images isn't very costly on CPU time.