James E. Lumpp (Adapted from: An Embedded Software Primer by David E. Simon)

Size: px

Start display at page:

Download "James E. Lumpp (Adapted from: An Embedded Software Primer by David E. Simon)"

Dorothy Henderson
5 years ago
Views:

1 Embedded Software Architectures James E. Lumpp (Adapted from: An Embedded Software Primer by David E. Simon)

2 Survey of Embedded Software Architectures 1. Round-Robin 2. Round-Robin with Interrupts 3. Function-Queue-Scheduling Architecture 4. Real-Time Operating System Architecture 5. Selecting an Architecture 2

3 Round-Robin The following code illustrates a round-robin where the code checks each I/O device in turn and services them as needed. 3

4 Round-Robin Example Void main (void) while(true) if(!! I/O Device A needs Service)!!Take Care of I/O Device A!!Handle data to or from I/O Device A if(!! I/O Device B needs service)!!take care of I/O Device B!!Handle data to or from I/O Device B etc. etc. if(!! I/O Device Z needs service)!!take care of I/O Device Z!!Handle data to or from I/O Device Z 4

5 Round-Robin Architecture This is the simplest architecture devoid of interrupts or shared-data concerns. However several problems arise from its simplicity: If a device has a response time constraints this architecture has problems (e.g. if in the example device Z has a deadline of 15 ms and A and B take 10 ms each.) If any one of the cases at the worst take 5 seconds, the system would have a max. response time of 5 seconds, which would make it less appealing. Architecture is not robust. Addition of a single device might cause all deadlines to be missed. 5

6 Round-Robin with Interrupts Bool fdevicea = FALSE; Bool fdeviceb = FALSE; Etc.. Void interrupt vhandledevicea (void)!!take care of I/O Device A fdevicea = TRUE; Void interrupt vhandledeviceb (void)!!take care of I/O Device B fdeviceb = TRUE; Etc. Void main(void) while(true) if(fdevicea) fdevicea = FALSE;!!Handle data to or from I/O Device A if(fdeviceb) fdeviceb = FALSE;!!Handle data to or from I/O Device B etc.. 6

7 Round-Robin with Interrupts Issues ISRs called by each device set flags. These are in turn polled by the main program which then does any required follow-up processing. ISRs can be assigned priorities giving better response, e.g., devices with hard deadlines. Shared Data is now an issue! 7

8 Round-Robin with Interrupts (cont.) The main shortcoming of this architecture is that all the task code executes with the same priority. If devices A,B and C take 200 ms, C will have to wait 400 ms. This can be avoided by moving C s task code to the ISR at the expense of increased interrupt latency of lower priority devices. 8

9 Round-Robin with Interrupts (cont.) Another solution is to check C s flag more often like A,C,B,C,D,C... The worst-case response for a device task-code occurs when the its interrupt occurs immediately after main passes its task code. Examples where this architecture does not work are A laser printer. Calculating locations for the black dots is time consuming so only ISRs will get good response. If task codes are moved into ISRs low priority interrupts will not be serviced fast enough. Underground tank monitoring system. The code that calculates the gasoline amount hogs the processor. 9

10 Function-Queue-Scheduling Architecture The ISRs add function pointers to a queue for main to call. Main can call the functions based on a preset priority providing better response times for higher priority tasks (queue functions by priorities) The worst-case response (WCR) for the highest priority task is equal to the longest task code function assuming that it started just before the ISR put the function pointer for the highest priority task in the queue. This is much better than the round-robin-with-interrupts which has a WCR equal to the sum of all the task codes for the other devices. A disadvantage of the architecture (apart from the complexity) is that a high priority task might hog the processor, and a lower priority task might never get to execute (never at the front of the queue). 10

11 Function-Queue-Scheduling Architecture!! Queue of function pointers: Void interrupt vhandledevicea(void)!!take care of I/O Device A!!Put function A on Queue of function pointers Void interrupt vhandledeviceb(void)!!take care of I/O Device B!!Put function B on Queue of function pointers Void main(void) while(true) while(!!queue of function pointers is empty) //Call first function on queue Void function_a (void) //Handle actions required by Device A Void function_b (void) //Handle actions required by device B 11

12 Real-Time Operating Systems Void interrupt vhandledevicea(void)!!take care of I/O device A!!Set signal X Void interrupt vhandledeviceb(void)!!take care of I/O Device B!!Set signal Y Void Task1 (void) while(true)!!wait for signal X!!Handle data to or from I/O Device A Void Task2 (void) while(true)!!wait for signal Y!!Handle data to or from I/O Device B 12

13 RTOS Features Again ISRs handle important sections. Some differences from previous architectures are: The real-time operating system (RTOS) handles communications between ISRs and task codes. The RTOS will decide which task code to run based on urgency (priority) RTOS can suspend a task to run another (usually higher priority) one. If an ISR sets a flag for a higher priority task the RTOS runs the task immediately on return even if it is in the middle of another lower priority one, hence the worst-case response is zero. Response is basically independent of task code length unlike previous architectures. Changes to code lengths of low priority tasks don t affect higher priority tasks. One disadvantage can be the added RTOS processing time. 13

14 Selecting an Architecture Select the simplest architecture meeting response requirements. RTOSs should be used where response requirements demand them. Hybrid architectures can be used if required. e.g. you can use an RTOS with a low-priority task polling the relatively slower hardware. Priorities: Round-robin: Everything equal Round-robin with Interrupts: Device ISRs, then all task code equal RTOS: Device ISRs, then each task has a priority 14

Bringing Organization to our Code (the shared-data problem)

Bringing Organization to our Code (the shared-data problem) Reference: An Embedded Software Primer By David E Simon (two copies in lab for checkout) Figure 44 Classic Shared-Data Problem Static int itemperatures[2];