Download presentation
Presentation is loading. Please wait.
1
CSE 370 - Fall 1999 - Introduction - 1 What is an Embedded Systems Its not a desktop system Fixed or semi-fixed functionality (not user programmable) Lacks some or all traditional human interfaces: screen, keyboard, pointing device, audio May have stringent real-time requirements (Hard and Soft) Usually has sensors and actuators for interface to physical world Figures of Merit Reliability – it can never crash Safety – Involves things that move and can harm/kill a person Power Consumption – may run on limited power supply. Want slowest possible clock, least amount of memory. You will always be resource constrained! Cost – Engineering Cost, Mfg Cost, Schedule tradeoffs Product life cycle issues: maintainability, upgradability, servicability Performance
2
CSE 370 - Fall 1999 - Introduction - 2 Features of an Embedded Operating System Live Without User Interface Dynamic Linking and Loading Virtual Memory, Protection Modes (Processes) Disk Device Drivers? Instead we have Low Latency Interrupts Tasks (threads) Task communication primitives Data sharing primitives Device Drivers?
3
CSE 370 - Fall 1999 - Introduction - 3 Embedded OS Features Task Scheduling/Multithreading Memory Management (Threads v. Processes) Synchronization and Communication Primitives Multitasking Overhead (Context Switch) Interrupt Latency Do Timer 1 interrupts trigger during operating system calls (? (use simulator to find out, or look at source code)
4
CSE 370 - Fall 1999 - Introduction - 4 Multitasking – state maintained for each task Running Ready BlockedDisabled time-slice wait() signal() delete() create() delete() only one task in this state at a time For TINY, this takes 100-200 cycles per update…is this okay?
5
CSE 370 - Fall 1999 - Introduction - 5 Interrupt Priorities Key question: Can Tone Generator Interrupt the OS? OS Task1 Task2 ISR Why is this important?
6
CSE 370 - Fall 1999 - Introduction - 6 Preemptive vs. Non preemptive OS T1/hi T2/lo ISR Pre-emptive: All tasks have a different priority… hi priority task can preempt low priority task. Highest priority task always runs to completion (wait). Advantage: Lower latency, faster response for high priority tasks. Disadvantage: Potential to starve a low priority task Tiny: no priority, round robin only. No starvation. signal T2 signal T1, preempt T2 T2 Completes
7
CSE 370 - Fall 1999 - Introduction - 7 Sharing Code between Tasks Shared functions are useful! deq? enq? next (same for head or tail)? Q declaration and initialization? Shared data issues What happens when one of these functions is interrupted by the OS unsigned char next(unsigned char current, unsigned char size) { if (current == size-1) return 0; else return (current+1); } it depends on where the parameters and the automatic variables are stored
8
CSE 370 - Fall 1999 - Introduction - 8 Encapsulation and Re-use typedef struct qstruct { unsigned char head; unsigned char tail; unsigned char *array; unsigned char size; } qtype; // global variable: qtype Q; void taskID(void) _task_ 0{ unsigned char d; unsigned char i; unsigned char array[QSIZE]; unsigned char x; initq(&Q, array, QSIZE); while (1) { do { ET0 = 0; x = enq(&Q,i++); ET0 = 1; } while (!x); do { ET0 = 0; x = deq(&Q,&d); ET0 = 1; } while (!x); } shared functions are okay if we disallow swapping during calls. why? re-entrant stack not protected by Tiny OS. But shared C libraries are okay. Why? not sure yet.
9
CSE 370 - Fall 1999 - Introduction - 9 Ways to Protect a Critical Section Disable Interrupts … be as specific as possible Semaphores wait() – signal() each system call is guaranteed to be atomic: wait block until the flag is set, and clears the flag before returning. signal sets the flag. most OS allow you to declare a semaphore as a data type. As many as you want. Tiny limits us to one/task, and it is used to signal the task. Therefore we use semaphores to protect shared data/critical sections. Disable task switching via a system call…about the same as disabling interrupts to the OS.
10
CSE 370 - Fall 1999 - Introduction - 10 Embedded System Types Control Dominated Systems Software State machines, state synchronization, etc … nuclear power plan Data flow dominated Systems our music player a network router queues, messages, packets, routing,
11
CSE 370 - Fall 1999 - Introduction - 11 Homework for Friday/Monday Propose what our systems should do, and a general architecture for doing it. Can we handle multiple streams to/from the pilot Can we stream music while sending a song to another player? Can we receive a tune while at the same time? What do we have to do in the system What do we have to do in the protocol with the host?
12
CSE 370 - Fall 1999 - Introduction - 12 General Binary Semaphores
13
CSE 370 - Fall 1999 - Introduction - 13 Comparative Real Time OSes Compare Tiny to Full to VxWorks
14
CSE 370 - Fall 1999 - Introduction - 14 Orchestra Functions Time of day Get data from net, send to player or to pilot Send music to net Get music from net Play music Task to play music from net Task to create/delete other tasks (master)
15
CSE 370 - Fall 1999 - Introduction - 15 Benefits
16
CSE 370 - Fall 1999 - Introduction - 16 Embedded Software Software States v. Finite State Machines Hierarchical State Thread/Process Communication Critical Sections Synchronization Messaging and Signaling
17
CSE 370 - Fall 1999 - Introduction - 17 Live without? Live Without User Interface Dynamic Linking and Loading Virtual Memory, Protection Modes Disk Processes Instead we have Real Time Kernel (very small OS) Tasks (threads) Task communication primitives ADC Timers Event Capture PWM
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.