[riot-devel] Driver design rules in RIOT
gunar at schorcht.net
Wed Sep 26 13:44:53 CEST 2018
Cool, that's exactly what I was looking for.
Unfortunaly, it seem not to be reachable from the top level wiki page or
I missed it. The only way to find is to use a search engine.
On 26.09.2018 13:31, Hauke Petersen wrote:
> long done :-)
> 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  ?)
>>  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.
>> >> - Should a driver always return normalized/converted data, or
>> >> 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
>> > 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.
>> >> - 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.
>> >> What else?
>> > All this information should go into the 'device driver guide'
>> > 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 :-)
>> 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>
>> devel mailing list
>> devel at riot-os.org
> devel mailing list
> devel at riot-os.org
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...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the devel