[riot-users] Radio Interrupt Handler

Joakim NohlgÄrd joakim.nohlgard at eistec.se
Fri Nov 16 08:38:23 CET 2018


Hi again Navneet,

On Wed, Nov 14, 2018 at 10:50 AM Navneet Pandey
<navneet.pandey at outlook.in> wrote:
>
> Hello everyone, I have some confusion regarding the process flow of program at the driver level.
>
>
>
> I have the following debug logs from at86rf2xx (with some custom logs)
>
>
>
> CLIENT - m3-100;[at86rf2xx] at86rf2xx_tx_load
>
> CLIENT - m3-100;[at86rf2xx] PRELOADED at86rf2xx_tx_exec
>
> CLIENT - m3-100;PKT SENT // Represents end of _send method in at86rf2xx_netdev.c
>
> server - m3-101;INTERRUPT
>
> server - m3-101;[at86rf2xx] EVT - ISR CALLED
>
> CLIENT - m3-100;INTERRUPT // Represents _irq_handler method in at86rf2xx_netdev.c if (dev->event_callback) this is TRUE/1
>
> CLIENT - m3-100;[at86rf2xx] EVT - ISR CALLED // represents _isr method being called
>
> CLIENT - m3-100;[at86rf2xx] return to idle state 0x16
>
> server - m3-101;[at86rf2xx] EVT - RX_END
>
> server - m3-101;PKT RECV
>
> server - m3-101;PKT RECV
>
> CLIENT - m3-100;[at86rf2xx] EVT - TX_END
>
> My question here is that,
>
> Firstly, does PKT_SENT i.e. the end of send method from netdev::send mean that data/packet was actually sent?

The end of the _send method (in at86rf2xx_netdev.c) means that the
frame has been loaded in the transceiver buffer and the transceiver is
going to send it at the next opportunity. This is also signaled to the
upper layers via the netdev->event_callback(netdev,
NETDEV_EVENT_TX_STARTED); call in at86rf2xx_tx_exec (at86rf2xx.c).
When the transmission is finished, the transceiver will issue an IRQ
to the CPU and the CPU will run the IRQ handler. If you look at the
_isr method you will find calls to netdev->event_callback(netdev,
NETDEV_EVENT_TX_COMPLETE); and other similar events. This is the way
that the driver tells the upper layers that the transmission has ended
for some reason, the type of event signals what the status is,
TX_COMPLETE means success, NOACK means that the frame was sent but
there was no acknowledgment from the remote side, MEDIUM_BUSY means
that there was someone else using the channel and we could not find a
free slot before running out of retries (CSMA failure).
>
> Secondly, if the answer is yes to previous question, why does INTERRUPT occur after the packet was sent? If answer to the first question is no, then when/where does the packet/data actually gets transmitted?

The exact behavior depend on which radio you are using, but generally
the data will begin transmitting as soon as the transceiver detects
that the channel is free if you are using CSMA, which is the default
setting on transceivers which support it. There may be a number of
retries if the channel is busy so the time that this takes is
indeterminate beforehand.

> I am aware that methods such as prepare/load/exec already start the transmission process, hence the dilemma about INTERRUPT being called after these modules/functions.
>
> Thirdly, In the logs (not present in the above log), I observed that the following piece of code never gets executed even though packet transmission starts
>
> if (netdev->event_callback &&
>
>         (dev->flags & AT86RF2XX_OPT_TELL_TX_START)) {
>
>         DEBUG("TX STARTED\n");
>
>         netdev->event_callback(netdev, NETDEV_EVENT_TX_STARTED);
>
>     }

Does your application enable the NETOPT_TX_START_IRQ option?
(Otherwise the (dev->flags & AT86RF2XX_OPT_TELL_TX_START) part is 0)
The example applications in the RIOT repository do not enable this,
only LWMAC seem to use it at present.

>
>
>
> I really appreciate any help in solving this small confusion. Thank you.
>

I hope this helps,
Joakim


More information about the users mailing list