Lecture 19 - PowerPoint Presentation

Document Sample
Lecture 19 - PowerPoint Presentation Powered By Docstoc
					Design Realization
    lecture 19

    John Canny
            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 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
        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.
             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
       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
            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
 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-

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

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