Group 10 Programmable Sensor Output Simulator Progress Report #2

Transcription

1 Department of Electrical Engineering University of Victoria ELEC 499 Design Project Group 10 Programmable Sensor Output Simulator Progress Report #2 March 5, 2005 Submitted by: Group No.: 10 Team: Exfour Systems Team Members: Shirley Shi ( ) Laurie Voroney ( ) Alice Cheung ( ) Brenda Law ( )

2 Table of Contents 1.0 Project Goals Progress to Date Functional Specification Hardware System Design Component Selection Analog I/O Module Design FPGA Logic Design Summary of Tasks Completed Firmware Firmware Design Summary of Tasks Completed Software Graphical User Interface Design Summary of Tasks Completed Tasks to be Completed Hardware Firmware Software Presentation Appendix A. Analog I/O Module Schematics (Draft)... 13

3 1.0 Project Goals The goal of this project is to design and prototype a programmable sensor output simulator. 2.0 Progress to Date The following is a summary of the progress that has been achieved to date. 2.1 Functional Specification The functional specifications have been finalized. Two major changes were made since the first progress report. First, the Pulse Width Modulation (PWM) outputs were changed to Pulse Frequency Modulation (PFM) outputs at the request of AXYS. As a result, frequency will be the time-varying parameter in the two PFM channels, and the duty cycle will be constant at 50%. Second, the 0-20mA current range was removed at the request of AXYS. Third, the RS232 message requirements were modified to allow the rotation of multiple RS232 message formats in one RS232 channel. This allows the simulator to mimic the behavior of equipment that might several message types in sequence. 2.2 Hardware The hardware component of this project is divided into the following sections: System Design, Component Selection, Analog I/O Module Design, and FPGA Logic Design System Design The design of the overall system has been completed. Because of the requirements for four simultaneous RS232 channels, we decided that a simple microcontroller based system using a Microchip PIC or an Atmel AVR was not the best solution. Due to their limited capabilities, multiple microcontrollers would have been required, increasing the complexity of their design. The alternative to using building a custom microcontroller based system is to use a commercially available computer system to be the core of the product. In particular, Single Board Computers (SBC) of relatively small size, low power requirements are commercially available from many different manufacturers. Most SBCs also facilitate interfacing with custom modules using an easily accessible PC/104 bus. Interface with the PC/104 bus can easily be accomplished using a Programming Logic Device (PLD) or a Field Programmable Gate Array (FPGA). Finally, most SBC manufacturers also offer expansion modules for multiple RS232 ports, further simplifying the hardware design. Based on these considerations, a system was designed around a SBC core. This top level design is shown in the following figure. Page 1

4 Analog Outputs PFM Outputs Custom I/O Module PLD/ FPGA Single Board Computer RS232 to PC RS232 Outputs RS232 Expansion Module PC/104 Bus Figure 1. Overall System Design Based on this system design, the hardware design can be further divided into selecting the SBC system and corresponding RS232 Expansion Module, and component selection and design of the Custom I/O Module Component Selection Single Board Computer and RS232 Expansion Module There are many manufacturers of Single Board Computers. They can be based on a wide array of different microprocessors, and can run on a variety of different operating systems, including Linux, DOS, and Windows CE. Most products interface to modules via a compact PC/104 bus. Many products also come available with useful onboard peripherals such as flash memory, ADC, serial communications, network connections, and interfaces to I/O devices such as displays, keyboard and mouse. Of particular interest is the available number of RS232 ports and their ease of use. Ideally, the SBC would already have five or more RS232 ports onboard, or that the manufacture could supply an expansion module that could accommodate additional RS232 ports as required. Other considerations include the experience of the group and AXYS with the manufacturers and their products, price, sufficient software and hardware documentation, and location of supplier. Page 2

5 Manufacturers of SBCs include: Tri-M System WinSystem Inc. Tri-M Systems and Engineering Inc. Technologic Systems Based on the product specifications, price, and AXYS experience, Technologic Systems TS-7200 SBC was chosen to serve as the core of the Programmable Sensor Output Simulator. And overview of the TS-2000 board s specifications can be found at To allow up to four RS232 message channels, a RS232 Expansion module from the TS-7200 was also selected ( Finally, an inexpensive battery backed Real Time Clock (RTC) module was chosen to allow the simulator to produce accurate date stamps. PLD / FPGA A PLD or FPGA is required to serve as the digital interface between the SBC and the Custom Analog I/O module. In additional to decoding addresses from the PC/104 bus and coordinating reads and writes, the PLD or FPGA could be used to implement all of the digital components required, such as registers and other digital memory components. Because of AXYS s experience and preference, only Xilinx products were investigated. Xilinx offers a free application for the design, synthesis, and programming of their PLDs and FPGA. Design choices were further limited to FPGAs because of their greater capacity and because Xilinx FPGAs contain built-in user configurable RAM that will be useful in the design of module. A Xilinx prototype board, used for laboratories, could be obtained on loan from UVic. This board, D2 from Digilent Inc., features a Xilinx Spartan II FPGA, which provides more than sufficient number of gates and user configurable I/O pins. The design of the Analog I/O module is currently based on this FPGA; however, in the future, the design could easily be transferred to another FPGA, such as the Spartan IIE, depending on the actual number of user I/O pins and gates required. Based on the capabilities of the Spartan II FPGA, an overall design was created for the Analog I/O Module. First, all required digital logic would be implemented on the FPGA. These including digital control signals and registers storing configuration information. Second, a hardware FIFO (First In First Out) memory would be used to remove the timing responsibilities from the SBC. The SBC would only be required to keep the FIFO at least half-full; updating digital values to the Digital to Analog Converters (DACs) at a 8 khz refresh rate would be done by the FPGA Page 3

6 Analog Components Based on the design shown in Figure 2, the following analog components are required: Power o ±5 VDC, 3.3 VDC, 2.5 VDC voltage regulators Analog Outputs o Digital to Analog Converters (DACs) o Analog Multiplexers o Operational Amplifiers o Current Transmitter User Interface o Numeric Display o Push buttons o LEDs Passive Components and Transistors o Resistors, Capacitors, Inductors o BJT Transistors for driving currents The selection of Analog Output components is of particular importance to the overall design of the Analog I/O Module. The following table summarizes the requirements and considerations for these components. Table 1. Requirements and Considerations for the Selection of Analog Output Related Components Component Requirements Other considerations DAC - At least 14 bits precision - 0-5V range - Simple serial interface - 16 bits or less is preferred, because the PC/104 allows 16 bit Analog Multiplexer Operational Amplifiers Current Transmitter - Enable / disable to keep output at high impedance when not in use - At least 3 output channels - Low noise - Low zero cross-over distortion is desired to allow accurate outputs around 0 V ma based on 0 5V input data transfer - low on resistances and high off impedance is desired - low power consumption is preferred - easy setup is preferred Because of the high input voltage requirements for the current transmitter ( VDC), it was discovered that an analog MUX satisfying this requirement would require a supply voltage at least equal to the maximum switching voltage. Because it is impractical to Page 4

7 supply a multiplexer with 36 VDC, the design needs to be modified. The use of a relay is currently being investigated Analog I/O Module Design Based on the overall design and the components selected, a design was created for the Analog I/O Module. Designs were created for the analog circuitry for the current / voltage output, power and voltage regulation, FPGA connections, and other peripherals required. The first draft of these design schematics can be found in Appendix B. Analog circuitry is not required for the PFM outputs, except for pull-up resistors on the corresponding FPGA output pins to achieve +5 V output FPGA Logic Design Based on the flowchart shown in Figure 3, the required FPGA logic was designed. The design can be divided into 4 components: 1. PC/104 Bus Read/Write and Address Decoding 2. General Memory Registers and Control Circuitry 3. DAC Control Circuit and FIFO memory 4. PFM Circuit Significant progress has been made in the FPGA logic design, and is discussed further in the following section Summary of Tasks Completed For the hardware component of this project, the followings tasks have been completed: 1. System Design 2. Component Selection o Relays and some power regulation components are still being investigated 3. Analog I/O Module Design o While the overall design has been completed, the schematics must be finalized and the power and relay components chosen. 4. FPGA Logic Design o DAC Control Circuit and FIFO memory has been completed. o Bus Reading / Writing and General Memory Registers and Control Circuitry are both nearing completion. o PFM Circuit will be modified from the DAC Control Circuit and FIFO memory, once that has been tested Page 5

8 2.3 Firmware Firmware Design The Technologic Systems TS7200 single board computer (SBC) employed in our project design contains an EP9302 ARM9 processor. The SBC is shipped with the Linux kernel, a Journaling Flash File System (JFFS2) and cross compliers for C program development on other Linux distributions or through Cygwin, which is a Linux-like environment on Windows. Two additional daughter cards have also been purchased. Both connect to the SBC through a PC104 bus. The first daughter card, TS-SER4, contains four RS232 serial ports for output; the second daughter card, TS-5620, is a battery packed Real Time Clock which can be used to time stamp data from the four RS232 channels and logging files to the PC application. To satisfy the functional requirement of the system, firmware is expected to handle the following tasks: 1. Sequential System Initialization a. Set up DAC, PFM, and RS232 serial outputs through addressing mapping. b. Establish RS232 serial communication with the PC control application. c. Synchronizing the real time clock on board with the PC system clock. d. Receive and validate XML files from the PC application e. Initialize interrupt signals for the output channels including DAC, PFM, the four RS232 serial output channels, and the system real time clock (RTC). Also, initialize interrupt for control signals (start, stop, pause, resume, reset) from the PC. f. Acknowledge the PC application that the SBC is ready. g. Wait for the start signal. Once the SBC is signaled by the PC application to start, the following events are expected: 2. Program Flow through Interrupt Handling a. Parse XML files from the PC application into a data storage structure (DSS). b. Enable/Disable output channels and associated interrupts (DAC, PFW and RS232 serial) according to data stored in the DSS. Set the baud rate of the four RS232 serial ports. c. Compute values to be fed into the hardware FIFO. d. Fill the FIFO. e. Enable Hardware Channels and Interrupts. f. Handle interrupts as required. Interrupt sources include Control signals from the PC. Pause/Resume will disable/enable the output channel and associated interrupts. Start will cause the program state to go to 2a). Stop will cause the program to return to state 1f. Page 6

9 Half empty FIFO interrupt from the DAC and the PFM. The SBC should compute values and fill the FIFO. Interrupts from the four RS232 serial outputs. The four serial ports are designed to share one interrupt pin on the SBC. Hence the interrupt handler should check which serial port is the source, latch the real time clock value and send more data to this port. Interrupt from the real time clock, which should be generated once per second. The interrupt handler should read from the FIFO of each DAC/PFM output channel, generate a serial text message by combining the current output information with a time stamp and send the message back to the PC application for logging purposes. In summary, C program development can be divided into two major sections 1. System initialization and communication with the PC application 2. Interrupt initialization and handling Summary of Tasks Completed 1. Sequential System Initialization A large proportion of time has been spent researching into the Linux operating system, C programming, and modifying the firmware system design according to the program requirements. An initial memory map of the SBC has been completed. RS232 communication between the SBC and the PC terminal has been established through the hyper terminal emulator. A 32MB Compact Flash disk is used to transfer compiled binary executables from another computer to the SBC. It is possible to boot into a Debian file system on the compact flash instead of the JFFS2 file system within the onboard flash. However, we have decided to use the onboard file system because it is sufficient yet does not require additional compact flash memory. 2. Flow Cycle through Interrupt Handling Interrupt initialization programs for the analog output channels has been written but not tested. Interrupt handler routines are in progress. 2.4 Software Graphical User Interface Design The software application created for the sensor simulator acts as both a control interface and a configuration interface. To differentiate between these two modes of operation, the GUI has been designed so that a separate program window will be provided for each mode. The main program window will house the controls necessary for communicating with the hardware device and a separate program window that is launched from the main Page 7

10 program window will allow the user to specify the desired output from the sensor simulator. A tree view structure was chosen and implemented for the settings window to provide intuitive and user friendly navigation interface. This is essential considering the large number of potential settings available. Each settings node in the tree view is associated with a settings pane tailored to the output type. The development of a graphical interface for analog and RS232 channel configuration has been completed. A save file format was also chosen and implemented for RS232 channel settings Summary of Tasks Completed Analog Settings Pane Design The analog channel output is defined through interpolating between sets of data points. The design of the analog settings pane provides the user with two different methods for configuring these data points. After choosing the analog channel type and specifying a maximum time value, the user may either click on the graph to specify voltage/current points or enter data values manually using the table provided. Figure 2. Analog Channel Settings The interactive graph is designed such that a new point is added as long as the user clicks within the x and y axis ranges. If a point is chosen such that it occurs between two previously defined points, that point inserted in between those points, with the table automatically updated. Values specified manually through the table that lie outside of the axis range are automatically set to the maximum or minimum value for that axis. Page 8

11 RS232 Channel Pane Design A RS232 channel output has several universal settings that apply to all messages sent from that particular RS232 channel. This pane allows the user to specify these universal settings, as well as load and save channel information. There is also an option to configure the channel to match a predefined RS232 channel output type. Choosing this option defines all of the settings for the channel, including the message definition, to coincide with a standard type. Figure 3. RS232 Channel Settings The number of messages associated with this RS232 channel can also be changed for cases where it is required to repeat of several different serial messages on the same RS232 channel. Actual serial message contents are defined under the Message # sub node in the tree view. Page 9

12 RS232 Message Settings Pane Design Each RS232 message is composed of a maximum of 25 fields. The settings required for each field differ depending on the type of information it contains. For example, text fields only require the specification of the field text while number fields require the user to specify a start value, maximum, minimum, increment value and increment interval. Figure 4. RS232 Message Settings The message settings pane is designed such that the user is able to choose the field type for each field and specify the required settings for them through dynamic property panes. The ability to preview the generated RS232 message is provided. Page 10

13 Save File Format Specification XML was chosen as a save file format for both individual RS232 settings and complete Stage and Stage Set settings. Through the use of a custom wrapper class for XML serialization, a highly descriptive and flexible settings file can be created for storage on the PC. This same file will be sent to the single board computer for interpretation. The save and load file functions have been implemented for RS232 messages. 3.0 Tasks to be Completed 3.1 Hardware 1. Hardware Design The Logic Design for the FPGA needs to be completed, and the schematics for the Analog I/O Module finalized. 2. Prototype Implementation : Assembly of Analog I/O Module Prototype The first prototype of he Analog I/O Module needs to be assembled. This will be done on a lab breadboard using components already procured. The analog circuit then needs to be tested with the FPGA and the SBC firmware. 3. Documentation Once the first prototype of the Analog I/O Module has been assembled and tested, documentation will be produced and assembled, including the following: Parts List and Datasheets Final Design Schematics ready to be transferred to PCB design Documentation of VHDL code and schematics for FPGA logic design 3.2 Firmware The Firmware is still in its development stage. More C programming and testing on the SBC is required in the following areas. 1. Sequential System Initialization Interfacing with the real time clock Communication with the PC application to retrieve XML files 2. Program Flow Cycle through Interrupt Handling Parsing and validation of the received XML files Initialization and handling of interrupts from the PC application. Interrupt handling for the output channels. Page 11

14 3.3 Software 1. Implement the PFM settings pane using the analog settings pane as a template 2. Implement the save/load file function for the entire stage set 3. Create main program window with control interface for the hardware device 4. Programmatically establish serial communications with the hardware device for the sending of control signals and settings configuration 5. Implement logging interface 3.4 Presentation 1. Presentation preparation for April 1 2. Web presentation design and implementation 3. Final Report and documentation Page 12

15 Appendix A. Analog I/O Module Schematics (Draft) Page 13

16 Page 14

17 Page 15

18 9VDC-12VDC Unregulated 100µF 7 +5 VDC +VIN FEEDBACK OUTPUT LM N µH 330µF V5+ V VDC VIN VOUT V33 LM2937ET µF 10µF GND #ON/OFF 8 0 GND -5 VDC / -4 VDC +2.5 VDC 9VDC-12VDC Unregulated 100µF 7 +VIN FEEDBACK OUTPUT LM GND #ON/OFF N µH 330µF 1M 5M V4- V5+ VIN VOUT V25 LM2937ET µF 10µF GND V5- Page 16

19 Page 17