In embedded, is there any difference between operating system and device driver?

First, the role of driving

The operation of any computer system is the result of collaboration between hardware and software in the system. Software without hardware is a paragon, while hardware without software is just a pile of scrap metal. Hardware is the underlying foundations, a platform where all software can run, and the code will eventually be implemented as combinational logic and sequential logic on the hardware; the software implements specific applications that are designed to meet a variety of business needs to meet user needs . Hardware is more fixed, the software is very flexible, can adapt to a variety of complex and ever-changing applications. It can be said that the computer hardware and software each other achievements of each other.

However, there is also a paradox between hardware and software that software and hardware should not penetrate each other’s territories.

In order to complete the design as quickly as possible, application software engineers do not want to and do not have to care about hardware, and hardware engineers hardly have enough time and ability to take care of the software. For example, an application engineer does not have to care about interrupts, registers, memory, I / O ports, chip select, and any other hardware vocabulary on a network adapter when it calls a socket to send and receive a packet. Using the printf () function When outputting the information, he does not need to know how the bottom of the corresponding information output to the screen or serial port.

That is, application software engineers need to see a purely software world without hardware, and hardware must be presented transparently to them. Who to implement hardware invisible to application software engineers? This daunting task falls on the head of the driver engineer.

The most common explanation for device drivers is “to drive hardware devices.”

The device driver directly deals with the underlying hardware, reads and writes device registers according to the specific working mode of the hardware device, completes device polling, interrupt processing, and DMA communication, and performs mapping from physical memory to virtual memory and finally enables the communication device to send and receive data Display devices can display text and images, enabling storage devices to record files and data.

Thus, the device driver serves as a link between the hardware and the application software,

so that the application software only needs to call the application programming interface (API) of the system software to allow the hardware to complete the required work. If there is no operating system in the system, engineers can customize the interface according to the characteristics of hardware devices, such as SerialSend () and SerialRecv () for serial ports; LightOn () and LightOff () for LEDs; and FlashWrite ), FlashRead () and so on. In the case of an operating system, the device-driven architecture is defined by the corresponding operating system, and the driver engineer must design the device driver according to the corresponding architecture so that the device driver can be well integrated into the operating system kernel.

Drivers communicate hardware and applications, while drive engineers communicate with hardware and application engineers.

With the rapid development of communications and electronics industry, a large number of new chips are produced every day in the world. A large number of new circuit boards are designed. Therefore, a large number of device drivers need to be developed. These devices play an irreplaceable role in driving, or running in a simple single-tasking environment, or in multi-tasking operating systems environments such as VxWorks, Linux and Windows.

Second, the difference between the operating system

1) Device driver without operating system (bare metal)

Not every computer system must run the operating system, in many cases the operating system is not necessary. For functions that are relatively simple and control is not complicated system, such as bus credit card machines, refrigerators, microwaves, simple mobile phones and PHS, does not require complex tasks such as multi-task scheduling, file system, memory management, single task architecture They are well supported for their work. Inclusion of an infinite loop Detection of device interrupts or polling of devices is a typical architecture for software in such a system. Bare metal to achieve a bit similar to the microcontroller (MCU), although the microcontroller registers are not so much, if the bare metal driver, I think, should be competent SCM work, huh, huh.

In such a system, although there is no operating system, but the device driver must exist.

In general, each device driver is defined as a software module containing .h files and .c files. The former defines the device-driven data structure and declares external functions, and the latter implements the device driver. The book cited a serial driver serial.c serial.h serial port, mainly to configure GPIO, serial port control registers, and send and receive serial (read and write) registers, and these configurations are custom functions, such as serial Write (send) SerialSend function.

Other modules need to use this device, you only need to include the device-driven header file serial.h, and then call one of the external interface functions can be. If we want to send the string “Hello World” from the serial port, use the function SerialSend (“Hello World”, 11).

Thus, in the absence of an operating system, the device-driven interface is submitted directly to the application software engineer, and the application software directly accesses the device-driven interface without crossing any hierarchy. Device drivers also include interface functions that work directly with the functionality of the hardware without any additional functionality.

It is clearly unreasonable for some engineers to design a single task system to be device-driven at the same level as a specific application software module (ie, the application is also implemented in serial.c, for example), which is not in accordance with the high cohesion low coupling Request.

Another unreasonable design is to directly manipulate hardware registers in the application (a single main.c, all functions are implemented in a function, do not use any other interface / function), rather than a separate design driver module, this Design means that the system does not exist or failed to make full use of the driver code can be reused.

2) device driver with operating system

Device drivers in device drivers without an operating system run directly on the hardware and are not associated with any operating system. When the system contains the operating system, the device driver will become like?

First of all, device-driven hardware operation without operating system is still indispensable.

Without this part, the device driver can not deal with the hardware.

Second, we also need to incorporate device drivers into the kernel. To achieve this convergence, the interface to the operating system kernel must be designed across all device drivers. Such interfaces are dictated by the operating system and are structurally and independently device-specific for a class of devices.

Thus, when there is an operating system in the system, the device driver becomes a bridge between the hardware and the kernel.

The existence of an operating system will inevitably require device drivers to attach more code and functionality (in my opinion, mostly to provide a lot of structure), turning the single “drive hardware device action” into a module for interacting with the hardware within the operating system External presentation of the operating system API, no longer provide direct interface to the application software engineer. With the operating system, the device driver has become more complicated, then what should the operating system do?

First of all, a complex software system needs to deal with multiple concurrent tasks, without an operating system, and it is very difficult to accomplish multi-task concurrency.

Second, the operating system gives us memory management mechanisms.

A typical example is that for most MMU-based processors, Windows, Linux and other operating systems allow each process to access 4GB of memory independently.

The above advantages do not seem to be reflected in the device driver, the existence of the operating system to the device driver what brought the benefits of it?

In short, operating systems serve the purpose of facilitating higher-level applications by creating device-driven problems. If device drivers are designed with the device-independent interface given by the operating system, the application will have access to a variety of devices using a unified system call interface. For UNIX-like VxWorks, Linux and other operating systems, applications through the write (), read () function to read and write files can access a variety of character devices and block devices, regardless of the specific type of device and work, Is very convenient.

Regardless of whether the operating system, whether it is SerialSend, or write, the access device needs to read and write registers, such as serial port, there is a ttys0 node in the dev directory, we can read and write operations through the ioctl function, of course Write, read more directly slightly. The upper application can encapsulate these functions, define different interfaces, in order to achieve more functions