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

José Alamos notifications at github.com
Thu May 14 15:39:00 CEST 2020

maybe we can fallback to IEEE802.15.4 notation:
- Confirm: an event in response to a Request like set_trx_state, transmit, etc (e.g PLL_LOCK, CCA_DONE, etc, etc).
- Indication: An asynchronous event indicated by the device (RX_START, RX_DONE, AMI, etc).

I propose this:
- Generate 2 kind of events on IRQ: a RF_CONFIRM and RF_INDICATION.
- An RF_CONFIRM is generated on requests (`set_trx_state, `cca`, `transmit`). This event can be used to unlock a semaphore or mutex (send_blocking)
- An RF_INDICATION is generated on asynchronous events (RX_START, RX_DONE, AMI, CRC_FAIL, etc). This event can be used to post an event to the bottom half processor.

Something like this:
void _isr(void *arg)
    if (irq_is_confirm()) {
    else {

Then, the upper layer can implement the event_callback like this:
switch(event) {
    case RF_CONFIRM:
        event_post(&ev_queue, &confirm_irq_handler);

So, a blocking send could look like:
ieee802154_radio_tramsit(dev); /* dev->driver->transmit(dev) */
/* wait for RF_CONFIRM event */
ieee802154_radio_process_confirm(dev); /* dev->driver->irq_handler(dev, true) */

And the bottom half processor could be wait for a RF_INDICATION before processing the IRQ:
/* event handler */
ieee802154_radio_process_indication(dev); /* dev->driver->irq_handler(dev, false) */

Does this make sense?

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/20200514/4ef4164e/attachment.htm>

More information about the notifications mailing list