Where the problem comes is when you exist outside that eco-system. When you look 'directly' into bare-metal MCUs, 32bit MCUs, MCUs with teeth and MCUs with balls that you start to speak in a different language to them. You are no longer working in the subset of functionality or the nomelcature of the eco-system, you are working with the vast expanse of all possibilities without any artificial framework limitations.
"Artificial framework limitations" sounds like a pejorative, making it sound like the framework
deliberately stops you from doing things you could do otherwise. It doesn't. Nothing stops you from writing lower-level code into your Arduino sketches. (The consequence is that you lose easy portability to another MCU.)
The limitations of the Arduino frameworks aren't there as artificial roadblocks, they are consequences of a) designing a product originally intended for artists*, not electronics nerds, and b) portability across MCU families, so a "lowest common denominator" base functionality.
But for all the complaints people have about the "limitations" of the Arduino framework, they either don't know, or deliberately ignore, that is is for all intents and purposes a set of lightweight libraries on top of ordinary C/C++, and that ordinary C/C++ code works, including directly reading and writing MCU registers if you want to (on most of the MCUs at least, including Atmel and STM32; others, like ESP32 and Rpi Pico, instead implement the Arduino framework as a lightweight layer over a RTOS, but you can call their specific calls to do all the stuff the Arduino framework won't).
I say this as someone who isn't a particularly gifted programmer: Working my way through the Arduino framework, starting with the classic "Blink", all the way to writing my own peripheral support libraries for external doodads, for Arduino on ESP32 in PlatformIO, was a great way to "graduate" to then programming in manufacturer IDEs like MPLAB X (for a PIC16 in a piece of measurement gear I built that has been in operation for well over a year now, where it is used to keep track of well over a million $ worth of liquid xenon; that project required me to manage special timers to capture the period-modulated output of the front-end measurement ICs) and STM32CubeIDE. For me, learning bit by bit was better than being thrown in the deep end. (Like in class, where we did STM32 in Keil, where I remember a bunch of us running into trouble programming the MCUs due to some checkbox whose function is as opaque to me now as it was back then. The teacher knew STM32 enough to understand it, but it's one of those things that can completely ruin a novice's day because there's not a snowball's chance in hell you'd ever be able to solve the issue on your own, you'd eventually just quit in frustration and throw the dev board in the trash.) By being able to solve problems that are at the edge of my understanding (as opposed to problems so far beyond my level of knowledge that there is no chance of identifying the solution), I was able to learn on my own, since the problems were not insurmountable. I learn more that way than by having someone else spoon-feed me a solution I don't actually understand.
*The Arduino people didn't actually invent the Arduino "language" (i.e. the framework), they forked an existing OSS project called Wiring, which in turn was a fork and extension of a platform called Processing, which was expressly developed for artists.
Home
Help
Search
Login
Register
