CAN bus embedded driver programming based on uclinux

　　1 Introduction
   
　　Early embedded systems used in software design of eight-bit single-chip microcomputers were mainly foreground and background systems (or super loop systems). The program was about several thousand lines long and consisted of two parts, namely, its application program was an infinite loop, in which functions were called to complete corresponding operations, which belonged to background behavior; its interrupt service program handled asynchronous events, which belonged to foreground behavior. As embedded system functions became more and more complex, such as friendly human-computer interface, networking, remote monitoring, etc., the priorities of various tasks were different, and traditional design methods could not complete them. The program was tens of thousands of lines long, and programmers had to deal with cumbersome underlying hardware, which was inefficient. The development of modern electronic technology has provided more peripherals for embedded microprocessors, such as serial ports, parallel ports, Ethernet ports, field buses, USB ports, etc. The embedded system uclinux, which was developed based on the free software Linux, is a free embedded operating system. The uclinux system has the characteristics of small kernel, high efficiency, open source code, stable performance, a large number of development tools, a good development environment, and rich application programs. It is one of the best tools for embedded system development.

　　2 Introduction to uclinux operating system
   
　　The uclinux system is mainly composed of four parts: user process, system call interface, uclinux kernel, and hardware controller. User process is an application developed by the user according to his own design and functional requirements, which realizes system functions by calling system function functions; system call interface realizes the interface between user and system kernel through system calls, and these calls and services can also be regarded as part of the system kernel; uclinux kernel is the soul of the operating system, it abstracts many hardware details, abstracts all hardware into a unified virtual interface, so that the program can process data in a unified way, it mainly includes five parts: priority-based process scheduling, memory management, file system, network interface, and inter-process communication; the hardware controller contains all possible physical devices required by the system. Each subsystem between the above four parts can only communicate with adjacent systems.
   
　　The device management system of uclinux is an important part of the embedded operating system. It can be divided into: the lower layer, which is related to the device, namely the so-called device driver, which directly deals with the corresponding device and provides a set of access interfaces to the upper layer; and the upper layer, which is independent of the device, communicates with the device according to the input and output requests through the interface provided by the specific device driver. For example, drivers for general serial ports, network cards, etc. can be found in uclinux.

　　3 UCLinux driver programming principle
   
　　UCLinux embedded system cannot dynamically load driver modules like Linux, but can only be compiled with the kernel, and fixed to the erasable Flash together with the application and other drivers. The driver resides in the memory and is a static driver. According to the different nature of the device, the UCLinux system divides the device into four types: character device (char), block device (block), network interface (net) and other device driver modules. In the downloaded UCLinux source code package, you can see common devices such as char, block, net, cdrom, scsi, sound, etc. in the UCLinux/linux/drivers directory. The system corresponds to a major device number and a minor device number for each device. Different devices can correspond to the same major device number. Applications access devices through different minor device numbers to identify and distinguish devices. In the Linux system/dev directory, you can enter the ls -l command to check the registered devices of the system, so when writing a new driver, you must register
the device with the system. In the UCLinux system, registration is achieved through the register_chrdev function.
   
　　The uclinux system abstracts all hardware into a virtual file system. All character devices and block devices support file operation interfaces, so file operations can be performed on this virtual device file system. The operations usually performed on device files include open, read, write, release, etc., that is, opening, reading, writing, and releasing files. Each device driver is essentially a set of functions used to complete specific tasks. The driver has a data structure called fileoperation, which contains pointers to most functions inside the driver. When booting the system, the kernel calls the initialization function of each driver and transmits the driver's major device number and the pointer to the function address structure inside the program to the kernel. In this way, the kernel can access the subroutine inside the driver through the device driver's major device number index to complete operations such as opening, reading, and writing. One of the tasks that programmers often face is to write drivers for new devices in the system.
   
　　In modern control systems, in order to facilitate data communication, field buses are often used at the bottom layer. At present, CAN buses are widely used in process industries, mechanical industries, textile machinery, agricultural machinery, robots, CNC machine tools, medical equipment, and sensors. The following introduces the driver programming of CAN buses for embedded systems.

　　4 Performance characteristics of CAN bus
   
　　CAN (Controller Area Network) is the controller area network. CAN bus has formed the international standard version 2.0. The technical specification includes two parts, A and B. 2.0A gives the standard format of CAN message, while 2.0B gives the factory standard and extended formats. CAN bus is one of the most widely used field buses. CAN works in multi-master mode. Any node on the network can actively send information to other nodes on the network at any time, regardless of master and slave. The communication mode is flexible and no node information such as station address is required. The node information on the CAN network is divided into different priorities to meet different real-time requirements. CAN uses non-destructive bus arbitration technology. When multiple nodes send information to the bus at the same time, the node with lower priority will actively exit the transmission, while the node with the highest priority can continue to transmit data without being affected. CAN can transmit and receive data in several ways such as point-to-point, point-to-multipoint and global broadcast by simply filtering the message, without the need for special "scheduling". The direct communication distance of CAN can reach up to 10km (speed 5kbps The communication rate can reach up to 1Mbps (the longest communication distance is 40m). The number of nodes on CAN depends mainly on the bus drive circuit, which can reach 110 at present. It adopts short frame structure, short transmission time, low interference probability and excellent error detection effect. The communication medium of CAN can be twisted pair, coaxial cable or optical fiber. The data communication of CAN bus has outstanding reliability, real-time and flexibility. [page]

　　5 Hardware Design of Embedded System of CAN Bus
   
　　This design uses Samsung's S3C4510B as the microprocessor chip of the embedded system. The processor is a 16/32-bit RISC microprocessor controller, which contains a 16/32-bit ARM7TDMI RISC processor core designed by ARM, and is suitable for price and power consumption sensitive occasions. In addition to the core, the microprocessor's on-chip peripheral function modules include: 2 HDLC channels with buffer descriptors; 2 UART channels; 2 GDMA channels; 2 32-bit timers and programmable I/O ports. The CAN controller uses Philips' SJA1000, which is electrically compatible with PCA82C200, with a 64-byte first-in-first-out (FIFO) stack, compatible with the protocol CAN2.0B, supports 11-bit and 29-bit identification codes, bit rates up to 1Mbps, 24MHZ clock frequency, and the chip contains registers, which can be configured by the user for the CAN bus baud rate, set the acceptance shield identification code, and configure the system as PeliCAN mode or BasicCAN mode, error alarm, etc.
   
　　The system uses 82C250 as the transceiver, and its hardware connection is shown in Figure (1). AD0~AD7 are connected to p0~p7 of S3C4510B, /cs is connected to p12, ALE is connected to p13, /RD is connected to p14, /wr is connected to p15, and /int is connected to XINTREQ0.

Figure 1 SJA1000 hardware connection

　　6 Driver Software Design

Figure 2 CAN bus initialization block diagram

　　In this design, the CAN bus driver is placed as a module in the linux/deriver/char/ folder. The software flow is shown in Figure (2). The design is described in detail as follows.[page]

　　The module first declares the referenced library function and defines it:
　　#define IOPMOD (*(volatile unsigned *)0x3ff5000)
　　#define IOPDATA (*(volatile unsigned *)0x3ff5008)
　　#define IOPCON (*(volatile unsigned *)0x3ff5004)
　　#define EXTDBWTH(*(volatile unsigned *)0x3ff5
　　#define SYSCFG(*(volatile unsigned *)0x3ff5 The
　　module mainly has the following modules:
　　void can_init(void)
　　{
　　SYSCFG =SYSCFG & 0x0fffffffd;
　　EXTDBWTH =EXTDBWTH& 0x00ff0ff;
　　IOPMOD=0xf0ff;
　　IOPDATA=0x6000; Register address 0, MOD register
　　IOPDATA= IO_PDATA&0xdfff; ALE=0 Configure MOD register
　　IOPDATA= IO_PDATA|0x3f; ; Reset mode, enable
　　IOPDATA=0x6006; ; Register address 6, bus timer 0 register
　　IOPDATA=IO_PDATA&0xdfff; ALE=0 configure register
　　IOPDATA= IO_PDATA|0x3f; Jump width, baud rate setting
　　...; Configure bus timer 1, acceptance code register, etc.
　　IOPDATA=0x6000; SJA1000 register address 0, MOD register
　　IOPDATA=IO_PDATA&0xdfff; ALE=0 configure MOD register
　　IOPDATA= IO_PDATA&0xfe; Write reset bit, enter working mode
　　result = register_chrdev(254,"can",&can_fops); Apply for master device number
　　if (result<0) {
　　printk(KERN_WARNING "CAN:can't getmajor ", result);
　　return result;
　　}
　　In this driver, define the structure variable can_fops as the interface for application to access the kernel:
　　static struct file_operations can_fops = {
　　read: can_read,
　　write: can_write,
　　open: can_open,
　　release: can_release,
　　};　
　　static int can_release(struct inode *inode, struct file *file)
　　{
　　MOD_DEC_USE_COUNT; ; user count down
　　Return 0;
　　}
　　static int can_open(struct inode *inode,struct file *file)
　　{
　　Scull_Dev *dev;
　　Int num = NUM(inode->i _rdev); Device number
　　Int type = TYPE(inode->i_rdev); Device type
　　If (num>=scull_nr_devs) return -ENODEV;
　　dev = &scull_devices[num];
　　flip->private_data = dev;
　　MOD_INC_USE_COUNT; Manual counting of users
　　IOPCON=0x16; //xIRQ0
　　disable_irq(INT_can);
　　if(request_irq(INT_can) , &can_rx,
　　SA_INTERRUPT, "can rx isr","can")) {
　　printk("s3c4510-can: Can\'t get irq %d ",
　　INT_sja1000);
　　return -EAGAIN;
　　}
　　printk("can has get irq 0 ");
　　enable_irq(INT_can);
　　…… ; Configure SJA1000 internal interrupt and mask register
　　return 0;
　　}

　　7 Conclusion
   
　　This paper introduces the driver programming of CAN bus in embedded systems and explores the application of CAN bus technology in embedded systems. This design has been applied in the remote monitoring system of inverter power supply for communication.

References:

[1]. S3C4510B datasheet http://www.dzsc.com/datasheet/S3C4510B_59.html.
[2]. RISC datasheet http://www.dzsc.com/datasheet/RISC_1189725.html.
[3]. SJA1000 datasheet http://www.dzsc.com/datasheet/SJA1000_609075.html.
[4]. PCA82C200 datasheet http://www.dzsc.com/datasheet/PCA82C200_554.html.
[5]. p12 datasheet http://www.dzsc.com/datasheet/p12_2043488.html.
[6]. p13 datasheet http://www.dzsc.com/datasheet/p13_2043489.html.
[7]. p15 datasheet http://www.dzsc.com/datasheet/p15_1204152.html.