Comment by ricw
7 days ago
Curious what the better frameworks are these days? Are they tied to specific hardware like arduino was? And what language do they use?
7 days ago
Curious what the better frameworks are these days? Are they tied to specific hardware like arduino was? And what language do they use?
FreeRTOS is pleasant to use.
I've recently been getting into Rust + Embassy + Probe-rs and in my opinion it's been the best embedded experience by far.
Broad support for many different chips is precisely why Arduino is so bad. It has to check pin numbers against a gigantic table for every gpio call.
You want chip-specific libraries. When the software is designed for the hardware everything works better.
The native AVR and esp-IDF frameworks are very good. There's also micropython and circuit python. I've heard good things, but I don't partake in Python.
Personally I think attempting to provide a cross-platform library for microcontrollers is an enormous mistake. This is not x86, you can't rely on any CPU feature existing, which results in awful branching code in places that in a sane framework is a single instruction updating a CPU register
I feel like this has to be a toolchain issue, there's no reason the pin number -> register table couldn't be resolved at compile time, similar with conditionally compiling certain things based on the CPU features.
I'm not saying it's not a real or an easy problem, just that I wonder if it truly is the reason Arduino is "bad"
It could and some cores do. Many do not and you get a runtime lookup unless you explicitly call digitalWriteFast which is also supposed to resolve to a single inline instruction. It usually does not and instead emits a function call in assembly.
The gpio thing is really just my personal pet peeve. There are a lot of things like this though. For example, the arduino core will consume several milliseconds doing something in between calls to your main function. I2C and similar drivers are typically not well designed and either use too much memory or just operate not-quite-right.
Which brings up another point, the Arduino ecosystem is not at all unified. If you use a chip that is not popular enough to be mainlined, you have to go out and find an Arduino core that supports it and try to plug that into your compiler. Such cores frequently are not API compatible and have slightly different behaviors. It's all a big mess.
There are a lot of features that are compile time conditional based on CPU, but the actual implementation of this is horrible. I once had to modify someone else's custom Arduino core to tweak some low level behavior and despite the change being very minimal, it took three days to find all the places and all the conditionals that needed tweaking.
But really my main complaint is that Arduino is incredibly slow and hides far too much from you. Firmware developers should know about CPU registers and hardware features. This is very important for understanding the machine! A lack of awareness of the machine and what its doing is (IMO) one of the major factors in how awful modern programs are.
1 reply →
If you want a "framework", Zephyr is the only thing i can think of, that is somewhat hardware agnostic, have great software packages, and fairly widely used.