[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:
https://github.com/RIOT-OS/RIOT/pull/10340#issuecomment-459650706
-------------- 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