Hello everyone,
Could someone confirm me some points about working with radio transceivers under RIOT ? - there is currently no way to perform a quick check for the availability of radio medium ("Clear Channel Assessment"); - working with the 'transceiver' module is done by sending and receiving messages to/from the corresponding thread (the one whose ID is stored in 'transceiver_pid'.
Thanks in advance and best regards,
Hi Kévin!
- there is currently no way to perform a quick check for the availability of radio medium ("Clear Channel Assessment");
Yes, that's only implemented as a part of the CC110X driver, (not the _ng version), but is currently not part of the general interface.
- working with the 'transceiver' module is done by sending and receiving messages to/from the corresponding thread (the one whose ID is stored in 'transceiver_pid'.
Correct. Or if you need a more abstract interface, use net_if. However, I don't know how sensible it is to implement the MAC protocol on top of this module.
Hauke, Martine, and me had recently some discussions about re-designing the radio driver interface.
Currently the layout is like:
Hello,
Le 24/03/2014 18:40, Oleg Hahm a �crit :
Hi K�vin!
- there is currently no way to perform a quick check for the availability of radio medium ("Clear Channel Assessment");
Yes, that's only implemented as a part of the CC110X driver, (not the _ng version), but is currently not part of the general interface.
I will probably propose a PR to add this: CCA is very useful for developing efficient MAC protocols.
- working with the 'transceiver' module is done by sending and receiving messages to/from the corresponding thread (the one whose ID is stored in 'transceiver_pid'.
Correct. Or if you need a more abstract interface, use net_if. However, I don't know how sensible it is to implement the MAC protocol on top of this module.
Hauke, Martine, and me had recently some discussions about re-designing the radio driver interface.
Currently the layout is like:
----------------------------- > Application | >---------------------------| > > > Network stack | > (e.g. UDP+6LoWPAN) | >---------------------------| > net_if | >---------------------------| > Transceiver | >---------------------------| > Radio driver | > (including MAC protocol) | -----------------------------
One option could be to totally omit the transceiver module and just specify a common interface for every radio driver. Still, I would envision to have the MAC protocol to implemented below the net_if module (directly as part of the driver or stand-alone), since timings are crucial here.
You are absolutely right: I am working (for my PhD thesis) on MAC/RDC protocols, and for maximum efficiency you need to control directly the "physical" radio driver. Timing is so important that I need hardware real-time timers to obtain acceptable performance (this is why I never was able to obtain satisfactory results on Contiki...)
Another thing that may become an issue is that the message passing model used currently is flexible and elegant, but also consumes quite a bit of RAM: you have many threads (each coming with their descriptors and--especially--their stack space) and message queues for each of them... On ARM Cortex that have at least 20K RAM, this is not a big issue; but on MSP430 and other "lesser" architectures, you must work with at most 8KB RAM (many devices even have less: 4K or even worse 2K of RAM space are common limitations on 8/16-bit MCUs). Even the Zolertia Z1 (whose MCU is a recent and high-end MSP430) is limited to 8K of RAM! On such limited devices, having a "terser", less-flexible but "cheaper-on-RAM" interface (i.e. calling directly the ad-hoc drivers) may prove very useful, especially if you want to implement a hungry application (e.g. with many threads) along with radio communication... Maybe did Hauke, Martine and you already envision that issue?...
Cheers, Oleg
Thanks for the clear answers, and best regards,
Hello,
I just proposed a possible common API for radio drivers in PR #925. Let me know what you think about it.
Best regards,
Le 24/03/2014 18:40, Oleg Hahm a �crit :
[...]
Correct. Or if you need a more abstract interface, use net_if. However, I don't know how sensible it is to implement the MAC protocol on top of this module.
Hauke, Martine, and me had recently some discussions about re-designing the radio driver interface.
[...]