Transcript ppt
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
CSE 370 - Fall 1999 - Introduction - 1
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?
CSE 370 - Fall 1999 - Introduction - 2
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)
CSE 370 - Fall 1999 - Introduction - 3
Multitasking – state maintained for each task
time-slice
only
Running
one task
in this state
at a time
wait()
signal()
Blocked
Ready
time-slice
delete()
delete()
create()
Disabled
For TINY, this takes 100-200 cycles per update…is this okay?
CSE 370 - Fall 1999 - Introduction - 4
Interrupt Priorities
Key question: Can Tone Generator Interrupt the OS?
ISR
Task2
Task1
OS
Why is this important?
CSE 370 - Fall 1999 - Introduction - 5
Preemptive vs. Non preemptive
ISR
T2/lo
signal T2 signal T1, preempt T2
T2 Completes
T1/hi
OS
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.
CSE 370 - Fall 1999 - Introduction - 6
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
CSE 370 - Fall 1999 - Introduction - 7
Encapsulation and Re-use
// global variable:
typedef struct qstruct {
qtype Q;
unsigned char head;
void taskID(void) _task_ 0{
unsigned char tail;
unsigned char d;
unsigned char *array;
unsigned char i;
unsigned char size;
unsigned char array[QSIZE];
} qtype;
unsigned char x;
initq(&Q, array, QSIZE);
while (1) {
shared functions are okay if
do { ET0 = 0;
we disallow swapping
x = enq(&Q,i++);
during calls.
ET0 = 1;
} while (!x);
why? re-entrant stack not
do { ET0 = 0;
protected by Tiny OS.
x = deq(&Q,&d);
But shared C libraries are
ET0 = 1;
} while (!x);
okay. Why? not sure yet.
}
}
CSE 370 - Fall 1999 - Introduction - 8
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.
CSE 370 - Fall 1999 - Introduction - 9
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,
CSE 370 - Fall 1999 - Introduction - 10
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?
CSE 370 - Fall 1999 - Introduction - 11
General Binary Semaphores
CSE 370 - Fall 1999 - Introduction - 12
Comparative Real Time OSes
Compare Tiny to Full to VxWorks
CSE 370 - Fall 1999 - Introduction - 13
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)
CSE 370 - Fall 1999 - Introduction - 14
Benefits
CSE 370 - Fall 1999 - Introduction - 15
Embedded Software
Software States v. Finite State Machines
Hierarchical State
Thread/Process Communication
Critical Sections
Synchronization
Messaging and Signaling
CSE 370 - Fall 1999 - Introduction - 16
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
CSE 370 - Fall 1999 - Introduction - 17