You're aware that there are already a couple of these, right? First one that pops up in a platformio search:
% pio pkg search rtpmidi
Found 1 packages (page 1 of 1)
lathoub/AppleMIDI
Library • 3.3.0 • Published on Sat Aug 27 11:57:15 2022
AppleMIDI (aka rtpMIDI) MIDI I/Os for Arduino. AppleMIDI (aka rtpMIDI) is a protocol to transport MIDI messages within RTP (Real-time Protocol) packets over Ethernet and WiFi networks. This major rewrite is faster, more stable and uses less memory. Read the Wiki page when migrating
.. is pretty stable and fast. I've used it in an ESP8266 project ..
Of course, the existence of some implementation is no reason not to write or share another one.
In fact, it's good for the ecosystem to have different people/teams exploring the problem space and it's good for individual developers to hone their craft on delicate technical problems even when they're ostensibly already covered.
Yes, I’m specifically targeting Zephyr. It’s actually less of an ESP32 thing and more of a Zephyr thing, I just happened to have an ESP32 LyraT Mini kicking around to do the project with.
And in general the Arduino/Platformio ecosystem causes me to break out into hives…
- 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.
