New Part Day: ESP32-P4 Espressif RISC-V Powerhouse

It seems every day there’s a new microcontroller announcement for which the manufacturer is keen to secure your eyeballs. Today it’s the turn of Espressif, whose new part is the ESP32-P4, which despite being another confusingly named ESP32, is a high-performance addition to their RISC-V line-up.

On board are dual-core 400 MHz and a single-core low power 40 MHz RISC-V processors, and an impressive array of hardware peripherals including display and camera interfaces and a hardware JPEG codec alongside the ones you’d expect from an ESP32 part. It’s got a whopping 768 KB of on-chip SRAM as well as 8 K of very fast cache RAM for intensive operations.

So after the blurb, what’s in it for us? It’s inevitable that the RISC-V parts will over time displace the Tensilica parts over time, so we’ll be seeing more on this processor in upcoming Hackaday projects. We expect in particular for this one to be seized upon by badge developers, who are intent on pushing extra functionality out of their parts.So we look forward to seeing the inevitable modules with this chip on board, and putting them through their paces.

Thanks [Renze] for the tip.

63 thoughts on “New Part Day: ESP32-P4 Espressif RISC-V Powerhouse

  1. >H.264 encoding support

    Looks like a license trap, will see the implications and what this might do to the price. Anyone who knows their stuff regarding this potential issue?

      1. Thanks Gravis that is good to know! Platforms like Steam still ship their binary encrypted, so that the encoder is only decrypted when the user wants to encode h.264 for i.e. a game stream. I hope paying this terrible license kraken a single cent can be avoided in the same way. If that means registering an SoC / MCU to unlock the encoder. I will gladly have that function locked and not feed the beast.

        Sadly according to BBC, AV1 is just as good as HEVS (h.264), but not a license bomb like VVC (h.266):

        We will see how the finalized codecs perform, but I hope AV1 to win just because it is true FLOSS.

        1. Race co dotio s generally come from parallel prcoessing, or multi threaded or multi-application solutions (e.g. client-server for example). Many bugs come from this, also on desktops, so the answer to your question mark is a firm yes!

        2. Clearly you have never dealt with processing interdependent workloads on more than one core. If you don’t get race conditions there, you either have very consciously mitigated them, are using OS mechanisms that take care of it (and maybe are unaware of it), or have gotten very, very lucky.

    1. Well, if you want wireless they just released the first ESP32-C6 development boards. The ESP32-C6 combines 2.4 GHz Wi-Fi (802.11 b/g/n/ax), Bluetooth 5 (LE), and a IEEE 802.15.4 radio for ZigBee and Thread. Expanding to a more powerful processor without any wireless really just shows that they are branching out. Probably a good move to make ESP32/RISC processors more diverse to make them compete with way more proprietary CPU architectures.

  2. There has been a dead zone, or at least a desert, at this performance level. Companies like Samsung had great success with chips like the S3C2440 which is a 400MHz ARM and is in loads of low end O’Scopes and routers, etc. They ran mostly Linux or WinCE. The ARM with Linux crowd has moved steadily to faster/newer/more cores. Meanwhile the simpler embedded stuff has mostly gone 32 or 64 bits with STM32F104 being 160MHz and others including Espressif making parts at 300+.

    400MHz with dual core. Hmmm. You can certainly slip into most of the embedded jobs that were done with the long discontinued phone chips. A lot of them had camera inputs and display outputs. The drones will be getting smarter.

    I see they exceeded the Gates Limit by 128K. Fascinating Captain.

  3. look interesting till I saw they had dropped the wifi and bluetooth..
    And I laughed when they said ‘ Espressif’s mature IoT Development Framework (ESP-IDF),’ – as esp-idf is the biggest drawback of their whole ecosystem..

    1. Well, ESP Rainmaker is always an option, especially for IoT. ESP-IDF isn’t the only option when using Esspressif as they parternered with AWS for rainmaker and it looks pretty promising. With that said I haven’t looked that deep into it but having a dedicated phone app platform, free evaluation’s and their own voice assistant while also working with Alexa and Google Assistant and an MQTT cloud platform isn’t a bad place to start if one was looking to get into the IoT business.

    2. Totally agree. ESP-IDF is useless if you require things like consistent interrupt latency. You know, just things you typically need when doing low level embedded project. It is however great for blinking an led or flipping a relay, the typical IOT junk.

      1. I’m doing consistent interrupt latency with (their) FreeRTOS in esp-idf. There’s nothing forcing you to follow their examples with posting things in ISR to tasks for processing, only a fool would do that for high frequency interrupts. You can process in an ISR like you want and since they have plenty of RAM, you’ve one of most performant µc here.

  4. What I really want to see is the datasheet… These days new MCUs come with a crapload of off-the-shelf-IP-core peripherals some of which are worse than useless and some of which are hackable to such a degree that they can be made to do stuff nobody expected (like the I2S port on the original ESP32 or the programmable DMA controllers on the PIC32MZ family).

    So, while these announcements are interesting it a vague and distant way, the point where I get excited is when there’s a register reference and an eval/breakout board I can buy to put it through its paces.

  5. Interesting to see h264 hw encoder in there. Do you guys think it will be able to do 1080p@30 ? Trying to do a wildlife trail camera. Was looking at the pi zero 2 but power consumption and boot time are problematic.. With the “standby” core, i believe this could solve both problems.

  6. It’s a shame they are using a h.264 encoder. Why not VP9 (AV1 is a bit too recent and computationally expensive to be added at this point).

    Any user of this encoder is almost certainly doomed to licensing headaches

    1. They may be thinking more of business customers such as those doing CCTV cameras, so you need a codec that’s going to be accepted by the current market. Existing ONVIF NVRs will expect h.264 (or h.265 at a stretch).

    1. Nope. Unfortunately, there’s a fair amount of time needed to tape out chips, and we (Espressif) have the tendency to announce fun stuff quite early on, so they generally aren’t available for a fair amount of time after the announcement. I think the current schedule is to have engineering samples available in aug/sept and mass production going near the end of the year, but don’t hold me to that please (as issues we find in the silicon or other unforeseen things may delay stuff)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.