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

Peter Kietzmann notifications at github.com
Fri Feb 1 09:52:18 CET 2019

@maribu it is correct that the `at86rf2xx` returns before the frame has been sent. When a **subsequent** frame has to be sent immediately, e.g. by 6Lo fragmentation, the driver blocks until the next frame can be loaded to the device buffer. The frame or packet_snip is in the packet buffer and there is no TX queue of the device. Is there no such "device-busy" flag for your device?

> So as far as I can see it, there seems to be a common need from the netdev_driver_t implementations to tell the upper layers to delay pending calls to netdev_driver_t::send() until the current transmission is completed

As you figured earlier there is `NETDEV_EVENT_TX_COMPLETE` but you are right that it's not used by 6Lo fragmentation to synchronize with the radio. Please let's not open that discussion in here. 

> OK, the current cc110x works for up to ping6 <addr> 73, but starting from ping6 <addr> 74 it fails. Because the driver can send frames of up to 255 Bytes

I don't understand what the current situation is like. Yesterday you mentioned  `ping6 <ADDR> 204` works. 

@maribu I wasn't about to compare against the current implementation. Furthermore, I wouldn't even insist on supporting 6Lo with that device, even if it's a nice feature. But in that case we should make sure the radio is not being used together with 6Lo...

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/52559829/attachment.html>

More information about the notifications mailing list