Abstract: Based on the explanation of embedded system software design methods, this paper introduces the design of the portability of the underlying software of embedded systems and the establishment of the hardware abstraction layer; and illustrates the design and testing process of embedded software using this idea. Keywords: device driver , embedded system software design, portability 1. Embedded system design Embedded systems have advantages such as small size, concentrated functions, and high reliability, and have been widely used in all aspects of daily life, such as mobile communication, industrial control, medical devices, and home appliances. How to shorten the development cycle of embedded systems, reduce development costs, and improve product reliability has become a common concern in the embedded industry. In embedded system design, the following design methods are usually adopted. (1) Waterfall mode development process The waterfall mode development process has a simple working mode, and the division and coordination of tasks, personnel arrangement, and material allocation and management are relatively easy. As shown in Figure 1, the development process is carried out in a pipeline manner from hardware to software. This type of development method has the following characteristics: ◇ Small systems, such as low-speed signal acquisition controlled by 8051; ◇ Limited human and material resources required for development, generally completed by one or a few people; ◇ Requires developers to be familiar with both software and hardware design and manufacturing; ◇ Low requirements for development cycle, this type of development process will undoubtedly use the longest development cycle; ◇ During the development process, any blockage in any link will affect the development of other links. (2) V-mode development process The V-mode development process is a parallel working method. The division and coordination of tasks, personnel arrangement, and material allocation must take into account different work contents, as shown in Figure 2. The development process is carried out simultaneously with hardware and software, and finally jointly debugged. This type of development method has the following characteristics: ◇ Large systems, such as network switching/access devices designed using processors such as PowerPC; ◇ Relatively abundant human and material resources for development; ◇ The division of labor among developers is relatively clear. Software developers do not need to know too much hardware information, and hardware developers do not need to know too much about software; ◇ It is conducive to shortening the development cycle; ◇ During the development process, software and hardware design are carried out independently. Hardware development blockages do not affect software development processes, and similarly, software development blockages do not affect hardware development processes. However, the following problems still exist in the V-mode development process: ◇ Poor portability of device drivers, which are closely related to both hardware and operating system; ◇ Software testing can only be carried out after the hardware is completed; ◇ Each device driver designer needs to have a background in both software and hardware; ◇ During testing, it is difficult to determine whether the error is caused by hardware or software. In order to overcome the above problems in the V-mode development process, this paper makes a slight improvement to the V-mode development process by adding a hardware abstraction layer, which isolates the system software and hardware, thereby improving the portability of the system software and effectively utilizing human resources, shortening the development cycle and improving the reliability of the product. 2. System software design characteristics based on hardware abstraction layer (1) Comparison of system structure with hardware abstraction layer Figure 3 and Figure 4 show that the hardware abstraction layer completely isolates the system software and hardware, which makes the system's device drivers independent of the hardware devices, thereby greatly improving the system's portability. From the perspective of software and hardware testing, the testing of software and hardware can be completed separately based on the hardware abstraction layer, making it possible to conduct software and hardware testing in parallel. In terms of the definition of the abstraction layer, a unified software and hardware interface standard needs to be specified. Its design work needs to be based on system requirements, and the coding work can be completed by personnel who are familiar with the hardware. The abstraction layer should generally include functions such as the initialization of related hardware, data input/output operations, and hardware device configuration operations. (2) The system development process including the hardware abstraction layer As shown in Figure 5, the V-mode development process including the hardware abstraction layer, after the system requirements are analyzed and the design requirements of the software and hardware are defined, it is necessary to spend a certain amount of time defining the interface of the hardware abstraction layer to ensure that hardware design and testing and software design and testing can be carried out on the same interface, which is conducive to the final software and hardware integration testing. As can be seen from Figure 5, in the V-mode development process based on the hardware abstraction layer, the design and debugging of software and hardware are independent and can be carried out completely in parallel. Hardware errors will not affect the debugging of system software, and similarly, software design errors will not affect the debugging of hardware, which can greatly shorten the system testing cycle and improve the system reliability. (3) Characteristics of Hardware Abstraction Layer The definition and code design of the hardware abstraction layer interface should have the following characteristics: ◇ The hardware abstraction layer is closely related to the hardware; ◇ The hardware abstraction layer is independent of the operating system; ◇ The functions defined in the interface should include all the functions required by the hardware or system; ◇ The interface definition should be simple and clear. Too many interface functions will increase the complexity of software simulation; ◇ A testable interface design is conducive to the hardware and software testing and integration of the system. 3. Design Example of Hardware Abstraction Layer The design of the hardware abstraction layer interface should generally include the following steps: ◇ Analyze the data transmission characteristics of the interface (bidirectional/unidirectional data transmission, byte-type/data frame-type transmission mode); ◇ Analyze the interface configuration attributes; ◇ Define the relevant functions required by the interface. The following is the interface definition content of the hardware abstraction layer of the UART interface that transmits data in units of characters: ◇ Device initialization function BOOL InitDevice(Device_Register *regs, Device_Attribute *attr) ① The first parameter is a pointer to the device register structure, which is used to index the relevant registers of the device. ② The second parameter is a device attribute structure used to describe the device initialization settings (baud rate, parity, etc.). ③ The function returns a boolean value describing the correctness of the initialization process. ◇ Device Character Input BOOL ReadDevice(Device_Register *regs, unsigned char *c) ① The first parameter is a pointer to a device register structure used to index the relevant registers of the device. ② The second parameter is a pointer to the address space of the character input, used to store the character input from the device. ③ The function returns a boolean value describing the correctness of the device character input. ◇ Device Character Output BOOL WriteDevice(Device_Register *regs, unsigned char c) ① The first parameter is a pointer to a device register structure used to index the relevant registers of the device. ② The second parameter is the character to be output by the device. ③ The function returns a boolean value describing the correctness of the device character output. ◇ Device Attribute Setting BOOL SetDevice(Device_Register *regs, Device_Attribute *attr) ① The first parameter is a pointer to a device register structure, used to index the relevant registers of the device. ② The second parameter is a device attribute structure, used to describe the attributes set during device initialization (baud rate, parity, etc.). ③ The function returns a boolean value indicating the correctness of the device attribute settings. 4. Conclusion The above describes a development process summarized by the author over many years of embedded system development, which has proven highly effective in practical applications. It is believed that effectively utilizing this development process in the development of a relatively complex embedded system will improve system portability, reduce product development and testing cycles, and ensure product reliability.