Introduction A human-computer interface (HCI), also known as a user interface, human-computer interaction, or human-computer interface, is a medium for transmitting and exchanging information between humans and machines. It is the comprehensive operating environment for users of a computer system. In product competition, the success of an application system depends to some extent on the user experience of the interface. Therefore, the design of the HCI plays a crucial role in the design of application systems. Embedded systems emphasize the real-time performance and simplification of HCI operations, focusing on time and space efficiency for specific applications on specific platforms. In traditional small system design, program design generally adopts a foreground-background workflow. The application program is an infinite loop, calling corresponding functions to complete corresponding operations. Time-sensitive critical operations are guaranteed by interrupt services. Because the information provided by the interrupt service is not processed until the background program reaches the step where it is supposed to process this information, the timeliness of information processing in such a system is worse than what is actually possible. The worst-case task-level response time depends on the execution time of the entire loop. Because the execution time of the loop is not constant, the exact time for the program to pass through a specific part is also uncertain. If the program is modified, the timing of the loop will also be affected. Real-time operating systems decompose applications into multiple tasks, simplifying the design of application system software. Good multi-tasking design helps improve system stability and reliability, and ensures the real-time performance of the system. Many real-time operating systems provide dedicated functions, simplifying program testing. 1. System Design As shown in Figure 1, the human-machine interface system adopts a text menu method with a keypad, used in an embedded digital video recording (DVR) system. μC/OS-II is ported to the MSP430F149 to independently implement the human-machine interface function. The user inputs commands via the keyboard, which are processed by the microcontroller and sent to the main system. Simultaneously, the corresponding information is displayed on the monitor through the OSD (On Screen Display) function of a dedicated chip. The user performs menu operations based on the information on the monitor, forming a human-machine interaction. By separating the human-machine interface from the main system, all user input commands are processed by the microcontroller, reducing the workload of the main system, making the entire system modular, facilitating development and debugging, and improving reliability and stability. Furthermore, this human-machine interface design is versatile and easy to port to various embedded systems. The MSP430nF149 microcontroller was chosen for this system based on the following three reasons: ① The OSD function requires frequent updates and handles data exchange with the host, demanding a sufficiently high computing speed from the microcontroller, the ability for the embedded system to operate normally for extended periods, and low chip power consumption. ② The real-time operating system itself consumes memory, and the OSD function requires building a font library, necessitating a large amount of memory; otherwise, external flash memory would be required, increasing design complexity and cost. ③ A keyboard circuit is needed, requiring numerous I/O ports. The MSP430 series microcontrollers are 16-bit microcontrollers developed by TI. Its outstanding features include ultra-low power consumption, making it suitable for various low-power applications; high processing speed, with an instruction cycle of 125ns driven by an 8 MHz crystal oscillator; the MSP430F149 has 60 KB of Flash ROM and 2 KB of RAM, which can meet the requirements of large system program and data volumes, and can solve the memory requirements increased by loading a real-time operating system; it has two serial communication interfaces, one for communication with the main system and the other for controlling other peripheral modules; it has 48 independently programmable I/O ports, including two 8-bit parallel ports with interrupt functionality, which can be conveniently used to identify key values ​​using interrupt mode when designing button circuits. 2. Software Design and Implementation 2.1 Real-time Operating System μC/OS-II is an open-source real-time operating system with a preemptive kernel that supports multitasking; tasks are divided into five states: sleeping, ready, running, suspended, and interrupted. The kernel processes tasks according to their state, and high-priority tasks that are ready can preempt low-priority tasks that are running from using the CPU. Most of the system code is written in C language, with hardware-related parts concentrated and standardized interface specifications provided, making porting quite convenient. It can be applied to most current 8-bit, 16-bit, and 32-bit CPUs. μC/OS-II provides only an operating system kernel, with very low hardware requirements, making it suitable for developing small systems on low-end CPUs. μC/OS-II was ported to the MSP430F149 microcontroller and then stripped down to only message queues for inter-task communication. Utilizing its task priority preemption mechanism, the human-machine interface effectively meets the real-time and reliability requirements of embedded systems. The following section details the program design based on the μC/OS-II operating system. 2.2 Software Design The software design of this system is based on the EO model, dividing events into events and objectives. Using a finite state machine within the μC/OS-II real-time operating system, the state machine connects objectives and events, implementing the OA (Object-Action) behavior mode to complete the human-machine interaction process, making the text menu design with keypad operation clearer. 2.2.1 Event-Object Driven User Interface Model The event-object driven user interface model, also known as the EO model, reduces human-computer interaction to the interaction between events and objectives. Events are the information transmitted in human-computer interaction, and objectives are the objects of the interaction; events trigger interaction, and objectives are the recipients of the interaction. The basic behavioral pattern based on the EO model is "Object-Action" (OA), with objectives at its core, exhibiting an object-oriented style. The EO model consists of four logical components: ① Device management module, which provides interfaces with various interactive devices and implements device independence; ② Event management subsystem, which reads input information from input devices to form events and manages them uniformly, interprets feedback information events into appropriate output instructions and transmits them to output devices; ③ Object management subsystem, which creates, loads, and saves various objects in the user interface and manages them; ④ Event-object management subsystem, whose main responsibility is to integrate events and objects, control the flow of events between object nodes according to appropriate strategies to form and maintain the interactive process, and is the core of the entire user interface system. 2.2.2 Formal Description of Finite State Machines A Finite State Machine (FSM) consists of states, events, transitions, and activities. Each state has one entry action and one exit action, and each transition has one source state and one target state and is associated with one event. When the event occurs in the source state and the guard condition triggering the transition is true, the following actions are executed sequentially: ① exiting the source state; ② transitioning; ③ entering the target state. The FSM can be formally represented as a quintuple: M = (0, I, λ, S, δ, S0). Where S is a finite set of states; I is a finite set of event inputs; 0 is a finite set of outputs; S0 is the initial state set; δ: S × I → S, the process of entering the next state; λ: S × I → O, the process of generating output. T = δUλ. Each element in T can be represented as a quintuple, T = (Source-State, Target-State, Input-Event, Constraint, Action). Where "Source-State" and "Target-State" represent the initial and target states of T, respectively; "Input-Event" represents the input event from I or is empty; "Constraint" represents the guard condition and input event parameters, etc.; and "Action" represents the action executed during the transition. There are two methods for implementing a finite state machine (FSM) in software: the table method and the process-driven method. The table-driven method uses a two-dimensional array. Each row in the array corresponds to a state, each column corresponds to an input event, and each item corresponds to the handling of the event in a given state. The table-driven method is suitable for finite state machines with regular structures and simple operations. The process-driven method defines a procedure for each state, which implements the response to events in that state, including output processing and transitions to the current state value. This procedure can use case statements to distinguish events and apply appropriate processing. Regardless of the method used to implement the FSM, when the FSM receives a message, it must know the current state. Therefore, each state machine must be able to save its current state. The process method is suitable for implementing a finite state machine with several transitions and complex operations. 2.3 Program Design and Implementation Based on the message-driven programming concept, to ensure the real-time performance of the system, the interrupt is only responsible for sending messages to the message queue of the corresponding task, which is then processed by the application-level task, ensuring that the processing time of each task is deterministic. The main program continuously checks the state of each task in the message loop and executes the task that enters the ready state. This allows for asynchronous handling of various interrupts and tasks. The system program uses two sets of finite state machines, which use message-driven methods to drive state changes. One set is a finite state machine driven by serial port data reception in the communication task, and the other set is a finite state machine driven by user key presses and command codes. Under the real-time operating system μC/OS-II, the entire human-machine interface is divided into three modules, namely three tasks, namely the key value processing module, the host communication module, and the clock module. (1) Key value processing module OSTaskCreate(KEYTaskStart, (void*)O, &TaskKey-Stk[], 7); First, initialize all modules, and then receive and process keyboard input in the loop. Key-Process(char KeyValue) performs corresponding operations on the menu according to the corresponding input key value and the state of the system. State_Trans(char RxData) is responsible for scheduling the state of the system according to the key value input event, and displays the menu according to the information received from the main system in the corresponding state. (2) Host communication module OSTaskCreate(UARTTaskskStart, (void *)0, &TaskU-artStk[], 6); Receives the message queue sent by the serial port interrupt through the message queue OSQPend(OS_EVENT*pevent, INT16U timeout, INT8U*err) and processes the data in it. In the process of human-computer interaction, a lot of interaction with the main system is required. A separate task is used to be responsible for communication with the main system, and a finite state machine driven by serial port receiving data is implemented. (3) Clock module OSTaskCreate(TimcTCk, (void *)0, &TimeTickStk[], 5); Clock task, using the clock interrupt of the microcontroller, can set the timers required by each task and send them to the tasks that need to be timed through the message queue. 2.3.1 Finite state machine driven by serial port receiving data In order to ensure reliable communication, the system adopts a stop-and-wait protocol. Before sending data, it needs to be packaged. Upon receiving data, it needs to be unpacked. After receiving the data packet from the host system, the microcontroller needs to remove the communication protocol field and then process the valid data correctly. Therefore, a Frame-FSM type data structure is defined to process the received data. `typedef struct { byte State; // Current state byte SYM_Plas; // Escape character flag; if 1, it indicates that the current data needs to be escaped by tc DatoLenoth; // Data length byte CheekSum; // Checksum byte Offset; // Offset address, corresponding to the position of the currently received data in the frame byteFrame_Data; // Valid data within the frame } Frame_FSM;` The finite state machine is driven by messages sent from the host. The finite state machine driven by serial port data reception includes the following states: ① Arbitrary state. Regardless of the microcontroller's previous state, receiving the character 0xaa indicates that a new frame of data is about to be sent. At this time, if the microcontroller is in the state of receiving a frame... The original data will be discarded and the system will re-enter the state of receiving the synchronization character. ② Any state (except INIT_STATE). Regardless of the microcontroller's original state, receiving the character 0xfc indicates the presence of an escape character in the system. At this time, the escape character flag is set to 1, the currently received data is discarded, and the system returns. Each time the reconstructed frame processing function is entered, the system will first check if the escape character flag is 1. If it is 1, the system will escape the current character (if the current character is 0x00, it will escape to Oxaa; if the current character is 0x01, it will escape to Oxfc; if it is any other character, it will be discarded), and then the escape character flag will be cleared back to 0. ③ INIT_STATE, initial state. In this state, the offset address and checksum of the reconstructed frame are cleared to 0, and then the system waits to receive data. After receiving the start character Oxaa, the system will transition to AA_SYN_STATE; other characters will be discarded. ④ AA_SYN_STATE, state of receiving the synchronization character. In this state, the MCU clears the offset address and checksum of the reconstructed frame to 0, and then sets the state to receive source address state. ⑤SRC_ADDR_STATE, Receive source address state. At this time, it compares whether the source address is the host address. If yes, it transitions to receive destination address state; otherwise, it transitions to the initial state. ⑥DEST_ADDR_STATE, Receive destination address state. At this time, it compares whether the destination address is the MCU address. If yes, it transitions to receive data length state; otherwise, it transitions to the initial state. ⑦DATA_LEN_STATE, Receive data length state. The data length is backed up, and the MCU transitions to receive data state. ⑧DATA_STATE, Receive normal data state. The received data is stored in the receive array REBUF. For each received data, the corresponding offset address is incremented by 1, the received data length is decremented by 1, and the checksum is calculated. When the data length is reduced to 0, it indicates that all 1 frame data has been received, and the MCU transitions to checksum verification state. ⑨CHECKSUM_STATE, Receive checksum state. The received checksum is compared with the locally calculated checksum. If the two are equal, the state transitions to INIT_STATE, and the correct data frame is processed, with an acknowledgment frame sent to the main system. If they are not equal, the frame is discarded, the state transitions to INIT_STATE, and the system waits to receive a new data frame. The corresponding state transition diagram is shown in Figure 2. 2.3.2 Finite State Machine Driven by Key Values ​​and Command Codes This finite state machine mainly relies on user operations on the menu for state transitions, using key values ​​and command codes as the excitation source for the FSM, with keyboard messages being the primary excitation source. The application layer FSM has multiple main states. When the user does not press a key or does not receive a new data frame, the state is IDLE_STATE; upon receiving a message, it transitions to the corresponding main state. Then, depending on the key pressed or the received command code, it transitions to the corresponding sub-state for processing. After the task is completed, the state is set back to IDLE_STATE. Pressing the cancel key returns to the previous state. Taking the user controlling the pan-tilt unit to rotate up, down, left, and right as an example, the system initially starts in IDLE_STATE. If the user presses the gimbal lens control key, the gimbal lens selection state is entered, and the gimbal lens control menu is displayed. After selecting a gimbal control option, the gimbal direction setting state is entered; selecting the up key switches to the up state. After executing the up command in this state, the state switches back to IDLE_STATE, accompanied by a corresponding change in the output menu. Pressing the cancel key returns to the previous gimbal selection state. For other keys, the system filters them out and does not respond, nor does it switch states. The state transition diagram of gimbal control is shown in Figure 3. 3. Testing μC/OS-IIV2.52 adds two system tasks compared to previous versions: CPU load monitoring task and stack capacity check task. These two tasks greatly facilitate program debugging. Setting the system configuration constant OS_TASK_STAT_EN to 1 will create the statistics task OSTaskStat(). It runs once per second, calculates the current CPU utilization, and stores it in a signed 8-bit integer 0SCPUUsage with an accuracy of 1%. μC/OS-II memory is fixed-allocated. The maximum stack space required by each task can be determined using `OSTaskStkChk()`, and memory space can be allocated reasonably based on the measured results. Table 1 shows the system parameters measured using the above functions. The corresponding debugging tool for the MSP430 microcontroller system, Embedded Workbench, can track program execution. By running Embedded Workbench on a PC, changes in various parameters in the program can be tracked, and the microcontroller's memory usage can be viewed. Conclusion After using μC/OS-II, the overall performance of this system has been greatly improved. Before using the real-time operating system, the foreground/background programming approach was used. When displaying a large amount of data on the screen while simultaneously receiving data, the microcontroller's processing was not timely. The debugging tool Workbench showed that the received data frames were incomplete and could not be correctly displayed on the screen. After porting the operating system, the system is reliable, and the system's response speed, i.e., real-time performance, has been greatly improved. The human-machine interface and embedded main system described in the article are independent modules, and the control module can be flexibly loaded on the microcontroller, making it suitable for various embedded systems.