[riot-notifications] [RIOT-OS/RIOT] drivers/cc110x: Complete rewrite from scratch (#10340)

Marian Buschsieweke notifications at github.com
Fri Feb 1 12:15:49 CET 2019

> The discussion about the need of a MAC layer

No need for a full fledged MAC layer here: https://github.com/RIOT-OS/RIOT/pull/10403 would solve the issue here as it is. (To remain in the picture: I would be happy to take @miri64 pinky and I'm not asking for the whole hand ;-))

> What's your opinion on getting rid of 6LoWPAN support for that device?

The underlying problem here is that the driver will return `-EBUSY` when `netdev_driver_t::send()` is called during TX and drop the frame. This can not only be caused by 6LoWPAN's Layer 2 fragmentation, but also user code could cause sending two frames without sufficient delay between them. So this needs to be addressed in some way, regardless of 6LoWPAN support. But once addressed, 6LoWPAN will work as well.

> If you only (i) feed the TX buffer and (ii) send the frame after checking if the device is busy, wouldn't that prevent from corrupted frames?

The driver configures the device when entering TX to signal the driver events using the two GDO pins. If the frame did not fit the TX buffer, the driver will configure one GDO pin to signal when the TX buffer is drained below a threshold. This change of the GDO pin will cause an interrupt, which will triggers a call to `netdev_driver_t::isr()`. In that, the driver will feed the buffer.

As far as I know both `netdev_driver_t::isr()` and `netdev_driver_t::send()` will be called in the same thread context. If one is blocking, the other is blocked as well. So a blocking `netdev_driver_t::send()` would prevent `netdev_driver_t::isr()` from being called. (If I'm wrong about that and `netdev_driver_t::isr()` and `netdev_driver_t::send()` are called from different thread contexts, I could make the second call to `netdev_driver_t::send()` indeed blocking.)

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190201/c9ce6b68/attachment.html>

More information about the notifications mailing list