Abstract: This paper introduces the design and development of a car black box based on an embedded system platform with a 32-bit Samsung S3C44B0X microprocessor as the core. The main problems solved by this system are: 1. Acquisition and processing of car driving status signal data. 2. Design of USB interface so that the data recorded in the black box can communicate with PC or PDA through USB interface. Finally, after system integration, this system can run well. In addition, the embedded operating system uClinux is also used in the design of this system, and its porting process is studied. Keywords: S3C44B0X embedded processor uClinux operating system USB interface car black box The car black box is a car driving recorder, which is used to record the state of the car while driving. With the successful application of black boxes in aircraft, more and more countries are also using this technology in automobiles. As early as 1990, the European Community passed legislation to install black boxes in automobiles, requiring the 15 member states of the European Community to install this device in 9 million commercial vehicles in use within 10 years. The United States, Japan, Hong Kong and Malaysia and other countries and regions have also widely used car black boxes [1]. From a practical standpoint, vehicle black boxes not only accurately reflect the vehicle's condition after an accident but also demonstrate significant effectiveness in preventing such accidents. On October 1, 2004, my country introduced the new "Technical Conditions for Safe Operation of Motor Vehicles" (GB7428-2004), which explicitly requires that passenger vehicles, heavy-duty trucks, and semi-trailers used for highway operation be equipped with and use vehicle driving recorders that meet national standards. Currently, there are over 60 domestic manufacturers of vehicle black boxes that have passed national standard testing. Two-thirds of these are OEM manufacturers or agents selling other companies' products; only about 18 companies truly possess the technology, capital, and production lines, among which Sichuan Daxing, Beijing Weihang, and Huizhou Ruishen are relatively well-known. However, most of their vehicle black boxes use 8-bit or 16-bit microcontrollers as processors, employ assembly language, and have relatively simple operating programs. Although some companies have developed second-generation vehicle black boxes with more functions, they still lack an operating system, resulting in deficiencies in expandability and stability. Abroad, Russia's latest automotive black box can record the changes in the physical quantities of vehicle spatial motion after an accident, thus helping people analyze how the accident happened and how the car can be improved in the future. In terms of embedded systems, ICE in Europe has successfully applied embedded systems to automotive black boxes. 1 Overall System Structure 1.1 Requirements Analysis According to the latest national standard for automotive driving recorders: automotive driving recorders are required to collect, record and store real-time clock, date and driving time, measure, record and store vehicle speed and mileage, etc. For suspected accident data, the recorder should continuously record and store the vehicle speed value and vehicle braking status signal corresponding to the real-time time 20 seconds before stopping at an interval of no more than 0.2 seconds [2]. 1.2 System Structure The main hardware used in this system is: a 32-bit Samsung S3C44B0X processor, signal processing circuit, RS232 standard interface and USB1.1 standard interface, 4M Flash, 8M SDRAM, 4K FRAM, operation keyboard and expansion interface. The operating system used is uClinux. The system architecture is shown in Figure 1. 1.3 Architecture Description: 1. A 32-bit Samsung S3C44B0X processor with a built-in RTC (Real-Time Clock) chip can display Beijing time and clock information. This date and clock information is used to mark the date and clock for all functions of the recorder (recording, storage, output, etc.). Its powerful other functions also provide excellent support for the system's application and future upgrades or expansions. 2. The signal processing circuit processes the signals collected by the car's black box to meet the requirements of our system. 3. This system is equipped with an RS232 standard interface and a USB 1.1 standard interface. The USB interface is used to complete data communication between the car's black box and the computer, making data communication more convenient and faster. 4. The main storage units are 4MB Flash memory for storing the uClinux operating system and recorded data, 8MB SDRAM, and one 4KB FRAM. While the car is running, the recorder continuously records and stores the vehicle's speed and eight braking signals in real time for the 20 seconds before stopping at 0.2-second intervals, and stores this data in FRAM memory. This data will be used as accident-related data. Simultaneously, the recorder samples from FRAM at 0.5-minute intervals and stores the sampling results in Flash memory. 5. The software uses the uClinux operating system, which better meets the requirements of system stability, scalability, and application diversity. 2 Key Technologies 2.1 Signal Data Acquisition and Processing To reduce costs and achieve practicality, the signals used in this system are directly collected from various sensors on the vehicle. The main signals acquired are vehicle speed signals, braking signals, and signals from various lights. 2.1.1 Vehicle Speed ​​Signal Acquisition and Processing The vehicle speed signal acquired by this system is the signal from the ABS wheel speed sensor on the vehicle. Currently, the wheel speed sensor of ABS widely uses a variable reluctance electromagnetic sensor. Research has shown that the signal emitted by the ABS sensor is a sine wave signal, and the frequency of the signal is proportional to the speed of the car. Therefore, we need to convert the frequency of the signal into the corresponding voltage value and then send it to the A/D converter. However, since the car is driving, it causes a lot of interference to the signal emitted by the ABS sensor. Therefore, the signal needs to be processed before the frequency-to-voltage conversion. The signal processing process is as follows: (1) Through the limiting circuit. Since the faster the wheel speed, the larger the amplitude of the sine wave signal, the amplitude of the signal is limited to within ±5 through two Zener diodes. (2) Through the filtering circuit. Since the car generates a lot of high-frequency interference signal when it is running, a second-order active filter with feedback is used to remove the high-frequency interference signal. (3) Through the shaping circuit, the sine wave signal is converted into a square wave signal. (4) Finally, through the frequency-to-voltage conversion circuit. The conversion process is shown in Figure 2. Figure 2.1.2 Acquisition and Processing of Braking Signals and Various Lighting Signals The braking and lighting signals in the car are acquired directly through the car's braking circuit or lighting circuit. Their output is a 12V ground jump signal; therefore, we use an opto-isolator to achieve anti-interference and voltage regulation. 2.2 USB Interface Design USB, or Universal Serial Bus, is a fast and flexible bus interface. Compared with other communication interfaces, the most prominent features of the USB interface are its ease of use and high transmission speed. Therefore, the USB interface is being adopted by more and more systems. To implement this system, this project uses the USB interface to transfer the data recorded and stored in the car's black box to a computer or PDA. We consider the entire system as a USB flash drive, which allows for convenient and fast data transfer. The USB organization defines a series of device classes and subclasses based on different device attributes. The advantage of grouping these devices with the same attributes together is that drivers for this class, primarily for PC hosts, can be developed simultaneously. Currently, USB defines the following classes: Audio, Communication, Display, Human Interface, Mass storage, Image, Printer, Power, PC Legacy, and Physical interface. Since our project requires the entire system to function as a USB flash drive for data transfer, we need to adhere to the Mass storage protocol. Microsoft Windows provides support for the Mass storage protocol, so USB mobile devices only need to follow the Mass storage protocol to organize data and process commands to achieve data exchange with a PC. Furthermore, the Flash storage unit organization uses the FAT16 file system, allowing direct data exchange via the removable disk within a Windows browser. The USB organization currently defines two specifications for Mass Storage protocol transmission: 1. USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport; 2. USB Mass Storage Class Bulk-Only Transport. However, CBI cannot be used for high-speed devices, so our system uses the second transmission method, Mass Storage Class Bulk-Only. In this transmission mode, attention needs to be paid to the settings of certain values ​​in the interface descriptor. Setting the value of bInterfaceClass to 08 indicates that this device is a Mass Storage Class device. Setting the value of bInterfaceSubClass to 06 indicates that the USB device follows the SCSI protocol during transmission. This is because a General Mass Storage Device (GCSD) is a random access, block/sector-based storage device. It can only store and retrieve data from the CPU. The interface of this type of device follows the Direct Access Storage Device (DAV) protocol of the SCSI-2 standard. Setting the value of bInterfaceProtocol to 50 indicates that the USB device is in Bulk-Only Transport mode. When the device is plugged into the USB, the USB searches for the device and requests the corresponding descriptor. After the USB Host obtains the descriptor, it completes the device configuration, recognizes the Bulk-Only Mass Storage device, and then enters Bulk-Only transport mode. In this transport mode, three types of data are transferred between the USB and the device: CBW, CSW, and ordinary data. A CBW (Command Block Wrapper) is a command sent from the USB host to the device. The command format conforms to the command block specified by `bInterfaceSubClass` in the interface, which in this case is the SCSI transport command set. The USB device needs to extract the SCSI command from the CBW, execute the corresponding command, and then send a CSW (Command Status Wrapper) to the host reflecting the current command execution status. The host uses the CSW to decide whether to continue sending the next CBW or data. The host might request the USB device to send data; in this case, specific data needs to be transmitted, and a CSW is sent afterward to allow the host to proceed with the next operation. The operations performed by the USB device are illustrated in Figure 3. It's important to note that Flash memory has the characteristic of allowing random reads but not random writes. Flash memory must be erased before writing, and erasing requires erasing a block or sector. Therefore, before erasing a block or sector, the relevant data in the same block or sector must be saved. If an erase, save, and write operation is performed every time data is received, the system task will be very heavy and unable to respond to the USB Host's requests in a timely manner. Therefore, this needs to be solved by setting a buffer of a certain size. 3 uClinux Operating System In embedded system design, the choice of operating system is crucial. Different operating systems are required for different system requirements. This system mainly considers stability and security, so the uClinux operating system is used. The uClinux operating system is basically the same as the Linux operating system. (1) It is license-free and has high stability, security and customizability. (2) It supports powerful network functions, which makes our system more scalable, such as implementing GPRS and other network functions on it in the future. (3) It has rich open tools, providing C, C++, JAVA and many other development tools, which greatly facilitates the development of our application. (4) There are a lot of documents available for our reference. The biggest difference between them is that uClinux is specially designed to meet the needs of processors without MMU, that is, uClinux cannot use the processor's virtual memory management technology but adopts a real memory management strategy. There are three main aspects to consider during the porting process: 1. If the processor core is not supported by uClinux, a new architecture needs to be added to uclinux/linux-2.4.x/arch/, which is a huge undertaking. However, the ARM7TDMI architecture already exists in our system in the uclinux/linux-2.4.x/arch/armnommu/ directory. 2. Find a configuration file for a processor in the same architecture directory that is close to your processor and modify it to suit your processor. If no suitable one is available, you will need to write it yourself, which is also quite labor-intensive. 3. If some peripheral circuits of this system are not supported by uClinux, you will need to write their device drivers yourself. 4. Conclusion This car black box is an embedded system built on a 32-bit Samsung S3C44B0X microprocessor and the uClinux operating system. It can better meet the requirements of system stability and application diversity, thus recording the vehicle's driving status more completely, accurately, and diversely, providing accurate evidence for accident analysis, and playing a significant role in preventing traffic accidents. In addition, we have made the entire system into a USB flash drive, so that the recorded data can be easily and quickly transferred to a computer or PDA.