Development and implementation of CAN bus driver under Android system

    The implementation of CAN driver under embedded operating system Android requires not only adding CAN driver device in Linux kernel, but also implementing the call of Android HAL layer. Taking S5PV 210 microprocessor and CAN bus controller MCP2515 as examples, this paper analyzes the principle of Android device driver, the development process and method of CAN device driver under Android, designs relevant important data structures and codes, and implements the driver development of CAN bus.

    Android refers to "robot". It is an open source mobile phone operating system based on Linux platform released by Google on November 5, 2007. It is the first truly open and complete mobile software built for mobile terminals. Android is an open platform with good application prospects in the field of embedded mobile devices, but different devices often have different hardware support. To add these hardware applications in Android, it is not just adding driver modules in Linux kernel, but also necessary to add corresponding support in user space and application framework.
    Controller Area Network (CAN), which belongs to the category of field bus, is a serial data communication bus developed by Bosch in Germany in the early 1980s to solve the data exchange between numerous control and test instruments in modern cars. Due to the good reliability, real-time and flexibility of CAN bus data communication, CAN has been widely used in the fields of automobile industry, aviation industry, industrial control, etc. In this paper, the S5PV210 microprocessor is used as the hardware platform, and the driver development of CAN controller MCP 2515 under the Android operating system is realized by expanding its SPI interface.

1 System hardware structure The
    transmission and reception of system data must pass through the CAN bus module. The design block diagram of the CAN bus module is shown in Figure 1. S5PV210 is connected to MCP2515 through the SPI interface. The CAN input and output pins of MCP2515 are connected to the CAN bus transceiver MCP2551 to form a complete CAN bus transceiver module.

    
1.1 SPI interface of S5PV210
    The interface protocol (Setial Peripheral Interface, SPI) is a synchronous serial protocol launched by Motorola that uses a clock line and two data lines to transmit data, namely a serial peripheral interface. The SPI interface provided by S5PV210 is mainly used for synchronous serial data transmission between S5PV210 and peripheral low-speed devices. It can realize full-duplex communication and the transmission speed can reach up to 5 Mbit·s-1. The SPI bus interface is mainly used in master-slave distributed communication networks. The data communication between the master and the slave can be completed by 4 lines. These 4 lines are: clock line (SCLK), data input line (SI), data output line (SO) and chip select line (CS). The validity of CS is completely determined by the master controller, and the clock signal is also sent by the master controller.
1.2 CAN controller MCP2515
    MCP2515 is an independent CAN protocol controller produced by MICro Chip . MCP2515 supports CAN1.2, CAN2.0A, active and passive CAN2.0B and other versions of the protocol. It can send and receive standard and extended messages. It also has acceptance filtering and message management functions. Figure 2 is a block diagram of the MCP2515. The device consists of three main parts: (1) CAN protocol engine. (2) Control logic and SRAM registers for configuring the device and its operation. (3) SPI protocol module.

    
1.3 CAN transceiver MCP2551
    MCP2551 is a fault-tolerant high-speed CAN device that can be used as a CAN protocol controller and physical bus interface. MCP2551 can provide differential transceiver capabilities for the CAN protocol controller. It fully complies with the ISO-11898 standard and meets the 24 V voltage requirement. Its operating rate reaches 1 Mbit·s-1.

2  Design of CAN bus driver
2.1 Android operating system driver principle
    Although Android uses the Linux kernel, the application is developed in Java language, so the application cannot use system calls like Linux applications when calling device drivers, but must use the native method of JNI of Java virtual machine. On the other hand, if Android wants to become a highly versatile platform, its portability must be enhanced, which is also the reason for adding a hardware abstraction layer (HAL) to the Android architecture, in order to provide a more advanced encapsulation for device calls. Figure 3 shows the technical structure of the Android driver.

    
    HAL Stub exists in the form of *.so library. In the whole driver architecture, it is the part of the driver running in the user space. It provides an abstract interface of hardware devices for Dalvik virtual machine upwards, and exchanges data with the driver in Linux kernel through system calls downwards. In this process, HAL can process the data of the driver, that is, the driver in Linux kernel only needs to provide a function of transmitting data with hardware devices, and the specific operation can be completed by HAL. The implementation of CAN bus driver under Android requires not only adding CAN driver module in Linux kernel, but also adding corresponding support in user space and application framework.
2.2 CAN driver implementation process
    The main controller S5PV210 realizes the connection with MCP2515 through its own SPI interface. If the platform is to work properly, software implementation is necessary. First, make sure that the SPI port of S5PV210 can send and receive data normally, and then use the SPI port to set the register of MCP2515. The CAN driver program flow chart is shown in Figure 4. The first step is to load and declare the SPI bus of S5PV210. The second step is to implement the CAN driver in Linux kernel, including the initialization of MCP2515, the reading and writing of MCP2515, and the loading of CAN driver. The third step is to call the Android HAL layer.

    

3 Implementation of CAN bus driver
3.1 Loading and declaring SPI bus
    The CAN bus devices of the system are connected through the SPI bus of S5PV210. Therefore, it is necessary to design SPI line driver to complete data reception and transmission. The SPI bus driver has good support in the Linux kernel. It can be used directly by loading and declaring the SPI bus. The Linux kernel uses the packaged abstract device driver spi_driver to indirectly establish a connection with the original device driver, and finally registers the original device driver by calling driver_register. That is, it only needs to modify and debug on the spi_driver provided by the kernel, which greatly improves the program efficiency and portability.
    In this way, the assignment of MCP2515 driver functions probe and remove is completed in the structure mop2515_driver. Then the registers of MCP2515 can be set through SPI to implement the CAN bus driver.

3.2 Implementation of CAN driver in Linux
    For the MCP2515 controller, the Linux kernel design adopts the form of character device driver development. The driver initialization function stat IC int_init MCP2515_init() first maps the physical address of the S5PV210 SPI register to the kernel space through the ioremap() function, so that the S5PV210 SPI register can be accessed and configured in the driver. After correctly configuring the S5PV210 SPI register, register the device driver for MCP2515 through the register_chrdev() function and assign the major device number. After creating the corresponding device file in the device file directory, the Linux system function can be used to operate MCP2515. The memory allocation part is completed in the probe() function, and the allocation space includes dynamically allocating space for the device data structure and its internal receive and send buffer. At the same time, in probe(), it is also necessary to complete the interrupt application work and initialize the interrupt processing queue. In the interrupt processing queue, the CANINTF register is read to determine which buffer of the receive/transmit interrupt is , or the error interrupt. Finally, the corresponding interrupt pin of S5PV210 is enabled through the enable_IRQ() function. (
    1) MCP2515 initialization. After the SPI loading and declaration are realized, the MCP2515 can be initialized using the SPI write command. The initialization process of MCP2515 is as follows: first, the REQOP<2:0> bit of the CAN control register CAN CTR L is set to '100' to enter the configuration mode, all error counters are cleared, and after entering the configuration mode, the baud rate is set, all interrupts are disabled, the filter is set , the send and receive buffers are cleared, the interrupt is enabled, and the initialization of MCP2515 is completed. The initialization process of MCP2515 is shown in Figure 5.

    
    (2) MCP2515 interrupt mode. Since the CAN bus must exchange data with the system in interrupt mode when receiving data, interrupts must be registered. The interrupt functions used are request_irq(), free_irq(), enable_irq() and disable_irq (), where request_irq() loads the interrupt handler for a given interrupt source; enable_irq() calls the interrupt control function to enable a given interrupt chain; free_irq() releases the memory allocated to a defined interrupt; disable_irq() disables the defined interrupt chain. The specific code is request_irq(irq_EINTO mcp2515_int, IRQF_DISAB LED , device_name, NULL); the first parameter of the function request_irq() is the interrupt number requested by the device; the second parameter is the interrupt processing function registered with the system; the third parameter is the attribute of the interrupt processing, IRQF_DISABLED means that the interrupt processing program is a fast interrupt processing program, and all interrupts are masked when it is called; the fourth parameter is the device name of the interrupt; the fifth parameter is the device flag that notifies the system when applying. The function returns a value of 0 to indicate a successful application, and a negative number to indicate a failure. In this way, when an interrupt occurs, the CAN status register CANSTAT is read in the interrupt processing function mcp2515_int() to determine whether RXB0 is loaded with a message. If so, the message is read into the buffer through the SPI receive data register and waits for the system function CAN_Read() to read it.
    (3) The core file structure file_operations of the MCP2515 driver. CAN bus applications access CAN device driver functions through the file_operations data structure. <／kemel／linux／fs．h> explains the various variables in the file_operations data structure in detail. The kernel can access the driver's functions through the file structure to implement system calls. CAN applications
    can read and write corresponding data through the system functions read() and write(). The device is opened in the open() function, and the device is unregistered in the close() function. The MCP2515 controller needs to be initialized in the ioctl() function: setting the controller's operating mode, setting the baud rate of the control bus, clearing the send buffer and the receive buffer, etc.
3.3 CAN driver compilation
    (1) Copy the written driver source file to /kernel/drivers/char/, open Kconfig and add the following code:
    config S5pv210_CAN
    tristate "S5pv210 can controller driver"
    depends on ARCH_S5pv210
    help
    This option enable support for CAN
    (2) Add the following code to the appropriate location of the /kernel/drivers/char/Makefile file:
    obj-$(CONFIG_S5pv210_CAN)+=S5pv210-can．o
    (3) Add the can function. In /kernel/, make menuconfig DeviceDrivers→Characterdevices→S5pv210 cancontroller driver to dynamically load the CAN driver and save and exit.
    (4) Recompile the kernel. Enter the /kernel/ directory in the terminal, execute the make command and find S5pv210_can．o in /kernel/drivers/char/. o, this is the CAN device driver file generated by the Linux kernel layer. The kernel layer driver directly operates the hardware downwards, and provides the /dev/can device node file and the driver interface unc LOC ked_ioctl() function to the upper layer, that is, the HAL layer.

4 Calling the Android HAL layer
    The call of the hardware abstraction layer (HAL) is the key to the implementation of the CAN driver under the Android system. When porting the Android system to other hardware platforms or adding new hardware support to the Android system, the Android HAL layer needs to be ported or implemented. In the header file hardware.h of the libhardware interface, three common structures in the HAL implementation process are defined: struct hw_module_t, struct hw_module_methods_t, and struct hw_device_to. Struct hw modules_methods_t is used to represent a module representation method. The structure only contains the function pointer to open the module. struethw_module_t is used to define the information of a hardware module. In a specific hardware module, this structure needs to be "inherited". The structure hw_device_t is used to represent a hardware device. A hardware module can contain multiple hardware devices at the same time. In the HAL layer development of a module, the specific hardware call process is: (1) Get the hardware module through the ID. (2) Get hw_modules_t from the hardware module, open it to get the hardware device hw_device_t. (3) Call each method in hw_device_t. (4) Close the device through the close of hw_device_t.
    The implementation of the CAN module under the Android system must implement the call of the Android HAL layer after completing the driver of the SPI bus and the MCP2515 controller. The HAL layer call process of the CAN bus is shown in Figure 6.

    
    Write the HAL layer to use struct hw_module_t, struct hw_module_methods_t and struct hw_device_t to set the operation method of the CAN module; the JNI layer mainly completes the registration of the hardware operation method provided by the HAL layer. JNI finds the corresponding stub through CAN_HARDWARE_MODULE_ID so that the Framework layer can use these methods; the Setv ice layer mainly declares the methods that JNI can provide, loads libcan_runtime.so, and calls JNI_OnLoad of the JNI layer when loading, so that the methods in JNI can be called by the Service; write the App application so that the App directly calls the service to complete the call of the Android HAL layer. Then put the can folder in the system development directory.
    Configure the environment variables and execute . . /build/envsetup.sh. Then execute mmm development/can to compile the file. Finally, recompile the kernel, generate the image file, download and run the operating system. At this time, the CAN bus driver will be loaded, thus realizing the development of the CAN controller MCP2515 driver under the Android system.

    5 Conclusion
    Based on the analysis of the Android driver principle, the implementation process of the CAN bus in Android was introduced, and the CAN driver program was added in the embedded operating system Android, which has a certain reference role in the development of non-standard device drivers on other Android platforms.