[riot-users] Radio Interrupt Handler

Navneet Pandey navneet.pandey at outlook.in
Fri Nov 9 20:30:48 CET 2018


Hello Joakim,


> default behavior of the gnrc_networking example,

> no configuration necessary. The radio will be initialized and set to listen

> for incoming traffic, and will remain turned on until you type ifconfig x

> set state sleep in the shell.



Just to confirm, I do not interact with the program when the experiment is running. So, there is no code which shut the radio during an experiment, right? (Unless and until I make the shell call)

> To disable the CPU power savings, the easiest
> way is to either disable the pm_layered module using
> DISABLE_MODULE=pm_layered on the command line with your make command, or
> change the initial pm_blockers to non-zero. The pm blocker initial value is
> found in cpu_conf.h, or cpu_conf_common.h

I tried disabling the pm_layered module. But, I received an error saying "Required modules were disabled using DISABLE_MODULE: pm_layered"
And PM_BLOCKER_INITIAL is set to "0x01010101", which is non-zero already. So, please let me know if I missed any step.

> The first transition from pm set lowest to idle could be a RX Begin event,
> and the second wake could be the RX End interrupt. The RX Begin interrupt
> is sent when only the first byte of the frame has been received. The RX End
> interrupt is sent when the frame has been completely received

Following is the trace of INTERRUPT and low power mode
CLIENT - m3-101; Radio Packet to be Sent
CLIENT - m3-101; pm set lowest
CLIENT - m3-101; pm: setting mode 2
CLIENT - m3-101; INTERRUPT
CLIENT - m3-101; [at86rf2xx] return to idle state 0x16
CLIENT - m3-101; [at86rf2xx] EVT - TX_END
SERVER - m3-102; INTERRUPT
SERVER - m3-102; [at86rf2xx] EVT - RX_END
CLIENT - m3-101; pm set lowest
CLIENT - m3-101; pm: setting mode 2
SERVER - m3-102; [at86rf2xx] LQI:255 high is good, RSSI:-34 high is either good ortoo much interference.
SERVER - m3-102; Received a MAC packet, Sending Reply..
CLIENT - m3-101; INTERRUPT
CLIENT - m3-101; [at86rf2xx] EVT - RX_END
SERVER - m3-102; INTERRUPT
SERVER - m3-102; [at86rf2xx] return to idle state 0x16
SERVER - m3-102; [at86rf2xx] EVT - TX_END
CLIENT - m3-101; [at86rf2xx] LQI:255 high is good, RSSI:-34 high is either good ortoo much interference.

Surprisingly SERVER node is not making any low power mode calls.
Is _irq_handler() the best place to keep track of when the Interrupt was called?
Could you guess the reason why I do not see 'DEBUG("[at86rf2xx] EVT - RX_START\n");' being printed anywhere.

And finally, I would like to confirm that 'IDLE' does not represent any power saving mode. It just means that no other thread is in use except IDLE thread?

If you need to look at the application code, please refer to [1]. It is a simple application using 'txtsnd' to for radio communication. The application is a bit old since I haven't updated the code. But the basic idea is still remains the same.

References:
[1] https://github.com/npcode15/RIOT_OS_Experiments/tree/master/MAC

Thank you.

Regards,
Navneet Pandey

From: Navneet Pandey
Sent: Friday, November 9, 2018 5:20 AM
To: 'users at riot-os.org' <users at riot-os.org>
Subject: RE: Radio Interrupt Handler

Hello Joakim, thanks for an elaborate explanation, I will check those articles out. Before I do, I have a few more queries.

Could you also point out which module is responsible for radio switch on/off, assuming radio only has a binary mode unlike the CPU.
Is it 'at86rf2xx_netdev' or something else?

Also, is it possible to keep the radio open always for the duration of an experiment? And may be avoid deep sleep mode as well?

And am I correct when I say that 'cortex_sleep(deep)' puts CPU to sleep but doesn't touch the radio (based on what you replied).

Based on some of the modules on which I enabled debugging:
Following was the pattern:  PACKET SENT-> TX_Ends -> pm_set_lowest -> Idle -> pm_set_lowest -> RX_Ends -> PACKET RCVD.
I did not understand the part where CPU moved to idle state before going to sleep again. Did I miss any state in the process (probably did not enable debugging)?

I know these are a lot of questions. I really appreciate that you are answering my question in great detail. Thank you.

Regards,
Navneet Pandey

From: Navneet Pandey <navneet.pandey at outlook.in<mailto:navneet.pandey at outlook.in>>
Sent: Thursday, November 8, 2018 1:08 PM
To: users at riot-os.org<mailto:users at riot-os.org>
Subject: RE: Radio Interrupt Handler

Hello Joakim,

Thank you, the information was really helpful. I was exploring the 'at86rf2xx_netdev.c' file. I noticed something weird. When I enabled debugging all I got was

  *   To Idle state
  *   Evt TX_END
  *   Evt RX_END

By enabling debugging in pm_layered.c and pm.c, I noticed cortex_sleep(deep) was being called when radio was not doing anything. So why am I not seeing any of the following debug statements being printed (or in other words none of the following cases being invoked).
case NETOPT_STATE_STANDBY:
            DEBUG("STANDBY\n");
            at86rf2xx_set_state(dev, AT86RF2XX_STATE_TRX_OFF);
            break;
        case NETOPT_STATE_SLEEP:
            DEBUG("To SLEEP\n");
            at86rf2xx_set_state(dev, AT86RF2XX_STATE_SLEEP);
            break;
        case NETOPT_STATE_IDLE:
            DEBUG("To IDLE\n");
            at86rf2xx_set_state(dev, AT86RF2XX_STATE_RX_AACK_ON);
            break;

Regards,
Navneet Pandey

From: Navneet Pandey <navneet.pandey at outlook.in<mailto:navneet.pandey at outlook.in>>
Sent: Monday, November 5, 2018 11:10 AM
To: users at riot-os.org<mailto:users at riot-os.org>
Subject: Radio Interrupt Handler

Hello,

Could someone please point out the code where radio is switched on/off when sending a MAC/UDP packet.

I am expecting something similar to the following code snippet:
/** Turn the MAC layer on. */
  int (* on)(void);

  /** Turn the MAC layer off. */
  int (* off)(int keep_radio_on);

This code is from Contiki.

I am interested in understanding the time it takes for system to wake up from sleep (dormant mode) to receive packets.

Thank you.

Regards,
Navneet Pandey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20181109/f3ea297d/attachment-0001.html>


More information about the users mailing list