Published 3 minutes ago

I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I’m XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017.

In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as adamc.99, or u/AdamConwayIE on Reddit.

Sign in to your XDA account

We’ve talked a lot about ESP32-powered displays, but what about displays that pack two ESP32 chips inside? That’s exactly what the Elecrow CrowPanel Advance 7-inch ESP32-P4 does, and it’s a ridiculously overkill piece of kit that represents the pinnacle of what you can do with the ESP32. However, you may recall that the ESP32-P4 is an Ethernet-only microcontroller... so Elecrow’s solution is to also bolt on an ESP32-C6 for Wi-Fi and Bluetooth. They’re not the first do it or anything, but it makes for a rather powerful display that combines the best of both worlds.

This particular display packs both of those chips, alongside two speakers, an optional camera add-on, a microphone, multiple GPIO pins, and a 1024x600 LCD touchscreen. Unfortunately, as it’s based on the ESP32-P4, there’s a bit of controversy within the PlatformIO world that affects your development process, so your best bet to get this up and running is to use the ESP-IDF framework... or attempt to use ESPHome. I used both, and I was able to get it mostly working, but with quite a few caveats.

Elecrow CrowPanel Advance 7.0" HMI ESP32-P4 AI Display

The Elecrow CrowPanel Advance ESP32-P4 is a display with an ESP32-C6 bolted on for Wi-Fi and Bluetooth, speakers, and an optional camera module. The ESP32-P4 has additional capabilities no other ESP32 can offer, such as H.264 codec support and, in this board, 32MB of PSRAM.

The ESP32-P4 is a very different ESP32

No Wi-Fi is already a big difference

The ESP32-P4 is a significantly different beast compared to the rest of the ESP32 family, and there are a few reasons for that. Firstly, it’s designed primarily as an AI development board, meaning the hardware is geared more in that direction than anything else. That’s why you don’t get Wi-Fi support, but you do get H.264 support, for example—and that’s just one of many differences. You also get significantly more PSRAM, faster cores, and more flash storage, all of which pose real challenges for development because supporting the hardware requires updated toolchains.

To get everything up and running, I first focused on ESPHome. Getting the camera working required using the following custom component:

• Modular Camera Framework with MIPI-CSI support

A custom component is required because the ESP32-P4 changes how certain hardware interfaces work, and ESPHome isn’t fully equipped to handle that yet, especially given how new the hardware is. Even getting the display working proved difficult at first, and required digging through Elecrow’s sample code to find the initialization sequence for booting the panel. There’s one issue with it though, and that’s Wi-Fi. In my testing, I discovered a bug in the implementation of the ESP32-C6 that affected Wi-Fi connectivity. The solution is simple if you use ESP-IDF, but for ESPHome, even though it should work, it doesn’t. All you need to do is ensure that the SDIO bus, facilitating communication between the ESP32-C6 and the ESP32-P4, is set to one-bit mode in your sdkconfig (through menuconfig), like so:

• CONFIG_ESP_SDIO_1_BIT_BUS=y
• CONFIG_ESP_SDIO_BUS_WIDTH=1

This decreases the transmission speed between both chips, but is still perfectly fine for the Wi-Fi speed the ESP32-C6 can achieve. Setting this in ESPHome didn’t fix the problem over there, but I was able to get the hardware working, and that’s what I cared most about. We’ll talk more about SDIO in a bit.

Once I switched over to ESP-IDF, I built a basic application so I could learn how to initialize the hardware myself, by modifying Elecrow’s own example application. I eventually got my program to compile, but my struggles were far from over.

Remember how I mentioned that the hardware is new? Well, it turns out flashing the ESP32-P4 was another issue I didn’t expect. My MacBook couldn’t recognize it at all, despite working for all my other ESP32s and despite trying a litany of cables. Even on my PC, many of the web-serial flashers didn’t know what the device was and simply saw it as "unidentified."

Thankfully, I came across the browser-based ESPressoFlash, which let me upload my application, bootloader, and partition table binaries, and flash the device that way. It’s a pretty neat website and saves me from needing to install all of the ESP-IDF tools on my main PC, which I normally don’t develop on. When I first flashed it, I was able to confirm that I had connected to and interfaced with the ESP32-C6 correctly, but the internal SPIFFS flash storage still hadn’t mounted. It turns out you need to enable a setting in ESP-IDF’s sdkconfig (through menuconfig) to wipe the flash storage if it fails to mount at boot; otherwise, the device just crashes. As someone used to ESPHome and PlatformIO, ESP-IDF is a lot more "hands-on" than I expected.

Since this was my first time using the ESP-IDF framework, it took a while to understand what was going on, both in terms of getting things up and running and in figuring out Elecrow’s example well enough to build a basically functioning device. Out of the box, it comes with the ESP-Brookesia Phone project preloaded, which is a great way to show off the hardware, but makes it harder to understand how to interface with it correctly. This Phone project demonstrates an entire operating system with working apps that use different hardware features. It’s an impressive tech demo, but difficult to learn from because it’s hard to decipher which parts are actually relevant.

Another challenge I faced numerous problems with was the ESP32-C6 being used for Wi-Fi. This relies on a library called "ESP-Hosted," where the P4 is the host that communicates with the C6 over Secure Digital Input Output (SDIO). You don’t have to use it only for Wi-Fi, but that’s the primary benefit. You can offload processing of all kinds of things if you’re willing to figure out the communication layer and build firmware for the on-board C6 to support it. Elecrow preloaded the C6 with ESP-Hosted 2.3, which should be intercompatible between 2.3 and 2.6.1 (which ESPHome used at the time of testing), though it wasn’t stable in practice. Now, with the SDIO one bit bus, I can even use ESP-Hosted 2.7 in my ESP-IDF application, and it works just fine.

I had a lot of back-and-forth with both Elecrow and the ESPHome developers through my testing, in order to diagnose, understand, and fix the problem in order to get it up and running. Elecrow eventually got to the bottom of the problem, and I’ve been able to continue working on it since then.

The result is a very basic application using the ESP-IDF framework, which I’ve shared on GitHub, along with an ESPHome configuration that implements the display, audio, and the camera. I’m hopeful that my example application is significantly easier to understand than the entirety of the ESP Brookesia project, as I implement the key hardware aspects (sans the camera) in a much smaller project.

A system information and music streaming panel, built with ESP-IDF

It works, and I love it

After much, much trial and error, I was able to build a basic application using the ESP-IDF framework and the Board Support Packages (BSPs) shared by Elecrow as a part of their code sample. It’s a relatively simple application, but removes most of the additional features so that you can understand the basics of how the hardware works and what you can do with it. I initialize the following, in order:

• NVS
• ESP-Hosted
• SPIFFS
• SD card
• Display
• UI creation
• Audio
• WiFi

One of the biggest difficulties I faced was surrounding the display initialization, and I discovered that the order really matters. If I initialized the display before the SD card, it would flash on and then immediately flash back off again, but swapping them so that the display came after worked just fine. I’m actually not even sure what the cause of this is, but it’s these kinds of unexpected pitfalls that delay the development process and can make it hard to get a device up and running.

Once initalized, it formats SPIFFS to the partition size dictated in the partitions.csv file. I’ve set it to 12MB for testing, but you can increase it to fill the remaining bounds of storage that’s free. Then, it listens for connections on a /audio endpoint. Here, you can send MP3 files using curl, like so:

curl -X POST -F 'file=@audio.mp3' http://IP_HERE/audio

If you want to delete a file, just send a GET request (either with curl or using your browser) to http://IP_HERE/delete. This will then mark the file for removal, set the audio loaded variable to false, and execute the SPIFFS garbage collector in order to free the space up for another file. The garbage collector can be quite slow, so you may need to wait before it will start to intake another audio file.

Once a file is present (saved as current_audio.mp3), the play button will change to a green "Play" button. You can then tap it again to stop the currently playing track. Pressing play again will begin it from the start. It uses the Elecrow audio codec support from its BSP, as does most of the hardware initialization.

This is a ridiculously powerful board, and you can do all kinds of things with it. From complete H.264 support to ample amounts of storage, processing power, and PSRAM, I’ll be sure to experiment a lot with it. If you want to try out this board yourself, you can check out the GitHub repository with all of the code to help you get started.