Hi Peter, I think I prefer the `common` solution most, though we need to be careful how interaction between the `common` module and the actual driver would work. #ifdef different variants is as you said to use a mixture of radio devices (e.g a samr21-xpro with an OpenLabs RaspPi hat attached) and also is prone to produce more complicated code if things get out of hand, even if the local ifdef seems small (see the old sys/transceiver drivers [1]). The third I don't like because of bloat, both code-size-wise and loc-wise.
Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/blob/89fa57c5a9188e5dbe292ba11997447e047b1c08/sys/transceiver/transceiver.c 2016-07-12 17:38 GMT+02:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>: > Hi Martin, > > thanks for your feedback. > > Am 12.07.2016 um 14:28 schrieb Martin: > >> Hi Perter, all, >> >> > this approach prohibits to use both devices simultaneously. >> I think this is a blocking issue for merging akin device drivers. >> IMHO If this situation happens the drivers should be separated back, >> even if bloating/doubling the code. >> >> > For similar CPUs we maintain a "common" folder ... >> Considering the mentioned "blocking issue" I would go for a "common" >> folder for solely collecting utility functions, i.e. functions not >> using global/static variables or buffers. >> >> > Another solution would be to handle common and individual functions >> in one file (without #ifdef). ... >> You mean putting all required functions in each driver without >> considering similarities? >> > > That approach is about to maintain one folder/file for a shared > implementation. That file consists of individual functions *and* shared > functions. That prohibits from bloating the file structure and enables > simultaneous usage but enlarges code size.. > > At least this would be safe, since every driver then truly operates in >> defined bounds. >> But obviously this would most probably introduce a lot >> developing/debugging repetition. >> >> Best regards, >> Martin >> > > Best > Peter > > >> Am 07/12/2016 um 10:49 AM schrieb Peter Kietzmann: >> >>> Hi devs, >>> >>> on several occasions the question about how to merge similar device >>> drivers occurred. That means covering different derivatives of a >>> device with one device driver, to avoid code duplication. Compare >>> discussions in these PRs: >>> >>> https://github.com/RIOT-OS/RIOT/pull/5604 >>> https://github.com/RIOT-OS/RIOT/pull/5484 >>> https://github.com/RIOT-OS/RIOT/pull/5433 >>> >>> For the dht11/22 or at86rf212b/232/233 we already merged drivers by >>> putting #ifdef around different code parts. This does not affect code >>> readability as long as differences are small (which is not >>> guaranteed). On the other hand, this approach prohibits to use both >>> devices simultaneously. Furthermore, naming schemes might get >>> confusing. E.g. merging "MPU6000", "MPU6050" and "MPU9150" might lead >>> to "MPUXXX0". I've no idea about further and future version names. >>> >>> For similar CPUs we maintain a "common" folder next to the dedicated >>> CPU version. Different code parts were maintained separately in >>> individual folders. The question is, if this approach is reasonable >>> for pretty simple device drivers where multiple derivatives might exist. >>> >>> Another solution would be to handle common and individual functions in >>> one file (without #ifdef). This might bloat code size but allows usage >>> of different versions in parallel. Also, it does not bloat the file >>> structure. The problem about naming schemes is still present here. >>> >>> I'd like to have a general principle for this. What is your opinion >>> about the above described procedures? Are there other/better ideas? >>> >>> Best >>> Peter >>> >>> >> _______________________________________________ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel >> > > -- > Peter Kietzmann > > Hamburg University of Applied Sciences > Dept. Informatik, Internet Technologies Group > Berliner Tor 7, 20099 Hamburg, Germany > Fon: +49-40-42875-8426 > Web: http://www.haw-hamburg.de/inet > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
