Embedded Software Architectures

1. Embedded Software Architectures • No Operating System • Round robin: sequential polling for events • Round robin w/ interrupts • Function Queue Scheduling • Real Time Operating Systems

2. Overall Architecture Serial ISR PC Main Tone ISR

3. FIFO Queue • Main • If (not empty) get item, move “tail” pointerelse what? • Serial ISR • If (not full) put item, move “head” pointer, and acknowledge received byteelse what? • When writing this code: • Think of ISR and MAIN are parallel processes running on separate computers using shared memory to communicate: why?

4. FIFO • Empty Condition • Tail = Head • Tail is place to get next byte if != head • Initial Condition • Same as empty condition • Full Condition • Head = (Tail –1) • Head is place to put next byte if not right behind tail

5. Example • Queue size is SIZE • In main while (1) { while (head == tail); // wait until queue not empty data = queue[tail]; tail = tail + 1 if (tail == SIZE) tail = 0; process(data); } • Do we have a problem? • Solution?

6. Safe Queue? • while (1) { • while (head == tail); // wait until queue not empty • data = queue[tail]; • ES = 0; // disable serial interrupts • tail = next(tail); • ES = 1 // enable serial interrupts • process(data); • } • unsigned char next(unsigned char ptr) { • if (++ptr == SIZE) ptr = 0; • return(ptr); • }

7. Consider the compiler Compiler output? MOV R0,TAIL MOV R1,HEAD LOOP: MOV A,R1 SUBB A,R0 JZ LOOP MOV R3,#QUEUE ADD R3,R0 MOV R4, @R3 CLR ET0 ACALL NEXT MOV TAIL,A SETB ET0 C code for blocking queue while (1) { while (head == tail); // wait until queue not empty data = queue[tail]; ES = 0; // disable serial interrupts tail = next(tail); ES = 1 // enable serial interrupts process(data); } unsigned char next(unsigned char ptr) { if (++ptr == SIZE) ptr = 0; return(ptr); } Assume next() operates on R0, returns in A

8. I think we’re safe now MOV R0,TAIL LOOP: MOV R1,HEAD MOV A,R1 SUBB A,R0 JZ LOOP MOV R3,#QUEUE ADD R3,R0 MOV R4, @R3 CLR ET0 ACALL NEXT MOV TAIL,A SETB ET0 volatile data unsigned char head; … while (1) { while (head == tail); data = queue[tail]; ES = 0; tail = next(tail); ES = 1 process(data); } unsigned char next(unsigned char ptr) { if (++ptr == SIZE) ptr = 0; return(ptr); } *compiler knows that sfr’s are volatile (ports, flags)

9. M-BOX in Round Robin Arch. void main (void) { if (TF0) music_task(); // process timer overflow if (R1) serial_input_task(); // process serial input } Would this work for the M-BOX? How do we know?

10. Task Diagram Worst case: character arrives one cycle before TF0 Worst Case Latency = max run time of all other tasks main serial task serial music main w.c. latency deadline What is the worst case serial processing time? Depends on response message length--could be bad! How much latency can we tolerate? Practically none timer0 overflow occurs (TF0) char arrives

11. Round Robin w/ Interrupts volatile bit fEvent; void isr(void) { time_critical_processing(); fEvent = TRUE; } void main (void) { if (R1) serial_input_task(); if (fEvent) { housekeeping(); fEvent = FALSE; } } Why not put housekeeping into the ISR too? Then our worst case latency to a separate time critical event would be poor Would this work for the M-BOX? See next slide

12. What are the time critical functions?Flipping channels, change tones at end of timeslice What are the housekeeping functions? TNE count down and stream processing (TNE, Tones) Do these have hard time constraints too? Yes, one time slice (18ms)…good enough? Not necessarily…serial is undefined! M-BOX in RR+INT volatile bit fEndOfSlice, fSerial; void isr(void) interrupt … { process_tones(); if (!--sliceCount) { changeTones(); sliceCount = SliceSize fEndOfSlice = TRUE; } } void serial(void) interrupt …{ timeCritical(); fSerial = TRUE; } main () { if (fSerial) {process_serial_data(); fSerial = FALSE;} if (fEndOfSlice) { if (--TNE==0) process_next_event(); fEndOfSlice = FALSE; } }

13. Task Diagram Worst case analysis: character comes one cycle before TF0 Worst case latency: Sum of max of all task functions. Advantage over RR: Critical Stuff happens in ISR time slice start time slice end serial_isr isr serial housekeeping main deadline timer0 overflow occurs (TF0) char arrives Can we do better?

14. What isthe advantage of this? Programmer can set priority for task functions. Worst case latency for priority n task function? Sum of max execution time for all task functions of priority > n + max current task Function Queue void isr(void) interrupt … { process_tones(); if (!--sliceCount) { changeTones(); sliceCount = SliceSize; enq(process_time_slice); } } void serial(void) interrupt …{ SerialTimeCritical(); enq(process_serial_data); } void main(void) { while (1) if (f = deq()) { *f()); } You get a scheduling opportunity every time a task completes.

15. Task Diagram Worst case analysis: character comes one cycle before TF0 Worst case latency: Sum of max of all task functions. Advantage over RR: Task functions can have easier deadlines time slice start time slice end serial_isr isr serial housekeeping main deadline timer0 overflow occurs (TF0) char arrives Can we do better?

16. Comparison Non OS Architectures • See Chapter 5, table 5.1 Simon

17. Real Time Operating Systems • What is the basic thing we want the OS to do to help us improve worst case latency? Enable multithreading • How? Define an OS time-slice (tick) at which highest priority ‘runnable’ task is continued. Priority function determines response behavior. • Simplest Scheduling algorithm: each task gets at most 1 tick at a time to run. Round Robin Scheduling. Worst case task latency = #tasks*tick. Worst case run time = ticks/task * #tasks • Some properties of such system: liveness, safety, fairness, latency, overhead. • Other niceties: Device Drivers, Synchronization, Message passing, Memory Management

18. Programmers View • Advantages: • Deterministic response time even w/ non deterministic tasks lengths. • Incremental development • Resources: • Task switching overhead • Memory overhead • Use of system timer • Degrades best case response time. void tone_isr(void) interrupt … { process_tones(); if (!--sliceCount) { changeTones(); sliceCount = SliceSize isr_send_signal(MUSIC); } } void serial_isr(void) interrupt …{ timeCritical(); os_send_signal(SERIAL); } void play(void) _task_ MUSIC { os_create(SERIAL); while (1) {os_wait(); process_next_event();} } void serial(void) _task_ SERIAL { while (1) {os_wait(); process_serial_data();} // os_create(MUSIC)? } Tasks are threads

19. Another Solution • Multiprocessor: Dedicate one processor to each (or a few) tasks. • Still need synchronization and communication. • Our player network could be an example of a multiprocessor system