[riot-devel] Driver design rules in RIOT

Hauke Petersen hauke.petersen at fu-berlin.de
Wed Sep 26 13:31:40 CEST 2018


Hi,

long done :-)

See 
https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT

Cheers,
Hauke

On 09/26/2018 11:11 AM, Emmanuel Baccelli wrote:
> Hi there,
>
> based on this exchange,
> is there matter for a wiki page on this?
> (Or for alternative documentation,
> e.g. reviving the concept of RDM [1] ?)
>
> Best
>
> Emmanuel
>
> [1] https://github.com/RIOT-OS/RIOT/pull/6191
>
>
> On Wed, Sep 26, 2018 at 11:38 AM Gunar Schorcht <gunar at schorcht.net 
> <mailto:gunar at schorcht.net>> wrote:
>
>     Hi Hauke,
>
>     many thanks for your comprehensive and clearifying answers. Most
>     of them
>     met my thoughts about driver design.
>
>     >> - Should a driver support at least data-ready interrupts (if
>     possible at
>     >> all) to realize event-driven data retrieval?
>     > If the driver comes with a 'full/extra' configuration, this is
>     part of
>     > it anyway, right? In the simples 'basic' configuration I don't think
>     > this needs to be part of I would say.
>
>     Agreed.
>
>     >> - 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.
>     > My opinion is quite clear: I am always in favor of returning
>     > normalized/converted data. In 90% of the cases the conversion is not
>     > expensive, so just do it. In those rare cases, where the
>     conversions is
>     > actually relatively expensive, we can always fall back by providing
>     > additional `xx_read_raw()` or similar functions, that allow to
>     access
>     > the data before conversion.
>
>     Agreed. All the drivers I wrote til now, either return
>     normalized/converted and raw data with same read function or offer an
>     additional read_raw function.
>
>     >> 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.
>     > that is a nice to have, but not a MUST.
>
>     Ok.
>
>     >> - Output are always 16 bit integers.
>     > Not quite true. The SAUL interface is build around 16-bit
>     integers, and
>     > at least when reading/writing data via SAUL the data needs to be
>     > converted. But the driver specific interface can always use
>     other data
>     > types/lengths. If it is however easily possible to use int16,
>     one should
>     > use it.
>
>     Ok.
>
>     >> What else?
>     > All this information should go into the 'device driver guide'
>     >
>     (https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT).
>     > This guide needs however still work - and I will not have the
>     time to do
>     > it. So it would be nice if other people can help here :-)
>
>     Agreed.
>
>     Regards
>     Gunar
>
>     -- 
>     Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
>     kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
>     _______________________________________________
>     devel mailing list
>     devel at riot-os.org <mailto:devel at riot-os.org>
>     https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20180926/93c334ff/attachment-0001.html>


More information about the devel mailing list