[riot-notifications] [RIOT-OS/RIOT] RDM: The 802.15.4 Radio HAL (#13943)

Marian Buschsieweke notifications at github.com
Thu May 14 13:06:02 CEST 2020


> Although I like this pattern, I think it would be hard to implement for SPI radios (there's no way to know which event was triggered unless `irq_handler` was called).

With ISR above I was referring to whatever code is handling the interrupt request; even if this is deferred from interrupt context to thread context. For users of the API this is an implementation detail; they won't notice a difference if their thread is unblocked from an ISR or anotther thread.

That said: This should often be possible from interrupt context. When switching from TRX_OFF to IDLE, often no other events can occur other than PLL_LOCK_REACHED. And even if other causes of IRQs are possible (but do not need to be attend to), features like the IRQ_MASK of the AT86RF233 are available for most transceivers to filter out interrupt sources not interested in. (But I do not want to imply that this is indeed the way every driver should implement it - that decision is likely best made individually with the specific context of the device and driver in mind.)

> Also, AFAIK some radios (e.g CC2420) don't report PLL_ON (this could be simulate though with a timer).

That is a pity. But yet again this problem needs to solve in any case: If the API would blocking, users would expect that `set_trx_state(IDLE)` only returns once the PLL lock is reached. So we would have fall back to either a timer (with a worst case delay) or periodically polling the PLL state, anyway. So I think that the timer (or polling) is in place anyway, we would just turn the code into an async API.

(Note that e.g. `xtimer_wait()` is internally also build on top of an async API with the callback function unblocking the caller of `xtimer_wait()`. So the async API would here have less overhead.)

-- 
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/13943#issuecomment-628561086
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200514/47eaf208/attachment-0001.htm>


More information about the notifications mailing list