Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

2017-09-20 Thread Thomas Eichinger
Hi Joakim, Thanks for sharing your point of view. Personally I think it complicates MAC protocol implementations when they somehow have to accommodate 802.15.4 functionality and deal with e.g. starting and maintaining the PAN and I'd expect we will have to use more #ifdefs. In my opinion

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

2017-09-20 Thread Martine Lenders
Hi Joakim, Hi Shuguo, First of all: We know of this problem and I try to come up with a solution for this for a long time, so thanks for picking this up. A step into that direction (but not the final solution) was the refactoring of GNRC's interface layer (aka gnrc_netif2, see [1], should also

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

2017-09-20 Thread Joakim Nohlgård
On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiser wrote: > Hi Joakim, > > On 09/20/2017 10:11 AM, Joakim Nohlgård wrote: >> I have recently been digging around the gnrc_netdev code as well. I >> think that adding support for other frame types and logic for sending >> these

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

2017-09-20 Thread Kaspar Schleiser
Hi Joakim, On 09/20/2017 10:11 AM, Joakim Nohlgård wrote: > I have recently been digging around the gnrc_netdev code as well. I > think that adding support for other frame types and logic for sending > these frames will definitely become a mess if the 802.15.4 code is not > decoupled from the

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

2017-09-20 Thread 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

[riot-devel] gnrc: MAC layer selection

2017-09-20 Thread Joakim Nohlgård
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