Hi, 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? Regards Gunar -- Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
