[riot-devel] Driver design rules in RIOT

Gunar Schorcht gunar at schorcht.net
Wed Sep 26 09:27:08 CEST 2018


I wrote a series of sensor drivers for esp-open-rtos/ESP-IDF, for
example for different ST sensors, the BME680, the CCS811 or the SHT3x. I
would like to port some of these drivers to RIOT OS. All the drivers are
quite complex as they try to cover all the features of the sensors.

I have seen that most drivers in RIOT for similar sensors usually only
implement an interface to with init, read, power-up and power-down. So
I'm wondering now, what the design rules for sensor drivers in RIOT are?

- Should a driver be as complete as possible, which of cource produces
more code, or should it be kept simple to produce small code? One option
would be to use the pseudomodule approach to enable additional features.
On some platforms unused code is not linked into the binary.

- Should a driver support at least data-ready interrupts (if possible at
all) to realize event-driven data retrieval?

- Should a driver always return normalized/converted data, or rather
return the raw data and the application needs to convert them? The
conversion is sometimes quite complex. I saw both approaches of them for
similar sensors.

The design rules that are clear to me are:

- Drivers have to provide an interface for polling with init and read
that is compatible with SAUL.

- Output are always 16 bit integers.

What else?


Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
kennenlernen willst, dann lauf Marathon. (Emil Zatopek)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20180926/cffa009e/attachment-0001.sig>

More information about the devel mailing list