MSD Project P10236:Configurable Control Platform for Unmanned Vehicles

Joe PinzoneRob GhildutaAlex MykytaJason StanislawskiRoberto Stolfa

System Overview and Nomenclature

The final control platform consists of three physically separable modules.:

Control Code Processor (CCP)

The control code processor contains a general-purpose processor and DSP processor combination. This module stores and executes control code generated and compiled from a Simulink model. On-board flash, RAM, and power management make this module a stand-alone processor. A high-speed serial bus is used to transfer control outputs and sensory information between the CCP and the Input/Output Controller.

Input / Output Controller (IOC)

The Input/Output Controller (IOC) arbitrates all sensor and actuator input/output streams, while simultaneously transmitting sensory data and receiving control output data from the CCP. This module is implemented on an FPGA and implements a highly parallelized architecture in order to maximize data throughput. Two I/O headers are provided (analog and digital) to connect to the I/O Breakout board.

Input / Output Breakout Board (IOB)

The IOB is a platform-specific hardware box which is designed to break the IOC header out to the vehicle sensors and actuators. This box is physically separate from the main control platform, since it is infeasible to be compatible with the slew of connectors available on the market straight off of the IOC. The RIT UAV IOB has been designed during P10236 in order to demonstrate the full system and perform full-system functional tests.

Other nomenclature as used in this document:

Firmware: Program code that runs on the embedded processors. This does not include the Control Code, which will always be referred to specifically.

Rigidware: The HDL containing the “image” of the FPGA gate configuration. This may contain RAM/ROM initialization images and basic boot loader to initialize and load the stored firmware. This term generally pertains only to the IOC, since it is the only programmable-logic device in the system.

Software: Any program that runs on the user PC for the purpose of programming, configuring, compiling, or monitoring the embedded system.

The image below is a CAD draft of the physical system layout. Note that each sub-system is truly physically separable. The three main boards (CCP, IOC, Power) will be contained in one box, which will have the appropriate connectors for power, programming, and connections to the I/O Breakout Board, which will be contained in its own box.

1. Power BoardThere are three subsystems requiring power. The Control Code Processor (CCP), the Input/Output Controller (IOC), and the Input/Output Breakout board (UAV_IOB). Table (1.1) below shows the power requirements for each electronic component, organized by sub-system.

Device / System Vmin Vnom Vmax Imax (A) Pmax (W)           

Control Code Processor          CCP (Gumstix = OMAP + PM) 3.2 4 4.5 0.4 1.6

I/O Controller          FPGA VCC INT 1.14 1.2 1.26 0.088 0.1056FPGA VCC AUX 2.375 2.5 2.625 0.045 0.1125FPGA VCC I/O 3 3.3 3.75 0.008 0.0264ADC IC 4.75 5 5.25 0.05 0.25USB > SERIAL CONVERTER 3 3.3 3.6 0.145 0.4785FLASH IC 2.7 3.3 3.6 0.025 0.0825FPGA CONFIG IC 1.8 3.3 3.6 0.02 0.066SD CARD   3.3   0.025 0.0825Oscillators (2) 3 3.3 3.6 0.04 0.132EEPROM for USB > SERIAL 1.8 3.3 5.5 0.002 0.0066DAC 4.5 5 5.5 0.0014 0.007Voltage Translators (x8) 1.2 3.3 3.6 0.000032 0.0001056           UAV I/O Breakout Board          

IMU 4.75 5 5.25 0.057 0.285GPS 3 3.3 3.6 0.057 0.1881Dual Pressure Sensor 4.75 5 5.25 0.01 0.05Thermistor   5 5 0.000015 0.000075IO Multiplexor 2 5 6 0.00016 0.0008Single Pressure Sensor 4.75 5 5.25 0.01 0.05           

TOTAL CCP + IOC 0.849432 2.9497056

TOTAL UAV_IOB 0.134175 0.573975

OVERALL TOTAL 0.983607 3.5236806

Supply Voltage 4.8 V 0.734100125 Ideal Batt. CurentEfficiency 80% 0.917625156 Battery CurrentSource Energy 2.7 A-h 2.942377922 Battery Life (hrs)

Table 1.1: Detailed Power Requirements

From Table (1.1), the power system requirements are condensed into Table (1.2), showing the necessary voltage rails, maximum current for each rail, and overall system power consumption.

VOLTAGE RAIL MAX CURRENT (AMPS) POWER REQUIRED (W)

1.2V 0.088 0.106

2.5V 0.045 0.113

3.3V 0.322 1.063

4.0V 0.400 1.600

5.0V 0.129 0.643Table 1.2: Power Requirement Summary

Part of the desires for the future of this product includes the use of alternative energy sources. For this first iteration, we assume to use a standard COTS hobby receiver power pack for our main power source. The pack consists of four, series-connected nickel-metal-hydride cells. The voltage range of the battery pack (full discharged to fully charged) is 4.6-5.8V.

In order to accommodate the need for a 5V rail across the voltage range of the battery while still maintaining power efficiency, a step-up/down switched-mode power module will be used for the front end of the power chain. To reduce output power ripple and eliminate the more demanding design effort required for five independent switched-mode regulators, low-dropout linear regulators are used between the front-end switched-mode converter and the electronics themselves. If time permits, a second revision replacing the LDO regulators with SM regulators will be developed, tested, and swapped in to the final product.

The Texas Instruments TPS43000 Multi-Topology High-Frequency PWM Controller will be used in SEPIC configuration for the front-end power conditioning. This IC permits the use of external MOSFET switches, which will allow for the controlling high-current outputs. With an input voltage range of 1.8-9.0VDC the TPS43000 is compatible with the 4-cell Ni-MH pack, and provides input voltage flexibility for use with future possible power sources in that voltage range.

It is notable that in general the power needs for the I/O breakout board is variable, and therefore it is unreasonable to assume that the IOC interface will provide all of the power needs for the breakout board. However, since the majority of the I/O sensing peripherals used in mobile applications are relatively low-power and require no more than 5V, the IOC interface will provide access to the 5V/250mA power bus which can be regulated however the break-out board designer desires. In the event that peripherals on the I/O breakout board require higher power, a separate power source will have to be provided.

The following diagram shows the schematic for the TPS43000 SEPIC power system.

Figure 1.1: 5v Output Boost Topology[Source: TPS43000 Datasheet]

This schematic is based on a model given in the design doc of the TPS43000 IC. The parts and values shown are the actual values to be used. The calculations for these components are based on equations contained in the TPS43000 data sheet, as well as a design guide titled “Designing DC/DC converters based on SEPIC topology” By Jeff Falin, Senior Applications Engineer for Texas Instruments.

To reduce redundancy, the equations will not be copied in this document. Instead, the original documents are available for download directly from the P10236 EDGE space, or from the Texas Instruments server - using the following links:

http://www.ti.com/lit/gpn/tps43000

http://focus.ti.com/lit/an/slyt309/slyt309.pdf

Figure 1.2: Power System Layout

It is also notable that switched-mode power noise may pose a problem for the system. A thin mu-metal shield box will be built around the power electronics to prevent EM leaks from the power unit. Output filter capacitors will be used on each LDO output before being sent out to the other modules through the power header.

TPS43000-Based

SW-MODE PSU

OUTPUT 5V/1.5A

5V/0.25A

4V/0.5A

3.3V/0.5A

2.5V/0.1A

1.2V/0.1A

IOB, ADC, DAC

CCP

IOCBattery Pack

2. Input/Output Controller Module

Introduction:The Input/Output Controller (IOC) is responsible for bridging the gap between the various sensory and control peripherals to be used in the vehicle and the Control Code Processor (CCP). The IOC is designed to be capable of communicating with a wide variety of peripherals, logging data, and making data available to the CCP for use during execution of the Simulink-generated control code.

Using a dedicated, FPGA-implemented I/O controller module offloads the task of I/O arbitration from the CCP and offers parallelization of the I/O flow, thus improving control and I/O throughput. Physical and functional modularization also allows the IOC to be disconnected from, or operated independently of the P10236 CCP. This means that the IOC can operate as a standalone data logger and arbiter, or be connected to any a future revision of the CCP assuming the same interface.

Hardware:The IOC is to be implemented using a Xilinx Spartan 3E FPGA as the backbone for peripheral control. The Spartan 3E family of FPGAs is chosen because of its relative ease of implementation and competitive price. The XCS500E-PQ208 offers the highest pin count and highest logic size without the requirement of a Ball Grid Array (BGA) package. Use of a BGA package is avoided due to routing difficulties and the inherent requirement of a circuit board with more than 4 copper layers.

Figure 2.1 shows an overview of the IOC hardware and electrical connections. The FPGA is provided two system clocks for internal use. The 50 MHz clock is provided for the internal time reference as well as all processor control. A second 14.7456 MHz clock is provided for convenient conversion to a wide range of common serial transmission baud rates. The remaining hardware subsystems are described in further detail in the following sections.

Figure 2.1: Overview of IOC Hardware

Digital IOThe digital IO ports on the IOC are organized in groups of 8 signals similar to typical microcontroller IO banks. Two of these groups are dedicated solely to reading and generating Pulse Width Modulated (PWM) signals for servo actuator control. It is beneficial to be able to read PWM inputs from sources like a hobby radio because a user may want to record manual control inputs, or implement a control mixer as part of their control code.

The remaining groupings of digital IO are general-purpose, bi-directional banks. Each signal is fed through a TXB0108 voltage translator. This IC is capable of translating the 3.3v FPGA bank levels to a custom logic level (up to 5v) set by the user-provided voltage reference through the ‘Bank Vref’ pin. Each bank can be separately configured to operate at a different voltage level. In addition, the bi-directional voltage translator ICs are capable of automatically detecting the direction of the signal drive, and therefore do not require any signal direction information.

For the MAV set of peripherals to be used, only one of the general-purpose, bi-directional banks are required. A target of 5 digital I/O banks (not including PWM) is planned (if the FPGA has logical space) for the final implementation of the IOC, which will allow for implementation in larger systems in the future.

Analog InputsThe IOC is designed to accept up to 8 differential analog inputs. A differential, 16-bit, 8-channel ADC (ADS1178) is used for this purpose. As shown in Figure 2.1, the ADC is shown side by side with an 8-bit DAC. The DAC is used to generate the full-scale voltage reference for the ADC, allowing the user to define the dynamic range of each analog channel, thus maximizing the use of the 16-bit digital range of the ADC.

The analog signal inputs are grouped into a separate analog connector to the I/O breakout board. This connection is to be physically separated from the digital signals in order to avoid analog signal corruption.

SD/MMC CardAlong with the provided I/O peripheral interfaces, the IOC board includes a socket for a standard SD card. Communication to the SD card is done using a standard MMC mode over the SPI protocol. The SD card’s primary function is to provide non-volatile removable storage for data and event logging purposes. Since the FLASH is only used during boot time, The SD card is chained on the same SPI bus as the SPI FLASH module. This chain conserves pins on the FPGA as well as logic that would otherwise need to be used to implement a second SPI module.

Rigidware:Figure 2.2 shows a detailed overview of the rigidware within the FPGA. At the center of the diagram is the “Plasma core”. The Plasma core is an open source HDL implementation of a MIPS-I 32-bit processor. This core is chosen because it is open source and can be manipulated to suit the needs of the IOC. Compared to other free controller cores, it provides good documentation and provides an easy to use tool chain for compiling program code.

Outside of the CPU are several peripherals that are mapped to the Plasma core’s address space. This includes approximately 40kB of block RAM that resides within the FPGA, as well as 1kB of dual port RAM. The dual port RAM provides the CCP unrestricted access to part of the IOC’s address space without interrupting the IOC’s operation. The remaining peripherals are discussed in further detail in the following sections.

Figure 2.2: FPGA Logic Overview

Dedicated Peripheral Controllers:Two of the IOC’s peripheral controllers are dedicated as ADC and PWM Controllers. The ADC controller is responsible solely for acquisition of data from the analog hardware outside of the FPGA. This includes the task of setting the DAC voltage reference and acquiring channel data from the ADC. The resulting conversion values are stored in registers in Plasma’s address space. This allows the CPU firmware to access and transfer analog data without consuming time in firmware to control communication.

The PWM input and output controllers work similarly to the analog controller. For PWM outputs, all that is necessary to move the connected servo is to write an 8-bit value is a register in the PWM Generator. The PWM reader is responsible for calculating the duty cycle of the input and placing that result in an 8-bit register in the CPU address space. This configuration allows PWM control to be performed without the need for firmware intervention.

Configurable IO Ports:The remaining peripherals in Figure 2.2 are multiple instances of configurable I/O ports. Each IO port is responsible for controlling eight (8) bi-directional signals for multipurpose use. Each of the 8 signals can either be configured to be a general-purpose input, output, or to perform a special function. Special functions include the ability to communicate using SPI, I2C or asynchronous serial (UART). When configured as a special function, that signal becomes connected to the respective communications controller. Figure 2.3 illustrates the operation of each configurable I/O port. Each port function can be configured using a control register in the Plasma address space.

Figure 2.3: Detail of Configurable IO Port

Programming InterfaceIn order to configure the IOC, a few steps need to be taken to load the FPGA with its rigidware, and the Plasma core with its firmware. The FPGA rigidware is programmed by connecting a JTAG programmer to a header on the IOC bard and uploading a bit-stream to configure the FPGA. Instead of directly configuring the FPGA with the bit-stream, the rigidware is saved in an onboard configuration IC. This allows for the previous bit-stream to be loaded into the FPGA during every power up without the need to reprogram via JTAG. The rigidware includes partially initialized RAM, to which a small boot loader is programmed to load the firmware for the IOC (containing configuration registers for the IOC peripheral interfaces and drivers for the serial device protocols). Because the rigidware configuration and boot loader will not need to change, re-synthesis of the FPGA rigidware is

unnecessary for the end-user, and will only change during development. Encouraging users to only change the firmware results in a faster turn around time between system updates.

The boot loader is executed at each power up of the FPGA, and is responsible for initializing the rest of the RAM with the current application’s I/O control code. During normal operation, this code is stored on an onboard SPI FLASH IC shown in Figure 2.1. At power up, the boot loader checks the FLASH for an available program and loads it into memory. The boot loader is also capable of reprogramming the FLASH with new program code. This program code is sent to the IOC via the USB interface. A dual USB to UART converter IC is provided on the IOC board to enable easy programming. [The second UART channel on the USB converter IC is routed straight to the CCP for configuration of that device. The dual UART IC eliminates the need for the user to switch physical plugs during configuration of the two devices.]

CCP InterfaceIn order to take full advantage of using separate I/O control and control code processing systems, a shared dual-port memory block is used for part of the IOC memory space. This allows the IOC and CCP to access the same memory space simultaneously, enabling efficient, bi-directional data transfer between the two systems. The interface between the CCP and IOC is a high speed serial bus similar to SPI, where the CCP is the master device. Using this interface, the CCP can request a read or write to specific addresses in the shared RAM. As suggested in Figure 2.1, extra pins and signals are reserved for the future possibility of changing this interface to a higher speed parallel GPMC bus if the CCP hardware can support that protocol in the future.

Analysis:

Logic Cost EstimationTable 2.1 shows an itemized breakdown of major components within the IOC rigidware and amount of look-up tables (LUT) used. Using this information, it is possible to conclude that implementing up to 5 configurable IO ports is reasonable for the logic constraints of the FPGA selected. The remaining logic (~20%) is left unused in order to facilitate uncertainties in estimations.

Plasma CoreTotal (LUT) 2-Stage CPU Fixed UART Misc.3306 2705 101 500

High Speed Serial ControllerTotal (LUT)300

PWM IO ControllerTotal (LUT)300

Analog ControllerTotal (LUT) SPI Control Logic230 130 100

Configurable IO PortTotal (LUT) SPI I2C UART Port Config. Logic710 130 230 150 200

Number of IO Ports: 5Total LUTs Used: 7686 (82.5%)Available LUTs 9312Remaining LUTs 1626

Table 2.1: Logic Cost Estimates for Rigidware Subsystems

Throughput EstimationIn order to have confidence in the feasibility of the IOC controller, a basic sampling throughput experiment is conducted using the standard MAV peripheral set as a model. Using information about the protocols used to communicate to the peripherals, a simple dummy program is written that emulates a sampling iteration.

Since the PWM and analog inputs are designed to place resulting values in the memory space, a simple move instruction for each parameter is required. Similarly for PWM outputs, a memory-memory move instruction is performed for each channel. For the IMU, each parameter is read from the device by writing a command word and reading the resulting word. Since the SPI protocol of the IMU can operate

at up to 2MHz and each parameter can be passed in 32 clock cycles, the time that the CPU must wait can also be computed. It is determined that each sampling iteration can be performed in approximately 140 clock cycles at 25 MHz. Since the actual control program is likely to have more complex flow control instructions, the value of 140 cycles is tripled as a safety margin. Combining these values results in a theoretical maximum sampling rate of approximately 30 kHz, which is well over the target of 4 kHz.

It is possible that the sampling speed can be improved further since the actual implementation will use interrupts to control peripherals, allowing more efficient multitasking.

3. I/O Breakout Board

Description:The I/O breakout board (IOB) will be used to break out the IOC I/O connector to the vehicle-specific sensors and actuator circuitry or connectors. This module will be unique for each vehicle application, and connects to the I/O Controller (IOC) through two external headers (Analog and Digital). A typical IOB may include connections for analog sensors, headers for PWM signal outputs, inertial/spatial sensors on an SPI or I2C bus, etc, and route these signals to the IOC / IOB header.

Although normally it will be up to the vehicle engineers to make this board, an IOB will be designed and manufactured so that the entire system can be tested and verified to be working properly. In the case of the UAV, the IOB will connect sensors used for the acquisition of flight parameters such as altitude, pressure, temperature, and position. The UAV IOB will also break out PWM I/O in order to control the UAV control servos.

The basic set of sensors to be included on the UAV IOB is listed in Table 3.2.

DEVICE LIST FOR UAV IOBAnalog Devices IMU Tyco Electronics GPSAirspeed Differential Pressure SensorAltimeter Absolute Pressure SensorThermistorTable 3.2: List of Sensors to be included on UAV IOB

The P10236 system will need to be installed in a vehicle whose sensors and actuators are permanently mounted. As a result, it is necessary to allow the IOB to be easily and readily disconnected from the sensors and actuators. To meet this need, the servo outputs and receiver inputs will connect via header pins on the sides of the IOB box. The pressure sensor tubes will protrude from the sides of the box and connect to the sensor tubes with a coupler. This configuration allows the IOB to be completely disconnected and removed from the vehicle without the need to remove the vehicles electronics.

Analog Peripherals:The I/O Controller provides eight 16-bit, differential ADC inputs. The full-scale reference voltage can be set for each input using a programmable 8-bit DAC, which generates the full-scale reference voltage for the ADC. The ADC channels have the following interface requirements:

Diff V_IN max. ( V+) - ( V-) +/- 3.1 V

V_IN max. V+ or V- 5.1 V

V_IN min. V+ or V- - 0.1V

In order to meet the input requirements, any analog output whose voltage may exceed 5.1 volts, or whose full-scale span is greater than 3.1V must be divided down before connection to the ADC. The absolute minimum voltage of -0.1V will be met by using the analog ground provided by the IOC as the negative-most potential of the sensor ICs.

In order to take full advantage of the digital range of the ADC (both + and – differential voltages), the V- input shall be the median output voltage. This V- reference is generated (in this implementation) through the use of a voltage divider network from a 5V source.

For example. An analog sensor with an output range of 3-5.5V must first divide the output by 1.1 in order to meet the absolute voltage limit of the ADC. The output full-scale range then becomes 2.72 – 5V, with the median output being (5 + 2.72)/2 = 3.86V. A 3.86V reference signal would be generated by a voltage divider network from a 5V source and fed to the V- input of the ADC. With a differential range of +/- 1.14V relative to V-, the DAC would be programmed provide 1.14V as the full-scale differential reference voltage to the ADC, therefore maximizing the accuracy of the digital conversion.

Airspeed Sensor: (already meets all spec for ADC connection, no scaling necessary)

(4.7V + .2V)/2 = 2.45V = V-

Altitude Sensor: (already meets all spec for ADC connection, no scaling necessary)

( 4.5V + .5V)/2 = 2.5V = V-

Temperature:

The output voltage values for temperature need to be determined before calculating Vin-. These maximum and minimum voltages were calculated by finding the thermistor resistance at the two extreme operating temperatures and then calculating the output voltage of the thermistor voltage divider circuit. A formula for determining thermistor resistor is given in the components datasheet. Assume a 5V input and a 10k resistor for the voltage divider (the recommended setup). Ω

Temperature(⁰C) Resistance Vout-80 3.58MΩ 4.986 V120 481Ω 0.229 VTable 3.3: Operating temperature characteristics

Therefore…

(4.986V + .229V) / 2 = 2.493V = V-

For circuit simplicity, a voltage of 2.5V will be used as V- for all three analog sensors.

Next, the full-scale differential reference voltage must be calculated. Vref is calculated by halving the full scale span of each sensor (from data sheets). The full scale span is the difference between maximum output voltage and minimum output voltage. Each sensor will have its own reference voltage for A/D conversion, set by the DAC onboard the IOC when conversion is taking place.

Sensor VrefAltimeter 2.25VAir Pressure 2.0VTemperature 2.38V

Table 3.4: Vref for each sensor (calculated by (Full Scale Span)/2)

Digital PeripheralsThe UAV IOB will contain two digital peripherals, the GPS and IMU (inertial measurement unit). The protocols required are UART (NMEA) and SPI, respectively. Since the IOC supports these protocols by design, the IOB only need route the digital signals to the corresponding pins on the Digital I/O header to the IOC.

Telemetry Interface Spec:The telemetry module will be connected as another digital I/O peripheral directly to the IOC through the IOB header. The telemetry system is therefore required to use SPI, I2C, or a UART protocol in order to transfer data to/from the system. The UAV IOB will provide a standard header outside the case for this purpose.

Manual Override:A manual override will be provided in case of control system failure or some other need for manual control of the vehicle. This override will be implemented through the use of two, quad 2-to-1 MUX ICs, switched by one of the spare receiver channels on the R/C receiver. The MUX is powered by the RX system battery, making it impervious to control system power failures.

External Interface:The CCP/IOC and IOB boxes will be standard aluminum (or similar) project boxes. An area inside the plane will be fitted with a mounting plate spanning the available area. The project boxes and plate can be drilled in any desired configuration, and attached via nut and bolt. This provides mounting flexibility to the aircraft for CG adjustments, while still providing firm attachment to the aircraft.

NOTE: TELEMETRY CONNECTOR AND ROUTED MUX SWITCH SIGNAL NOT SHOWN

Figure 3.2: IO Breakout Board Schematic

Packaging:The IOB case in will be an off the shelf project box. The appropriate holes will be cut to fit the selected connectors and sensors. This will allow for greater flexibility in IOB layout rather than selecting a box with predetermined connector locations and other such requirements. Connectors have not all been specified yet, but distributors have been bookmarked and lead times have been researched so any risk due to this selection has been mitigated.

The connectors for the (8) servo outputs and (8) receiver inputs will be 3 row, 24 position right angle Molex connectors. Each of the 16 columns will contain one ground, one power and one signal line. The pressure sensor tubes will have couplings on the ends in order to allow connection without disassembling the box.

4. Control Code Processor

Hardware:To satisfy the control system processor’s needed capabilities, especially numerical throughput, it was decided that a solution implementing TI DSPs would be optimal. After comparing and contrasting between various manufacturers and model numbers, the OMAP “Application Processor” was selected. The processor is a fusion between a general-purpose processor and a high-throughput DSP. Despite its voluminous feature set, the OMAP is a very low-power chip, making it suitable for use in battery-powered applications.

To mitigate possible risks, an incremental design approach is adopted. It is planned that each completed revision will be capable of meeting the customer’s needs. For the initial revision, an off-the-shelf Gumstix board will be used. Future revisions can incorporate improvements such as upgrading the IOC interface, using lower power modules, and reducing layout area.

The Gumstix board is a ready to run, out of the box solution for the OMAP processor. The board features on-board expansion slots that allow for simple and straightforward interfacing with the I/O controller. The board contains all of the necessary power management, RAM, and FLASH resources needed, and therefore only a very small number of pins must be routed in order to function properly; specifically, power and IOC interface pins.

Architecturally, the system relies on a separate I/O controller (IOC) to acquire and transmit control data with the system peripherals. An obvious interface requirement exists between the two devices. In order to avoid throughput-limiting communication techniques (such as polling or interrupting), the ideal interface is either DMA, or a memory controller interface. Unfortunately, the Gumstix board does not break out all of the OMAP pins. Specifically, the board lacks sys_ndmareq[1:4] pins, making it infeasible to implement a complete GPMC (General-purpose Memory Controller) interface to talk to the I/O controller, which is the highest throughput bus the OMAP supports and the ideal interface solution. Instead, a McBSP (Multi-channel Buffered Serial Port) will be used for the CCP/IOC interface. Although slower than the GPMC interface, McBSP is highly configurable and still provides ample bandwidth for this application. According to Texas Instruments' "OMAP35x Applications Processor Technical Reference Manual", the OMAP supports full-duplex, twin-channel, asynchronous, high-speed serial communication with a sustained speed of 8 bits per cycle of the "OMAP's peripheral L3 connect clock." Simply stated, the serial transceiver can be configured to support burst speeds of up to 200MB/s, which is well above the specification. The McBSP features DMA capabilities, allowing for a solution, which, from the DSP’s software perspective, behaves, similar to the GPMC.

For reference, the GPMC is an enhanced version of a typical SRAM interface consisting of a configurable number data and address lines (8 or 16 in the case of the OMAP), and control line (chip-select, clock, read/write, direction, write protect). Using the OMAP's MMU it is possible to have memory references within a specific memory region travel off the chip through the GPMC interface, on the other side of this interface would lie the I/O controller which would act like a memory device, sending back I/O data depending on the requested memory address.

The main disadvantage of the Gumstix board is that the manufacturer does not provide schematics or layouts. Additionally, the current Gumstix boards feature hardware for video and audio processing which is not needed, and only consume extra power. In order to maximize power efficiency and minimize extraneous hardware, future versions of the CCP can make use of a custom board solution with more appropriately-featured hardware. A redesign would provide an opportunity to reimplement the IOC interface to use the GPMC. This change would provide lower latencies between sampling and control system executions, thus increase the performance of the system as a whole and reducing delay effects in the control system.

SoftwareOne of the criteria for selecting the OMAP3 for the Control Code Processor(CCP) was the available software development environment. The OMAP3 met this need by having TI-supported free Windows tool chains for both the ARM and DSP cores.

The MATLAB/Simulink integration requires a new Realtime Workshop target template to be written for our processor and environment. This involves writing the ARM-side wrapper for initializing the DSP bridge and starting the DSP node, as well as writing the DSP node wrapper that actually runs the Simulink model. Further, this code must be aware of a vehicle-specific configuration file that describes the sensors and actuators available. Figure 4.1 shows the end-user workflow for creating the vehicle control code and uploading it to the system. Figure 4.2 shows the execution flowchart for the control code.

Figure 4.1: End-User Workflow

Figure 4.2: Control Code Flowchart

Due to the choice of the OMAP3 processor, the opportunity arose to use the Linux operating system on the CCP. Using a pre-existing operating system removes the need to write hardware device drivers for our peripherals and provides an ideal debugging/monitoring interface. Furthermore, Linux provides a wide range of real-

time capabilities without having to switch a more traditional real-time operating system. Figure 4.3 shows the CCP's boot process.

Figure 4.3: Control Code Processor Boot Sequence

As the last task in the boot sequence, the control code loader daemon will run. This loads and runs any existing control code software. The control code loader daemon also periodically checks for new control code. If new control code becomes available, it then terminates the old control code, and launches the update. Figure 4.4 shows the flowchart for the control code loader daemon.

Figure 4.4: Flowchart for the Control Code Loader Daemon