Comment by estimator7292
7 days ago
Trouble is, this kind of trivial throwaway application is all that Arduino is really good for. Because the framework is designed to support thousands of chips, it supports none of them well. Any arduino code you write is easily 5x more terse than any of the native libraries, but it's also 10x slower. If you don't care, you don't care. But if you do care, Arduino is the least appropriate way to make a microcontroller go.
Besides that, IMO hiding hardware details from the developer is the worst thing about Arduino. The hardware details matter and it's far too easy to get footgunned by some implementation detail hidden from you.
But really, esp-IDF isn't that much more complex, nor are most of the other native frameworks. It's a bit more verbose, but esp-IDF provides helper libraries that replace almost everything Arduino provides, but in a way that is actually designed for the hardware and doesn't have to do things like lookup pin numbers in a giant table for each and every gpio call.
> Besides that, IMO hiding hardware details from the developer is the worst thing about Arduino. The hardware details matter and it's far too easy to get footgunned by some implementation detail hidden from you.
Wasn't Arduino not for developers, but for hobbyists? People who aren't super technical but want to do something neat with basic microcontroller functionality?
You're complaint kinda seems like saying "BASIC isn't great language, it's got a lot of problems when used for enterprise applications." It's not really meant for that.
IMO Mbed was just as easy for hobbyists but had a far better designed API that could support professional work as well. Arduino is just badly designed.
Unfortunately the Mbed guys stuck to their crap web-based IDE for waaaay too long, and when they finally realised it couldn't cut it, they pivoted to Yotto, which was a terrible Python based build too. When that failed they finally made Mbed Studio which was based on Theia (same as Arduino is now) but by then it was too late.
I think they also lacked an obvious "start with this" board like the Arduino Duo.
I think if they have blessed one of the Neutrino boards (which were incredibly cheap and powerful compared to Arduino) with their branding, and switched to Theia like 5 years earlier they might have had a chance.
Real shame because it really was a far superior software system.
I really think what killed Mbed is the C++. I don't want to poison my codebase with the C++ stuff(and now you have to write wrapper for C++ if you want to use them inside your C codebase).
1 reply →
The pin mapping shenanigans are another annoying footgun with Arduino. Even in native development you're dealing with a physical pin number and the logical assignment (PA5, PA6, etc), but now Arduino maps that all again to an Arduino board pin number, and it's all shuffled to ensure the peripherals are in the right place to enable I2C, ADC, and PWM pins to function as expected.
Of course they did that. It's a HAL (hardware abstraction library).
That also means that simple projects are abstracted from the hardware. Means I can go across a dozen different CPU arch and board/pin layouts, and I change nothing in my source. I only change my target and it just works.
I did that when I went from a board operating at 16MHz/atmel to a STmicro running 50MHz. No change in my source. And that's really valuable in rapid prototyping.
Once I settled in on a board and everything, I could do it the "right way" aka the old waterfall-gile embedded approach and get things tweaked and optimized.
The problem is that a lot of this abstraction is done at runtime, not compile time. Your binaries become bloated, your application slow, and you end up using a microcontroller with three times the resources you actually need just to support all the dead weight.
A lot of firmware people consider HAL libraries as harmful. In general, microcontroller companies as pretty terrible at software.
Same deal exactly for the various ESP32 boards. With the added wrinkle that some of them (like T-Display) have had pins swapped in the doc at various stages.
And yet there is clearly a market for easy-to-program MCUs for hobby and educational purposes.
I would argue the RP2040/2350 fills that niche. Cheap, available, easy to program, flexible peripherals, fast enough for many projects, good documentation, and good community support.
RPi's toolchain situation is awful for beginners/hobbyists. CMake and non-manifest-versioned toolchains are a huge barrier to entry. I'd love to use the hardware but have given up multiple times because I'd rather spend my time writing code than wrestling with toolchain setup. And they won't support platformio which could make things massively easier for beginners to set up.
2 replies →
I'm using the RP2040s with FreeRTOS for a hobby project. I think the Pico probe is a much better debugging story than buying a Blackmagic (or if you got the dough, a Segger), to debug the "modern" Arduinos. I have one of the Atmel programmers for the Uno R3/2560/Mega boards and that's nice.
But for people getting started, the ability to just plug in an Uno R3 and stack a motor controller shield on it, is pretty attractive. I like the Cytron break out boards for the Picos, but I still think the path from opening the box to working thing is still easiest with Arduino.
Once you know what you're doing, (and maybe that's when you realize you need a debugger), you move on to something else. And with the Pico I can spend the $800 on an O-scope instead of the Segger.
As a hobby user, RP2040/2350 seems like the best to for beginners. As long as it's not battery powered.
Arduino was around long before RP2040, therefore RP2040 shouldn’t exist because the niche was already filled.
arduino was supposed to be learning opportunity and training grounds for people who wanted to work in the field in the future, there was small arduino boards (similar to pi pico) for integration with actual projects, but still arduino was for hobbyists and students in the first place