[riot-notifications] [RIOT-OS/RIOT] drivers/cc110x: Complete rewrite from scratch (#10340)
notifications at github.com
Thu Jan 31 13:29:20 CET 2019
`at86rf2xx` seems to upload the outgoing frame and then return from `netdev_driver_t::send()`. So there `netdev_driver_t::send()` will also be called before the previous frame is completely send out. (However, maybe the transceiver has a TX queue that can hold multiple outgoing frames, so this might not be an issue there.)
The current `cc110x` does also only block while uploading the first chunk into the TX FIFO. There will sending 6LoWPAN frames with link layer fragmentation not work as well, as the driver also refuses to send while not having finished sending the current frame. (I will do a quick test to confirm this.)
`xbee` seems to be like `at86rf2xx`: It could work if the hardware is able to queue TX frames internally.
`cc2420` will upload the outgoing frame in `netdev_driver_t::send()` and put the device in TX mode. Afterwards it will return without waiting for the device to have completely send the device. I think here the same issue will arise, if upper layers do not wait for sending to complete.
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. Maybe this does exists and I'm just not aware.
Btw: Changing `netdev_driver_t::send()` to block until the transmission is fully completed is not trival, as `netdev_driver_t::isr()` is (a.f.a.I.k.) called in the same thread context as `netdev_driver_t::send()`. So I would rather not do make `netdev_driver_t::send()` to block longer than really needed.
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...
More information about the notifications