Shhhh stop spilling our secret to the software people... The semiconductor shortage is bad enough already...
That said though, programming embedded devices like Arduino and ESP32 needs a completely different style of thinking than with high level languages or web stuff. Things like MicroPython reduces the friction just a bit to make it easy enough to get on board.
The thing that tripped me up the most was concurrent tasks. In languages like Go or JavaScript it’s pretty easy to figure out how to decrement a timer or wait until x time to perform a task without having the waiting period be blocking. On an arduino, you have a few options but none of them are likely to be familiar to high level software devs.
It isn’t rocket science, but there are loads of little details like that which will make you pause and then write loads of bugs and awful software before you finally figure it out. Meanwhile, accomplishing the same thing with a high level language might be trivial.
It can be discouraging but I’ve come to love it. You learn a lot, and having a physical board doing a tangible thing with actuators and sensors can be really gratifying.
RTOSes are developed to solve this exact problem of concurrency. Try Zephyr, ThreadX (from MS) or FreeRTOS (from Amazon) or whichever OS your microcontroller vendor supports. It will be eye opening, and you get to learn to write safe code in C with synchronization primitives just like our ancestors.
Amazon did not create FreeRTOS; they simply took over maintenance a few years back. I didn’t know that happened until I fact-checked your comment, but it is enough to make me never want to use it ever again. And that makes me very sad.
They improved the licensing to MIT. The pre-acquisition license was "GPL" but it had a noncompliant restriction prohibiting comparative benchmarks. There have also been useful improvements to the codebase. Amazon is a net positive in this case.
Many microcontrolers have timers and counters or even state machines (PIOs on RP2040 is a nice example of that) for this reason. They allow you to handle those cases out of the main computing unit. The MSP430s are also full of these magic things. They are harder to get introduced to than just writing Python. But you don't realize how powerful those things are until you step out of how you were handling things on a multi-GHz computer with ton of RAM.
And these peripherals can run at hundreds of MHz doing real work in every cycle. I can probably do very low latency audio processing with an interrupt firing at the sample rate. Delay is a few samples instead of at least couple of ms like on a PC with an audio interface.
You probably could, but I’d recommend getting a chip with a dedicated I2S peripheral and use freertos with a high priority dedicated audio task that’s sole task is processing audio. You really don’t want to miss an audio sample. It’s very audible, and depending on what you’re doing makes audio processing essentially a hard real-time constraint.
I recently used Rust (RTIC) for that and it was relatively pleasant experience, it had "tasks" (that cleverly used unused interrupt handlers for context switching so it was nice and efficient) that could be triggered by various stuff, not unlike threads, and they had priorities. As long as you busy waited only in the main, lowest priority one, it "just worked"
I completely agree. It brings you back to more fundamental aspects of problem solving that sometimes you miss with higher level programming. There are a lot of things I can do on a modern web server with a language like Go that are pretty cool, but not particularly interesting because it's kind of trivial. There are so many resources available to the program, things to fall back on for resilience, plenty of common problems are ironed out into popular libraries, etc.
Trying to automate something truly reliable and consistently with a microcontroller on the other hand can be simultaneously soul crushing and exciting — there are so many edge cases and challenging problems.
Sometimes I'll spend hours trying to figure out how to interface with a single sensor, and while it isn't important or impressive in the scheme of things, I really enjoy it.
> Sometimes I'll spend hours trying to figure out how to interface with a single sensor, and while it isn't important or impressive in the scheme of things, I really enjoy it.
I found a fake sensor like that once.... was wondering why my code done by datasheet didn't worked on cheapo breakout board I bought off aliexpress.
Then I read ID register and they used older chip that had some of the stuff set up differently...
Same, I bought a couple waterproof temperature probes under the name of a reputable manufacturer and wound up getting what turns out to be notorious knock offs. It was way harder to set up and the actual sensors measured within several degrees C of each other, haha. I'm a lot more careful of where I order components from, now.
You can always run Espruino on your ESP32 -- a nodejs like environment for microcontroller. It works well and has lots of drivers for different components.
Using Rust and esp-idf you can simply call the standard library threading facilities if you want to do concurrency, and it's all handled in the background by FreeRTOS for you.
This is so true! I just programmed an Arduino for a diy attic fan controller. Was it hard? Not really. Was it a bigger pain in the butt than programming for home assistant? Oh gosh yes. And quite limited in comparison. It really made me appreciate zWave plus python plus home assistant plus appdaemon. High level coding - use it if you can!
I did use esphome for something similar.
It uses a yaml file to generate C++ code for you and it works like a charm (in 99% of the cases).
Very easy integration in home assistant and it has support for the usual home automation peripherals.
Honestly, working with all the restrictions of an embedded system like this is something that all programmers should experience at some point. Being forced to actually consider how you're using resources teaches you a lot about how to write efficient code. Or at least if gives you a better understanding of what the machine is actually doing with your code.
You chose to ignore the like this your parent mentioned ;)
And I agree. All programmers should at some point work on a super slow, super limited AVR or something like that. Something where you have to make hard decisions either because you don't have enough RAM, not enough CPU power, not enough storage, not enough I/O pins etc.
Even non flagship phones are more powerful than the boxes running Windows Embedded 20 years ago.
I once ran a project on an Attiny. That bad boy has 1KiB of flash and 128 Bytes of RAM at an unthinkable 4/8MHz.
I can't begin to tell you how incredibly annoying it was, but it taught me a lot. I know a lot of people who would be completely dumbfounded at 128B of memory. That's only four int32!
That said though, programming embedded devices like Arduino and ESP32 needs a completely different style of thinking than with high level languages or web stuff. Things like MicroPython reduces the friction just a bit to make it easy enough to get on board.