Transcript
Universal Measurement System with Web Interface Maciej Lipiński, Grzegorz Kasprowicz Institute of Electronic Systems, Faculty of Electronics and Information Technology, Warsaw University of Technology
ABSTRACT Universal Measurement System with Web Interface (UMSWI) is presented in this paper. This is an autonomous, universal acquisition system which required development of flexible and easily extensible control. The choice of technologies, their flexibility, respect of limited resources and simplicity were the main consideration during design and development. Example implementation of oscilloscope and spectrum analyzer Web Graphic User Interface (WGUI) and Measurement Interface (ME) are described in details Keywords: web application, Java Applet, embedded systems, embedded Linux, FPGA, SCPI, Linux Device Drivers
1. INTRODUCTION In the era of miniaturization and remote control, local control interface (i.e. screen, buttons, knobs) of measurement systems (in general any systems) can introduce unnecessary overheads in costs and size. It has been noticed that most of the measurement instruments offer remote control as an additional feature. There is very few measurement equipment (except specialized units) which is controlled using only remote interfaces. Lack of local control interface can significantly lower costs of production and development. It can also eliminate size restrictions. If there is no need to integrate screen, buttons, etc on the measurement equipment, the size can be reduced significantly improving device’s mobility. Importantly, such devices do not lack any of the functionality of standard instruments. Furthermore, web-based control requires only Ethernet card and web browser for operation. This requirement is met by overwhelming majority of standard PCs and laptops. User interface of only-remotely controlled devices can be easily changed. This is a great asset. One of the factors which determines application of a device is it’s interface. The possibility to easily change interface enables device to be universal within hardware limitations. Thus the idea to create a small, cheap, Universal Measurement System with Web Interface. Such a device can be perfect for data acquisition in dangerous places (i.e. high physics particle accelerators) where the measurements need to be performed remotely and local user interface is unnecessary. It can be used for remote monitoring of industrial parameters. Small size makes it convenient for transportation. The system shell enable the user to acquire measurement data in a graphic form using web browser (Web Graphic User Interface) and perform measurement from “measurement application” such as LabView (Measurement Interface).
2. HARDWARE ARCHITECTURE The hardware for the UMSWI is commercially available (Creotech ltd) ARM based microcomputer with data acquisition daughterboard. It consists of 3 modules: main board, ARM computer and recorder. The most important parameters and features of the hardware are presented in Table 1. 1
Module name Main board
Module application Hosts power supply, peripherals and other modules
ARMputer
Single Board Computer
Recorder
Acquisition
Module’s components Switched-mode Power Supply Graphic controller Sound controller I2C interface Peripherals: USB, RS232, Ethernet, output for built-in LCDTFT and for VGA monitor Processor: ARM9 (AT91RM9200) 128MB SDRAM Ethernet interface 10/100 Mbit FLASH 8MB SD/MMC reader, Interfaces: 2 x Serial ports, 2x USB hub and device ALTERA Cyclone I FPGA 2 x fast, 105MS/s. 10 bit ADCs SSRAM – 128k x 32
Size [mm] 100x80
Photo
60x70
100x80
Table 1. Hardware description and parameters
Figure 1. presents hardware architecture and data flow. The acquired signal is converted by 10 bits Analog-to-digital Converters (ADC) and saved into Synchronous Static Random Access Memory (SSRAM). The acquisition is controlled by the Field Programmable Gate Array (FPGA). As soon as the acquisition is finished, data is ready to be read by the processor. Readout process is also controlled by the FPGA. From the processor data is transported to the user by the Ethernet or can be displayed locally on LCD/VGA monitor. Data processing can be performed using the FPGA or microprocessor. Data can be also sent to the user in raw form. The hardware architecture had significant influence to the software architecture.
Fig 1. Hardware architecture and system data flow 2
3. SOFTWARE ARCHITECTURE The ARM processor (AT91RM92000) installed on the Single Board Computer module is very popular among embedded systems. It is, of course, possible to develop applications directly for this processor. However, much better and more popular solution is running embedded operating system (OS). Using an operating system is a concept to make UMSWI very universal. Using OS, development of extensions which adapt the system to the user’s needs, does not require extensive, processor-specific knowledge. Development of new programs/scripts is exactly the same as on standard PC, just the compilation must be performed for ARM architecture and the consideration of limited resources must be taken into account. Linux has been chosen for the UMSWI operating system. Linux is an open source operating system with a very strong developers’ support. There is vast number of books, articles and forums describing it’s usage and development on embedded systems, particularly on ARM9 8 9 10 11. Running Linux enables using a vast number of open source programs and support of a strong and numerous community of Linux developers. The Linux which is used on UMSWI is based on Pelos Project of Atmel AT91RM9200 Eval Board 13.
Fig. 2 Software architecture
A general design of software architecture is presented in Figure 2. For each of the required interfaces (measurement and web interface) a server is provided. Measurement Interface (SCPI) server has been developed from scratches. The Web Interface server is provided by Busybox 12. Both servers communicate with hardware (in order to control acquisition process and retrieve measurement data) using Linux Device Driver. As SCPI server has been developed from scratches, the communication with Linux Device Driver is integrated into the server. On the contrary, Web Server needs Common Gate Interface (CGI)3 to communicate with Linux Driver. A client to Measurement Server can be any measurement application (i.e. LabView, Matlab) which enables control of remote instruments via TCP/IP using SCPI commands. A client to Web Server is a web browser which runs web application (Java Applet) enabling the user to control acquisition and receive data in a graphic form. The GUI has a form of standard digital oscilloscope.
3
4. DATA ACQUISITION AND READOUT Data acquisition and readout is controlled by the FPGA. Figure 3 presents architecture of hardware involved in this process. Three various clock sources are present. CLK defines clock signal generated by oscillator which is connected to ADC and FPGA. The frequency of ADC cannot be changed. A1-CLK stands for adjustable clock provided by ARM. This clock can be derived by dividing the main ARM clock (180MHz) by the power of two. A2-CLK stands for adjustable clock generated by FPGA which can be virtually anything, in particular can be equal to CLK or A1-CLK. Therefore, the following clock domains: • Clock domain imposed by 100MHz clock connected to ADCs used during data acquisition, • Clock domain imposed by ARM clock (90MHz) used during data readout The clock of SSRAM is switched between 100MHz and 90 MHz appropriately.
Fig 3. Acquisition and readout hardware architecture
Data acquisition and readout is managed using registers mapped into microprocessor address space. The following parameters can be controlled: • Sampling time (ts) – the minimum sampling time (tsmin) is determined by ADCs’ sampling frequency (100MHz), sampling time can be a multiple of tsmin, • Record length (l) – number of samples stored in SSRAM after trigger. Maximum value of record length (lmax) is limited by SSRAM size (128K 32bit-words), • Delay time (td) – the interval between trigger detection and start of record length counter, • Trigger source (SRC)– there are three types: external signal, signal from ARM9 (user), signal level, • Trigger level, • Readout start address, • Test mode – enables and controls tests of SSRAM. When the data acquisition is started, data is stored continuously to SSRAM with programmed frequency (sampling time). If the trigger source is set to signal level, the input data is compared with the trigger level value. When trigger is detected, the delay counter is activated. After programmed delay (if any), the address of first sample data is stored in FPGA register and the record length counter is started. After an appropriate number of samples have been stored in SSRAM, acquisition is stopped, the end address is saved in FPGA register and appropriate bit in status register is set. SSRAM clock domain is switched from 100MHz to 90MHz and data is ready for readout. 4
Figure 3 indicates that it is not possible to access entire SSRAM memory space directly from ARM due to the difference in address bus width. This problem has been solved in the following way. The entire memory space of SSRAM is mapped to one FPGA register of one word size (16bits) called readout register. This register is, in turn, mapped to a certain address in ARM address space. Each time the processor reads readout register, SSRAM address is incremented. Because data bus width between ARM and FPGA (16bits) is twice smaller than SSRAM word (32bits), it takes two readout operations for ARM to read entire SSRAM word (32bits)
Fig 4. Acquisition and readout control
5. WEB INTERFACE Web Interface is understood in this article as a medium of communication between a user (web client) and hardware (FPGA) which allows to control of the acquisition process, retrieve measurement data and present data in the graphic form. Technologies and tools used to create Web Interface were carefully chosen taking into account two criteria: simplicity and limited resources (processor speed, memory size). Simplicity of solutions is important for the development and further extensions to the system. The Web Interface can be divided into following subsystems: • Graphic User Interface o Java Applet-web application (Oscilloscope) o website, • Web Server providing Common Gate Interface (CGI), • Linux Device Driver (oscilloscope). 5
Fig. 5 Choice of technologies and techniques
Sec. 5.1. Java Applet Graphic User Interface (GUI) has been developed using Java Applet1. Applet is Java program which can be embedded in HTML documents (i.e. web pages). When a browser loads a web page containing an applet, the applet downloads into the web browser and executes. Using Java Applet has the following advantages: • Workload of graphic generation and user interaction handling is moved to the client’s side – less data exchanged between the client and the Web Server, • No requirements on the Web Server, • No additional tools required (unlike in PHP, which needs PHP parser). The applet design follows Model-View-Controller2 (MVC) architecture which allows easier and independent modification of visual appearance or underling business rules.
Fig 6. MVC architecture in Web Interface
Oscilloscope applet with Java classes associated with MVC functions is presented in Figure 6. OscApplet represents the main applet class, it controls exchange of information between the user (View) and the Model. Model component of MVC architecture consists of two classes OscUtils and OscModel. The first represents hardware. It implements communication between applet and hardware enabling control of acquisition and readout. On the other hand, OscModel is a model of a virtual oscilloscope. Hardware settings’ values and raw data are updated in OscModel only when the measurement takes place. Based on raw data, screenVectors are calculated in OscModel each time user changes the display settings. screenVectors are provided to OscWidget which implements graphic display. If enabled by the user, OscWidget displays screenVectors on the screen starting with the position indicted by the user. This indicates very clear division into three kinds of settings which are available to the user: • Hardware settings – parameters which can be used to control acquisition logic (sampling time, trigger delay, trigger source, record length, trigger level, start acquisition, trigger, stop acquisition), • Display settings – parameters which control the way data is displayed (Volts/Div, Time/Div, Freq/Div, Freq/Div), • Enable/disable display – controls whether data should be displayed on the screen (enable chan1/chan2, enable analyzer, Decibel). Each time a display setting is changed, controller calls updateScreenVectors function of OscModel. The function updates all screenVectors even if they are currently not displayed. It makes the OscModel architecture simpler but introduce calculation overhead. It needs to be investigated whether further optimization can increase performance. OscWidget implements Oscilloscope screen. It displays data provided by OscModel (which is already scaled) along with appropriate scales, grid and descriptions. The position change of displayed data is also handled by OscWidget. 6
Sec. 5.2. Common Gate Interface The communication between applet and hardware (more precisely Linux Device Driver) is performed using Common Gate Interface3 (CGI). CGI enables to communicate with programs running on the server from the webpage. With CGI, the Web server can call up a program and pass user-specific data to the program The program then processes that data and the server passes the program's response back to the Web Fig 7. Simple diagram of CGI [3] browser. Most servers expect CGI scripts to reside in special directories (ex cgi-bin) and have special extension (ex .cgi), Table 2. When a user opens an URL associated with CGI script, the client sends a request to the server asking for the file. When the server recognizes that the address being requested is a CGI program, the server does not return the file content verbatim. Instead, the server tries to execute the script. The process is explained in Figure 7. In Universal Measurement System with Web Interface CGI is used in non-standard way. It is called from the applet application and the output is never shown to the user directly. It is either ignored (when data is send to the hardware) or stored in applet variable for further processing. OscUtils provides special universal functions to read/write data from/to hardware. Such functions create appropriate requests to the server, send them and read the answer. The method used to pass the data to the server is GET. Action Read from hardware Write to hardware
GET request send by the applet to the server /cgi-bin/oscilloscope/get_name_.cgi /cgi-bin/oscilloscope/get_name_.cg?param_value
Table 2. GET requests: _name_ is the name of hardware parameter
Since GET is used, server stores the argument of the request (everything after ‘?’) in environmental variable QUERY_STRING which can be read in the script. Example “get” and “set” scripts are presented in Figure 8, detailed description is also provided.
Fig 8. Example CGI scripts with a detailed description. 7
Figure 9 presents UML Sequence Diagram explaining the process of setting sampling time parameter. A user changes value of sampling time using JSpinner provided by GUI. The change is detected. As sampling time belongs to the group of “hardware settings”, a function of OscUtils class is called. OscUtils provides appropriate function which forms HTML GET request and requests appropriate CGI script (Figure 8). The script sets appropriate hardware parameter.
Fig 9. UML Sequence Diagram
Sec. 5.3. Linux Device Driver It has been already mentioned that the communication between user space and hardware is handled by Linux Device Driver5. FPGA address bus and data bus are connected to Static Memory Controller14 (SMC). SMC controls access to external static memory and peripheral devices. In communication between ARM and FPGA the speed is crucial. Up to 512 Kb of measurement data needs to be transferred from FPGA. This is the reason why it has been decided to develop a Linux Device Driver instead of using user space mapping. A few techniques are available to interface the driver: creating a file in /proc filesystem, using the ioctl driver method, and exporting attributes via sysfs. The driver developed for UMSWI implements ioctl and proc methods. The later method has been found extremely convenient to use with CGI scripts. The /proc filesystem is a special, software-created filesystem that is used by the kernel to export information to the user space and can be used to import information from the user space to the kernel space. Each file under /proc is tied to a kernel function that generates the file’s “content” on the fly when the file is read. This technique is used in the driver developed for UMSWI to export to the user space the data from acquisition control logic registers and write this registers. It is also used to retrieve the measurement data. The driver interface is divided into: • general purpose – can be used to access FPGA with any configuration, prepared for custom-made configuration, • oscilloscope specific – for oscilloscope/spectrum analyzer implementation.
6. MEASUREMENT INTERFACE Measurement Interface (MI) is described in this article as an interface which enables UMSWI to be controlled remotely by measurement applications (i.e. LabView, Matlab). It has been decided to implement Standard Command for Programmable Instruments4 (SCPI). SCPI defines a set of commands to control programmable test and measurement Fig 10. SCPI command devices in instrumentation systems. SCPI specifies command structure and syntax, it does example not define underlying hardware and software. However, the decision to implement socket server was obvious. A SCPI command consists of nodes and an input value (Figure 10). The nodes create a tree-like hierarchy. For each instrument a “dictionary” of commands is implemented. Commands’ names and hierarchy should be 8
created in accordance with SCPI standard. However, studying Tektronix’s7, RIGOL’s6 and other companie’s programmer’s manuals of digital oscilloscopes, it has been noticed that some of the SCPI commands found in the manuals do not comply with SCPI standard but seem useful and reasonable, this is why they were implemented as well. The SCPI server consists of two modules (parts): parser and commands’ decoder. The role of the parser is to separate command’s nodes and values. The parser, which has been written, is fully compatible with SCPI syntax. It is written in C, and is easily extensible for new commands. The output of the parser is a list of command’s nodes and the input argument. Such information is passed to the command decoder which is specific for the given device. In the decoder, the hierarchy of commands is recognized and appropriate functions to control hardware called. Decoder interfaces hardware using Linux Device Drivers via proc filesystem. The command decoder has been written in a way which enables easy extension. Parser and command decoder are embedded in one Fig. 11 Interfacing SCPI server application called SCPIserver.
7. TEST RESULTS Tests have been performed using signal generator as a reference signal source and Tektronix oscilloscope as a reference measurement device . Calibration A square waveform of 100kHz was supplied to UMSWI with various amplitudes. Differences in values measured by UMSWI (Vmeasured) and reference oscilloscope (Vref) required implementation of input data scaling function (Figure 12). Oscilloscope parameters Figure 13 presents results of frequency measurement error test. Taking into account the fact that frequency was measured on UMSWI by reading signal time from the screen, the error of ± 1% is a good result. The frequency range of the oscilloscope has been measured to be 750kHz – 50Hz The measurement time of maximum length data sample takes 7s on average. VmeasuredMax = f(VrefMax)
VmeasuredMin = f(VrefMin)
600
Frequency error
100 measured corrected
1
measrued corrected
500
Reference Generator Reference oscilloscope
0
300
200
100
0
-100 0 error [%]
Vmeasured | Vcorrected
Vmeasured | Vcorrected
0.5
400
-200
-0.5
-300
-1
-400
0
100
200
300 Vref
400
500
600
-500 -500
-400
-300
-200 Vref
-100
0
100
-1.5 -1 10
0
10
1
10 f[kHz]
2
10
3
10
Fig. 13 Frequency measurement error
Fig 12. Calibration 9
Figure 14. Square wave.
Figure 14 presents measurement of square wave with spectrum analyze.
8. CONCLUSIONS Creating universal measurement system required design and development of well-thought, flexible and easily extensible system. The goal was achieved. Moreover, the outcome design can be easily applicable to control any hardware. With only little changes, the control subsystem (processor and software) can be used in any device which needs web control. The performance (number acquisitions per second) can be improved by further optimization of the applet application.
REFERENCES [ 1 ] P. J. Deitel, Java™ How to Program, Seventh Edition, Prentice Hall, 2006 [ 2 ] V. Piroumian, Java GUI Development: The Authoritative Solution, Sams 1999 [ 3 ] S. Gundavaram, CGI Programming on the World Wide Web, First Edition,O`Reilly,1996 [ 4 ] SCPI Consortium; Standard Commands for Programmable Instruments (SCPI), USA, 1999. [ 5 ] J. Corbet, A. Rubini, G. Kroah-Hartman, Linux Device Drivers, Third Edition, USA 2005 [ 6 ] RIGOL Technologies, Inc. Programming Guide for DS1000/DS1000CA Series, 2008 [ 7 ] Tektronix, Programmer Manual TDS 200-Series Digital Real-Time Oscilloscope, USA [ 8 ] C. Hallinan, Embedded Linux Primer: A practical, Real-World Approach, Prentice Hall, 2006 [ 9 ] Karim Yaghmour, Building Embedded Linux Systems, O'Reilly, 2003 [10] P.Raghavan, A. Lad, S. Neelakandan, Embedded Linux System Design and Development, Auerbach Publications,2006 [11] Thomas Petazzoni, Michael Opdenacker, Embedded Linux kernel and driver development, Free Electrons http://free-electrons.com/ [12] Busybox Project homepage www.busybox.net/ [13] Atmel AT91RM9200 Eval Board; http://twarm.pelos.pl/ [14] ATMEL, ARM920T-based Microcontroller, AT91RM9200, 2006 10
