Embedded Software TI2726 B. 7. Embedded software design. Koen Langendoen. Embedded Software Group

Size: px

Start display at page:

Download "Embedded Software TI2726 B. 7. Embedded software design. Koen Langendoen. Embedded Software Group"

Gregory Miles
5 years ago
Views:

1 Embedded Software 7. Embedded software design TI2726 B Koen Langendoen Embedded Software Group

2 Overview Timing services RTOS and ISRs Design of embedded systems General principles

3 Timing Functionality Basic requirement of an embedded RTOS Suspend task for some time (vs. busy wait) Produce a result at a certain time Timeout (wait for an acknowledgement for some time) X32: delay(dt) busy waits (loops) until X32 clock has advanced dt ms ( polling ) RTOS: OSTimeDly(n) suspends caller (task) until time has advanced n OS ticks ( interrupt )!! set a timer variable to x ticks;!! decrement each tick;!! if zero move task to ready 16

4 delay() /* * delay -- busy-wait for ms milliseconds * */ void delay(int ms) { int time = X32_clock; while(x32_clock - time < ms) {} } 17

5 Time Delay Functionality OSTimeDly() is more efficient than delay() schedules other tasks (does useful work) while waiting for time to pass OS needs a timer interrupt mechanism to periodically check time NOTE: without OS, context switching is initiated by task calls => no timer interrupts are needed Timer interrupt => tick => delay resolution (and OS overhead) Timeouts in semaphores, etc. Blocking with WAIT_FOREVER is simple! Blocking for X timer ticks is more difficult Accuracy of a tick: OSTimeDly(3) OSTimeDly(3) time 18

6 OS Delay Processing highest priority task starts first timer ISR RTOS Task 1 Task 2 context switch timer IRQ tick tick OS_Delay(2) delay expired 19

7 Questions Is the parameter of OSTimeDly() given in ms? How accurate is the result of OSTimeDly()? How does the RTOS know how to setup the timer HW? What is normal length of a system tick? What if I need very accurate timing? 20

8 Overview Timing services RTOS and ISRs Design of embedded systems General principles

9 RTOS and Interrupts RTOS and interrupts are two separate worlds Exception are timers > OS delays Embedded programs use interrupts to react to events (buttons, I/O lines, UART, decoder,..) Interrupts and RTOS = trouble! Rule 1: No blocking Rule 2: No RTOS calls without a fair warning 23

10 RTOS and Interrupts Rule 1: an ISR must not call any RTOS function that might block the caller no pend type calls no semaphores to protect shared data in ISRs no reading queues, etc in ISR Violating this rule may affect response time and may even cause deadlock! 24

11 Example Violating Rule 1 void { } void { } isr_read_temps(void) // (reactor) OS_Pend(s); ISR Deadlock! itemperatures[0] = peripherals[..]; itemperatures[1] = peripherals[..]; OS_Post(s); main(void) interrupt OS_Pend(s); itemp[0] = itemperatures[0]; itemp[1] = itemperatures[1]; OS_Post(s); 25

12 Helping tools for rule 1 System calls that do not block Examples: Function giving the status of a semaphore Queues: use post() in ISR, use pend() in task code If queue is full, error is returned in ISR > nonblocking Task code might miss a number of elements This code works only if rule #2 is obeyed 26

13 RTOS and Interrupts Rule 2: An ISR must not call any RTOS function that might cause a context switch unless RTOS knows that it s an ISR (and not a task) that is calling no post() type calls (which is typical use!) unless RTOS knows it s an ISR No semaphore release events No writing to a queue, etc Violate this rule! RTOS will switch to other task ISR may not complete for a long time No guarantees on response time anymore 27

14 Example Violating Rule 2 void { } void { } isr_buttons(void) // (UTMS) if (peripherals[buttons] & 0x01) // button 0 OS_Post(event); // signal event vbuttontask(void) while (TRUE) { OS_Pend(event); // wait for event printf( current float levels: \n );!! list them } Context switch may block all lower priority ISRs 28

15 Example Violating Rule 2 How ISRs should work: button ISR RTOS vbuttontask vlevelstask OS_Post context switch after ISR finished What would really happen: button ISR RTOS vbuttontask vlevelstask OS_Post context switch before ISR finished! 29

16 Solution to Satisfy Rule 2 (uc/os) void { } isr_buttons(void) // (UTMS) OSIntEnter(); // warn uc/os not to reschedule if (peripherals[buttons] & 0x01) // button 0 OS_Post(event); // signal event OSIntExit(); // uc/os free to reschedule button ISR RTOS vbuttontask vlevelstask OS_Post but NO context switch Let the RTOS know an ISR is in progress by calling OSIntEnter()/OSIntExit() (uc/os) 30

17 Alternative solution Specialized functions for ISR Instead of OS_Post() use OS_ISR_Post() Not all OSes provide these alternatives 31

18 Overview Timing services RTOS and ISRs Design of embedded systems General principles

19 Overview Design of an embedded system Specify the real time system can be very difficult What must the system do? How fast should the system serve the inputs? Example: bar code scanner It must send the data to the terminal within reasonable time (fraction of a second one second) 100% guarantee can be hard A longer delay in a small amount of cases can be tolerated Choosing the right processor Example: serial port interface can we run ISR 1000 times a second? Should we go for a processor with DMA support? 34

20 Principles general operation System is in sleep state most of the time Tasks are in the blocked state waiting for events Processor may be in a low power mode ISR are active External event triggers ISR that trigger a whole series of tasks to start running When processing is done, system goes back to sleep Example: telegraph system 35

21 Principles short ISRs Short ISRs are preferred over long ISRs Lowest priority ISR runs before highest priority task Longer ISR > slower task response time ISRs exhibit more bugs/nr. lines of code ISRs are harder to debug Example: serial port communication System responds to commands coming from serial port Commands always end up with \n Commands arrive one at a time, after completion of prev. Serial port has a buffer of one character System can take a long time to respond to commands 36

22 Trade off designs Everything in the ISR Provides excellent response time for the serial port block System response for other tasks is disaster ISR for each event individual tasks for each event perfect architecture Will trigger a very low output from the processor A lot of time spent by RTOS in context switching Possible solution? 37

23 Principles how many tasks? Advantages of many tasks More tasks > usage of priority > faster system response 1 task versus 8 tasks Modularity A task for each: the display, printer, buttons, etc. More tasks > better data encapsulation Network task the only one that needs to access the HW signals 38

24 Principles how many tasks? Disadvantages of many tasks More tasks = more shared data = more semaphores More semaphore bugs and RTOS overhead More tasks = more data passed around in queues, pipes, More bugs and more RTOS overhead Each task has a stack > more memory needed General throughput smaller in a system with more tasks 39

25 Example of time constants RTOS on 20MHz Intel Get a semaphore 10 microsec. Release a semaphore 6 38 microsec. Switch tasks microsec. Write to a queue microsec. Read from a queue microsec. Create a task 158 microsec. Destroy a task microsec. 40

26 Principles task structure mytask.c!! private static data declared here void mytask(void) {!! More private data declared here!! either static either on the stack!! Initialization code here while(1) {!! wait for signal event } } switch(!! type of signal) { case!! signal type 1:... break; case!! signal type 2:... break;... }; 42

27 Create/destroy tasks Most RTOS allow dynamic tasks dynamic create/destroy Avoid this functionality Lengthy operation throughput is minimized Task destruction is dangerous Task owns a semaphore? Messages on the task input queues? What if these messages contain pointers to data that needed to be deleted by other tasks? Alternative: create all the dynamic tasks at the startup If memory is not an issue do not destroy the task! 43

28 Time slicing? Tasks with same priority > one options is to time slice Round robin scheduling Time slicing used a lot in desktops > fairness Embedded systems > timely response! Responses of all tasks with the same priority is needed Avoid time slicing Avoid having the same priority for two tasks 44

Exam TI2720-C/TI2725-C Embedded Software

Exam TI2720-C/TI2725-C Embedded Software Wednesday April 16 2014 (18.30-21.30) Koen Langendoen In order to avoid misunderstanding on the syntactical correctness of code fragments in this examination, we