Re: [riot-devel] How to know whether a MCU/Board supports LwMAC ?

[Shuguo Zhuo]

Hi, Chris,

> Also reading the readme file of the gnrc_networking_mac example I noted
> that it states that currently it should work only on samr21-xpro board.

Yes, since LwMAC has only been evaluated on samr21-xpro before, so to be 
secure, the developers (me and Daniel-krebs) stated that it currently only 
works with samr21-xpro.

> I'm wondering... which features should I search for in MCU/Boards in
> order to work with this module?

Basically, the current version of LwMAC requires RTT (real-time timer) for 
supporting its low-duty cycling scheme. 
So, if you want to run (the current version in RIOT) LwMAC, you need RTT on 
your board (also with a frequency no less than 1k Hz of the RTT). ;-)
And, that is it! Since LwMAC was developed with the general netdev (radio) 
APIs, you shouldn't need other (very specific) features for running LwMAC.
(But, notice that, you radio driver should also have RX-start, RX-complete and 
TX-end interrupt events.)

PS: I have recently tested LwMAC on iotlab-m3 nodes (with some modifications on 
RTT and some timer APIs, cheat/bypass the compiler), and it works (with unicast 
and bcast). (But, principally, LwMAC currently don't support iotlab-m3, since 
iotlab-m3 has a RTT of only 1Hz, don't try it yourself).

On the other hand, we are on the way to make LwMAC more generic (support more 
boards), there are already some PRs about it. 
We will try to replace the timer source module (i.e., RTT) with the more 
general evtimer module (CPU timer). In short, after this work has been done 
(maybe in recent months), you will not even need RTT for running LwMAC.
(actually, it will be like in an optional way, if the board has RTT, then use 
it; otherwise use evtimer).

Cheers!
Shuguo



- 原始邮件 -
> 发件人: "Hawkboy" 
> 收件人: devel@riot-os.org
> 发送时间: 星期一, 2017年 10 月 23日 下午 2:22:00
> 主题: [riot-devel] How to know whether a MCU/Board supports LwMAC ?
> 
> Hi,
> 
> I was reading about LwMAC here
> ttps://riot-os.org/api/group__net__gnrc__lwmac.html.
> 
> Also reading the readme file of the gnrc_networking_mac example I noted
> that it states that currently it should work only on samr21-xpro board.
> 
> I'm wondering... which features should I search for in MCU/Boards in
> order to work with this module?
> 
> thanks,
> 
> Chris
> 
> ___
> 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

Re: [riot-devel] gnrc: MAC layer selection

[Shuguo Zhuo]

Hi, Joakim,

This is a very good topic which also confuses me (with also my GoMacH MAC 
implementation queued up in pipe). 

> One possible solution is to add a function pointer member to the
> `at86rf2xx_params_t` (and similar parameter structs for the other
> netdev drivers) for initializing the MAC layer, and let the user
> select the MAC layer there.

This sounds like a good solution to me. 
Waiting for responses from more experienced RIOT developers. ;-)

Bests,
Shuguo

- 原始邮件 -
> 发件人: "Joakim Nohlgård" 
> 收件人: "RIOT OS kernel developers" 
> 发送时间: 星期三, 2017年 9 月 20日 上午 9:56:19
> 主题: [riot-devel] gnrc: MAC layer selection
> 
> Dear developers,
> Currently there are two different MAC layers for gnrc in the master
> branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a
> no-op MAC layer, only passes packets between the netdev driver and the
> upper layers, while LWMAC is a duty cycling MAC implementation which
> manages a schedule for the radio, including sleep.
> 
> Which layer is used is selected by which init function is called
> during boot, if gnrc_lwmac_init is called, then the device will run
> LWMAC, or if gnrc_netdev_init is called, then the device will use
> gnrc_netdev. auto_init has an `#ifdef` block checking for
> `MODULE_GNRC_LWMAC` and uses that to select which init function is
> called, but this is only implemented for the at86rf2xx driver, any
> other drivers will need to have similar changes to their auto_init
> functions as well.
> 
> This current model is not going to scale well when new devices are
> added and new MAC layers are implemented. All MAC layer
> implementations will need to touch all netif auto_init
> implementations.
> 
> I am asking for ideas on how to make this more modular and less #ifdeffy.
> 
> One possible solution is to add a function pointer member to the
> `at86rf2xx_params_t` (and similar parameter structs for the other
> netdev drivers) for initializing the MAC layer, and let the user
> select the MAC layer there.
> By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose
> the default MAC layer depending on the module selection. This would
> behave like it is today for LWMAC, but the #ifdef hell would be kept
> in a common header file, like gnrc_mac_default.h or something.
> 
> What are your thoughts on this?
> 
> I have a ContikiMAC MAC layer implementation queued up in the pipe for
> inclusion in master and it will only make this situation worse if we
> don't alter the current model.
> 
> Best regards,
> Joakim Nohlgård
> Eistec AB
> ___
> 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

Re: [riot-devel] At86rf2xx ACK frame

[Shuguo Zhuo]

I guess if you only want to use the ACK frame as an input of the function, 
given that it is hard to get from the extended mode, then, maybe one solution 
is that you can manually build one yourself (you can get the sequence number 
from the hardware) and pass it to the function. 

Cheers, 
Shuguo 

- 原始邮件 -

> 发件人: "Joakim Nohlgård" 
> 收件人: "RIOT OS kernel developers" 
> 发送时间: 星期四, 2017年 6 月 15日 下午 10:55:03
> 主题: Re: [riot-devel] At86rf2xx ACK frame

> Why do you need the actual ACK frame? It's only like 3 bytes + FCS and
> doesn't really contain anything interesting. The only interesting
> information is that the frame with the given sequence id was received
> properly, which is exactly the same information you get from the transceiver
> hardware.

> Regards,
> Joakim

> On Jun 15, 2017 8:18 AM, "Baptiste Clenet" < bapcle...@gmail.com > wrote:

> > Which mean that automated ACK by the transceiver is fine.
> 
> > 1 - RIOT sends a frame
> 
> > 2 - Transceiver receives an ACK and transmit a
> > AT86RF2XX_TRX_STATE__TRAC_SUCCESS
> 
> > 3 - Here I want to get the ACK frame content
> 
> > 4 - Use it with openthread (Have a look here [1] to understand why we need
> > it)
> 

> > [1]
> > https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404
> 

> > Cheers,
> 

> > 2017-06-13 15:46 GMT+02:00 Baptiste Clenet < bapcle...@gmail.com >:
> 
> > > 2017-06-13 14:45 GMT+02:00 Oleg < o...@riot-os.org >:
> 
> > >> Hi Baptiste!
> 
> > >>
> 
> > >> On 2017-06-13 12:30, Baptiste Clenet wrote:
> 
> > >>>
> 
> > >>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after
> 
> > >>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
> 
> > >>> received by at86rf2xx?
> 
> > >>
> 
> > >>
> 
> > >> The ACK frame is processed automatically by the transceiver. There is no
> > >> way
> 
> > >> to access it using the extended mode. If you use the base mode, you will
> 
> > >> have to send and process the ACK yourself.
> 
> > >>
> 
> > >
> 
> > > Ok I don't want to process the ACK myself, I only want to get the
> 
> > > frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
> 
> > > store in a register/frame buffer? Or do we must use base mode to get
> 
> > > the ACK frame.
> 
> > >
> 
> > >>
> 
> > >> Cheers,
> 
> > >> Oleg
> 
> > >> ___
> 
> > >> devel mailing list
> 
> > >> devel@riot-os.org
> 
> > >> https://lists.riot-os.org/mailman/listinfo/devel
> 
> > >
> 
> > >
> 
> > >
> 
> > > --
> 
> > > Baptiste
> 

> > --
> 
> > Baptiste
> 
> > ___
> 
> > 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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel