RTOS Device Driver porting to embedded Linux-general Linux technology-Linux programming and kernel information. The following is a detailed description. Linux occupies the embedded system market like a storm. Analysts pointed out that about 1/3 to 1/2 of New embedded systems use Linux. Embedded Linux has shown its advantages in many application fields, such as SOHO home network and imaging/multi-functional peripherals. In (NAS/SAN) Storage, home Digital Entertainment (HDTV/PVR/DVR/STB), and handheld/wireless devices, especially digital mobile phones, have gained significant development.
New embedded Linux applications won't come out of the developer's mind. Most projects are composed of thousands or even millions of lines of code. Over embedded projects have successfully ported code from other existing platforms to Linux, such as Wind River VxWorks, pSOS, VRTX, Nucleus and other RTOS. These transplantation work has important values and practical significance.
So far, most documents about porting existing RTOS applications to embedded Linux focus on RTOS interfaces (APIS), tasks, scheduling modes, and how to map them to the corresponding user space. It is equally important to port the RTOS hardware interface code to a more standardized Linux Device Driver in an I/O-intensive embedded program.
This article will outline several common memory ing I/O methods that often appear in existing embedded applications. They cover a range from special use of interrupt service routines and access to hardware by user threads to a semi-standardized driver model that appears in some ROTS. This has some inspiration for porting RTOS code to the standardized Linux Device boot program, and introduces some porting methods. In particular, this article will focus on the memory ing between RTOS and Linux, porting Based on I/O scheduling queues, redefines rtos I/O to the drivers and daemon in Linux.
Rtos I/O Concept
"Nonstandard" is the best term for describing most RTOS system I/O. Most RTOS are designed for earlier CPUs without MMU, So memory management is ignored, even when MMU comes out: Physical addresses and logical addresses are not distinguished. Most RTOS still run in privileged mode, although it seems to have enhanced performance. All RTOS applications and system code can access the entire address space, memory-mapped devices, and other I/O operations. In this way, even if there are differences, it is difficult to distinguish the RTOS application code from the driver code.
The nonstandard structure leads to the special implementation of I/O. In many cases, the identification of the device driver model is lacking. Based on this non-hierarchical feature, it is of great guiding significance to review some important concepts and habits used in RTOS-based software.
Embedded Memory Access
Among the RTOS products commercialized in the 1980s s, most embedded software had a strict demand for execution time, using a large loop of I/O queries and service interruption routines. Developers use RTOS and execution programs in the project, mainly to enhance concurrency and multi-task synchronization, bypassing other program structures that impede the achievement of this goal. In this way, even if RTOS provides a formal method for I/O calls, 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 */
} |
