5 ms·

Shame to see Arduino go, but honestly how relevant are they anymore? The Arduino framework is one of the worst ways possible to write firmware for any slightly

Shame to see Arduino go, but honestly how relevant are they anymore? The Arduino framework is one of the worst ways possible to write firmware for any slightly serious use, and their hardware is... quaint in the era of Espressif and the Cambrian explosion of devboards with any number of highly advanced features. Arduino was a great way to get into microcontrollers back when the only alternative was vendors' native libraries in straight undocumented C and wiggling CPU registers manually. But that's not really a niche anymore, there's plenty of other, better designed, frameworks and libraries. Arduino has always been the worst, slowest framework available. Honestly it's high time to replace Arduino with something else that doesn't instill such awful habits in new engineers.

ricw 1y ago
Curious what the better frameworks are these days? Are they tied to specific hardware like arduino was? And what language do they use?
- bschwindHN 1y ago
  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.
- estimator7292 1y ago
  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
  - theon144 1y ago
    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"
    - estimator7292 1y ago
      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.
      - BenjiWiebe 1y ago
        I agree with you, with the caveat that the awful software that's written by an inexperienced programmer ends up getting used, and the perfect efficient well-tuned software I want to write never gets finished (or even started, usually). It's so much more work.
- mrheosuper 1y ago
  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.
bobsomers 1y ago
What frameworks would you recommend for new people learning about embedded systems?
- mrheosuper 1y ago
  Why care about framework, just use whatever vendor HAL for your MCU and be good with it
babl-yc 1y ago
There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional. But certainly for pro use cases the hardware specific frameworks are way more powerful (but also complex). I wrote up a bit on Arduino vs ESP-IDF here https://bitclock.io/blog/esp-idf-vscode https://bitclock.io/blog/esp-idf-vscode
- danhor 1y ago
  > There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional. This group is has been moving to circuitpython, which is much less performant, but even easier to use. The more serious cross-platform development environments, like Zephyr, have also become much better.
- estimator7292 1y ago
  The native AVR libraries are really good. It's not quite as idiomatic as Arduino, but it's really not all that different. Beginners can learn frameworks more complicated than Arduino and I think they should. Before Arduino, beginners were expected to write plain C or assembly, and the industry got along just fine. There were still countless hackers and weekend tinkerers. They just had to learn more, which is not a bad thing
  - BenjiWiebe 1y ago
    If by native AVR, you mean avr-libc, it's nothing at all like Arduino. Instead of analogRead, you need to write your own busy loop watching certain bits in a register (or ISR), you need to twiddle bits in several registers to set up the ADC the way you want it, etc. Serial.write? Nope, gotta read the docs, twiddle some bits again, and then you actually do get to use printf. Those two right there are big hurdles to someone new to microcontrollers. In fact, they're a hurdle to me and I've read AVR datasheets for fun.
    - 1y ago

ricw 1y ago

Curious what the better frameworks are these days? Are they tied to specific hardware like arduino was? And what language do they use?

bschwindHN 1y ago
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.
estimator7292 1y ago
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
- theon144 1y ago
  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"
  - estimator7292 1y ago
    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.
    - BenjiWiebe 1y ago
      I agree with you, with the caveat that the awful software that's written by an inexperienced programmer ends up getting used, and the perfect efficient well-tuned software I want to write never gets finished (or even started, usually). It's so much more work.
mrheosuper 1y ago
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.

bobsomers 1y ago

What frameworks would you recommend for new people learning about embedded systems?

mrheosuper 1y ago
Why care about framework, just use whatever vendor HAL for your MCU and be good with it

babl-yc 1y ago

There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional. But certainly for pro use cases the hardware specific frameworks are way more powerful (but also complex). I wrote up a bit on Arduino vs ESP-IDF here https://bitclock.io/blog/esp-idf-vscode https://bitclock.io/blog/esp-idf-vscode

danhor 1y ago
> There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional. This group is has been moving to circuitpython, which is much less performant, but even easier to use. The more serious cross-platform development environments, like Zephyr, have also become much better.
estimator7292 1y ago
The native AVR libraries are really good. It's not quite as idiomatic as Arduino, but it's really not all that different. Beginners can learn frameworks more complicated than Arduino and I think they should. Before Arduino, beginners were expected to write plain C or assembly, and the industry got along just fine. There were still countless hackers and weekend tinkerers. They just had to learn more, which is not a bad thing
- BenjiWiebe 1y ago
  If by native AVR, you mean avr-libc, it's nothing at all like Arduino. Instead of analogRead, you need to write your own busy loop watching certain bits in a register (or ISR), you need to twiddle bits in several registers to set up the ADC the way you want it, etc. Serial.write? Nope, gotta read the docs, twiddle some bits again, and then you actually do get to use printf. Those two right there are big hurdles to someone new to microcontrollers. In fact, they're a hurdle to me and I've read AVR datasheets for fun.
  - 1y ago