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 computer systems. In product competition, the success of an application system depends to some extent on the user experience of its interface. Therefore, HCI design plays a crucial role in application system design. Embedded systems emphasize the real-time performance and simplification of HCI operation, focusing on time and space efficiency for specific applications on specific platforms. In traditional small system design, program design typically employs a foreground/background workflow. The application program is an infinite loop, calling corresponding functions to complete specific 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 practically achievable. 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 it takes 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. In addition, this human-machine interface design is universal and easy to port to various embedded systems. The MSP430nF149 microcontroller was chosen for this system for the following three reasons: ① The OSD function needs frequent refreshing and data exchange with the host, requiring the microcontroller to have a sufficiently high computing speed, and the embedded system to operate normally for extended periods with low power consumption. ② The real-time operating system itself consumes memory, and the OSD function requires the creation of a font library, necessitating a large memory space; otherwise, external flash memory would be required, increasing design complexity and cost. 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; a high-priority task that is ready can preempt a running low-priority task 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 for 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). Here, 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). Here, "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 *)O, &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 to realize the finite state machine driven by serial port receiving data. (3) Clock module OSTaskCreate(TimcTCk, (void*)O, &TimeTICkStk[], 5); Clock task, using the clock interrupt of the microcontroller, can set the timers required by each task and send them to the task that needs 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 the stop-wait protocol. Before sending data, the data must be packaged. After receiving the data, it must be unpacked. After receiving the data packet sent by the main system, the microcontroller needs to remove the communication protocol field and then process the valid data correctly. For this purpose, a Frame-FSM type data structure is defined to process the received data. The finite state machine driven by the message sent by the host includes the following states; ① Any state. Regardless of the microcontroller's original state, receiving the character 0xaa indicates that a new data frame is about to be sent. If the microcontroller is currently receiving a frame, it will discard the original data and 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 that an escape character has appeared in the system. In this case, the escape character flag is set to 1, the currently received data is discarded, and the process returns. Each time the reconstructed frame processing function is entered, the system first checks if the escape character flag is 1. If it is 1, it escapes the current character (0x00, escapes to 0xaa; 0x01, escapes to 0xfc; other characters are discarded), and then clears the escape character flag again. ③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. Upon receiving the start character Oxaa, the state transitions to AA_SYN_STATE; other characters are discarded. ④AA_SYN_STATE, Synchronization Character Received State. 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, Source Address Received State. At this time, the source address is compared to the host address. If yes, the system transitions to receive destination address state; otherwise, it transitions to the initial state. ⑥DEST_ADDR_STATE, Destination Address Received State. At this time, the destination address is compared to the MCU address. If yes, the system transitions to receive data length state; otherwise, it transitions to the initial state. ⑦DATA_LEN_STATE, Data Received Length State. The data length is backed up, and the system transitions to receive data state. ⑧DATA_STATE, Normal Data Reception State. Received data is stored in the receive array REBUF. For each received data item, 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 reaches 0, it indicates that all 1 frames of data have been received, and the system transitions to the checksum verification state. ⑨CHECKSUM_STATE, Checksum Reception State. The received checksum is compared with the locally calculated checksum. If they 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 new data frames. The corresponding state transition diagram is shown in Figure 2. 2.3.2 The key-value and command-code driven finite state machine (FSM) relies primarily on user interactions with the menu for state transitions, using key values ​​and command codes as the excitation sources, with keyboard messages being the primary source. The application-layer FSM has multiple main states. When the user hasn't pressed any keys or hasn't received 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 task completion, the state is set back to IDLE_STATE. Pressing the cancel key returns to the previous state. Taking user-controlled pan-tilt-zoom (PTZ) rotation as an example, the system initially operates in IDLE_STATE. If the user presses a PTZ lens control key, the system enters the PTZ lens selection state and displays the PTZ lens control menu. After selecting a PTZ control option, the system enters the PTZ direction setting state; selecting the up key switches to the up state. After executing the up command in this state, the system returns to IDLE_STATE, accompanied by corresponding changes in the output menu. Pressing the cancel key returns the user to the previous PTZ lens selection state. For other keys, the system filters them out and does not respond, nor does it transition between states. The PTZ control state transition diagram is shown in Figure 3. 3. Testing μC/OS-IIV2.52 adds two system tasks compared to previous versions: a CPU load monitoring task and a 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, calculating the current CPU utilization and storing it in a signed 8-bit integer 0SCPUUsage with an accuracy of 1%. μC/OS-II memory is fixedly 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, a 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, preventing correct display 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 this paper are independent modules, allowing for flexible loading of control modules onto the microcontroller, making them suitable for various embedded systems.