1 / 26

Design Realization 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).

marycjones
Download Presentation

Design Realization lecture 19

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Realization lecture 19 John Canny 10/28/03

  2. Last time • Sensors

  3. This time • Real-time programming

  4. 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.

  5. Threads and Processes • Inter-process communication requires file, message or socket communication. • Threads can communicate simply via shared variables.

  6. Threads in real-time code • Threads are almost always a good idea in real-time 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.

  7. 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

  8. 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.

  9. 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…

  10. 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”.

  11. 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

  12. 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 delay-adjusted. • Output is r/c pulse data, a kind of PWM.

  13. 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.

  14. 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

  15. 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.

  16. 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).

  17. 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

  18. Real-time OSes • Hard-hat Linux • Qnx • Lynx • Nucl(e)ar • Tiny-OS

  19. 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.

  20. Network protocol stacks • Network software is deeply layered: e.g. TCP/IP

  21. Bluetooth protocol stack • Lets take a quick look at the Bluetooth stack Software (on microcontroller) Bluetooth radio module

  22. 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.

  23. 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).

  24. 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.

  25. CAN stack • CAN stack is relatively simple, possibly built into hardware. • Another protocol stack called Devicenetis built on the CANphysical layer.

  26. 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).

More Related