Download Lecture 19

Design Realization
lecture 19
John Canny
10/28/03
Last time
 Sensors
This time
 Real-time programming
Threads and Processes
 A thread is a sequence of program steps that
may be executed concurrently (with other
threads).
 Threads contrast with processes, which run in
different address spaces. Threads share a
common address space.
Threads and Processes
 Inter-process communication requires file,
message or socket communication.
 Threads can communicate simply via shared
variables.
Threads in real-time code
 Threads are almost always a good idea in realtime code.
 They provide a clean way to deal with outside
events happening at different rates.
 Switching between threads can be very fast,
supporting fast event streams.
Threads and interrupts
 On a single-processor machine, the processor
executes all the threads (not true concurrency).
 Changes from one thread to another (context
switches) are triggered by hardware interrupts,
and by software (e.g. return instruction).
 Typical interrupt triggers:




Serial port send/receive buffer full (or empty).
Digital I/O pin change
A/D or D/A conversion complete
Timer interrupt
Interrupts and masks
 Interrupt masks specify what the processor
should pay attention to. You set these first then
execute an “enable interrupts” instruction.
 You can also disable interrupts while executing a
critical section of code, e.g. processing another
interrupt. But make sure to re-enable them fast
enough to catch the fastest event stream.
Interrupts and state saving
 Interrupts on small machines don’t save much
state. Perhaps only the program counter and a
status byte.
 You’re responsible for saving any variables that
are shared by the original program and the
interrupt routine.
 You should then restore these values before you
return from the interrupt.
 But check whether the compiler takes care of
this…
Interrupts vs. polling
 Sometimes an event doesn’t trigger an interrupt,
or it may not be desirable to allow a certain kind
of interrupt.
 In such cases the code can explicitly test the
condition periodically.
 This is called “polling”.
Inter-thread communication
 Usually no direct software support – implement
using semaphores in variables:
Main thread:
DataReady := 0;
// Set some data here
DataReady := 1;
Other thread:
While (! DataReady);
// Read new data
// Set DataReady := 0, or set another semaphore
Example
 Serial data to r/c control servo PIC program.
 Receives time-stamped values for two servos
over a serial port.
 Variable network delays, so data must be delayadjusted.
 Output is r/c pulse data, a kind of PWM.
r/c servo control signals
 Each servo is controlled by a pulse whose width
varies from 1-2 ms and occurs every 20 ms.
 To get 8-bit (256 levels) resolution in the pulse
width requires a temporal resolution of 1 ms/256
~ 4 s.
r/c control example
 Real-time needs: serial port data receive and r/c
pulse output.
 Delay correction requires a moving average filter
which is “math intensive”.
 Implement with 4 threads:
 Two timer threads
• One for clock updates (to resync the data)
• One for PWM updates
 One polling “thread” for serial input
 One main thread for math
 Communication with semaphores
Larger systems
 eCos: an open-source operating system for
small (PDA-sized) devices.
 Architectures: PowerPC, ARM, IA32, H8, M68K
 Component-based and configurable: only
needed modules are included.
 TCP/IP stack and USB slave support.
 Based on GNU tools, open-source, popular.
Larger systems
 VxWorks: popular but expensive real-time
operating system for many devices.
 Good suite of development tools for debugging
the running system.
 High reliability code (widely used by aerospace
and military).
Mobile systems







Symbian OS: designed for phones.
API for contacts, messaging, browsing
TCP/IP stack (?)
WAP, HTTP, SSL, XML and XHTML support.
Communication: Irda, Bluetooth, USB, Serial
POP, Imap mail support
Java VMs: personal Java and J2ME
Real-time OSes





Hard-hat Linux
Qnx
Lynx
Nucl(e)ar
Tiny-OS
Mobile systems
 Qualcomm’s BREW, aka Verizon’s “Get It Now”
 Similar features to Symbian, but allows binary
“applets” to be downloaded from the server.
 Designed for native code or native browsers,
e.g. they have Flash and SVG (2d graphics).
 Not really an OS, but a set of APIs for device
services.
Network protocol stacks
 Network software is deeply layered: e.g. TCP/IP
Bluetooth protocol stack
 Lets take a quick look at the Bluetooth stack
Software (on
microcontroller)
Bluetooth radio module
Bluetooth protocol stack
 These (core) layers are always present:
 HCI: The Host Controller Interface layer provides a standard
communications protocol between the stack and the Bluetooth
module. HCI communication packets can be transmitted using
UART, RS232 or USB interface.
 L2CAP The Logical Link Control and Adaptation Protocol layer
allows multiple channels to share a single Bluetooth link. It also
handles segmentation and assembly of long messages, group
management and quality of service functionalities.
Bluetooth protocol stack
 These core layers are always present:
 RFCOMM: The RFCOMM layer implements the functionalities of a
virtual RS232 link. Most of the application Profiles uses RFCOMM
as a means of transmitting and receiving data.
 SDP The Service Discovery Protocol layer provides functionalities to
publish supported Bluetooth functionalities (SDP server), as well as
for querying remote Bluetooth devices for supported functionalities
(SDP client).
Bluetooth protocol stack
 The higher layers implement one or more “bluetooth
profiles” with specific APIs:





Bluetooth audio
Bluetooth printing
Data access profiles (incl. TCP/IP over Bluetooth)
Information transfer profiles (calendar, contacts sync.)
Human Interface device profiles (mouse, keyboard,…)
 Overall, this is a lot of code! But many Bluetooth stack
implementations exist, including open source stacks.
E.g. BlueZ for Linux and Smart-Its for Atmel AVR chips.
CAN stack
 CAN stack is relatively simple, possibly built into
hardware.
 Another protocol
stack called Devicenet
is built on the CAN
physical layer.
Direct communication
 Note that standard protocols are designed to
allow devices to communicate with other devices
of unknown origin.
 If all your devices are configured by you, you
can bypass the protocol and use low-level
protocols directly (like RS485).