This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is there a way to determine how long TSK_idle?

Other Parts Discussed in Thread: OMAPL138

I'm using DSP_BIOS version 5.40.02.22 running in the DSP of an OMAPL138.

I'm using TSK_idle to do some power management, shutting down unneeded devices when all the other tasks are idle.  I'm looking for a method to determine, when the next task will become ready.  For example, if two tasks are running and one executes a SEM_pend with a timeout of 1 second and the other executes a TSK_sleep for 2 seconds, I'd like TSK_idle to be able to find out that some task will be ready in 1 second.  TSK_idle could power hardware down but could make sure to power it back up before the first task becomes ready.

  • I don't know of anything along the lines you're describing, but there might actually be a better way.  There's a feature called a "hook" function that allows you to specify functions that will run at certain points of time.  In particular I think you might want to create a "ready" function that would be called when a task becomes ready.  Basically it's a callback function that would run when the task becomes ready. Inside that function I would expect you to do whatever power stuff is necessary.

  • What I really want to do, is shut down the hardware, turn off the appropriate clocks, and idle the processor.  Before I do that, I'd like to set an alarm or timer interrupt that will bring the processor out of idle just before the task times out.  So the ready hook won't do it.  I'll likely have shut off the periodic timer interrupt to save as much power as possible.  Can you suggest another approach?   

  • John Walter said:
    I'd like to set an alarm or timer interrupt that will bring the processor out of idle just before the task times out.

    John Walter said:
    I'll likely have shut off the periodic timer interrupt to save as much power as possible.

    It seems like the two statements above are conflicting.  Can you further explain?

    If you do not have a periodic BIOS interrupt then the internal BIOS counters will not increment and your task will remain blocked forever.

  • Yes, I know that shutting of the periodic timer will cause time to stand still.  The first step is knowing how long I can sleep.  After that I'll have to figure out how to convince the BIOS that time has passed.

    Here's what I'd like to do...

    TSK_idle() {

    IdleTime = AskTheBiosWhenToWakeUp();

    set real time clock alarm to go off after IdleTime has elapsed;

    get to lowest power consumption -- shutdown hardware, turn off clocks, etc.

    asm(' idle')

    // some external interrupt or the real time clock brought us out of idle!

    tell the bios how much time has elapsed while idle.

    }

  • John,

    There is no API to dynamically query all the timeouts (e.g., CLK objects, SEM_pend() calls, TSK_sleep() calls, etc.) active for the application.  If you want this I think you’ll need to track this at the application level, for example, if you have multiple tasks pending on semaphores or sleeping, you’ll need to keep track of those counts versus the tick counts when the calls are being made.  And then look at these counts when you are determining how long you want to go to sleep.  And this would only be for system tick interrupts.  You’d likely have do something similar to accommodate peripheral interrupts, like when the next DMA, serial port, etc. interrupt might go off.  This may be doable for a simple application, but will probably get complex quickly.

    Regarding “After that I'll have to figure out how to convince the BIOS that time has passed.” – there is no API to do that either.  You’d probably have to provide your own application function to serve as a timekeeper – this function could get tick counts from CLK, and then add the amount of ticks you’ve skipped.

    Also, if you plan on going to the “lowest” consumption state (i.e., DEEPSLEEP), the only way to wakeup is EITHER an RTC alarm or a dedicated external I/O - the device only supports one or the other.

    Scott