Page History

Device Drivers

...

Device drivers should be implemented in the RTOS and used by applications. Drivers provide access to device functionality for applications. This is a necessary part of the modular RTOS design. In the NuttX directory structure, share-able device drivers reside under /drivers and custom drivers reside in the board-specific directories at nuttx/boards/<arch>/<chip>/<board>/src that are built into the RTOS.

Bus Drivers

There a many things that get called drivers in OS; NuttX makes a distinction between device drivers and bus drivers. For example, SPI, PCI, PCMCIA, USB, Ethernet, etc. are buses and not devices. You will never find a device driver for a bus in the NuttX architecture.

...

Back to SPI... There will never be an application accessible interface to SPI. If your application were to use SPI directly, then you would have have embedded a device driver in your application and would have violated the RTOS functional partition.

Exceptions to the Rule / Clarifications / Grey Areas

That said, of course NuttX is a completely open RTOS and you are free to use it in any way that you would like. But I would never incorporate such support into the base RTOS design.

Test Drivers

It would be possible to provide character driver, such as SPI driver, that could perform bus level accesses on behalf of an application. There are not many cases where this would be acceptable, however. One possibility would be to support support testing of bus drivers. There is, an example for I2S here: drivers/audio/i2schar.c with a test case here apps/examples/i2schar. I2S is, of course, very similar to SPI. This interface exists only for testing purposes and would probably not be possible to build any meaningless application with it.

The I2C Tool

Of course, like most rules, there are lots of violations. I2C is another bus and the the I2C "driver" is another transport similar in many ways to SPI. For I2C, there is an application at apps/system/i2c alled the "I2C tool" that will allow you access I2C devices from the command line. This is not really just a test tool and not a real part of an application.

And there is a fundamental flaw in the I2C tool: it uses NuttX internal interfaces and violates the functional partitioning. NuttX has three build mode: (1) A flat build where there is no enforcement of RTOS boundaries. In that flat build, the I2C tool works fine. And (2) a kernel build mode and (3) a protected build mode. In bothof these latter cases, the OS interfaces are strictly enforced. In the kernel and protected build modes, the I2C tool is not available because it cannot access those NuttX internal interfaces.

User Space Drivers

Above, it was stated that if your application were to use a bus directly, then you would have have embedded a device driver in your application and would violate the RTOS functional partition. Such device built into user applications are referred to as user space drivers in some contexts. There is no plan or intent to support user space drivers in NuttX.

Communication Devices

What about interface like CAN and UARTs? Why are those exposed as drivers when SPI and I2C are not?

...

Communication devices support a fundamental peer-to-peer model. CAN and UARTs are basically serial interfaces. But so are SPI, I2C, and USB. But those latter serial interfaces clearly have a host/device, master/slave model associated with them. It make perfectly good sense to think of them as buses that support device interfaces.

I/O Expander

An I/O expander is device that interfaces with the MCU, usually via I2C, and provides additional discrete inputs and outputs. The same rules apply:

...