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?
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?
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);
}
I really appreciate any help in solving this small confusion. Thank you.
Regards,
Navneet Pandey
From: Navneet Pandey
Sent: Friday, November 9, 2018 1:31 PM
To: 'users@riot-os.org' <users@riot-os.org>
Subject: RE: Radio Interrupt Handler
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@riot-os.org' <users@riot-os.org<mailto:users@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.pan...@outlook.in<mailto:navneet.pan...@outlook.in>>
Sent: Thursday, November 8, 2018 1:08 PM
To: users@riot-os.org<mailto:users@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.pan...@outlook.in<mailto:navneet.pan...@outlook.in>>
Sent: Monday, November 5, 2018 11:10 AM
To: users@riot-os.org<mailto:users@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
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users
