interrupt and time management in c os iii n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Interrupt and Time Management in µC/OS-III PowerPoint Presentation
Download Presentation
Interrupt and Time Management in µC/OS-III

Loading in 2 Seconds...

play fullscreen
1 / 22

Interrupt and Time Management in µC/OS-III - PowerPoint PPT Presentation


  • 183 Views
  • Uploaded on

Interrupt and Time Management in µC/OS-III. Akos Ledeczi EECE 354, Fall 2012 Vanderbilt University. Interrupt Basics. Context Interrupt Service Routine (ISR) Enable/Disable Nesting Interrupt disable time Interrupt response: time between interrupt and start of user ISR execution

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Interrupt and Time Management in µC/OS-III' - quant


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
interrupt and time management in c os iii

Interrupt and Time Management in µC/OS-III

Akos Ledeczi

EECE 354, Fall 2012

Vanderbilt University

interrupt basics
Interrupt Basics
  • Context
  • Interrupt Service Routine (ISR)
  • Enable/Disable
  • Nesting
  • Interrupt disable time
  • Interrupt response: time between interrupt and start of user ISR execution
  • Interrupt recovery: time required to return to interrupted code (or higher priority task)
  • Task latency: time to return to task level code
interrupt handling
Interrupt Handling
  • Interrupt controller handles many issues including providing the address of the required ISR in many cases
  • Two models:
    • All interrupts vector to a single interrupt handler
    • Each interrupt vector directly to its own ISR
c os iii isr pseudo code
µC/OS-III ISR Pseudo Code

MyISR:

Disable all interrupts;

Save CPU registers;

OSIntNestingCtr++;

if (OSIntNestingCtr == 1)

OSTCBCurPtr->StkPtr =

current task’s CPU stackpointer register value

Clear interrupting device;

Re-enable interrupts (optional);

Call user ISR;

OSIntExit();

Restore CPU registers;

Return from interrupt;

ISR Prologue

ISR Epilogue

  • Written in assembly
  • Context: some CPUs do this automatically
  • Some CPUs have separate stack (and SP) for interrupts (µC/OS-III port can implement this in software saving space on all task stacks)
  • User code typically needs to call one of the Post() functions
  • Must call OSIntExit()
short isr
Short ISR

MyShortISR:

Disable all interrupts;

Save necessary CPU registers;

Clear interrupting device;

DO NOT re-enable interrupts;

Call user ISR;

Restore saved CPU registers;

Return from interrupt;

  • When no Post() call is needed
  • No OSIntExit() call is needed
  • Should be the exception as the OS does not know about this at all…
one common master isr
One Common Master ISR
  • The while loop above can be part of a user ISR written in C
  • Interrupt controller may provide an actual address of the required ISR or just an index that can be used to get the address from a table in memory
  • ISR needs to look like this (one for each kind of interrupt):

void MyISRHandler(void)

  • Note that there is no nested interrupts even though it does handle multiple interrupts, so ISR Prologue and Epilogue need to be called only once

ISR Prologue;

while (there are still interrupts to process) {

Get vector address from interrupt controller;

Call interrupt handler;

}

ISR Epilogue;

direct post
Direct Post

Interrupt Latency =

maximum interrupt disable time;

Interrupt Response =

interrupt latency +

vectoring to ISR +

ISR prologue;

Interrupt Recovery =

handling of device +

Post() +

ISR epilogue;

Task Latency =

interrupt response +

interrupt recovery +

scheduler lock time

deferred post
Deferred Post

Interrupt Latency =

maximum interrupt disable time;

Interrupt Response =

interrupt latency +

vectoring to ISR +

ISR prologue;

Interrupt Recovery =

handling of device +

Post() +

ISR epilogue;

Task Latency =

interrupt response +

interrupt recovery +

re-issue Post() +

context switch to task +

scheduler lock time

tick handling
Tick Handling
  • Hook is called first to give the application more precise timing
  • Your low power app may not need tick processing at all: it is OK, but no time delays and timeouts can be used.

void OS_CPU_SysTickHandler (void) /* ISR */

{

CPU_CRITICAL_ENTER();

OSIntNestingCtr++; /* Tell uC/OS-III that we are starting an ISR */

CPU_CRITICAL_EXIT();

OSTimeTick(); /* Call uC/OS-III's OSTimeTick() */

OSIntExit(); /* Tell uC/OS-III that we are leaving the ISR */

}

voidOSTimeTick(void)

{

OSTimeTickHook();

#if OS_CFG_ISR_POST_DEFERRED_EN > 0u

Get timestamp;

Post “time tick” to the interrupt queue;

#else

Signal the Tick Task;

Run round robin scheduling if enabled;

Signal the Timer Task;

#end

}

pend lists
Pend Lists
  • The first few fields are the same: OS_PEND_OBJ
  • Type: four characters for easy debugging
  • Head and Tail pointer point to OS_PEND_DATA and not TCB
pend lists cont d
Pend Lists cont’d.
  • Prev and Next: doubly linked list
  • TCBPtr: corresponding TCB
  • PenObjPtr: object task is pending on
  • Rest: only needed when pending on multiple objects
time management relative delay
Time Management: Relative Delay
  • OS_OPT_TIME_DELAY
  • Timing is not precise:
    • The only thing guaranteed is that the task will be delayed at least: ((ticks – 1) * tick-period)
absolute delay
Absolute Delay
  • Regardless of CPU load, the task remains “synchronized”: for example, it will be called 100 times during 1000 ticks. In relative mode under heavy CPU load, it may miss ticks, so it might get called less than 100 times. A time-of-day clock may be “late” if relative mode is used.

Void MyTask(void *p_arg)

{

OS_ERR err;

OS_TICK current;

:

:

current = OSTimeGet();

while (1) {

current = current + 10;

OSTimeDly(current, OS_OPT_TIME_MATCH, &err);

if (err == OS_ERR_NONE) {

/* code resumes here after waiting for 10 ticks or resumed by another task */

}

else {

/* some error in Dly function call */

}

}

}

time management
Time Management
  • OSTimeDlyHMSM() only works in relative mode
    • OS_OPT_TIME_HMSM_STRICT : only valid ranges
    • OS_OPT_TIME_HMSM_NON_STRICT: hr: 0-999, sec: 0-9999
  • OSTimeDlyResume()
  • OSTimeSet()
  • OSTimeGet()
timers
Timers
  • Counters that perform an action via a callback function when 0 is reached
  • OS_CFG_TMR_EN
  • Timer rate is typically (much) lower than tick rate
  • Callback is run from the context of the Timer Task: must not make blocking calls

void OSTmrCreate (OS_TMR *p_tmr,

CPU_CHAR *p_name,

OS_TICK dly, /* initial delay */

OS_TICK period, /* repeat period */

OS_OPT opt,

OS_TMR_CALLBACK_PTR p_callback,

void *p_callback_arg,

OS_ERR *p_err)

one shot timers
One-shot Timers
  • Can be retriggered
  • Can be used to implement watchdog timers
timing
Timing
  • Tick ISR signals Timer Task at the timer rate
  • Timer Task eventually runs and calls callback functions of all timers that have expired
timer wheel
Timer wheel
  • The exact same concept as the tick wheel: only a fraction of the timers need to be looked at at any one time