Design Realization lecture 19 John Canny 102803 Last

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: Data. Ready : = 0; // Set some data here Data. Ready : = 1; Other thread: While (! Data. Ready); // Read new data // Set Data. Ready : = 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 § e. Cos: an open-source operating system for small (PDA-sized) devices. § Architectures: Power. PC, ARM, IA 32, H 8, M 68 K § 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 § Vx. Works: 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 J 2 ME

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 (2 d 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, RS 232 or USB interface. § L 2 CAP 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 RS 232 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. Blue. Z 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 RS 485).