978-1-4244-2800-7/09/$25.00 ©2009 IEEE ICIEA 2009
Research on Embedded Data Display Unit Based on
CAN Bus
Peng Yang, Le Ya...
III. CAN BUS SYSTEM
A. The implement of CAN interface
The CAN is a serial communications protocol which
efficiently suppor...
static int init s3c2410_mcp2510_init(void);
After designed CAN drivers, the CAN device could be
operate by open, close, re...
CAN bus. So it is essential to create a new thread in the GUI
thread, so as to read and write CAN bus.
The GUI thread can ...
Upcoming SlideShare
Loading in …5
×

Research on Embedded Data Display Unit Based on CAN Bus

289 views

Published on

For more projects feel free to contact us @ www.nanocdac.com

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
289
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Research on Embedded Data Display Unit Based on CAN Bus

  1. 1. 978-1-4244-2800-7/09/$25.00 ©2009 IEEE ICIEA 2009 Research on Embedded Data Display Unit Based on CAN Bus Peng Yang, Le Yang, Xin Guo College of Electrical Engineering and Automation Hebei University of Technology Tianjin, China e-mail: cole1984@163.com Abstract—The application development of embedded display terminal based on ARM microprocessor is studied, by applying 32 bit RISC key microprocessor technique, embedded software technology, embedded GUI (Graphics User Interface) technology, CAN bus communication technology, information storage and management technology etc.. The design of embedded hardware platform, of which the core is S3C2410CPU, is completed. On the basis, the Linux operation system is embedded into the platform and the man-machine interface based on Qt/Embedded are realized. Index Terms—data collection, data display, CAN bus, ARM/Linux, Qt/Embedded I. INTRODUCTION The development trend and research focus of control system is networked control. The Fieldbus Control System (FCS) which is important segment in networked system is widely applied in control system. The CAN (Controller Area Network) bus which is strong fault tolerance, high reliability, and low cost played an important role in FCS[1]. However, the host computer of control system which adopts CAN bus is industrial computer. This computer usually costs much and needs more space. If the embedded equipment is applied in control system, the cost is very low and the control system has advantage in easy customization and extension[2] II. HARDWARE SYSTEM This design consists of the collection and display of data which are independent. The data collection module receives data through CAN bus, and the data display module display these data via GUI designed by Qt/Embedded in ARM. The S3C2410 processor in data collection doesn’t have CAN controller. To resolve this problem and reduce the complexity of circuit, MCP2510 is used for extending CAN interface for S3C2410. The whole CAN bus system is made up of the MCP2510 which is a stand-alone CAN controller with SPI Interface and the TJA1050 which is the interface between the CAN protocol controller and the physical bus. MCP2510 is a Full CAN protocol controller implementing CAN specification V2.0 A/B. It supports CAN 1.2, CAN 2.0A, CAN 2.0B Passive, and CAN 2.0B Active versions of the protocol, and is capable of transmitting and receiving standard and extended messages. It is also capable of both acceptance filtering and message management. It includes three transmit buffers and two receive buffers that reduce the amount of microcontroller (MCU) management required. The MCU communication is implemented via an industry standard Serial Peripheral Interface (SPI) with data rates up to 5 Mb/s. The TJA1050 is the interface between the CAN protocol controller and the physical bus. It is primarily intended for high-speed automotive applications using baud rates from 60k baud up to 1M baud. It provides differential transmit capability to the bus and differential receiver capability to the CAN protocol controller. The display components adopt the embedded MCU S3C2410 based on ARM9 processor and LCD. the S3C2410 includes the following components separate 16KB Instruction and 16KB Data Cache, MMU to handle virtual memory management, LCD Controller (STN & TFT), NAND Flash Boot Loader, System Manager (chip select logic and SDRAM Controller), 3-ch UART, 4-ch DMA, 4-ch Timers with PWM, I/O Ports, RTC, 8-ch 10-bit ADC and Touch Screen Interface, IIC-BUS Interface, IIS-BUS Interface, USB Host, USB Device, SD Host & Multi-Media Card Interface, 2-ch SPI and PLL for clock generation. The whole frame of this system is Figure 1. Figure 1. The whole frame of this system LCD ARM control system man- machine interface Keyboard Mouse CAN bus 3498
  2. 2. III. CAN BUS SYSTEM A. The implement of CAN interface The CAN is a serial communications protocol which efficiently supports distributed real-time control with a very high level of security. Its domain of application ranges from high speed networks to low cost multiplex wiring. In automotive electronics, engine control units, sensors, anti-skid-systems, etc. are connected using CAN with bit rates up to 1M bit/s. The intention of this specification is to achieve compatibility between any two CAN implementations. Compatibility, however, has different aspects regarding e.g. electrical features and the interpretation of data to be transferred. To achieve design transparency and implementation flexibility CAN has been subdivided into different layers. The whole CAN bus system is made up of the MCP2510 which is a stand-alone CAN controller with SPI Interface and the TJA1050. When using the MCP2510, it is essential to initial it. Differently with other CAN controllers, the MCU communication is implemented via SPI. Commands and data are sent to the device via the SI pin, with data being clocked in on the rising edge of SCK. Data is driven out by the MCP2510, on the SO line, on the falling edge of SCK. The CS pin must be held low while any operation is performed. The Write Instruction is started by lowering the CS pin. The write instruction is then sent to the MCP2510 followed by the address and at least one byte of data. It is possible to write to sequential registers by continuing to clock in data bytes, as long as CS is held low. Data will actually be written to the register on the rising edge of the SCK line for the D0 bit. If the CS line is brought high before eight bits are loaded, the write will be aborted for that data byte, previous bytes in the command will have been written. Refer to the timing diagram in Figure.2-a for more detailed illustration of the byte write sequence. The Read Instruction is started by lowering the CS pin. The read instruction is then sent to the MCP2510 followed by the 8- bit address. After the read instruction and address are sent, the data stored in the register at the selected address will be shifted out on the SO pin. The internal address pointer is automatically incremented to the next address after each byte of data is shifted out. Therefore it is possible to read the next consecutive register address by continuing to provide clock pulses. Any number of consecutive register locations can be read sequentially using this method. The read operation is terminated by raising the CS pin.( Figure.2-b). The Linux way of looking at devices distinguishes between three fundamental device types. Each module usually implements one of these types, and thus is classifiable as a char module, a block module, or a network module. This division of modules into different types, or classes, is not a rigid one; the programmer can choose to build huge modules implementing different drivers in a single chunk of code. Good programmers, nonetheless, usually create a different module for each new functionality they implement, because decomposition is a key element of scalability and extendability. The CAN bus is a kind of character devices. A character (char) device is one that can be accessed as a stream of bytes (like a file); a char driver is in charge of implementing this behavior. Such a driver usually implements at least the open, close, read, and write system calls. The CAN is accessed by means of filesystem nodes. Figure 2. SPI read and write instruction After confirming the I/O mode and the hardware of CAN bus, the CAN could be controlled by ioctl. The emphasis of writing device drivers for the Linux system is writing the file_operation over again[4]. The follow is file_operation which is renewal. static struct file_operations s3c2410_fops = { owner: THIS_MODULE, write: s3c2410_mcp2510_write, read: s3c2410_mcp2510_read, ioctl: s3c2410_mcp2510_ioctl, open: s3c2410_mcp2510_open, release: s3c2410_mcp2510_release, }; Thereinto, the action of these function as follows. the function prototype of open CAN: static int s3c2410_mcp2510_open(struct inode *inode, struct file *file); the function prototype of reading CAN: static ssize_t s3c2410_mcp2510_read(struct file *filp, char *buffer, size_t count, loff_t *ppos); the function prototype of writing CAN: static ssize_t s3c2410_mcp2510_write(struct file *file, const char *buffer, size_t count, loff_t * ppos); the function prototype of initializing CAN: 3499
  3. 3. static int init s3c2410_mcp2510_init(void); After designed CAN drivers, the CAN device could be operate by open, close, read, write system calls. B. Data storage Because of the data storage and display modules are implemented via S3C2410 in which there is not enough memory to store the large numbers of data, the SD card is adopted to resolve this problem. The SD Memory Card system defines two alternative communication protocols: SD and SPI. Applications can choose either one of modes. Mode selection is transparent to the host. The card automatically detects the mode of the reset command and will expect all further communication to be in the same communication mode. Therefore, applications which uses only one communication mode do not have to be aware of the other. Single and multiple blocks read commands are supported in SPI mode. However, in order to comply with the SPI industry standard, only two (unidirectional) signals are used. Upon reception of a valid read command the card will respond with a response token followed by a data token of the length defined in a previous SET_BLOCKLEN (CMD16) command. A multiple block read operation is terminated, similar to the SD protocol, with the STOP command. Single and multiple blocks write operations are supported in SPI mode. Upon reception of a valid write command, the card will respond with a response token and will wait for a data block to be sent from the host. CRC suffix, block length and start address restrictions are identical to the read operation. After a data block has been received, the card will respond with a data-response token. If the data block has been received without errors, it will be programmed. As long as the card is busy programming, a continuous stream of busy tokens will be sent to the host. IV. MAN-MACHINE INTERFACE The man-machine interaction system is made up of ARM processor, LCD, mouse and keyboard. The ARM through the commends of the mouse and keyboard displays the data which received by CAN on the LCD. Because of the huge predominance of Qt/Embedded, and there are mouse and keyboard classes in Qt/Embedded, the man-machine interface is developed by Qt/Embedded. The Qt/Embedded is a embedded version of Qt, it has same API with Qt. the Qt toolkit is a C++ class library and a set of tools for building multiplatform GUI programs using a "write once, compile anywhere" approach[3]. Qt lets programmers use a single source tree for applications that will run on Windows 95 to XP, Mac OS X, Linux, Solaris, HP-UX, and many other versions of Unix with X11. A. The implement of mouse and keyboard interfaces Qt/Embedded put the source files which is corresponding to hardware into dir “src/embedded”, so the drivers of mouse and keyboard should be put into this dir. The input classes in Qt/Embedded are divided into mouse class and keyboard class. The abstract base class of mouse is QWSMouseHandler, the abstract base class of keyboard is QWSKeyboardHandler. New class can inherit from these two classes for actual input devices. The window system of Qt/Embedded is client/server architecture. A typical Qt/Embedded window consists of one server process and several client processes. The server distributes display areas for client and itself and creates mouse and keyboard events. The client applies the display area and receives mouse and keyboard events through communicating with server. The client has access to display area directly, so as to offer GUI for user. Every Qt/Embedded application could be a only GUI server. When application is loaded for the first time as GUI server, the application will build QWSServer. The system will call function QWSServer::openMouse() and QWSServer::openKeyboard() when QWSServer is loaded. These two functions separately call QMouseDriverFactory::create() and QKbdDriverFactory::create(). The QWSServer will obtain the devices types and nodes of mouse and keyboard by the environment variable of Linux, then open the devices and return the filehandle to the system. The system forcibly converts filehandle into actual subclass device pointer and could operate the mouse and keyboard. In other words, put the devices classes into the QMouseDriverFactory::create() and QKbdDriverFactory::create(). Via above analysis, the keyboard interface is implemented as follow: 1) The specific class inherits from abstract base class QWSKeyboardHandler, for example, MyKbdHandler class. Create mykbd_qws.h and mykbd_qws.cpp devices drivers file in the dir ”src/embedded”. 2) Put the MyKbdHandler class into QkbdDriverFactory::create() function. 3) Compile Qt/Embedded and download the generated library files into this system. Set up the environment variable Thus, the keyboard interface is accomplished in Qt/Embedded, and the mouse interface could be accomplished in the same way. B. The implement of GUI The signals and slots mechanism is a central feature of Qt and probably the part that differs most from the features provided by other frameworks. When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. So the signals and slots mechanism can easily achieve kinds of function. For example, initialization of CAN bus, data display setup, the upper and lower limit alarm setup, and so on When a Qt application starts, only one thread is running— the initial thread. This is the only thread that is allowed to create the QApplication object and call exec() on it[5]. For this reason, this thread is called the GUI thread. After the call to exec(), this thread is either waiting for an event or processing an event. This system need to read the CAN bus all time, if only there is one thread, the GUI will be frozen by continuously reading 3500
  4. 4. CAN bus. So it is essential to create a new thread in the GUI thread, so as to read and write CAN bus. The GUI thread can start new threads by creating objects of a QThread subclass. If these new threads need to communicate among themselves, they can use shared variables together with mutexes, semaphores, or wait conditions. But none of these techniques can be used to communicate with the GUI thread, since they would lock the event loop and freeze the user interface. The solution for communicating from a non-GUI thread to the GUI thread is to use custom events[6]. Qt's event mechanism allows us to define custom event types in addition to the built-in types, and allows us to post events of these types using QApplication::postEvent(). It is needed to subclass QThread and reimplement its run() function in the GUI thread, in the run() function, when reading a frame data of CAN, the QApplication::postEvent() will post a custom event to transfer the data. Since postEvent() is thread- safe, it can be used from any thread to post events to the GUI thread. The GUI thread receive the custom event, display the data in GUI. Figure 3. man-machine interface When it is needed to refurbish the data, the draw function void paintEvent (QPaintEvent*event) that is a virtual overloaded member function will be called. The draw function will accomplish two assignments, one is draw the newest wave and data, the other one is draw the wave before refurbishment. So, the data in the display interface could be refurbished, and display in dynamic state. The GUI is Figure.3 V. CONCLUSIONS The data terminal based on ARM embedded Linux system is actualized. The monitor has advantage in easy customization and extension. Through the experiment, it is proved that the veracity of parameter transmit based on CAN bus is very high and the display module can easily plug and play. Therefore, this control method and communication module has more reliability and mobility. As a field equipment bus, the CAN is more reliable and higher performance to price ratio than other bus. To sum up, because of the superior performance of ARM- Linux system and the reliability and real-time performance of the data transmitted on CAN bus, the CAN bus combined with ARM-Linux is appropriate to industry and it has wide applied foreground in process control, motor manufacture, agricultural equipment, iatrical equipment and so on. ACKNOWLEDGMENT With the valuable advice given by Dr. Xu of Hebei University of Technology, and great support from the lab which the authors work in, this paper was completed. The authors hereby would like to take this opportunity to thank all who have been providing supports during and after the preparation of this paper. The first author would like to thank Hebei University of Technology and the research group for supporting the bulk of his work on this project. This work is supported from National Key Technology R&D Program under research project 2006BAI22B03. REFERENCES [1] Yantang Wang, Yibin Li, Rui Song, “Design and implementation of CAN device driver under embedded ARM Linux operating system,” Computer Engineering and Applications, 2007,43(15),79-82. [2] Yamaoka T, Tamura H, “Information display method and process considerations in the TRON/GUI,” TRON Project International Symposium, 1993, No.10, 41-44. [3] Xianchun Wang, “Research on Embedded Graphical System Based on ARM and Linux,” Microcomputer Information, 2007, vol 23, pp13-15. [4] Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini, “Linux Device Drivers, 3rd Edition,” O'Reilly, 2005 [5] Jasmin Blanchette, Mark Summerfield, “C++ GUI Programming with Qt 3,” Prentice Hall PTR, 2004. [6] Donald Hearn, M.Pauline Baker, “Computer Graphies C version(SeeondEdition),” Prentiee Hall, 1998. 3501

×