Huge huge fan of ESP32s over Arduino/RPi/etc for any/all projects where I can do so. I’ve probably got 15-20 ESP32 projects around the house, and have done somewhere around 80-100 for other people.
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.
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.
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.
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.
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.
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
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)
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_.
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.
> 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).
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).
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.
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?
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 ?
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.
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.
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).
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...
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.
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
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 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?
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.
$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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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
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.