Android (Linux) line rules, androidlinux

Android (Linux) line rules, androidlinux

Generally, the on-board navigation host requires multiple external UART peripherals, for example, the HFP bluetooth module, the CAN decoding box module for communications with the original car, the u-blox GPS module and the DVD movement are supported. In the early years, Telechips TCC8902 + WinCE6.0 was used. This chip has many serial ports and is basically enough. Finally, I thought about a new trick. I need to dynamically reuse the debugging serial port. For details, see "dynamic reuse of debugging serial ports under WinCE". Later, RK3188 + Android was used as the car machine, and RK3188 was not so many serial ports, so all serial ports and peripherals were connected to STM32, and even IIC devices such as the touch screen and radio were connected together. STM32 is responsible for transparent data transmission between RK3188 and various peripherals. I have to say that the STM32 is really powerful. Of course, it is also difficult for Yao to use it. A software supports dozens of touch screens, N versions of hardware, and self-written OS runs fast on it. He used STM32 to hack all the peripherals and connected the master CPU to a serial port. The data stream is as follows.

Android was updated too quickly, and RK3188 was out of date soon. Later, MTK6735 was used as the main CPU. Yao transplanted the STM32 program to the new board in minutes. In old Deng's words, Yao is quick! Give it to me and start porting the Android driver. Originally on RK3188, it was directly modified at the bottom layer of the serial port driver. Starting from the interruption, caching, packaging and distribution, the touch screen driver was also modified based on the original GT9XX driver, the platform is highly dependent and cannot be transplanted. Later, I discussed with Lao Deng and GYP to modify the software architecture, write a virtual device driver to read the serial port data, and distribute the data to Bluetooth, CAN, and other device drivers using a pair of virtual serial ports. In this way, the drivers of all devices are purely virtual, so you do not need to modify the MTK6735 serial port driver. It will be convenient to transplant the driver to other platforms later. I think it's beautiful, but I just found a problem. The driver of the virtual device cannot read the TTY device, which is completely different from that of WinCE. Linux cannot call open or read in the driver. I searched the driver code of Linux, and almost never used it like this. I used it for debugging only a few times. It looked awkward and I couldn't find relevant information on the Internet, driving Me Nuts-Things You Never shoshould Do in the Kernel clearly states that this is forbidden and the article also analyzes why developers have such unreasonable ideas. the excerpt is as follows:

　　The most common question asked in this don't-do-that category is, "How do I read a file from within my kernel module?" Most new kernel developers are coming from user-space programming environments or other operating systems where reading a file is a natural and essential part of bringing configuration information into a program. From within the Linux kernel, however, reading data out of a file for configuration information is considered to be forbidden. This is due to a vast array of different problems that could result if a developer tries to do this.

This cannot be done, so try another way. If the driver cannot read the TTY device, write an application to read the TTY device, and then distribute the read data to the device drivers such as Bluetooth. After careful consideration, I think this solution is very bad, and the data stream is bent around a lot, which is very bad. Is there any other way? In Linux, serial mouse, serial bluetooth module, and serial Modem are supported. How do they get TTY data in the driver! Although the project was a little anxious and Yao was so awesome, I still planned to study it for another two days. I was not eager to change the native serial port driver. I know that it is a pitfall. Once it falls into it, there will be a second and a third time. I 'd rather slow down and bypass it.

However, I did not lose my mind. I finally Google a good article about TTY, The TTY demystified. It is mentioned that:

　　Incidentally, the kernel provides several different line disciplines. Only one of them is attached to a given serial device at a time. The default discipline, which provides line editing, is called N_TTY (drivers/char/n_tty.c, if you're feeling adventurous). Other disciplines are used for other purposes, such as managing packet switched data (ppp, IrDA, serial mice), but that is outside the scope of this article. 

This is what I want! Although the author did not elaborate on line discipline, he clearly pointed out that Modem and serial mouse use line procedures to process data, and TTY itself is the default line procedure. There is no way in the mountains and waters! Next, we will focus on how the line procedure works and find a suitable driver for porting. Finally, we will select kernel-3.10/drivers/tty/n_hdlc.c as the driver template for porting, it supports data frame packaging and bidirectional communication. Linux driver development, try to find a ready-made transplant, so that efficiency will be high. Writing a Kernel Line Discipline is also a good article, which is helpful when porting the driver.

Shows the UART data stream in Linux.

The simple figure is as follows:

Originally, the Low level serial driver was modified on RK3188, and the related lines on the platform were large. If the original manufacturer updated the serial driver, the Code should also be manually synchronized. The above problems are avoided by using the line rules, which is irrelevant to the platform and convenient to transplant. After porting all the drivers on MT6735, the project switched to MT8735, which took about half an hour to transplant, you only need to copy the line procedure driver, virtual touch screen driver, Radio driver, bluetooth module driver, and uartd application, modify several configuration files, and compile them without modifying a line of code. Uartd is an application for switching line rules. If Qualcomm's CPU is used later, it can be done in minutes like Yao's.

In addition to the above basic functions, the use of Line Rules also adds a function for monitoring and capturing all data streams on UART, facilitating the development and debugging of new serial ports. I have to say that the line procedure is really a good thing! The Linux driver architecture is awesome!