Hi Jose, the "RIOT way" or rather the GNRC way would be to extend (in the object oriented sense) `gnrc_netdev2_t`, similar how `gnrc_netdev2_ieee80215.c` and `gnrc_netdev2_eth.c` already did. Hope I was able to helpful.
Cheers, Martine 2016-11-04 19:11 GMT+01:00 Anon Anonymous <[email protected]>: > Hi Jose, > > I think this is not the best way to do so. IMHO, you should write your own > MAC code using RIOT's code guidelines, API, stacks and common best > practices. > Semtech's code appears in different coding style and implements different > approaches in implementation so it wouldn't fit in RIOT's code well without > full re-writing. > > Cheers! > > > 2016-11-04 17:47 GMT+03:00 Jose Alamos <[email protected]>: >> >> Hi RIOTers, >> >> We have been working in a LoRaMAC layer for RIOT, based on Semtech >> LoRaMAC. >> We only need a fraction of code (just the MAC part [1]), so the first >> approach is to compile only this part and develop some glue code. >> We are having some problems with this, because there's no API and most >> function are internal, so we are not sure if it's the best way to proceed. >> >> Are there any RIOT standards to deal with these cases? Should we consider >> this as a pkg if only a small part is being used? >> >> Thank you. >> Cheers! >> >> [1]: https://github.com/Lora-net/LoRaMac-node/tree/master/src/mac >> >> _______________________________________________ >> devel mailing list >> [email protected] >> https://lists.riot-os.org/mailman/listinfo/devel >> > > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
