Just to offer some counter-examples, based on having done this successfully many times.
Firstly - many if not most embedded applications are board-specific, because theyâre part of a larger system that includes the board and the things connected to it.
Thereâs often a strong desire to avoid making modifications to the OS, particularly when the thing being interfaced to is weird or custom, or just not likely to be interesting to the OS community.
The GPIO driver is actually a great example of where you want the chip or board to be a replaceable / upgradeable component within the larger system; the *behaviour* associated with the GPIO is a system / application thing, but the banging of the bits to make the GPIO do what it does is chip-specific. So you want to expose the GPIO with a standard protocol, and a standard way of finding the right GPIO (by name, etc.) but you donât want to put anything specific to the application into the OS side of things.
Applications can and do receive signals; I donât think itâs unreasonable to bind signals to asynchronous hardware events (thatâs what poll does at the end of the day, after all), so why should GPIO events be any different?
On the subject of I2C, if the application is bound to the system, why shouldnât it know what I2C slave IDs are in use? Here thereâs the whole chip / board / system question, but I2C is routinely used as an off-board interface (regardless of whether thatâs a sensible idea or not). Why shouldnât an application be capable of being the delivery mechanism for code to support such a device?
SPI is really the same thing once you substitute ânamed GPIO discoveryâ for âslave addressâ.
For single-image NuttX systems, itâs trivial to write what is effectively a TSR or loadable that implements a âdevice driverâ that uses the bus-level interfaces - if there was a comparable mechanism for kernel systems (i.e. loadable driver modules) that would address the issue of having to modify and maintain a modified version of the OS.
Post by ***@yahoo.com [nuttx]
No, the more I think about this concept the more opposed I get. I want to be fair and flexible, but this is just the wrong way to go in my way of thinking. It violates every concept of partitioning of functionality and layering of the architecture that I can imagine.
For example, how would a GPIO driver work? Would you specify the port number and pin number? Would you want to configure the GPIO for application space too? Only the board knows that kind of detail. A board-independent application should not have that knowledge.
Would the application expect to get GPIO interrupts? No, that is not going to happen.
Would the application have to know I2C device numbers? SPI chip select pins?
No, I definitely won't go this way.
There is really not difference between writing a driver the "correct" way (in C as part of the OS) or the ad hoc way by putting a bunch of garbage in your application and using wild, crap interfaces with OS. I see no advantage. The device/board knowledge has to exist somewhere and that somewhere is only the board-specific logic under configs/ that is build into the OS.