The question....
I also remember trying to run DOS games from windows 3.1.....
Dat timer interrupt....
rage-face.jpg
For the sake of this discussion: here are my applications...
- STM32F4: A high-bandwidth, latency-sensitive, open-source motion-capture glove.
- Teensy3.1: An audio device with shallower demands of the HARDWARE specificity, but very STRICT demands on the interoperability of various special-purpose libraries (Paul's Audio, a few AdaFruit drivers, SdFAT, and Teensyduino itself).
- Teensy3.1 / RasPi-Linux / Fubarino Mini: A general-purpose gesture controller that may or may not need threads, depending on platform. Low bandwidth.
...and numerous other things I haven't published (bluetooth beacons, geiger counters, power-suppies, etc).
...on the right projects it might be a nice plan. I'm pessimistic.
Before I bore you with a case-study,
know that I share your pessimism. If all you need to do is turn off a light switch given the value from a CdS cell, anything resembling an OS is taking the
NASA Route. If we're going to go so far as introducing threads, I would be
even more pessimistic. With no MMU and the very serious concurrency considerations thereby introduced, I would argue very strongly against threads for
any application that didn't need sub-millisecond response times in the midst of heavy CPU usage. Most of the threaded code I've seen in embedded land is
only present as a means of avoiding writing a proper hardware-specific ISR. Essentially:
polling done dishonestly.
In such tight spaces, we can ill-afford to leverage the immutable-types and recursion that the "big-platform" functional guys seem to have recetly discovered, nor the garbage-collection and soft-types that they take for granted. And the complexity of good concurrency-control is not worth an afternoon's laziness about writing a platform-specific ISR.
..my gut feeling is OS kernels (no matter how lightweight) really don't belong in a land of such limited resource.
But for those times when they DO, I have to confess... I'm *really* tired of writing the
same sort-of code over-and-over again. For anything more complex than a simple sketch or one-off project, a good programmer will find himself implementing a work-queue (or something that is in-substance equivalent).
Moreover, if I want to
port the Audio library to PIC32, I don't want to also be required to port DMA drivers for the SPI subsystem if all I care about is a variable filter. So as someone who (I think?) shares your anathema for unnecessary complexity, I submit:
This discussion might be best-viewed as a serparation of functional responsibilities in code, and (by extension) between personages and institutions.
It would be nice to be able to better-levarage not only other-people's code, but also my own under different circumstances. And also to limit the burden for those of us that (say) maintain a sensor driver in places where there is no common API or access paradigm. Or who find themselves on the unfavorable-side of the design choices made by another (differently-constrained
and/or less-competent) engineer.
I wrote
ManuvrOS to solve these problems. The same ones that Zephyr is also trying to solve, with the exception that my stuff doesn't imply a threading model. In this regard, it bears more structural resemblance to
Contiki.
This started
because I wanted to use the same i2c code on a Teensy as well as a linux environment. And that meant wrapping it. And that meant using the
same API to deal with (no-threads + ISR), as well as (under some sort of a threading model [on linux, where no hardware ISR is accessible]). If threading is desired, ManuvrOS uses FreeRTOS in small-spaces, and pthreads on linux.
ManuvrOS is a work of evolution. And it shows. I've been slowely
re-working pieces of it for the sake of portability. But I have to ask an honest question of myself:
Is it worth it to burn so much time doing the same things as everyone else (porting the INA219 driver to their particular situation), or would it be better to translate the things I've done that are uniquely-useful into a form that others can use in a wider range of projects (and vice-versa)?
While I contemplate that, I created an account at the Linux Foundation.
Having just taken the position as the principle firmware engineer at a large telecom (which is genuinely embracing open-source), I think it also worth saying that I have no ego about my code. IDGAF if the winning design is my own. But the thing that I
*really* don't want is to see the IoT realm being dominated by closed/crap/incompatible corporate offerings because -despite its inherrent-bias towards meritocracy, its diversity-of-thought, and its
FAR superior manpower- the open-source world is too balkanized to keep pace.
Zephyr already has support for a closely-related microcontroller. Most of the porting effort would be in the libraries, and not in the hardware-layer. The
release-candidate for Digitabulum needs support for the STM32F746, and I'm sick of fighting FreeRTOS support on PIC32 (not my primary platform). From where I sit, Zephry appears to me to be an excellent pattern to start conforming to, as those of us who are serious and make a living off this stuff have long-since grown out of the intolerably-interwoven and
brain-damaged build system of Arduino, as well as it's limiting API.
I will be watching this thread closely for the next several weeks to see what others think. The discussion held here might determine how you turn on your light bulbs in a few years, as these are the choices before us today.