[riot-devel] Working with radio transceivers

ROUSSEL Kévin Kevin.Roussel at inria.fr
Tue Mar 25 10:34:07 CET 2014


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,

      Kévin Roussel
      Doctorant, projet LAR
      Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
      Tél. : +33 3 54 95 86 27
      Kevin.Roussel at inria.fr

More information about the devel mailing list