ESP32 is nice in that a lot of things you might have to fiddle with elsewhere just work.
They have a good ecosystem that they've spent time on. So things like auto-reconnecting wifi just works (it's been ported from ESP32 elsewhere but is a bit hit or miss).
Same with bluetooth and OTA upgrades, and you name it.
Especially coming from some other board types, it was like "oh i guess that just worked the first time" for a lot of things.
I have a bunch of ESP32-S3's locked in some woodworking machine cabinets (they are used to monitor the machines for dust collection control/failure/etc.). It's trivial to make them do firmware reprogramming over bluetooth. You could do over wifi too, but in my case, the machines are too RF noisy (VFD's, etc) and enclosed to make it work. bluetooth only works because i'm like 2 feet away, but it works and i don't have to open the cabinet to update the programming.
I also use one to broadcast a stupid bluetooth beacon that my garage door opener uses for "UL compliance" - It has bluetooth lights, and it won't let you open/close the door remotely unless it detects them, because UL requires they visually signal the open/close when done over wifi.
Which again, just works. I never had that experience outside of the nRF52/nRF53 series
There are some good low-power boards with the S3's, though it can be hit or miss (IE assuming you really want the 20ua deep sleep to be ~20ua).
If you want something like a remote running off a small battery for 10 years, you may be better off with the heltec cubecell's or something.
(They really easily get 3.5ua in sleep)
I honestly had a hard time getting started with ESP32-C3 (my first ESP device). Admittedly all of it was my fault, I got too cocky and assumed things based on previous work with competing devices that I shouldn't have.
Once up and running they really are quite pleasant to use, and pretty damn cheap.
The issues that hurt me the most were:
1/ It doesn't come preloaded with 'AT' firmware, it took me a while to figure this out as well as a PCB respin.
2/ The clearly labelled TX and RX pins are for flashing and debug output only, not for communication with an an external microcontroller. Two to four GPIO pins (decided by the AT firmware) are used for communication in 'AT' mode
3/ Two GPIO pins need to be asserted high and low on startup to enter flash mode. This fine when you figure it out, however the flash tool still tries to upload the firmware and 'fails successfully' with the correct upload delay.
Coming from the rpi platform one thing I miss is there's no standard UI configurator or desktop OS. For wifi credentials or cloud authentication and such it ends up getting programmed in, or you have to build a UI yourself that is specific. But if it doesn't include all the amenities an OS would have like mouse/keyboard, USB file transfer, corporate wifi setup, etc - it's not useable for environments where IT has to co figure it.
I feel like the modern world of embedded hobbyist computing has really obscured the embedded aspect. This is good for getting people going but terrible for newcomers understanding the difference between a tiny personal computer with IO(raspberry pi) and baremetal/rtos devices that range in various levels of compatibility.
When I read this, at first I thought "well DUH it doesn't have a desktop OS or various desktop utilities built in, its a microcontroller!"
Then I realized for a lot of people now, their first led blink "hello world" was possibly not on a microcontroller at all. To me, the idea of wanting a mouse and keyboard for a microcontroller to set up wifi seems silly, but to others, they just haven't experienced the alternative.
There is great support for various wifi security standards for the ESP though, you just need to create something equivalent to how a chromecast connects to the internet for the first time. bootstrap an AP, connect to a portal, configure on the portal, reboot and connect to the actual AP.
Depending on what you want to actually build, another option is ESPHome coupled with the Home Assistant ecosystem or standalone with MQTT. Most of the sensors, displays, etc. you'd want to interface with are supported, and everything is some simple YAML config. If you need more flexibility, it supports 'lambdas' which are snippits of any arbitrary C++ code you want, or you can write custom components in C++.
The big benefit to ESPHome is it handles all the 'boring' stuff like Wifi updates, timers, and API/MQTT glue code. I still write one-off stuff in PlatformIO, but most of my devices are running ESPHome with some custom code added on, because I don't feel like reinventing the wheel.
What use case prompts you to making this statement?
It's not a general purpose PC with I/O tacked on, like a Pi is, but more like the reverse: I/O and a wifi/bluetooth chip that also has a small (but powerful) processor.
I must be reading your comment wrong, because it sounds like your IT department can't handle devices without a mouse and keyboard, which means they don't use any networking switches or access points. Or badge readers. IT departments can handle it just fine if required to, they just don't want to have to.
I bet the line of sight check is so you don't accidentally crush children or animals in your garage door while closing. So I don't think it's that stupid.
No you are misunderstanding. It's not the line of sight sensors that are Bluetooth (that would be highly dangerous), its just a light.
When you have an overhead opener the light is built in, and hard wired. It blinks when the door is triggered remotely.
When you have a side mount (jack mount) opener, there is no light built in. They give you a Bluetooth light, meant to be mounted on the ceiling like you would have in an overhead opener.
The light is only required when the door is opened over wifi. All keypads (which are RF as well) and remotes work regardless. It is only wifi opening.
This is not a useful safety device. Either it should be required and trigger regardless of how the door is opened (so that I know that it means door is about to move) or not be required at all. Having it required and triggering only some of the time the door opens is not something dependable or useful.
This safety device is useful because other methods of closing the garage door require physical proximity, i.e. the wired button, the remote in your car. These operators are necessarily close enough to the door to see if it is clear.
But if you close the garage door over wifi, the user closing the door could be anywhere. This user may not be able to see the door or warn people nearby that it is closing.
I own a Tailwind device which implements this safety feature.
Err, no.
The buttons are not wired anymore. All buttons are battery powered remotes, even wall pads. This is how it's done now - the manufacturer does not ship any hardwired buttons for these models (Genie 6170)
Not sure why everyone keeps making assertions about the setup instead of asking questions. First claims that it's a line of sight safety device (which is wrong), now weird claims about physical proximity (which are also wrong).
Zero of the manufacturer shipped mechanisms to open or close these require physical proximity. Someone can open the door while i am in there using the remote, etc.
It works fine from 300 feet away, and in fact, it's quite common for it to be opened or closed while someone is 150ft away at the bottom of the driveway.
We also had a wall pad in the house that triggers the garage, also (it's no longer needed but we started with one).
Wifi is no better or worse here - So i still maintain having a device that does not trigger all the time, despite lack of physical proximity, but instead based on whether it's FSK or wifi, is confusing and pointless
But it would cost nothing to also have the light activate on all occasions when the door is actuated. Someone who is hard of hearing may be physically present but unaware that the door is being operated.
It seems strange to not at least have the option to choose if you want the light to operate in such cases. The manufacturers have gone out of their way to reduce safety.
I agree. This article seemed like person who wanted to pick something up and make something and just have it work.
The ESP is often a good series for that. It is widely used and well tested.
Cubecell is great for very low power. But it took more work to get it working. The scale of use is clearly lower so I ran into bugs at the time that I'm sure are worked out by now.
The result was great mind you. I built a remote controller for some things and it will easily last 10 years on a simple 1/2 as cell.
nrf is definitely more featured and thoroughly tested then either. But the startup can be harder to do depending on what you do (ie running zephyr on it)
I really enjoy using ESP32 devices in Home Assistant with ESPHome.
From the add-on:
> [ESPHome] add-on allows you to manage and program your ESP8266 and ESP32 based microcontrollers directly through Home Assistant with no programming experience required. All you need to do is write YAML configuration files; the rest (over-the-air updates, compiling) is all handled by ESPHome.
You can also add that a lot of commercial home automation devices use ESP chips. This often allows the open source [Tasmota][0] firmware to be flashed on them and make the devices compatible with Home Assistant or alike.
Some points that could be improved:
The article reads like someone is talking. For me that style of writing is bit off-putting, i.e. too much fluff.
I am surprised the manufacturer of the chip Expressif is not mentioned, as both ESP8266 and and ESP32 are by them.
> The ESP has no integrated firmware.
then near after this, you write
> This firmware is then flashed to the ESP Chip with the help of a “burned into the chip” ROM bootloader (more info).
That means there is a firmware, the bootloader. Expressif gives a really good [explanation][1] how this bootloader firmware works.
I started out with Arduino but quickly switched to EspHome. There's just so much built in that you don't have to sort out:
* Wifi reconnect
* Mqtt (and HomeAssistant) integration, with reconnect
* Hotspot (initial configuration) support
* Tons of hardware devices supported
* Even for basic digital io, there's nice quality of life things a line of yaml away: debounce, internal pullup, invert..
Basically by my second or third experiment I found myself starting to build more reusable libraries to do stuff like wifi+mqtt reconnect. Thought "someone must have done this before" and found "Yes, plus went 1000 miles further and built EspHome"
For those looking for cheap dev boards, I've had good luck with 'HiLetgo' on Amazon. The WROOM-32S is my go-to, but I also use the WROOM-32U when I need an external antenna (it _must_ be connected) or the 32S+CAM module for the camera. I haven't gotten a DOA component yet.
The Ali prices aren't significantly cheaper than many of the sellers on Amazon (at least in small quantities), you don't have to wait a month, and if you get a dud, replacements are easy.
Even though I started with the 8266, as the article mentions, there's little reason to choose that outdated board at this point. It's worth the extra $1 to get the 32 in a DEV board configuration. Having the CP210x and USB onboard is also worth it for the hobbyist.
Looks like the HiLetgo also has an ESP32 board with integrated LCD display. Boards with integrated displays I found to be very cool when beginning to play with. My "Hello World" was a graphical traffic light (bonus using the integrated buttons to simulate car-over-sensor or pedestrian hitting crossing button).
Many cases that don’t require Bluetooth I still find the 8266 worthwhile. Especially if you’re trying to build a product and BOM cost are being considered. The extra $1 doesn’t matter for hobbyists. Also I second the HiLetgo products, I have dozens of their products and it’s always good quality.
Amazon is giving me prices of $25-$35 for all the esp32, including the hitletgo you mentioned. Ali is $1.5-$2. Amazon also says 2+weeks deliver for many, Ali says 3 weeks. I'm in Canada
The -S2 (and -S3?) have native USB so you don't need a USB-UART chip on-board, and they can thus emulate other classes of USB devices. That's something I was hoping to find mentioned in this guide, but nope.
Unlike the ESP32-S ones though, that's all it does on the C, so you can use it to program and debug the thing, but you cannot make your own USB device with it.
Not much to be said, it should "just work" out of the box. You plug a board in (for example this one https://www.dfrobot.com/product-2566.html, I've seen it in a bunch of online stores in Europe), and it should give you a COM port on Windows, a `/dev/cu.usbmodem...` device on macOS, and something similar on Linux. Then all the usual tools should work as normal, at least the ones that come with ESP-IDF.
On the chip or the modules, this is pins GPIO18 and GPIO19 that just need to be directly connected to USB D- and D+. Of course the chip still needs between 3.0V and 3.6V for power, so you can't power it from USB directly. If the firmware is just rebooting all the time (sometimes the case on a fresh module), you may need to pull GPIO9 low to enter bootloader instead (https://docs.espressif.com/projects/esptool/en/latest/esp32c..., there is a button for this on some boards), but otherwise you can just flash it in normal mode too.
Oh, so this isn’t full in circuit debugging like ESP-PROG would enable, correct? These parts just have built in USB-Serial for programming and printing to the terminal without an external IC.
Edit: Never mind, it does appear to allow full in circuit debugging. I’ll have to do some more research.
As far as debugging goes, you basically need to run `idf.py openocd` to start OpenOCD, and then connect to it with the gdb that's part of the ESP-IDF SDK, by default it should be listening on port 3333. At least that's how I have it set up in CLion.
Yeah, this is great if you're making your own PCBs -- all you need is the ESP32 module, power supply and a USB connector.
There's no need for a usb-serial converter, JTAG connector (you can debug over USB), or a serial header with yet another random pinout that you have to figure out every time you want to program the thing...
Exactly! Our board at work got all our JTAG pins back for us to use for other things, and we got a more robust programming/debugging setup to boot. So nice. The S3 is phenomenal, and the LX7 on it is surprisingly powerful too.
Nice. They also tidied up the GPIOs a lot, which is such a good quality of life improvement (though I did spend a while hunting through the datasheet looking for the bit where they tell you that GPIO7 can only be used as an output during a full moon, or whatever).
I have one of the Wemos C3 pico boards which rely on the C3's native USB serial controller. The experience is pretty rough for quick iterations on a devboard on Windows.
You restart the board to programming mode by holding down the BOOT button down while pressing RESET. Wait a few seconds, then COM7 is available. You program the board, and then manually RESET the board with the button. COM7 disappears. Then you wait a few seconds, then COM6 appears. Oh, did you print some debug info on boot? Too bad, it takes a few seconds for the virtual serial port to appear in Windows so you just can't get input during that time because the reset resets the USB controller as well (the entire chip).
This is the benefit of on-board USB-UART chips: if you need to reset the chip, your USB controller doesn't need to be reset so your serial port stays open. Additionally, most ESP32 dev boards offer automatic reset by utilizing the DTR or RTS pins of the UART chip and a couple of transistors.
No button presses necessary (there are no buttons even, I have a slide switch on my PCB but almost never need to use it), everything resets automatically (except when it's in deep sleep, then I need to unplug it and plug it in again), I see log lines from the very first line in `app_main()`, etc.
I'm using a recent version of the ESP-IDF framework including all its tools (there is a VS Code extension that has a `Build, Flash and Monitor` button, I think all the operations are just run using the `idf.py` script, but not sure).
I haven't followed QMK recently, but I assume someone is working on an ESP32 port, now that some chips have USB device support. I'm not sure what I'd do with a keyboard that has WiFi, but I'm sure cool (and non-nefarious) ideas will emerge.
I have been working on the Toit language for the ESP32 for a number of years now -- and it has been an enjoyable challenge to build an open source stack capable of supporting live reloading on a micro-controller that can run for years on batteries.
I've only been building things with Arduino Uno/Nano/Mega (clones) so far and they are kind of limited. Those ESP32 I've now got seem to have _everything_ onboard: lots of IO pins, hardware PWM (although I do not understand that fully yet), WiFi, Bluetooth, hall and temperature sensor onboard.
All of that for 8 Euro/piece. It's sick for IoT projects, really looking forward to doing more of that.
edit: I'd love if Arduino et. al. would start using USB-C plugs though. I've got everything from USB-A to micro USB around here and I'm constantly looking for the right cable to use a board. Does anybody know why they haven't switched to USB-C yet?
I suspect USB-C connectors just cost 5 cents more so they aren't used on most dirt cheap dev boards. I've seen adafruit update their stuff to USB-C but they also charge a good premium over the generic ebay clones.
Amusingly, the PWM output we do on our firmware is actually done using the RMT infrared remote control peripheral instead, as the LED strips we need to control are too fast for the internal PWM controller lol
I just had a quick glance at the PWM documentation but I don't fully grasp it anyway: I select one of the 16 internal PWM controllers, set it's clock/frequency and then bind an output pin to that.
I thought that fading a LED would then stick to the frequency of the PWM controllers, but it seems I still have to take care of the speed?
I thought setting the PWM frequency to 100 Hz and cycling my LED brightness from 1 to 100 would take 1 second. It doesn't work that way it seems?!?
A word of warning on this. It uses a custom fork of LLVM/Clang/Rust which adds support for a new architecture. The tooling that sets up this environment has failed in obscure ways each time I’ve attempted to set up and build one of their own hello world samples.
Support for the ESP8266 I had sitting in my desk drawer is a little rough, the code templates they provide don't seem to work out of the box. I gave up and am just buying an ESP32. Should be a much better experience, I'm hoping.
For those who want to start experimenting with a fully loaded device ready to go, the M5Stack Core2 is a great option because it includes a ~2-inch color touch screen, soft buttons, 16 MB flash and 8 MB PSRAM, a speaker with I2S amplifier, PDM microphone, 10 programmable LEDs, vibration motor, RTC, microSD slot, lithium battery, 6-axis IMU, M-Bus Socket, and Grove connector for $50 delivered.
M5Stack makes a huge ecosystem of >100 add-on modules that snap onto the bottom of the Core2's form factor, including a wide range of sensors, LoRa & cellular radios, I/Os, interfaces, servo drivers, GPS, cameras, HMDI, RJ45, UWB, RFID, etc. It's quite a clever modular expansion system that makes prototyping (or just playing around) super easy.
Note: I linked (and have) the AWS IoT Devkit version of the Core2 which comes with an upgraded battery module on the bottom vs the standard Core2 (a bit more Mah plus ten RGB LEDs built-in). It's also $10 cheaper than the base Core2 on Amazon thanks to AWS subsidy. The only difference is it comes with AWS Fire IoT Devkit firmware pre-flashed but it only takes a minute to flash it back to stock Core2 firmware.
I've been using Wemos and other various 8266 and ESP32 boards but recently picked up a M5StickC PLUS and i dont think I'll ever go back to those little standalone boards. Having everything in a nice little case with battery and most of the sensors i need, it is def a good way to go. Poked around with that FlowUI stuff and it was just too creepy to have to have my microcontroller connect to a server across the globe to program it, so a switched back to Arduino and using OTA.
The whole M5Stick ecosystem of addons it awesome too.
Yes, there's a grove connector for 3.3v on one end and more GPIO that can handle up to 5v. They have a lot of i/o on that particular device already allocated - there's a screen, a beeper, a microphone, IR and LED out, an RTC, and a 6-way motion detector, plus the buttons and a small (120mAh) battery with charging management hardware. If you are unhappy about having that much power and flexibility for under $20 you might be a little hard to please :-)
Larger units have 2, 3, or 6 grove connectors, plus a big library of pluggable peripherals.
S2 and C2 are not old versions of S3 and C3 (C2 isn't even released yet), they are just cut down/lower cost version (but also with some added features for low power operation).
If it's a guide maybe you should mention that the original ESP32 is still for sale and still faster than some of the newer alternatives. There is also a new faster risc-v based variant without wifi/bt that was recently presented called ESP32-P4.
Some projects don't work with the newer boards (wled for example).
Partly this is because the Esp sdks aren't as mature for the newer boards. This is very true for the brand new C6 series, but somewhat true for th S3 and C3 lines as well
Does anyone know of a nicely packaged US smart plug that's not actually smart, but instead has an external input that I can plug a GPIO output into, and that has a solid-state relay so that I can PWM the plug?
This is the closest I could find, but it uses a physical relay, so it would be loud and probably incapable of any reasonable PWM rate: https://www.amazon.com/gp/aw/d/B00WV7GMA2
I'm interested in playing around with sous vide. I realized I have all the parts (anything Arduino-like, basic AC immersion heater, water pump, thermocouple with MAX6675 interface) except the SSR. I could buy a $15 SSR, but if I'm adding one to my collection of tools for this and future projects, I'd prefer it look more like a smart plug than a mess of wires and terminals that could be a hazard in the kitchen.
(Sorry to hijack, but can't resist this gathering of IoT enthusiasts.)
I'm not sure I would use PWM to control the flow of power to an AC appliance. That's more of a technique for getting analog approximations from digital sources.
If the purpose is to make a temperature-controlled water heater, you would probably be alright with just using that regular relay and switching power on/off to the element every few seconds. It takes a while for electricity to heat up water, and with some hysteresis / a PID loop you will get very accurate results, even switching once every five seconds.
Thanks (and thanks to petre down below). The Arduino PID libraries I found want to use PWM, but part of the appeal of the project was understanding PID in the first place, so perhaps I could adapt it to something like a 0.1Hz modulation rate and see where that gets me.
I assume it's hard to do proper AC PWM if you don't know when the AC sine wave's phase starts, preventing you from maintaining a consistent pulse amplitude over time. But I was hoping that something simple like a resistive heater wouldn't be too fussy about it.
And then there's the small matter of my home being constructed from flammable materials....
You can do PID using a discrete output instead of analog/PWM. It's a common use case. I think I've seen an Arduino library that allows for this. Or, you can use whatever library you're already using and convert the PWM value to OFF or ON. Slow down the loop so you don't get a lot of chatter on the output; add hysteresis if necessary.
If you actually want to do AC "PWM" (it's not really PWM), use a triac as suggested by another poster, and make sure it does zero crossing detection.
For the water heater he doesn't need PWM, Tasmota has a thermostat mode with hybrid PID control. There's Sonoff TH2 device that can do that. Dunno what temperatures does sous vide use but it can be definitely done with a Pt1000 or a thermocouple if not the regular digital sensors.
You might want to look into AC Dimmer products. I don't have a specific manufacturer / product to recommend, but I think you can find generic boards that'll do what you want. I _don't_ know if you can find one in a nice enclosure.
From what I remember, you probably want something that'll provide zero crossing detection. My vague understanding is you get the equivalent of PWM control, by cutting the AC sine wave relative to when it crosses zero voltage.
Thanks. I'm looking for something that can be put away when the project is done and that can be moved to other places and used in different projects. I could spend a weekend figuring out how to build something safe with a quad box, or I could give $20 to someone who's already done it.
If you’re willing to do that why not just buy a sous vide? There are $50-60 ones available. I’m guessing cause you want to code the control, but just saying because there was a time when I couldn’t find one for less than about $300 but they’re more affordable now.
I actually already have one that works fine. It's less about cooking better chicken, and more curiosity about the software, PID algorithms, etc. The AC relay isn't all that interesting to me, so I'd be happy to treat it as a black box.
Normally only if the display has its own controller, and you talk to it via SPI, i2c, or an 8 or 16 bit interface.
But those methods are slower and if you're doing a higher resolution user interface, the RGB interface lets you drive stuff like an 800x480 display at well over 60 fps.
For example: what does it mean "Built-in battery support."?
- will it allow you to monitor the battery charge?
- can I charge it using the micro-USB
- does it have undervoltage protection?
- what is its quiescent voltage?
- what is its consumption in deep sleep mode?
As for the Esp32-Cam, those little camera modules are flawed, one of the pins act as a 20Mhz antenna and causes interference everywhere including itself, and your board might or might not work.
Good point. Indeed, a closer look is needed in order to make use of any feature of a MCU board that's not built into the MCU itself. I've gotten in the habit of going straight to the schematic, e.g., for the Wemos C3 pico:
Battery charging is handled by an external chip, so I've looked up its datasheet when I needed (for instance) to reduce the charging current. The schematic shows a voltage divider feeding one of the ADC inputs for battery monitoring.
Also, no schematic, no buy. I've had good results with stuff from Wemos. I've also gotten boards that were definitely copies, worked fine, but caveat emptor.
Just got into IOT devices and I am using RP2040 boards(with wifi and without wifi, bluetooth is enabled now I think), what's the advantage of ESP32 to RP2040 these days? It's $4 ~ $6 a piece and also is solder-able to your base-board if you need make your own, it of course runs on its own without any base-board perfectly fine.
Compared to the ESP32-S3, the RP2040 doesn't have Wifi/BT, doesn't have an RGB display controller, has slower clocks, and has less RAM and Flash.
For most IoT devices the ESP32-S3 is overkill unless running a large display, and you could use the cheaper ESP32-C3, which has 1 core instead of 2, no RGB interface, and less GPIO. These run about $2 each for a solder-able module with built in antenna: https://www.digikey.com/short/cttthh0h
It could be an advantage if the rp2040 had a decent low power mode - then you could only turn on the wifi when you need it (eg data upload every few hours) and run for a year on battery. Alas it doesn't...
I think the main advantage (to some, in the current geopolitical climate) is that it's not Chinese.
The ESP series can disable wifi/bt entirely if needed, their low power sleep is pretty good. IIRC someone got a year or more out of a single 18650 cell doing very slow updates.
ESP32 doesn't have RP2040's PIO. It's just amazing, and can easily emulate RGB display controller or whatever you want it to. Even software HDMI with most CPU power still available. Thus bitbanging possibilities are endless, and this chip can sometimes replace an FPGA.
Pi Pico W boards also indeed have Wifi and recently bluetooth was enabled.
RP2040 also overclocks pretty easily, and people have pushed it even past 400 MHz. Wouldn't overclock in anything important, but for hobby projects — why not! It's about as fast per clock as dual core ESP32 (except for DIV & FPU math).
Both chips have their uses. For example ESP32 got HW FPU and integer division division, those can really help in some cases.
Anyone have a recommendation for something that can take 2 USB in and be the USB device to 2 separate up stream systems? I’d like to build something can pass through a keyboard and mouse to 2 systems but also embed some hot key actions and the like so it always works regardless if my preferred OS install is configured and booted.
The Teensy is very popular for acting as either USB host or peripheral and there's lots of projects to draw ideas and code from. The latest one only has 2 physical USB ports, so you would have to use a hub for your use case. I don't think you'll find a microcontroller with 4 physical ports anyway.
You want 2 or more off CH9350 - HID mouse/keyboard to serial adapters - they are designed for exactly your application. Wire back-to-back and piggyback an ESP of your choice on the serial ports to eavesdrop/intercept/augment. Available from Ali.
Looks really interesting, do you mind sharing it (if its open-source) once its done? Probably it could be a great addition to https://github.com/esp-rs/awesome-esp-rust
The article doesn't mention plain ESP32 - the first in family, dual core. These are the most popular on Amazon etc. There is also ESP32-S0WD single core version.
This is great. I tried to spin up a small project over the Christmas break and got bogged down with so many options for buying an esp32 and then struggled working through the docs. I previously worked with an Arduino Uno years ago and that thing felt like it had a better UX for someone that is a real amateur when it comes to hardware. Glad to see a resource like this cut through the fog.
My new HomePod was delivered yesterday and while exploring I discovered HomeKit now has Matter support. I have a few ESP 32s lying around and wondered if I could connect them directly instead of bridging through ESPHome / Home Assistant. Apparently you can! Will be trying it out later: https://docs.espressif.com/projects/esp-matter/en/main/esp32...
Whoa. You can also use their ecosystem to put together a Thread border router! I think your HomePod might integrate that functionality already, but this is super interesting for someone like me and my old trusty Asus wifi router.
If you're willing to spend a little more for extra features, it's worth mentioning the S3 boards by Unexpected maker: https://esp32s3.com
They have some nice improvements over the generic boards you'll find on Amazon, etc., like extra flash, extra GPIO pins, USB Serial JTAG pins, multiple LDO regulators, and multiple Qwiic/Stemma QT connectors (4-pin JST PH-compatible connectors used by I2C devices made by Sparkfun and Adafruit).
And really annoying physical layouts - it's impossible to get the LED arrays flush with a front panel because USB connectors etc. are significantly taller.
Question for anyone else using an ESP32 to build a USB input device (macropad, game controller, sim button box, control panel, etc.):
Is there a generic library, config file format, host application, or other tool you use for configuring keypresses and macros? I'm currently doing that manually with hardcoded mappings, but it seems like there must be a better way. I'd really like to use something like QMK, but that's fairly specific to keyboards and doesn't support ESP32.
I realized after posting that this is a personal blog, not a corporate one - so I do regret and apologize for being rather blunt.
(I think the .io and me misreading as “etherway” made me think it was company-published and for right or wrong I assume companies only ever blog for brand recognition, so am probably over critical of them)
That’s partly a big compliment - your blog is really well styled and easy to read.
RISC-V is a fairly popular topic on HN, and for me at least it’s really interesting as both a low-level nerd, as well as curiosity about what impact it may have given we lived in an x86 world for a long time, before ARM really took hold, and now that there’s a new player and it’s an open standard is really interesting.
Could it be the “Linux kernel” of the hardware world? I have probably 20x ESP8266s doing various things in my life, maybe 5x ESP32-Sx, and will probably pick up a few -Cx, and they’ll be the first RISC-V device I own.
>I know the ESP32-Cx is based on the RISC-V architecture. Could you elaborate why this is a feature or in what way this is an advantage?
Long term support. As Espressif has publicly declared their intent to fully move to RISC-V, it is not in your interest long-term to base your designs on the ISA that's been deprecated.
How does dual core work on these microcontrollers? Do you have to deal with scheduling between both cores or is it magic?
It would seem that it would be up to me to figure out which CPU something should run on, right?
So if you aren’t doing a workload that requires it, is there a point? Or does it use one of the cores to offload managing networks, Bluetooth’s and whatnot?
A little bit of both. The simplest way that I like use is by creating a seperate function that you want to run asynchronously, then linking it to a callback that is scheduled to run by the FreeRTOS scheduler: https://savjee.be/blog/multitasking-esp32-arduino-freertos/
As long as you don't create too many long-running tasks and be mindful of which core is running what, it's been incredibly reliable in my experience.
My biggest use case for this is keeping an active display, like those 64x64 RGB LED Panels, fed with pixel data from a display buffer using one core fully pegged to the task, then using the second core for wifi and display buffer updates. In Arduino land, since loop runs on a specific core, you can basically put your 'constantly running code' in the loop, and schedule the tasks to run on the other core in setup().
The multi-core aspect can cause interesting challenges, especially if you’re using Arduino libraries that assume single core usage. Fortunately there’s really great synchronization primitives that you can use but if you come from an Arduino world it can be a shock. You have to be a lot more careful with interrupts and such to avoid causing crashes.
I’ve also found Espressif’s documentation to be exceptionally good which has been a big help.
If you’re doing any ESP32 dev work I strongly recommend getting a FT232H which can be used as a JTAG debugger if you don’t have a board with native capabilities otherwise debugging is really, really painful.
It was actually launched in Jan 2023. It's been mostly out of stock, but a bare module with 4mb spi flash is in stock right now. However, currently populated dev boards are overpriced.
I have been using the M5Stack Tough for a product. It has worked reasonably well, though I have had a 10% defect rate on the touch digitizers. I will probably end up switching over to a product from https://www.makerfabs.com/ for a larger display.
But it has worked fairly well. The stack was:
-Platform.io
-ESP-IDF framework
-LVGL an embedded ui framework that is pretty simple to use.
-FreeRTOS
Works great, its been reliable and it will probably remain my choice for the next couple years.
One thing I would like is better Rust support. I have taken a look around and everything is just out of date bindings to C/C++ projects. Not a whole lot of native Rust, so I don't really feel the need to switch until that changes.
> One thing I would like is better Rust support. I have taken a look around and everything is just out of date bindings to C/C++ projects. Not a whole lot of native Rust, so I don't really feel the need to switch until that changes.
There are currently 2 approaches for Rust in ESPs:
- std: Its built on top of ESP-IDF, so it ends up calling C functions. I guess this is what you've seen in the past.
I want to build a game with
- a wireless led (a 5-light length of a led strip would work)
- a camera or other module to tell what color ball is in front of it
And a controller to change multiple of the wireless LED lights based on different cameras...
Esp32-cam has 4 available gpio pins (there are 2 more pins but one is used by SD card and one is connected to built-in flash) plus 2 uart pins. With narrow angle camera it costs around $6. Wide angle camera costs $4 or so. You need serial port to program it. There are some other limitations you'll only find when you start playing with it like DAC not working when wifi is on. So theoretically you can control 6 LEDs directly. On one 18650 battery it lasts 2 hours.
--------------
| SDCARD |
5V -|1 16|- 3V3
GND -|2 CAMERA 15|- GPIO_16 (useless, can't be used for anything)
A GPIO_12 -|3 14|- GPIO_0, connect to GND during programming, used by camera, don't use!
A GPIO_13 -|4 13|- GND
A GPIO_15 -|5 12|- 3V3/5V
A GPIO_14 -|6 11|- UART RX, GPIO_3
A GPIO_2** -|7 10|- UART TX, GPIO_1
A GPIO_4* -|8 9|- GND (weird, don't use)
| LED |
--------------
- A=analog input 0..4096
- GPIO_4 is connected to FLASH LED, if you want to use as input you need to desolder resistor R13 that goes to base of npn transistor
- GPIO_2 is HS2_DATA0 for SD card, it has 47k pullup
You could use addressable RGB LEDs, like the WS2812B. You just need to supply power and a single IO line to control them so you don't need any external hardware like MOSFETs.
The ESP32 can read the camera, recognize objects/colors, and control the LEDs without any external systems.
Using ESP32s connected via Wifi and MQTT to a host (Pi or something) would be the easiest way I can think of to coordinate that.
You could also go without a host, by having the ESP with the ball randomly choose another and send the command to it, and connect them all together with ESP-NOW which is direct P2P communication.
(no affiliation and never bought from them, just an example of what to look for)
If you never worked before with electronics, however, you'll probably also need some basic equipment to test things and/or add functions (say you want one more LED, or need to add/replace a capacitor, drive
more current with an i/o line etc.).
Take also a look at the beginners section at the EeevBlog forums. It contains some good advice on how to set up a basic workbench: https://www.eevblog.com/forum/beginners/
It's worth mentioning that the Arduino IDE now supports MicroPython, which will make getting started a lot easier for a lot of people. Most advanced IDEs do too.
As far as makers/peripherals go, I'm also a big fan of M5stack, which have a big range of controllers and peripherals and are very accessible & responsive on Twitter. Their stuff is very competitively priced, available stripped down or in enclosures suitable for pocket, industrial or even outdoor deployment, and it's super-easy to get started with.
The ESP32-C3 has a limited number of IOs but it is very small and has a connector for an external antenna (At least the Seeed Xiao ESP32-C3 does). It's great for many applications when a bit of Wifi range is needed.
I had been using the 8266 in a personal project and this past year moved it over to the c3. I was excited to use a RISCV chip. That doesn’t really make a difference in the end, but I’m really pleased with it, especially after I stopped fighting the Arduino IDE and moved to PlatformIO - I had been reluctant to do so, but it’s really matured.
Hunting around for answers about how the c3 works can be rough. There’s still not a lot of info about its quirks written up yet. But once you get into it, it’s great. And quite affordable.
I'm working on a network-level AdBlocker project functionally similar to Privoxy which requires 2 Ethernet ports. One connecting to the modem and the other connecting to the router so that it's possible to MITM the traffic, but I don't see any boards with 2 Ethernet ports. Should I:
- buy 2 ESP32s with an Ethernet port on each and communicate between them over serial
- buy an ESP32 with Ethernet and USB and use an Ethernet to USB adapter
Yeah, I know a lot about PiHole and how it works, but I'm creating a MITM AdBlocker like Privoxy. For that, I need 2 Ethernet ports. Raspberry Pis also cost a ton right now because they have been heavily affected by the silicon shortage. Also, I want to develop for a platform which is cheaper than the Raspberry Pi at MSRP.
It should be possible to do that using one Ethernet port using VLANs. You could buy a cheap L2 managed switch and use it to trunk two different Ethernet networks on the same port. Then you would configure the Linux networking stack to split the VLANs into separate interfaces.
I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!
ESP32 are great! The best use case for me is using them as bluetooth repeaters. I use ESPHome and its configs for most devices. For some ble devices, I use nrglogger on my Android to reverse engineer the commands and then feed that into an ESPHome config. It has helped to connect many devices which don't have WiFi anywhere in the house.
If you're just making HTTPS requests to your own servers, you can simply include the root certificate of the CA you're using, pass it to the config when calling `esp_http_client_init` (https://docs.espressif.com/projects/esp-idf/en/latest/esp32c...) and then you probably don't have to worry about it for a long time, it will work through your regular certificate rotation.
I wish the BSP was more robust. You try much, it dies. E.g. open/close connections to an IoT server out there repeatedly. Or try to talk to two endpoints over network with any kind of bandwidth. Even the serial code is fragile.
It's good for proof-of-concept hobby projects. But on the job we've had to repair the BSP each time.
'Board Support Package'. The library that FreeRTOS links to or whatnot, custom to each board shipped (a board being, SOM on a little dev card etc)
They vary massively. Usually written in a sweatshop in the far east by students, pushed out and forgotten because they are table stakes but not a profit center.
They usually include support for board boot, threads, timers, and something that looks like networking.
I say 'looks like' because they are often paper-thin implementations of a familiar API, with little or nothing inside. No proper flow control; no dynamic anything. Not even thread-safe as a rule.
Check out LILYGO TTGO. ESP32 (orig, 2016, LX6) WITH 240x135 IPS display, 16MB flash, < $10 !!! Lots of "volos projects" videos on YouTube with videogame downloads for that platform (breakout, centipede etc.)
The whole point of the ESP32 family is that the WiFi radio is integrated into the microcontroller itself, so the only external part required is some SPI flash memory for firmware storage. CE/FCC certification doesn't apply to chips, only to modules and products that include them, and there are several vendors (including well known names such as u-blox) offering pre-certified ESP32 modules that can be easily integrated into a custom design. Most of the development boards linked in the article are basically breakout boards for these modules.
They're hit or miss. I've used a few of their various boards successfully, but you usually wind up hunting down random libraries or having to tweak old code examples.
I wouldn't use them for my first foray into ESP32, but if you're fairly decent at debugging C, you'll probably be fine.
I built a clock with iCal support with the LILY Pi. Everything seemed to work, although I found it challenging to reproduce the example application, but once I did, things were fine. Eventually, I rearranged to build in Visual Studio with platform.io which I like a lot more; I feel there's more clarity than the Arduino IDE.
Currently I have one device at home, and a second in the field, which a friend is planning to use once I make some timezone adjustments (Google stopped providing vtimezone data for new calendars, apparently, so I need to get it somewhere else).
I used a couple for automated garage doors and I also build a little CDP/LLDP query tool to determine what switch port unlabeled Ethernet drops are connected to. The door openers are bulletproof and haven't had any issues with my tool either.
I experimented with their TTGO LoRa boards and gave up out of frustration. That said, folks (including less technical) seem to have success with them for things like the meshtastic project, so they can’t be terrible. YMMV
I've been very happy with their esp32 boards. Easy, cheap, well integrated.
The only issue I've had is the battery charger circuit on some boards has a fuse instead of a diode making it a hazard (realized pretty quickly while testing). This is supposedly fixed on newer revisions but there's always a chance of getting an old one through some sources....
I have used and deployed the ttgo lora boards. The boards are a bit cramped, soldering the headers requires you to remove the screen in order not to melt the ribbon cable (w I didnt try). But they work. Zero problems in the field but two out if 20~ died on my bench while just coding/out of nowhere. Furthermore, IIRC, the default i2c pins used in many libraries are used for lora/oled so you need to define two custom pins using TwoWire for example.
I tried to setup esp32-cam as a cheap security cam for my yard, but had a bad experience:
- There are no good tutorials on how to have the cam save to SD.
- streaming it is easy with
esphome, but there is no easy way to save it since it doesn't use a normal streaming protocol
- the camera image quality sucks. I got some 5mp cameras to use instead of stock camera, but the chip can't stream that resolution at anything above 2-3fps
The ESP32 is not really meant to be used with a camera. It has no hardware acceleration for the task, only ~500 KB of RAM (it can use external SPI PSRAM but not without massive performance penalties) and its radio is inadequate for high-bandwidth streaming. All those camera boards are basically a hack, they leverage the chip's parallel bus interface to receive data from a camera module with a built-in MJPEG encoder which does the heavy lifting; the data is then piped out as fast as the networking stack and radio can handle (i.e. not particularly fast).
A proper SoC with a dedicated camera interface and an external WiFi chip is going to do a far better job than pretty much any of these microcontrollers; even the low-end Allwinner V3 often used in cheap Chinese IP cameras can run circles around the ESP32, even with the overhead of a full Linux kernel. Microcontrollers with hardware camera acceleration (including a soon-to-be-released ESP32 variant) are slowly becoming more common, but the original ESP32 isn't one of them.
I really like ESP boards. A couple years ago, I had an expensive robotic cat toy which went out of support from the vendor (Petronics Mousr) and the app disappeared and I couldn’t even re-download it. I didn’t want it to become a brick so I decided to go down at rabbit hole of learning more about reverse engineering to figure out how the app works, Bluetooth LE sniffing to analyze the protocols, and then embedded programming to build a standalone device I could use to control the robot without needing a phone app.
Using an ESP32, i2c joystick controller, and i2c 128x64 OLED display I was able to cobble together a device that could control the robot and perform all its functions, as well as get telemetry from Bluetooth LE and show it on the display along with displaying controller inputs.
It wasn’t simple - it took months of work to get to a point where I had a mostly working prototype. That work including reverse engineering the device software and firmware, POCs running on my computer and then my phone before even starting on the standalone ESP32 version.
Pretty much from the start I was impressed with the capability of the ESP32. I had quite a bit of past experience doing hobby projects with Arduino and its ATmega 328 but the ESP32 was a whole new world. It was quite a learning curve at times. While I could use Arduino libraries which helped accelerate a lot of my progress, the multi-core nature of the ESP32 also meant that I ran into many interesting issues and incompatibilities with things I would do on the Arduino. Interrupt handling was completely different, for instance. i2c in particular was very challenging with lots of new and exciting issues to contend with.
Any sort of concurrent operations against the i2c bus would cause a crash, so I had to ensure I had careful synchronization of reads/writes. The speed of the ESP32 also meant I could easily saturate the i2c bus. This became a problem as I was trying to read inputs from the joystick, and output data to the display from both Bluetooth LE messages and the controller state. The ESP had the speed handle this no problem of course, but not the i2c bus. I had to write a rudimentary frame queue to control display output without saturating the bus since dropped frames weren’t as big a deal as not quickly processing joystick inputs. I also found many bugs in various Arduino libraries where they made bad assumptions on ESP32 hardware. I’d contribute fixes wherever I could. Most of my HW and libraries were from Adafruit, and they in particular were great about accepting my fixes into their repositories for the various issues I found.
One saving grace throughout any challenges I had was I found much of Espressif’s documentation to be very good - far better than I’m accustomed to from embedded hardware vendors. The community was also really vibrant which meant answers were often easy to find.
There was no serial debugging so I had to get a JTAG-capable device to save my sanity. Thankfully a cheap FT232H board in JTAG mode made a good enough debugger.
After lots of trial and error, I ultimately settled on Platform IO with Visual Studio Code for my development environment. It worked pretty well, although I ran into some really nasty bugs in Platform IO when debugging that would cause it to quickly drain my laptop battery (which they still haven’t fixed as far as I can tell).
Eventually the delisted software that inspired this whole project came back for download and I was able to get it back on all my devices and I kind of lost interest after that. However, the time I spent working on it was definitely a rewarding learning experience and made me a big fan of the ESP32.
Especially coming from some other board types, it was like "oh i guess that just worked the first time" for a lot of things.
I have a bunch of ESP32-S3's locked in some woodworking machine cabinets (they are used to monitor the machines for dust collection control/failure/etc.). It's trivial to make them do firmware reprogramming over bluetooth. You could do over wifi too, but in my case, the machines are too RF noisy (VFD's, etc) and enclosed to make it work. bluetooth only works because i'm like 2 feet away, but it works and i don't have to open the cabinet to update the programming.
I also use one to broadcast a stupid bluetooth beacon that my garage door opener uses for "UL compliance" - It has bluetooth lights, and it won't let you open/close the door remotely unless it detects them, because UL requires they visually signal the open/close when done over wifi. Which again, just works. I never had that experience outside of the nRF52/nRF53 series
There are some good low-power boards with the S3's, though it can be hit or miss (IE assuming you really want the 20ua deep sleep to be ~20ua).
If you want something like a remote running off a small battery for 10 years, you may be better off with the heltec cubecell's or something. (They really easily get 3.5ua in sleep)