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
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
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
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
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
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