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
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
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. The follow is file_operation
which is renewal.
static struct file_operations s3c2410_fops =
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:
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
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. 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
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
Via above analysis, the keyboard interface is implemented
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
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. 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
This system need to read the CAN bus all time, if only there
is one thread, the GUI will be frozen by continuously reading
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
The solution for communicating from a non-GUI thread to
the GUI thread is to use custom events. 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
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
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
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.
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
 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.
 Yamaoka T, Tamura H, “Information display method and process
considerations in the TRON/GUI,” TRON Project International
Symposium, 1993, No.10, 41-44.
 Xianchun Wang, “Research on Embedded Graphical System Based on
ARM and Linux,” Microcomputer Information, 2007, vol 23, pp13-15.
 Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini, “Linux
Device Drivers, 3rd Edition,” O'Reilly, 2005
 Jasmin Blanchette, Mark Summerfield, “C++ GUI Programming with Qt
3,” Prentice Hall PTR, 2004.
 Donald Hearn, M.Pauline Baker, “Computer Graphies C
version(SeeondEdition),” Prentiee Hall, 1998.