Embedded Operating System Design
October 4, 2012
Doug Kelly
Embedded Platforms
What’s different?
• System-on-Chip (SoC) integrates components
• Storage (MNAND, NOR, SD…)
• Power requirements/management
• May have memory management (MMU)
• May have graphics processor (GPU)
• May have direct memory access (DMA)
• More specialized hardware
• Digital signal processor (DSP)
• GPS baseband processor
• Camera/imaging processor
Embedded Platforms - Processors
• ARM, MIPS, RISC…?
• ARM is RISC-based, sold as IP “blocks”
•
•
•
•
•
•
•
Core processor
Debugging coprocessor
GPU block (Mali), or 3rd-party vendors (SGX, Tegra)
Vector Floating Point (VFP)
NEON (SIMD processing architecture)
Memory management
Cache memory
• 32-bit architecture
• Three instruction sets (ARM, Thumb, Thumb2)
Embedded Platforms
• Okay, so what?
•
•
•
•
•
Floating point is not free.
Time-critical tasks need servicing
Other devices may be using memory bus
May only have physical addressing
Storage is slow, cache is limited
• Engineers need to solve this!
Operating System Design
• Emebedded OSes exist!
• Home-grown, open-source or commercial
•
•
•
•
•
•
GarminOS
WindowsCE (Windows Embedded Compact)
VxWorks
QNX
Linux (RTLinux)
eCos
• Handle scheduling by priority or round-robin
• WinCE has 256 process priorities (8 for applications) and
round-robin scheduling within a priority
Operating System Design - Memory
• RTOSes handle memory management
• Some platforms don’t have MMUs, now what?
• May not be possible to use dynamic memory
• Safest, most portable option.
• Relies on static structures within program to use as
scratch space
• Design a malloc() replacement?
• Need to mark memory in-use, so it isn’t used while
defragging memory
• Pointer to allocated memory may change, so requires
careful design
Operating System Design - Scheduling
• Threads can be used to limit impact of noncritical failures in some applications
• Priority systems guarantee most critical tasks
run when needed
• Lower priority tasks run when higher tasks are blocked in
some form (may be waiting for next event)
• But… higher priority tasks could be blocked if a
lower-priority task holds a resource!
Operating System Design - Scheduling
• Priority “inversion” temporarily raises priority
• Allows low-priority tasks to finish faster, unblocking highpriority tasks
• Control your loops/recursion!
• Some coding guidelines for embedded systems prohibit
recursion, since it can quickly go without bound or
exceed stack space.
• A high priority task stuck in a runaway loop can result in
an unresponsive or useless system.
• Watch for deadlocks!
• True in any OS, but may be catastrophic in some cases
• Some RTOSes can detect deadlocks
• Always reserve resources in the same order
Operating System Design - Interrupts
• IRQ, FIQ
• Come in many flavors
• Hardware
• External peripherals
• DMA
• Timers
• Special-purpose hardware interrupt
• Service watchdog timers, handle rescheduling, sometimes
communication
• Software
•
•
•
•
•
When good software goes bad
“Data Abort” – illegal memory access, page faults (if supported)
“Pre-fetch Abort”
“Undefined Instruction”
Division by zero, etc.
Operating System Design - Interrupts
• ISRs used to handle interrupts
• ISRs may have limitations imposed by OS,
platform, or processor technology
•
•
•
•
Timing constraints
Access to memory
IRQ may be interrupted
Must not block!
• Handling dependent on the interrupt vector
table
• Defines both exception and IRQ/FIQ handlers
• Fast and efficient is the key!
Operating System Design - IPC
• Inter-process communication used to interact
with the system at all levels
• Hardware drivers have no business updating UI state,
nor should UI touch hardware
• Can also be used to process long-running jobs
• May be simple events, or contain data
• Who owns the data?
• Which thread is the event processed on?
• When is the event processed?
• Callback functions to return control
• Boost signals/slots
• Object-Oriented Callbacks
Debugging
• JTAG
• Closest to processor, can access entire memory bus
• May be useful for saving snapshot of device state for
future analysis.
• Can also load code into RAM and reset registers (but
peripherals may not reset!)
• WinCE: KITL
• Kernel level transport, has a fair-amount of control
• Allows developer to see “into” kernel calls
• WinCE also supports Visual Studio Remote Debugging
• Linux/Other: GDB
• Can be implemented on many platforms; gdb has stubs
• Don’t rule out printf()!
Questions?
Doug Kelly
Software Engineer
doug.kelly@garmin.com