Porting real-time device drivers to embedded Linux-general Linux technology-Linux programming and kernel information. The following is a detailed description. Linux has occupied the embedded system market like a storm. According to industry analysts, about 1/3 to 1/2 of the New 32-bit and 64-bit embedded systems are designed to use Linux. Embedded Linux has shown its advantages in many application fields, such as SOHO home network and imaging/multi-functional peripherals, and has a huge development prospect in the following aspects: (NAS/SAN) storage, home Digital Entertainment (HDTV/PVR/DVR/STB) and handheld devices/wireless devices, especially mobile phones.
The new embedded Linux applications will not suddenly pop up from the developer's mind as they are in the hands of the god of wisdom and technology-Raytheon. A large number of projects must use thousands of lines, or even millions of lines of old ready-made code. Hundreds of embedded projects have successfully transplanted off-the-shelf code from other platforms to Linux, such as Wind River VxWorks and pSOS, VRTX, Nucleus, and other RTOS, these porting work is still valuable and practical.
So far, most documents about porting old RTOS applications to embedded Linux have been focusing on RTOS interfaces (APIS) and tasks, the scheduling mode and how to map them to the corresponding user space. In the intensive I/O space of embedded programs, it is equally important to port the RTOS application hardware interface code to a Linux device with a more standardized mode.
This article will look at several common memory ing I/O methods, which often appear in old embedded applications. They cover the scope, from special use of interrupt service routines and access to hardware by user threads, to the semi-standardized driver model that appears in some ROTS. It is enlightening for porting RTOS code to a Linux Device in standardized mode and introduces some methods. In particular, this article will focus on and compare the memory ing in RTOS code, Linux porting Based on I/O scheduling queues, and redefinition of rtos I/O, it can be applied in the local Linux driver and daemon.
Rtos I/O Concept
"Nonstandard" is the best word that can describe most of the I/O Based on RTOS systems. Most RTOS are designed for earlier CPUs without MMU, ignoring memory management. Even when MMU is available, it does not distinguish physical addresses from logical addresses. Most RTOS are still running in the privileged state (system mode), and the performance is enhanced on the surface. In this way, all RTOS applications and system code can access the entire machine address space, memory ing devices, and I/O commands. In fact, it is very difficult to distinguish the RTOS application code from the driver code, even if they are different.
This nonstandard structure leads to the special implementation of I/O. In many cases, there is a lack of identification of a device driver model. Based on the equality of work and the absence of hierarchy, it is of great guiding significance to review some important concepts and practices used in RTOS-based software.
Online memory ing access
When the commercial RTOS products were available in the 1980s s, most of the embedded software included a huge main loop, the main loop contains registration I/O and interrupt service routines for strict time operations. Developers design RTOS and execution programs into their projects, mainly to enhance the synchronicity and help with multi-task synchronization, but to avoid any other constructor that has an "obstruction. Similarly, even if an RTOS provides an I/O call method, embedded programmers continue to use direct I/O operations:
CODE: # define DATA_REGISTER 0xF00000F5
Char getchar (void ){
Return (* (char *) DATA_REGISTER);/* read from port */
}
Void putchar (char c ){
* (Char *) DATA_REGISTER) = c;/* write to port */
} |
