Single-Stack RTOS for Embedded Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current real-time operating systems for embedded systems are inefficient due to complex hardware and software designs, leading to high costs and slow startup times, which are unsuitable for resource-limited devices like TV sets and DVD players, and lack features like per-task priority and blocking nested functions.
Innovation Solution
The ROMANTIKI OS uses a single stack for all tasks with priority-based scheduling, cooperative multitasking, context switching via protothreads, and a bitmap scheduler, allowing for fast and deterministic task scheduling, and supports blocking nested functions, reducing stack size and improving development ease.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If standard off-the-shelf operating systems are used in embedded systems, then networking and application tasks can be provided, but the hardware design becomes expensive and complex, and software design becomes inefficient
Solution Approach 1:
The patent segments the operating system into a minimal kernel that provides only essential real-time scheduling and task management functions. All other functionalities (networking, file systems, etc.) are implemented as separate user-space applications, allowing the core OS to remain extremely small while providing adaptability through configurable task combinations.
Solution Approach 2:
The patent extracts and removes all non-essential components from the operating system kernel, keeping only the critical real-time scheduling functionality. This extraction reduces the OS footprint to a minimum while maintaining real-time performance, with other capabilities added only when specifically needed through separate modules.
2Reliability
If standard operating systems with multiple stacks per task are used, then per-task priority and preemptive multitasking are achieved, but RAM requirements increase significantly
Solution Approach 1:
The patent merges all task stacks into a single shared stack structure. Instead of allocating separate stack memory for each task, the system uses one global stack that is dynamically managed through explicit save/restore operations during context switching, dramatically reducing total stack memory requirements while maintaining task isolation through software-based stack frames.
Solution Approach 2:
The patent changes the fundamental parameter of stack allocation from per-task to global-shared. By modifying how stacks are organized (single shared stack versus multiple independent stacks) and managing them through explicit context switching protocols, the system achieves the same task isolation and priority handling with fraction of the memory.
3Quantity of substance
If a single stack is shared by all tasks, then RAM usage is reduced, but it becomes difficult to provide per-task priority and real-time response
Solution Approach 1:
The patent introduces an intermediary context switching mechanism that mediates between the single shared stack and multiple tasks. The context switch structure acts as an intermediary data structure that saves and restores task states, enabling the scheduler to switch between tasks with different priorities while all tasks share the same physical stack memory.
Solution Approach 2:
The patent replaces the mechanical hardware-based stack separation (separate physical stacks for each task) with a software-based solution using explicit context switching. Instead of relying on hardware stack pointers to provide task isolation, the system uses software-managed save/restore operations that achieve the same effect with shared memory.
4Quantity of substance
If cooperative scheduling with single stack is used, then footprint is reduced, but blocking nested functions cannot be implemented
Solution Approach 1:
The patent implements dynamic context switching that allows tasks to be suspended and resumed at arbitrary points. The context switch structure dynamically captures the current execution state including nested function calls, enabling blocking operations within nested functions while maintaining the single-stack architecture. Tasks can block at any level of nesting and be properly resumed when their condition is met.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A real time operating system (RTOS) for embedded controllers having limited memory includes a continuations library, a wide range of macros that hide continuation point management, nested blocking functions, and a communications stack. The RTOS executes at least a first and second task and uses a plurality of task priorities. The tasks share only a single stack. The task scheduler switches control to the highest-priority task. The continuations library provides macros to automatically manage the continuation points. The yield function sets a first continuation point in the first task and yields control to the task scheduler, whereupon the task scheduler switches to the second task and wherein at a later time the task scheduler switches control back to the first task at the first continuation point. The nested blocking function invokes other blocking functions from within its body and yields control to the task scheduler.