- Reproducibility: often enough I'll come across a straightforward issue like "using an extra serial port" that already has the pins broken out on the board but isn't set as a serial port by default. The solution is almost inevitably "go into this directory deep inside your Arduino install and edit this header file". That results in two issues:
- It's not project-specific so other projects on my machine now also get the modified header
- If someone else checks out my project, they have to go in and edit that file themselves, spreading the modification like a virus.
- The abstractions are often overly simplistic and hide what's going on under the hood too much. I don't remember which board/chip it was off the top of my head but one board I was working on was having weird timing issues. As it turned out, the whole BSP for Arduino-on-that-board was running FreeRTOS under the hood and was context switching out of my loop() function arbitrarily (causing the delay between, say, two digitalWrite() statements to be dramatically different sometimes)
- The code quality of 3rd-party libraries that are commonly used varies dramatically.
I ultimately settled on Zephyr. It does a fantastic job of doing hardware abstraction and configuration behind a DeviceTree setup, it exposes really nice and consistent RTOS primatives, it has a ton of device driver support baked-in and has generally quite good code quality for all of them. I can do multiple stack-allocated threads with priority instead of having to do ugly polling hacks in a single superloop.
> I can do multiple stack-allocated threads with priority instead of having to do ugly polling hacks in a single superloop.
I think most of your issues are because you haven't escaped the impositions of the Arduino runtime/execution environment, and are sitting on top of a layer of stuff that was designed for students.
The real value of platformio is when you move beyond this, accept responsibility for your executive runtime, and have full control over things. Its not enough to run into the brick wall of the init()/loop() abstraction and then complain that stuff is too simplistic - that is the point, after all, of the Arduino ecosystem. But platformio sits separately from this, and if you do take care to administer your runtime properly - i.e. bypass the Arduino student layer - you can solve pretty much every problem you've noted, better.
>Zephyr
Definitely interesting, but I don't like the idea of a DeviceTree blob, personally. This isn't future proof. But I guess everyone has different requirements for this, going forward. I've taken 5 projects, originally based on Arduino/Platformio, through 3 different hardware design iterations, and the sue of platformio tooling and methodology was definitely a key factor in the ease with which we did that.
Why so? All the disparate platforms being supported?