PetOS is a self-designed embedded real-time operating system. This article introduces the technical background of PetOS and elaborates on the implementation principles of the task scheduling mechanism, task management mechanism and interrupt management mechanism in the PetOS system, and points out the advantages and disadvantages of PetOS in application. 1 Introduction In the embedded field, embedded real-time operating systems are being used more and more widely. Using an embedded real-time operating system (RTOS) can make more reasonable and effective use of CPU resources, simplify the design of application software, shorten the system development time, and better guarantee the real-time performance and reliability of the system. Since RTOS requires a certain amount of system resources (especially RAM resources), only a few real-time operating systems such as μC/OS II and PalOS can run on small RAM systems. Compared with commercial operating systems such as μC/OS II[2], PalOS[1] is a completely free operating system with open source code and simple kernel. However, the system does not support relatively complex functions such as task priority and interrupts, and cannot meet the needs of embedded electronic devices well. 2 Introduction to PetOS PalOS is a micro-operating system designed by UCLA (University of California, Los Angeles) for sensor networks. The system polls the message queue of each task, and if a message exists, it calls the corresponding message handling function for that task. However, this simple polling mechanism and system architecture cannot meet the needs of more complex applications. PalOS's functionality in task management, system clock management, and interrupt management needs improvement. PetOS, based on PalOS, improves the task scheduling algorithm by introducing the concept of priority. Each task can be assigned a priority based on its importance, and the CPU always allows the highest-priority task in the ready state to run first, thus achieving task priority management. PetOS also provides strict priority scheduling and non-strict priority scheduling modes to alleviate the 'starvation' phenomenon of low-priority tasks when high-priority tasks are continuously scheduled. Figure 1 shows the PetOS kernel framework. Simple polling or priority scheduling cannot guarantee the system's real-time performance. Both scheduling methods are event-driven; a task must complete an event response before the next round of scheduling is executed. Therefore, the system's real-time performance is affected by the granularity of the event response function. To improve system real-time performance, PetOS adds interrupt management and system clock management. Interrupts can be generated by hardware or by the application. After an interrupt occurs, the system will promptly enter interrupt mode for processing, thus ensuring that transactions with high real-time requirements can be processed in a timely manner. The PetOS kernel framework is shown in Figure 1. 3 PetOS Implementation 3.1 PetOS Task Maintenance/Scheduling Module The task maintenance/scheduling module is the core module of PetOS, responsible for task management and scheduling. ·TASK: A TASK is a logical entity of a PetOS application, possessing independent input response, message response, and output control. It is the scheduling entity of PetOS. PetOS tasks have the following 5 states: ·UNREGISTER: Since the Task list uses a static array, this state indicates that the array item is invalid. ·UNINIT: The task has been registered but not yet initialized and cannot be executed. ·STOP: The task is stopped. It does not accept messages and cannot be executed. No data. Figure 2 PetOS Task State Transition Diagram ·RUN: The task is running. It can accept messages and can be executed. ·PAUSE: The task is suspended. It cannot accept messages and cannot be executed. However, it retains data. Tasks are registered when PetOS starts and reside in the operating system. After the operating system is initialized and started, the task list scheduled by the operating system is fixed. After the operating system starts, tasks will only switch between running, paused, and suspended states. The task state diagram is shown in Figure 2. To facilitate task management and control, each TASK is bound to a TCB (task control block). The TCB is similar to the PCB of a process in a modern operating system. It records various state variables, control variables, and function pointers of standard interfaces for the task, which is convenient for PetOS and application maintenance. Event: An event is the granularity unit of PetOS process scheduling. Since each task in PetOS does not have an independent code/data segment/stack pointer, we cannot pause one task and start another at any point. PetOS's solution is to break down tasks into independent event-driven logical modules, each task having its own independent event queue. Each logical function of a task is mapped to an event, and the operating system completes a scheduling by granting a task the right to respond to an event. The operating system's multi-task scheduling can be achieved by tasks responding to events in turn. Task scheduling: Figure 3 shows the scheduling algorithm flowchart. In embedded systems, many applications require absolute priority of execution, such as USB file transfer processing. To address this, PetOS employs a multi-level task mechanism, granting higher-priority tasks greater execution privileges. During scheduling, PetOS prioritizes high-priority tasks. This scheduling method ensures real-time response for high-priority tasks but may result in low-priority tasks never being executed. To alleviate this 'starvation' phenomenon, PetOS provides two optional configurations: • Strict priority scheduling mode: If there are still unresponsive tasks in the high-priority task queue, the high-priority task is executed unconditionally. • Non-strict priority scheduling mode: After one round of scheduling in the high-priority queue, the first task in the next-lower-priority task queue receives one scheduling opportunity. After scheduling, the high-priority queue is polled again. The difference between the two is that strict scheduling mode guarantees absolute priority for high-priority tasks, but low-priority tasks may experience 'starvation'. In non-strict scheduling mode, regardless of task priority, tasks are always executed at a lower frequency. Analysis and optimization of the scheduling algorithm: In non-strict mode, let the lengths of the first, second, and third-level task queues be N1, N2, and N3, respectively. Scheduling a task in a secondary queue requires checking the primary task N1 times; scheduling a task in a tertiary queue requires checking N1×N2 times in the primary queue and N2 times in the secondary queue. When primary and secondary tasks are rarely executed, while the task message granularity in the tertiary queue is small and the execution frequency is high, the system overhead of task scheduling increases sharply. One solution is that PetOS adds a 32-bit message flag to each message queue. Each bit corresponds to a task in that priority. If a bit of the message flag variable is 1, it means that the corresponding task has an unresponsive event; if it is 0, it means that all tasks in that level of queue have completed their events and can schedule the next priority task. Through the message flag strategy, if there are no tasks to be scheduled in the primary and secondary queues, the cost of scheduling a tertiary task is only checking the message flag bits of the primary and secondary tasks once each, thus greatly reducing system overhead. 3.2 Interrupt Management/Timer Function Management Interrupt Management: Since the real-time performance of PetOS is affected by the event granularity, the system needs to provide a stronger real-time guarantee: interrupts. The PetOS interrupt handling module mainly completes the tasks of judging interrupt sources, maintaining interrupt vectors, and scheduling interrupt response functions. PetOS supports 64 interrupt sources [3] and supports an unlimited number of interrupt handling functions for each interrupt source. Therefore, the list is a doubly linked list containing the interrupt handling functions under the interrupt number. After locating, the functions in the linked list are executed in sequence. Using a linked list to maintain the interrupt handling function can maintain the interrupt function list more flexibly. However, in reality, many interrupt functions are one-time use. For example, after the USB connection response function is called, it needs to remove itself from the function list of the interrupt. At this time, the interrupt handling function is using the list, which causes inconsistency in the interrupt function linked list. The solution is: 1) Add status to all function handles. 2) When maintaining the interrupt function list, if the handle is in an idle state, the default operation is performed; if the handle is in an IRQ state and is deleted, the direct deletion operation is not performed for the time being, but the handle status is changed to PETOS_IRQ_HANDLER_CALL_STATUS_DELETE. 3) After the interrupt handling main function finishes calling the function, if it finds that the function handle state has changed, it indicates that the function has unregistered itself during the call. IrqHandler will rewrite the unregistration function in the interrupt maintenance module API at this time, deleting the function handle here. 4) Relink the interrupt function list and locate tmpIrqHandler to find the next interrupt handling function handle. Interrupt Extension Module – System Clock Module and Timer Trigger Function: The interrupt mechanism ensures the real-time response of PetOS to hardware requests, while the real-time response to software requests is handled by the PetOS system clock/timer trigger function module. This module mainly performs two tasks: • System Clock Module: The system generates a time interrupt at fixed intervals. Using the interrupt mechanism mentioned above, we can simulate a near real-time, continuously executing task. The specific method is to register this code as the system clock interrupt handling function. • Timer Trigger Function Module: To meet the needs of embedded electronic product applications, PetOS provides timer trigger function functionality based on the system clock module. Users can register a timer trigger function with the system and specify the time when it will be called. The operating system checks for expired timed trigger functions by using a pre-registered system clock interrupt handler and executes the scheduling accordingly. PetOS's task scheduling is event-based, preventing two tasks from accessing the same code simultaneously. Therefore, most code does not require consideration of reentrancy. 4. PetOS's Shortcomings and Improvement Directions Current scheduling algorithms still suffer from large task priority ranges, potentially causing low-priority tasks to "starve." PetOS's non-preemptive task scheduling mechanism, lacking independent stacks for tasks, results in inflexible scheduling. If one task's message processing time is long, other tasks' message response times will also be long, leading to poor real-time performance and hindering the portability of blocking applications. PetOS does not enable polymorphic execution, instead simply reusing the address space of the OS core and other applications. While this simplifies the system structure, it introduces the risk of other applications directly accessing the OS core's address space. Therefore, scheduling algorithms and memory management will be key areas for improvement in PetOS. 5 Conclusion With the addition of priority scheduling, task management, interrupt management and system clock management, PetOS has transformed from a micro operating system that is only suitable for simple applications into a small operating system that can be applied to complex environments. Due to the modular structure and open code of PetOS, the scalability and maintainability of each solution are greatly enhanced, and the cycle and cost of solution development and product maintenance are greatly shortened. At present, based on the ARM922 hardware platform, PetOS has implemented solutions for embedded consumer electronics products such as MP4/learning machines, and mature products have been launched, proving the market potential of PetOS. With the new application requirements, PetOS will be further improved and play a greater role in the embedded field. References: [1] UCLA Networked and Embedded Systems Lab. PALOS. http://sourceforge.net/projects/palos/ 2002 [2] Jean J. Labrosse. uC /OS-11-Source Code Open Real-Time Embedded Operating System [M], China Electric Power Press, 2001 [3] Du Chunlei. ARM Architecture and Programming [M] Tsinghua University Press, 2003 [4] Shen Shengqing. Research on Kernel of Embedded Operating System [J]. Microcomputer Information, 2006, 2-2: 72-74