ESP32-P4: High-performance MCU with IO-connectivity and security features(espressif.com)
espressif.com
ESP32-P4: High-performance MCU with IO-connectivity and security features
https://www.espressif.com/en/news/ESP32-P4
94 comments
Agreed - they deliver a very flexible, cost-effective, performant MCU. Downsides (to me) are toolchain and power consumption.
Has the Arduino toolchain been enough for home automation? I’ve been playing with Zephyr, but when I’ve gotten down into those gritty late-AM Saturday night programming hours, actual library support seems to be patchy, outside Arduino and Espressif toolchains.
I ended up running MicroPython on the Sonoff Dual R3 (a cheap and cheerful box about the size of a fig, controlling two separate line voltage relays) but GPIO access is really unsafe, which makes it useless for sensing, but fine for control. For everything else I use the ESP-WROOM-32, a fairly ancient dev board, and it’s highly capable, but I get the sense there are better boards for prototyping in 2023.
If you have a preferred board, do tell!
Has the Arduino toolchain been enough for home automation? I’ve been playing with Zephyr, but when I’ve gotten down into those gritty late-AM Saturday night programming hours, actual library support seems to be patchy, outside Arduino and Espressif toolchains.
I ended up running MicroPython on the Sonoff Dual R3 (a cheap and cheerful box about the size of a fig, controlling two separate line voltage relays) but GPIO access is really unsafe, which makes it useless for sensing, but fine for control. For everything else I use the ESP-WROOM-32, a fairly ancient dev board, and it’s highly capable, but I get the sense there are better boards for prototyping in 2023.
If you have a preferred board, do tell!
I want to emphasize that MicroPython is actually really great, especially on the ESP-32. I was pretty skeptical (having written both Arduino and ESP-IDF code) but after using it a bit, it solves a wide range of problems for me. I was surprised to see that interrupts in python actually can be fast enough to be useful, and it can control a number of the peripherals through DMA, which means you can often do stuff at hardware speeds w/ no CPU involvement. You also get a REPL and a real filesystem for free. And I know I can always take whatever I've written and transliterate it to ESP-IDF.
I use a wide mix of ESP-WROOM-32, Lolin ESP-32-OLED (when I want on-board display), and all sorts of other random ones.
For all my home automation I use ESPHome and Home Assistant (20+ custom devices, plus however many light bulbs and Sonoffs and stuff).
For tool chain I personally use Platform.IO in VSCode but I’ve done a fair few with Arduino IDE and it works in a pinch.
For all my home automation I use ESPHome and Home Assistant (20+ custom devices, plus however many light bulbs and Sonoffs and stuff).
For tool chain I personally use Platform.IO in VSCode but I’ve done a fair few with Arduino IDE and it works in a pinch.
Would you mind sharing some of the Home Assistant projects you’ve built? I have some ESP32-CAMs coming and plan to setup a cat box monitor.
Not the person you’re replying to, but I’ve built a battery voltage monitor (to alert if my home generator battery is discharging) and am working on temperature monitors for my BBQ and oven! Those have been left on accidentally in the past
There are 2 flavors of the ESP, depending on model. The Xtensa cores and RISCV, go with the RISCV variant. The Xtensa variant requires you to use their compilers, which are derived from he ones provided by Cadence. There's a better path long-term for the RISCV cores to get tooling on par to what's available for ARM.
The Xtensa based ESP32 chips have upstream support in GCC, do they not?
Espressif has compilers you can download. GCC may work fine, but I’d use their compilers.
Yes, but not llvm support. Which makes rust a no go.
Upstream support landed a couple of weeks ago: https://github.com/llvm/llvm-project/search?o=desc&p=1&q=Xte...
Rust support landed before that, https://github.com/esp-rs
This is all being done by Xtensa themselves, including the Rust.
Rust support landed before that, https://github.com/esp-rs
This is all being done by Xtensa themselves, including the Rust.
Toit is where it's at for esp32 projects. It runs on a VM system called Jag, which lets you basically deploy containers to an esp. It also handles updates via wifi, logging and all that, while giving you a terse language with quite a lot of packages to build things with.
I don't have any use for them, but I am also a fan of the ESP32, mainly because it represents having the desktop computers of my 9th grade (similar somehow to PC1512) available on the palm of my hand, and with much better hardware.
And WiFi, running on 3AA batteries, GPIO and costing US$ 5. Same feeling.
What kind of battery life do you get? I know it depends on workload/wifi use etc., but any such data would be helpful.
So many variables due to application, so camera streaming will use more that a humidity/temp/pressure sensor that deep sleeps for a minute, awakes, reads and sends the data and pops back to sleep.
A good YouTube Channel I find for microcontroller aspects is - Andreas Spiess
One of his videos you may find useful - https://youtu.be/ajt7vtgKNNM
A good YouTube Channel I find for microcontroller aspects is - Andreas Spiess
One of his videos you may find useful - https://youtu.be/ajt7vtgKNNM
I made a bunch of temp sensors that would wake up every 5min and post the data via wifi. Powered by 4 C-cells it lasted about 450 days.
> use less power,
I was about to go off on a rant about how power hungry the ESP32 is. But having a look its not as bad as I remembered (or perhaps I was thinking about the 8266)
https://diyi0t.com/reduce-the-esp32-power-consumption/
depending on the board you can get it to as low as 15ma in "normal" use(light sleep microprocessor only, modems off). But when the wifi is on it chows down powers.
I was about to go off on a rant about how power hungry the ESP32 is. But having a look its not as bad as I remembered (or perhaps I was thinking about the 8266)
https://diyi0t.com/reduce-the-esp32-power-consumption/
depending on the board you can get it to as low as 15ma in "normal" use(light sleep microprocessor only, modems off). But when the wifi is on it chows down powers.
The chips various Arduino-like chips are 5mA active, 500uA when light sleeping, 5uA in deeper sleep, and hundreds-nanoamps in deepest sleep.
15mA "light sleep" is really heavy actually compared to most things IMO. Hell, the Nordic Semiconductor nRF5340 uses 5mA _WHEN TRANSMITTING ON ITS RADIO_.
https://www.nordicsemi.com/Products/nRF5340
-----------
ESP32 is in that zone between the low-power (and ultra-low power) uCs and Raspberry Pi. ESP32 is ~20mA to 50mA, comparable to RP2040 (which I also consider to be very "heavy").
Arduino-chips, like the ATMega328pb (as old as it is), is on the scale of "Years on AA batteries of sleep". While chips like ESP32 are on "Hours of AA batteries of sleep".
--------
The only advantage to ESP32 is its WiFi. If you need anything else at all, there's a lot of better chips available. In particular, Teensy is probably the best board for ~50mA to ~100mA levels that the ESP32 finds itself in.
15mA "light sleep" is really heavy actually compared to most things IMO. Hell, the Nordic Semiconductor nRF5340 uses 5mA _WHEN TRANSMITTING ON ITS RADIO_.
https://www.nordicsemi.com/Products/nRF5340
-----------
ESP32 is in that zone between the low-power (and ultra-low power) uCs and Raspberry Pi. ESP32 is ~20mA to 50mA, comparable to RP2040 (which I also consider to be very "heavy").
Arduino-chips, like the ATMega328pb (as old as it is), is on the scale of "Years on AA batteries of sleep". While chips like ESP32 are on "Hours of AA batteries of sleep".
--------
The only advantage to ESP32 is its WiFi. If you need anything else at all, there's a lot of better chips available. In particular, Teensy is probably the best board for ~50mA to ~100mA levels that the ESP32 finds itself in.
Personally, I'd would say another advantage is sdk. IMO ESP-IDF is up there with Silabs and nRF in the top tier of dev experience. Then STM/TI etc and Microchip a very distant last.
The ESP32 isn't ideal for basic battery stuff that needs to be awake all the time, or size constrained stuff - that's where nRF and BLE shines (or Silabs/Cypress).
However, in deep sleep you can get 10uA< which is decent assuming you wake up rarely, do a bit of WiFi work and go back to sleep.
For the right job (powered stuff that needs BLE, WiFi or ethernet, maybe hosting a local webserver for config and/or mqtt) the ESP32 is an absolute bargain compared to alternatives and a pleasure to work with to boot. The modules also typically have lots of flash onboard, ideal for embedding web UIs.
The ESP32 isn't ideal for basic battery stuff that needs to be awake all the time, or size constrained stuff - that's where nRF and BLE shines (or Silabs/Cypress).
However, in deep sleep you can get 10uA< which is decent assuming you wake up rarely, do a bit of WiFi work and go back to sleep.
For the right job (powered stuff that needs BLE, WiFi or ethernet, maybe hosting a local webserver for config and/or mqtt) the ESP32 is an absolute bargain compared to alternatives and a pleasure to work with to boot. The modules also typically have lots of flash onboard, ideal for embedding web UIs.
Teensy 4.1 is very capable indeed, but it is also roughly 4x the price of an ESP32 WeMos D1 Mini where I live.
> nRF5340 uses 5mA _WHEN TRANSMITTING ON ITS RADIO_.
I mean that is bluetooth radio, so its cheating just a little :)
No, I get your point. the ESP stuff I do spends most of its time in deepsleep, so yeah the 15ma is not great, but its not _that_ much of an issue because I can just wake up less often. Not having to use C is even better though.
10 year previous me would be screaming at my attitude. I remember when the pyboard came out and I was very much "pfftt, amateurs. 35mA to do nothing very fast"
However having lots of connectivity really makes up for the not great consumption. I don't have to slap on an RF solution, or like I did 12 years ago, use a horrific ethernet->rs232 bridge.
However if I need online low power consumption, I'll need to use STM32, and cry at how bad the documentation is(or was, I've not tried to use it for years).
I mean that is bluetooth radio, so its cheating just a little :)
No, I get your point. the ESP stuff I do spends most of its time in deepsleep, so yeah the 15ma is not great, but its not _that_ much of an issue because I can just wake up less often. Not having to use C is even better though.
10 year previous me would be screaming at my attitude. I remember when the pyboard came out and I was very much "pfftt, amateurs. 35mA to do nothing very fast"
However having lots of connectivity really makes up for the not great consumption. I don't have to slap on an RF solution, or like I did 12 years ago, use a horrific ethernet->rs232 bridge.
However if I need online low power consumption, I'll need to use STM32, and cry at how bad the documentation is(or was, I've not tried to use it for years).
The Cortex M23 and Cortex M33 chips seem to be the lowest power I can find.
That's Microchip's SAM L10/L11, STM32U5, and the Nordic Semiconductor chip I mentioned earlier. Probably a few more out there (ARM sells their core to many different companies after all).
That's Microchip's SAM L10/L11, STM32U5, and the Nordic Semiconductor chip I mentioned earlier. Probably a few more out there (ARM sells their core to many different companies after all).
Well, it's shit if you want something battery-powered (at least "needs a lot of work" to get good standby") but for everything else, comparing to what it can do and how much it costs, it's fine.
There are hacks like putting a delay(250) on the main loop.
I seem to remember reading somewhere that it made a significant difference to power usage while having little responsiveness effect.
I seem to remember reading somewhere that it made a significant difference to power usage while having little responsiveness effect.
That you can actually buy an ESP32 right now is another huge advantage over the RPi.
A little off topic: Is there a video compression chip that I can put on a board with an ESP32 to make a live streaming camera similar to what can be done with an RPi or Jetson Nano?
I don't understand the question - this chip has an H.264 encoder on board.
Yes. I didn't look carefully enough at the new one. Thanks.
Why not use an ESP32-CAM board?
ov2640 camera has hardware JPEG compression.
How do you connect them? I would actually love to have a few PoE powered and connected ESP's since you have to power these things anyway.
Depending on the project, but either find a nearby USB port (I have home temperature sensors powered off the back of my TV, and other projects off USB ports around the house) or use battery power. Batteries can last months on ESP32s if you set them up right. They have great deep-sleep modes and can use practically nothing unless they're actively needed.
Why use ESP32 if you're powering with PoE? Might as well use an "Ethernet-on-board" like Teensy 4.1, and then use a PoE splitter (ex: https://www.adafruit.com/product/3239) to power it.
Why pay for WiFi power (which is rather expensive) when you literally are sending Ethernet communication wires to your uC ?
https://www.pjrc.com/store/teensy41.html
Why pay for WiFi power (which is rather expensive) when you literally are sending Ethernet communication wires to your uC ?
https://www.pjrc.com/store/teensy41.html
I use these https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-sou... - they support proper PoE as opposed to the dodgy passive stuff you usually end up with with splitters.
Personally I'd take an ESP32 over a teensy 4.1 unless you specifically need the extra GPIOs or something. The teensy's are great hardware, but you're stuck with either Arduino or hand rolling.
You don't pay for WiFi power if the RF amp is off, and ESP-IDF for me is far better to work with than the Arduino software ecosystem especially once the complexity starts going up.
Also, if you just want to make widgets and not learn embedded development esp-home is brilliant.
Personally I'd take an ESP32 over a teensy 4.1 unless you specifically need the extra GPIOs or something. The teensy's are great hardware, but you're stuck with either Arduino or hand rolling.
You don't pay for WiFi power if the RF amp is off, and ESP-IDF for me is far better to work with than the Arduino software ecosystem especially once the complexity starts going up.
Also, if you just want to make widgets and not learn embedded development esp-home is brilliant.
Why via a wifi mesh of course: https://www.espressif.com/en/products/sdks/esp-wifi-mesh/ove...
That's really cool. I'd start with star topology first though, with just 4-5 devices. In my use case it's just gardening stuff.
I use old phone chargers accumulated over the years. It's been 3 or 4 years since I started doing that and they don't seem to mind at all.
I would highly recommend checking out toit lang for esp32 projects. It's really really nice to use.
Ha, for most of my applications the ESP32s are actually wildly over-powered - but the development experience is quite good.
It's cool that they're seriously expanding their media interfacing capabilities - the ESP32s already have some, but they're quite basic.
I don't see a mention of it, so I have to wonder: What about Linux? There was a project a while back to get Linux running (at a snail's pace) by using JuiceVM to emulate a RISC-V CPU - now we have ESP32s with actual RISC-V CPUs (and MMUs as well!) ... so what's stopping Linux from running?
To answer the foreseeable "why would you want that": It would be really nice to get a standard OS with preemptive multitasking, dynamically loaded binaries, a shell and standard tooling.
NuttX has a lot of these (Zephyr has some), but I still feel find them quite limiting: At best you have to deal with "the microcontroller version of ..." (see Python, Go, .NET - they're all somehow worse versions). Don't we have enough power nowadays, even in the lower-tier ESPs or is my intuition totally off?
I know there are relatively cheap "SBC-style" boards (Raspberry Pi Zero W) for this purpose, but there's still a sizeable pricing (and size) gap between those and "MCU style" boards.
The one board I'm aware of that is trying to bridge the gap is the 128Mb Ox64 (https://pine64.com/product/128mb-ox64-sbc-available-on-decem...) and basically I wonder whether this might be Espressif's response to it.
It's cool that they're seriously expanding their media interfacing capabilities - the ESP32s already have some, but they're quite basic.
I don't see a mention of it, so I have to wonder: What about Linux? There was a project a while back to get Linux running (at a snail's pace) by using JuiceVM to emulate a RISC-V CPU - now we have ESP32s with actual RISC-V CPUs (and MMUs as well!) ... so what's stopping Linux from running?
To answer the foreseeable "why would you want that": It would be really nice to get a standard OS with preemptive multitasking, dynamically loaded binaries, a shell and standard tooling.
NuttX has a lot of these (Zephyr has some), but I still feel find them quite limiting: At best you have to deal with "the microcontroller version of ..." (see Python, Go, .NET - they're all somehow worse versions). Don't we have enough power nowadays, even in the lower-tier ESPs or is my intuition totally off?
I know there are relatively cheap "SBC-style" boards (Raspberry Pi Zero W) for this purpose, but there's still a sizeable pricing (and size) gap between those and "MCU style" boards.
The one board I'm aware of that is trying to bridge the gap is the 128Mb Ox64 (https://pine64.com/product/128mb-ox64-sbc-available-on-decem...) and basically I wonder whether this might be Espressif's response to it.
Last time I read into it, the lack of memory management hardware (paging etc.) was one of the main reasons stated why normal Linux can't run on these devices.
Someone managed to get Linux to work by writing a virtual machine and emulating a Linux capable computer, but that was obviously not a serious use case (it was also extremely slow for obvious reasons).
Someone managed to get Linux to work by writing a virtual machine and emulating a Linux capable computer, but that was obviously not a serious use case (it was also extremely slow for obvious reasons).
There's also just a native nommu Linux port to RISC-V.
https://www.cnx-software.com/2020/02/17/how-to-build-run-lin...
https://www.cnx-software.com/2020/02/17/how-to-build-run-lin...
Probably the amount of RAM available more than the CPU. Surely you can get a very stripped down version of Linux running, but I doubt a version of Linux that you can use to do something useful.
Surely the day that even on these sort of low cost microcontrollers can run Linux is not far...
Surely the day that even on these sort of low cost microcontrollers can run Linux is not far...
It has an external PSRAM interface. You can easily get 64MB PSRAM chips which is plenty for Linux.
It's about virtual memory controllers. Linux needs one. The chips at this size don't always have the minimum hardware features to even boot Linux.
Linux has a no MMU mode where it works very well without an MMU, just using an MPU for process isolation. I'm not sure if it's been ported to RISC-V M mode though.
Edit: looks like there is already a port https://www.cnx-software.com/2020/02/17/how-to-build-run-lin...
Edit: looks like there is already a port https://www.cnx-software.com/2020/02/17/how-to-build-run-lin...
There's a very nice language dedicated to ESP32 programming that has semantics very similar to ruby and python and very clean minimalistic syntax. It called toit
https://toitlang.org/
https://toitlang.org/
It’s strange that in their examples they don’t show any I/O (apart from print).
I would expect support from such a language to support me with I/O while I concentrate on my program. For example by providing an event loop.
Of course, if I need a more performant approach I would switch to a low level language.
I would expect support from such a language to support me with I/O while I concentrate on my program. For example by providing an event loop.
Of course, if I need a more performant approach I would switch to a low level language.
There is no event loop. You make lightweight threads called tasks, and they can block on things or wait for each other.
https://docs.toit.io/language/tasks
Synchronization: https://libs.toit.io/monitor/library-summary
For example the GPIO pin has a wait_for method which pauses a task until a signal is seen. https://libs.toit.io/gpio/class-Pin
https://docs.toit.io/language/tasks
Synchronization: https://libs.toit.io/monitor/library-summary
For example the GPIO pin has a wait_for method which pauses a task until a signal is seen. https://libs.toit.io/gpio/class-Pin
I concur that's strange; the homepage code examples are standard imperative things. Clean IO, peripheral APIs, scheduling/code structure, and resource sharing is what I'd expect as priorities from an embedded-dedicated lang.
I think they mostly try to introduce the new language itself.
But surely quick "How to do Esp32 things" mirroring this http://docs.micropython.org/en/latest/esp32/quickref.html would be very nice.
Without it you need to look for tutorials and documentation tree or even documentation for specific packages providing embedded functionalities.
But surely quick "How to do Esp32 things" mirroring this http://docs.micropython.org/en/latest/esp32/quickref.html would be very nice.
Without it you need to look for tutorials and documentation tree or even documentation for specific packages providing embedded functionalities.
It's on our (my) Todo list.
The next best thing is currently probably this tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...
The next best thing is currently probably this tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...
The documentation at first glance looks like any general purpose language but they do have io through various buses:
https://docs.toit.io/peripherals
They also have nice simple tutorials.
Not sure about the event loop. I don't think it's even based. Looks more like "immediate mode".
https://docs.toit.io/peripherals
They also have nice simple tutorials.
Not sure about the event loop. I don't think it's even based. Looks more like "immediate mode".
I looked through the docs and did a couple of google searches and found nothing, but what’s the story with using toit for a DIY MIDI controller using the ESP32?
Similar idea. I'd love to build a merger/splitter with some midi transformation functions. I think I saw a midi library once?
What's the industry's consensus on Espressif modules?
As a layman they look like an insane deal. With western manufacturers $3.5 doesn't even get you a firm handshake whereas Espressif gives you a fully intergrated module with everything already on board.
https://www.digikey.com/en/products/detail/espressif-systems...
As a layman they look like an insane deal. With western manufacturers $3.5 doesn't even get you a firm handshake whereas Espressif gives you a fully intergrated module with everything already on board.
https://www.digikey.com/en/products/detail/espressif-systems...
$3.5 is pretty expensive when you can get microcontroller chips for $0.5 or less in bulk.
In general, "the industry" makes their own boards and modules, and prefers cutting off any excess cost and features in favor of getting cheaper microcontrollers to optimally integrate into a design.
That is, unless said designs actually need wifi, in which case Espressif is actually a consideration, but otherwise STMicroelectronics or Nordic Semiconductors chips tend to be more cost-effective, and the latter has significant leniency on board design as it allows remapping nearly all pins.
I look at Nordic the same way, but for battery-powered BLE etc vice WiFi; If this is your requirement, Noric is great. If not, it's probably not the ideal fit.
STM is more about versatile lineup; there are many variants with different footprints, redundant peripherals, price points etc. I think the $0.5 is only if you're a major manufacturer buying G0s or they're predecessors.
STM is more about versatile lineup; there are many variants with different footprints, redundant peripherals, price points etc. I think the $0.5 is only if you're a major manufacturer buying G0s or they're predecessors.
I have played in the past with the ESP8266 and the (original) ESP32, but I would be too concerned about backdoors to use them for anything serious. I'd prefer something like Nordic nRF.
This is exactly what I had in mind. With integrated WiFi and crypto it couldn't get any juicier as a backdoor target...
Espressif also has a bookstore direct outlet. The “module” prices look spendy but are sold in strips of 10. Here is ESP32-C3 at 1.90/module
https://www.amazon.com/Espressif-ESP32-C3-WROOM-02-N4-Module...
https://www.amazon.com/Espressif-ESP32-C3-WROOM-02-N4-Module...
Given that Espressif was one of the few companies not to fail during the supply chain crunch I wouldn't hesitate to use them. Unlike the Raspberry PI Foundation.
The pico (rp2040) never really had issues and it's more of a direct competitor to the esp32 than a standard pi.
True, but at this point their reputation is kind of burned for me. I'm not confident that if they have challenges come up with rp2040 production that they will be able to compensate quickly.
This is mostly due to Espressif modules being less demanded.
I'm running a few ESP32s and given their widespread usage I was surprised to notice that Espressif stock is very much near the lows of its 5 yr range, having lost over 2/3rds of its value from the peak. Is it just a function of market volatility? Do they have competition?
Tech market is down worldwide
Looks broadly similar to the stm32h7 series that I'm familiar with. Of course all of those are out of stock and cost up to $25. Presumably these are cheaper, though don't have onboard flash memory.
The documentation for the STM32s is probably better though still not impressive, and the STM32 software libraries are nothing to write home about. I think the ESP IDF might actually be better though I don't have a lot of experience with it.
The documentation for the STM32s is probably better though still not impressive, and the STM32 software libraries are nothing to write home about. I think the ESP IDF might actually be better though I don't have a lot of experience with it.
Having worked with both the ESP-IDF experience is far better than Cube MX or even HAL. FreeRTOS is properly integrated out of the box, and stateful drivers are implemented as FreeRTOS tasks. There are decent escape hatches if you need to get closer to the metal.
TRM and datasheets are clean and good (and no forced registration like some vendors).
H7 is a very beefy general purpose micro - more GPIO, multiple CAN, more UARTs etc. ESP shines when you need IP networking, wifi or bluetooth and can live within the (pretty generous) gpio and peripheral limitations.
TRM and datasheets are clean and good (and no forced registration like some vendors).
H7 is a very beefy general purpose micro - more GPIO, multiple CAN, more UARTs etc. ESP shines when you need IP networking, wifi or bluetooth and can live within the (pretty generous) gpio and peripheral limitations.
The ARM cores used in STM32s have great support. I think, at this point, almost any language and toolchain you could ever want. Good debugger support. The RISCV cores are going to get there and that's why I'm glad Espressif is moving that way. The Xtensa based ESP's are a dead end, in my very humble opinion.
I'm also not sure about licensing, but I know STM32s that you buy as development boards have a non-production or non-commercial use clause. Which sucks if you want to produce something in really small batches. I don't know if ARM based Picos or RISCV ESP32s have that same constraint. But I doubt they do.
I'm also not sure about licensing, but I know STM32s that you buy as development boards have a non-production or non-commercial use clause. Which sucks if you want to produce something in really small batches. I don't know if ARM based Picos or RISCV ESP32s have that same constraint. But I doubt they do.
The H7 in particular had some bug which made debugging difficult, though I forget the details. I think it was fixed after a few months.
> I don't know if ARM based Picos or RISCV ESP32s have that same constraint.
No, they don't. You can get the boards starting at about $2 a piece, which is about the same as STM32 clone boards.
No, they don't. You can get the boards starting at about $2 a piece, which is about the same as STM32 clone boards.
The code generation of the STM tooling is honestly the best part of using STM32s IMO. Especially in the personal project/hobby area where sometimes you just don't feel like churning out boilerplate but also don't want to sink to arduino ide levels.
The ESP-IDF framework is very nice but I haven't had much exposure to CMake so I'm still wrangling around with project structure.
The ESP-IDF framework is very nice but I haven't had much exposure to CMake so I'm still wrangling around with project structure.
64bits RISC-V cores? or a mix of 64bits/32bits RISC-V cores like on the bouffalo BL808? I cannot find anything about it.
This is chip is interesting as it is said the BL808 has a USB bug which forbid you to flash the bootrom over USB and you need to use the UART.
This is chip is interesting as it is said the BL808 has a USB bug which forbid you to flash the bootrom over USB and you need to use the UART.
Surely all 32 bit? I doubt anyone is going to use this with more than 2GB of RAM.
Maybe not, since we would like to write 64bits RISC-V assembly code paths once and re-use them (like on the bouffalo). Then 64bits<->32bits ports would not happen, even though we know RISC-V 32bits<->64bits ISA port was made easy.
This means seriously strong assembly code reuse.
This means seriously strong assembly code reuse.
@dang: can we merge https://news.ycombinator.com/item?id=34266996 in?
That one never made the front page so I think it's ok to let a second thread run. Thanks for linking to it so people can read those comments also!
Meanwhile, we still can't buy many STM32s. An H7 project of mine has been on hold for 1.5 years. It's time I learn to program for Espressif.
Have you considered the RP2040 for it? I switched many of my projects (they have low computation needs) to that and it worked well.
What is the price for this?
ESP32 is my go to MCU to use now. Their tooling and libraries are so far ahead of the competition especially when you factor in the choice of CLI or VS Code - an actually good IDE. ESP-IDF is so reliable and easy to use I don’t feel the need to JTAG/SWD debug anymore…
I use it at work, and while it’s quite good, I find some of the ESP libraries on top of FreeRTOS to actually be a step backwards. As soon as esp adds their event loop, you’re pushed towards using that architecture, and while I’ve found that good for single use devices, for devices that are doing multiple things at the same time, fitting in memory has been a chore.
I also would love some higher performance networking with zero copy, most of the interface boundaries in the esp code involve a memory copy.
Yes its easy to use but a bit wasteful. I suspect that the innovative stuff will come from the Rust side of things, with zero copy, shared stack etc. They are actively funding efforts here [0]. The RTIC [1] project looks really neat, but only supports Cortex-M afaik.
[0] https://github.com/esp-rs
[1] https://github.com/rtic-rs/
[0] https://github.com/esp-rs
[1] https://github.com/rtic-rs/
I’m really really pumped about the rust stack, for two big reasons.
1. The innovation and performance you’re talking about.
2. Hiring. We’re going to be able to be on a flashy language, doing something cool which isn’t always the case with embedded. We’ve had a hell of a time getting candidates in that could write low level code competently. Rust should make that easier and hopefully using it will make us more attractive to the small pool of devs we’re courting.
1. The innovation and performance you’re talking about.
2. Hiring. We’re going to be able to be on a flashy language, doing something cool which isn’t always the case with embedded. We’ve had a hell of a time getting candidates in that could write low level code competently. Rust should make that easier and hopefully using it will make us more attractive to the small pool of devs we’re courting.
My impression is that a certain kind of people find the challenges of embedded work attractive, but leave it sooner or later since the pay is not competitive with generic (but more boring) webdev. I guess this is due to the nature of thin margins in manufacturing hardware?
Depends what you’re building and where I guess. I didn’t get a pay cut moving from BE distributed services to embedded.
I did a bit of RTIC and can confirm it's pretty pleasurable to work with. It's sort of almost-RTOS, just enough to get some concurrency going without going full-on OS. It also cleverly uses unused ARM interrupts to act as sorta hardware accelerated context switches
That wouldn't be entirely surprising!
Arduino does a great job with marketing but at the end of the day you could do 99% of Arduino projects with an ESP32 for 1/10th the cost, use less power, and get way more features at the same time, while still using the Arduino IDE or VS Code with Platform.IO.