1 / 17

Embedded Software Architectures

Embedded Software Architectures. James E. Lumpp (Adapted from: An Embedded Software Primer by David E. Simon). Survey of Embedded Software Architectures. Round-Robin Round-Robin with Interrupts Function-Queue-Scheduling Architecture Real-Time Operating System Architecture

sylviab
Download Presentation

Embedded Software Architectures

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  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.

  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 } } }

  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.

  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.. } }

  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!

  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.

  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.

  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).

  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 }

  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 } } ……

  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.

  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

  15. Bridge Example Example: A Simple Bridge • A communication bridge is a simple example that passes data between 2 ports. • Assume the bridge encrypts data at one port and decrypts it at the other.

  16. Round-Robin with Interrupts (contd.) • A character received at one of the bridge links causes an interrupt that must be serviced before the next character arrives. • The link will be busy while sending a character after which it will interrupt the microprocessor to indicate it is ready for the next character. • Routines read and write characters to queues and check whether the queues is empty or not. • Encryption and decryption is handled by routines. • Transmitting and receiving characters on links A and B are handled by separate ISRs. • vEncrypt and vDecrypt in main read the data queues and pass the processed data to qDataToLinkA and qDataToLinkB. • fLinkAReadyToSend and fLinkBReadyToSend track whether I/O is ready to send characters. • Note that shared-data sections are made atomic. • As reading and writing is done in ISRs, these have higher priority than the encryption or decryption, so a sudden character burst will not cause system overruns.

More Related