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 the 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 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 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 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. Figure 1 shows the human-machine interface system. 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 ample memory space; 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. (1) Event-Object Driven User Interface Model The event-object driven user interface model, also known as the EO model, reduces human-computer interaction activities to the interaction between events and objectives. Events are the information transmitted in human-computer interaction activities, and objectives are the objects of interaction activities; events trigger interaction activities, and objectives are the recipients of interaction activities. The basic behavioral pattern based on the EO model is "object-action" (OA), which is centered on objectives and has an object-oriented style. The EO model consists of four logical components: ① Device management module, which provides interfaces with various interactive devices and realizes device independence; ② Event Management subsystem, which reads input information from input devices to form events and manages them uniformly, interprets the events of feedback information as 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 the objects; ④ 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, so as to form and maintain the interactive process, and is the core of the entire user interface system. (2) Formal description of finite state machine The 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, employing a message-driven approach to drive state changes. One set is a finite state machine driven by serial port data reception as the event object in communication tasks, and the other set is a finite state machine driven by user key presses and command codes as the event object. Under the real-time operating system μC/OS-II, the entire human-machine interface is divided into three modules, implemented through three tasks: a key-value processing module, a host communication module, and a clock module. ● Key-value processing module OSTaskCreate(KEYTaskStart, (void *)O, &TaskKey-Stk[], 7); First, all modules are initialized. Then, in a loop, keyboard input is received and processed. Key-Process(char KeyValue) performs corresponding operations on the menu based on the corresponding input key value and the system's current state. State_Trans(char RxData) is responsible for scheduling the system's state based on the key-value input event and, in the corresponding state, displays the menu based on information received from the main system. ● 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. ● 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. (1) Finite state machine driven by serial port receiving data In order to ensure reliable communication, the system adopts the stop-and-wait protocol. Before sending data, the data must be packaged. After receiving the data, the data 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. To this end, 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 original 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, it will discard the original data and re-enter the state of receiving the synchronization character. ② Arbitrary 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. At this point, 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, the current character is escaped (0x00 is escaped to Oxaa; 0x01 is escaped to Oxfc; other characters are discarded), and then the escape character flag is 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. Upon receiving the start character Oxaa, the state transitions to AA_SYN_STATE; other characters are discarded. ④ AA_SYN_STATE, state upon receiving 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 the source address state. ⑤ SRC_ADDR_STATE, state upon receiving source address. At this point, the source address is compared to the host address. If it is, the system transitions to the destination address state; otherwise, it transitions to the initial state. ⑥ DEST_ADDR_STATE, Destination Address Received. At this point, compare whether the destination address is the MCU address. If yes, transition to the receive data length state; otherwise, transition to the initial state. ⑦ DATA_LEN_STATE, Receive Data Length State. Back up the data length and transition to the receive data state. ⑧ DATA_STATE, Receive Normal Data State. Store the received data in the receive array REBUF. For each received data, increment the corresponding offset address by 1, decrement the received data length by 1, and calculate the checksum. When the data length reaches 0, it indicates that all 1 frames of data have been received, and transition to the checksum verification state. ⑨ CHECKSUM_STATE, Receive Checksum State. Compare the received checksum with the locally calculated checksum. If they are equal, transition to INIT_STATE, process the correct data frame, and send an acknowledgment frame to the master system; if they are not equal, discard the frame, transition to INIT_STATE, and wait to receive new data frames. The corresponding state transition diagram is shown in Figure 2. Figure 2 Data reception state transition diagram (2) Finite state machine driven by key value and command code This set of finite state machines mainly relies on the user's operation of the menu for state transition, that is, the key value and command code are used as the excitation source of the FSM, among which the keyboard message is the most important 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; after receiving a message, it enters the corresponding main state. Then, depending on the key press or the different received command codes, it enters the corresponding sub-state for processing. After the task is completed, the state is set to IDLE_STATE again. Pressing the cancel key can return to the previous state. Taking the user controlling the pan-tilt to rotate up, down, left and right as an example, the system is initially in IDLE_STATE. If the user presses the pan-tilt lens control key, it enters the pan-tilt lens selection state and displays the pan-tilt lens control menu. After selecting the pan-tilt control option, it enters the pan-tilt direction setting state; selecting the up key, it enters the up state. After executing the upward command operation in this state, the state transitions back to IDLE_STATE, accompanied by corresponding changes in the output menu. Pressing the cancel key returns to the previous cloud selection state. For other keys, the system filters them out and does not respond, nor does the state transition. The state transition diagram of the PTZ control is shown in Figure 3. Figure 3 State transition diagram of PTZ control 3. Testing μC/OS-II V2.52 has added 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 fixedly allocated. The maximum stack space actually required by each task can be determined through OSTaskStkChk(), and memory space can be allocated reasonably based on the measurement results. Table 1 shows the system parameters measured by the above functions. Table 1 shows the system parameters and the corresponding debugging tool for the MSP430 microcontroller system, Embedded Workbench, which can track program execution. Running Embedded Workbench on a PC allows tracking changes in various parameters and monitoring microcontroller memory usage. 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 employed. When displaying a large amount of data on the screen while simultaneously receiving data, the microcontroller's processing was untimely. The Workbench debugging tool revealed incomplete data frames received by the receive buffer, preventing correct display on the screen. After porting the operating system, the system operates reliably, and its 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.