Menu
▾
▴
Re: [Contiki-developers] Custom Interrupts and Contikimac
|
From: David K. <da...@em...> - 2012-11-13 19:38:55
|
Right, you would have to call the rtimer_arch_sleep routine from the main
loop, and make the contikimac CYCLE_TIME and cycle_start globals to
calculate the wake time.
rtimer_arch_sleep(CYCLE_TIME - (RTIMER_NOW() - cycle_start));
That is in rtimer_arch.c:
#if RDC_CONF_MCU_SLEEP
/*---------------------------------------------------------------------------*/
void
rtimer_arch_sleep(rtimer_clock_t howlong)
{
/* Deep Sleep for howlong rtimer ticks. This will stop all timers except
* for TIMER2 which can be clocked using an external crystal.
* Unfortunately this is an 8 bit timer; a lower prescaler gives higher
* precision but smaller maximum sleep time.
* Here a maximum 128msec (contikimac 8Hz channel check sleep) is assumed.
* The rtimer and system clocks are adjusted to reflect the sleep time.
*/
You could sleep up to 8 seconds if you don't need to receive any radio
packets. Even the "correct" sleep will lose the contikimac phase though,
unless you phase-lock the rtimer to the 32KHz crystal, because of rounding
errors when converting from rtimer ticks to timer2 ticks.
The radio tx routine turns the power on if necessary, does the configured
csma and autotx/ack detect, and powers off, so you could leave the radio off
entirely with NETSTACK_MAC.off(0) and a call to rf230_transmit would still
send the packet once. But contikimac has an explicit block when the radio is
off, you would have to disable that to get strobing over the channel cycle
(but the hardware could be configured to do 15 strobes on its own). You'd
only need the full strobing if the receiver is duty cycling.
/* Exit if RDC and radio were explicitly turned off */
if (!contikimac_is_on && !contikimac_keep_radio_on) {
PRINTF("contikimac: radio is turned off\n");
return MAC_TX_ERR_FATAL;
}
-----Original Message-----
From: Juan Villa
Sent: Tuesday, November 13, 2012 1:05 PM
To: Contiki developer mailing list
Subject: Re: [Contiki-developers] Custom Interrupts and Contikimac
That makes sense. My first attempt at sleeping in the main loop caused some
erratic behavior and I did not have enough time to look into it. I have that
work branched off and I'll keep on working on it soon.
What I have noticed though is that for the Atmel chips, the only timer that
can wake-up the chip from sleep is Timer2 when running in asynchronous mode
(with a 32.768KHz external crystal). This means I can't just sleep randomly
for 1/4 second on the main loop (like on the econotag sample you provided
earlier) because rtimer (Timer3 on the Atmel) will not wake up the chip from
sleep (Timer3 runs from the IOclk which is derived from the main clock --
which is off in all good sleep modes). The sleeping mechanism/hack in
contikimac calculates the time the chip can sleep before the next rtimer
interrupt.
What can I do to make this process better? Am I missing something big?
The only I can think of is to explore sleeping for 1/4 second at a time in
the main loop but using the "Standby" sleep mode which will save some power,
but not as much as I want.
Also, technically I don't need to run Contikimac on these devices. It would
be nice to be able to transmit data to these devices, but during 99.999% of
the time I will not have the need to transmit anything to them. Is there an
example I can follow or anything you might know about implementing a RDC
algorithm that keeps the radio off except when transmitting (and back to off
when done -- assume I'll need to wait for ACK). I can then go into deep
sleep and wait for an external interrupt which would wake up my board to
latch data and transmit again (then back to sleep). Is this a plausible
scheme? I have a few ideas on how I can begin to work with this. Any
suggestions?
Thanks!
On Mon, Nov 12, 2012 at 10:00 AM, David Kopf <da...@em...> wrote:
http://www.sics.se/contiki/wiki/index.php/RDC_Phase_Optimization
It can reduce the number of tx strobes to 2-3 instead of 16 on average, but
does not change packet throughput. That cuts energy consumption, not much of
a consideration for an always-on border router, and reduces RF traffic which
would help when multiple nodes try to transmit at the same time. Probably
won't help much unless you phase lock the rtimer to a crystal.
That sleep in the main routine is better in every way. The contikimac sleep
stays awake 1/16 of the time so minimum CPU is over 5%; the main loop sleep
cuts that to 2% or less. And process latency is reduced from 2 seconds to
<1/8 second.
-----Original Message-----
From: Juan Villa
Sent: Sunday, November 11, 2012 4:06 PM
To: Contiki developer mailing list
Subject: Re: [Contiki-developers] Custom Interrupts and Contikimac
David,
I tried to implement the sleep in the main loop, but I did not get better
results than the currently implemented hack. CPU sleeping coordinated by
contikimac works very well for now. I have not done very accurate testing of
battery consumption yet. This is one of my long term goals for this platform
I developed. For now the device has been running for a few days on a CR2032
coin cell and it has dropped less than 0.1V with all the debugging and
testing I have put it through. I need to carefuly optimize everything when I
get a chance. For now I am happy with the contikimac optimizations.
Thank you for the example though! I am going to use that code as reference
for writing a good implementation for my platform.
Also, I managed to fix the issue I have had with the radio hanging and
watchdog restarts. Interestingly enough I managed to fix the issue by not
disabling/enabling the rtimer from my interrupts. I simply made the main IRQ
interrupt ISR_NOBLOCK and I have not seen a hang/restart in 18 hours. It
handles about 3 to 5 interrupts and data transfers per second and transmits
the results in a UDP packet at the same rate to the edge router. My
interrupts are less time sensitive than the rtimer interrupts for contikimac
and the radio so as long as my interrupt triggers I have about 250uS to
capture every bit before I loose it. Even if my interrupt gets nested by
another interrupt I recover nicely. 1 out of every 10 to 20 interrupts
looses one bit, but the code can detect it and discard the results.
Does phase optimization work well? It says in the source code that it's not
very well tested. I will also be giving that a shot.
I will keep on working towards optimizing my solution.
Thank you for all your insight! I greatly appreciate it!
On Sun, Nov 11, 2012 at 7:23 AM, David Kopf <da...@em...> wrote:
Juan Villa wrote:
>When I refer to sleep I am actually referring to the sleep that contikimac
>handles when RDC_CONF_MCU_SLEEP = 1. I am not making any calls to custom
>sleep >routines.
Ah, that sleep routine in contikimac was an early hack. It does cut power
consumption, but returning to the main idle loop only once every two seconds
blocks foreground tasks, and makes nested interrupts far more likely. Do
those problems go away when you disable the sleep?
In any case, better to sleep in the main loop after checking for radio off
and no more processes to be polled. I thought I pushed that to the repo but
apparently not; here is the econotag version
http://git.devl.org/?p=malvira/contiki-2.x.git;a=blob;f=platform/redbee-econotag/contiki-mc1322x-main.c;h=6bdb1227801f6f24548a8efa9771f999eb9ea36d;hb=dak-contikimac-rebase
The main loop runs till idle:
676 /* Main scheduler loop */
677 while(1) {
678 idle:
679 do {
699 ...
700 } while (process_run());
701
702 /* No events remaining in queue, maybe we can catch a quick nap */
then converts the contikimac rtimer interrupt into a sleep wake:
892 #if !RPL_BORDER_ROUTER
894 /* If radio is off and no uart tx, sleep 1/4 second or until next
rtimer interrupt */
895 if (maca_pwr == 0) {
896 static uint8_t uart1_was_transmitting;
897 if(*UART1_UTXCON == 32) {
898 if(uart1_was_transmitting) {
899 /* Last character is going out, go through main loop
some more times */
900 uart1_was_transmitting--;
901 } else {
902 rtimer_arch_sleep(RTIMER_ARCH_SECOND/4);
903 }
904 } else {
905 uart1_was_transmitting = 4;
906 }
907 }
908 #endif
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
--
Juan C. Villa
Chief Technology Officer
MedEyes Global
M. 404.441.9653
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
--
Juan C. Villa
Chief Technology Officer
MedEyes Global
M. 404.441.9653
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Contiki-developers mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
|
