AnsweredAssumed Answered

Multitasking-with-sleeping shortcoming in JenOS

Question asked by Emmanuel Hernandez on Oct 10, 2016
Latest reply on Oct 11, 2016 by Emmanuel Hernandez

I am developing a ZigBee application using the JN5168 wireless chip and the NXP ZigBee PRO Stack which includes the JenOS.  Reading the manual, I see that JenOS provides all the usual RTOS features such as the ability to schedule tasks and respond to interrupts.  My question relates specifically to task scheduling.  In section 2.4.6 of the JenOS manual, it states: 

 

Caution: To allow the JN516x device to enter sleep
mode, no software timers should be active. Any running
software timers must first be stopped and any expired
timers must be de-activated.

 

A quick study of the JN5168 data sheet shows that, when scheduling tasks to execute in the future, energy consumption can be reduced by having the processor sleep until it is time to execute the next task if the task is more than 10 milliseconds or so into the future.  But it appears the processor has to keep running in order to run the software timer the OS needs to initiate execution of the next scheduled task.  This is a serious limitation of the OS for low-energy applications if it's true!  Why can't the OS take responsibility for putting the processor to sleep during idle times?

 

It would seem it falls to the application to determine when there is a sufficiently long span of idle time to justify putting the processor to sleep, then shut down any software timers, set up a sleep timer to wake up the processor at the appropriate time in the future, put the processor to sleep, restore/reschedule tasks as needed on wake-up, then finally execute the target task.  If the application has multiple tasks potentially executing in parallel, this can get very complicated very quickly! I don't even know if the OS provides the necessary API features to support this!

 

Looks to me like I need to manage multi-tasking at the application level if I want to make good use of sleep mode for this energy-critical application, more or less defeating much of the benefit of an RTOS!  Am I missing something here?  Please let me know what it is I'm overlooking that is leading me to this unfortunate conclusion!

Outcomes