Abstract uClinux and eCos are two high-performance, open-source, and widely used free embedded operating systems. This paper compares uClinux and eCos, analyzes and summarizes several important issues in embedded operating system applications, and summarizes the selection criteria for operating systems in embedded system development. Keywords Embedded operating system eCos uClinux 1 Introduction to Two Open-Source Embedded Operating Systems uClinux is an excellent embedded Linux version. uClinux is an abbreviation for micro-Control-linux. Compared with standard Linux, it integrates the main advantages of standard Linux operating system, such as stability, powerful networking functions, and excellent file system. However, due to the lack of MMU (Memory Management Unit), its multitasking implementation requires certain skills. eCos (embedded Configurable operating system) is a Red Hat product, but eCos is not Linux or a derivative of Linux. eCos makes up for the shortcomings of Linux in the field of embedded applications. It is an open-source, configurable, portable, royalty-free real-time operating system for deep embedded applications. The core of eCos is composed of different components, including the kernel, C language library, and low-level runtime packages. Each component offers numerous configurable options, which can be easily configured using the configuration tools provided by eCos. Different configurations allow eCos to meet the needs of various embedded applications. For the two publicly available real-time operating systems, the following aspects will be compared. This comparison will provide a reference for choosing the right RTOS for your system. 2. Comparison of Basic Operational Performance 2.1 Application Computing Power When Linux and uClinux operating systems boot, they display the following message: "Calibrating delay 1oop... 0k—xxx BogoMips." This process is called BogoMips (pronounced bogumips). Linus Torvalds introduced BogoMips primarily for two purposes: ① to give users a general idea of ​​the system's computing power; ② because many lines of code in the system require precise software delays, BogoMips is used to obtain the time consumed by each software delay cycle. The BogoMips process is a simple counting loop; it counts how many times `ls` loops and then divides by 500,000 to obtain the BogoMips value. Table 1 shows the results obtained by running the BogoMips application under eCos and uClinux on the target hardware platform, respectively. We used different test conditions, activating and deactivating the AT76C120 memory buffer controller. Table 1 shows that enabling the buffer memory has a greater impact on the performance of the eCos application than uClinux; conversely, disabling the buffer significantly reduces the performance of the eCos application. 2.2 Memory Access Capability A test method that can simultaneously test the buffer controller and standard memory access functions was used to test memory access capability. Here, the CacheBench method proposed by Philip J. Mucci et al. from the University of Tennessee was selected. Its working principle is to repeatedly read/write data in a certain length of memory block sequentially, record the time taken for n repetitions, and divide the total read/write data by the time taken to obtain the time taken to read/write each byte; simultaneously, by adjusting the length of the data block and different read/write methods (using standard functions or direct code read/write), the impact of different conditions on memory read/write was obtained. In the experiment, four different block lengths (256, 512, 1024, and 2048 bytes) were used for each test mode to observe the impact of different block lengths on memory access performance. Table 2 shows the experimental results: Horizontally, eCos' memory access performance is generally better than uClinux; vertically, the performance relationship across the five modes is roughly: buffered read > buffered read, overwrite/write > buffered write > mmmset > mmmcpy. Within the same test mode, for buffered read, larger block lengths result in better memory access performance; while in other modes, memory access performance is basically independent of block length. The analysis based on these results is as follows: ① The reason eCos' memory access capability is better than uClinux is that eCos applications have longer processor time; ② The reason why memory access performance improves with increasing block length in read buffer mode, while remaining unchanged in other modes, is related to the write-back mode of the AT76C120 buffer controller. Because the AT76C120's buffer controller uses a direct write-back buffered write-back mode, the buffer controller provides no buffering for memory write operations. Therefore, when the processor writes to memory, it essentially doesn't benefit from the buffer controller's capabilities, effectively accessing external memory directly. 2.3 Driver Performance Testing To test the system's driver performance, the CF card driver was chosen as the test object. Our testing method is simple: open a large file (10MB) in the application, then call `fread` to read the file, reading 512 bytes at a time into the buffer until the file is completely read. Table 3 shows the test results: uClinux outperforms eCos. This is mainly because uClinux's block driver has a clustering function, which can merge multiple requests to block devices together for execution, thus improving the overall read/write speed for slower devices like disks. 3 Comprehensive Application Performance Comparison We know that an image compression and decompression program often requires large memory access operations, intensive mathematical operations, and numerous disk accesses. Since most handheld embedded devices now require this type of application, an image compression and decompression application meets both theoretical research requirements and practical application needs. Therefore, we chose a GIF image encoding/decoding program as the test program for comprehensive performance testing. The test results are shown in Table 4. We can see that the decoding speed of eCos and uClinux is very low, mainly because they use software decompression entirely; moreover, since the image display format of AT76C120 is YCrCb, while the decompression result of giflib is RGB, floating-point operations must be used to convert the RGB data to YCrCb. The ARM7TDMI of AT76C120 does not support floating-point instructions, so software simulation must be used to complete the floating-point operations, most of which is spent on the conversion from RGB to YCrCb. The test results are basically consistent with the results of the previous basic operating system tests—eCos is better than uClinux overall. 4 Portability The system portability of eCos should be significantly better than that of uClinux. In the eCos system, each hardware platform uses a separate directory to store the code and configuration information of the hardware abstraction layer for that hardware platform, which is easier for users to understand. The hardware abstraction layer (HAL) code in uClinux is distributed across several directories, with code for various platforms mixed in a single source file. Different hardware platform code is selected using `#ifdef` followed by `#end`. Furthermore, eCos requires fewer source code files to be modified during porting compared to uClinux. Portability should not only encompass operating system portability but also application portability. Program portability is determined by two factors. First, the application must be written in a portable manner. A. Dolenc, A. Lemmke, and D. Keppel provide a good explanation of this in their Notes on Writing Portable Programs in C. Second, embedded operating systems provide richer system functions and standard function libraries. The richer the function libraries provided by a system, the more applications can run directly on it without significant modifications. Regarding standard functions, eCos only provides a relatively simple C standard function library and the IEEE floating-point arithmetic library, while uClinux provides a library compatible with glibc under Linux, and glibc is the foundation for most open-source projects. Therefore, it can be seen that uClinux has better compatibility in terms of application portability. 5. Development Mode and Difficulty: eCos's development mode is closer to that of traditional microcontrollers (e.g., static linking of applications), while uClinux's development mode is closer to that of Linux. Therefore, it is foreseeable that eCos will be more popular with designers transitioning from 8-bit microcontroller system development to 32-bit embedded system development, while uClinux will be more favored by designers familiar with Linux. 6. Conclusion Through the above comparison, it can be seen that because eCos was designed with embedded systems in mind from the beginning, it has a significant advantage in performance; conversely, uClinux evolved from Linux, and therefore does not have an advantage in embedded system environments where speed and optimization are paramount. However, due to the strong backing of Linux, its powerful functionality and compatibility are outstanding. If the application is ported from other systems, or the developers have a Linux background, or the development cost accounts for a high proportion of the total cost, then uClinux is more suitable; otherwise, eCos is more suitable.