T-Kernel’s software architecture features a flexible, layer-type scalable structure, allowing you to change it accordingly to match the system you’re developing. Various setups are available to promote re-use of software. A simple explanation of each program feature that makes up the architecture is provided here.
T-Kernel
T-Kernel consists of: The T-Kernel/Operating System (T-Kernel/OS), the T-Kernel/System Manager (T-Kernel/SM), and T-Kernel/Debugger Support (T-Kernel/DS). The list below shows their functions. T-Kernel/OS is the main part of T-Kernel and includes all task management features, memory management features, and system control features included in a standard Real-Time OS such as µITRON. T-Kernel/OS can only be called T-Kernel in a strict sense.
T-Kernel/OS
(Operating System) |
T-Kernel/SM
(System Manager) |
T-Kernel/DS
(Debugger Support) |
- Task management
- Task-included synchronization
- Task-excluded processing
- Synchronization / communication
- Memory pool management
- Time management
- Interruption management
- System status management
- Subsystem status management
|
- System memory management
- Address space management
- Device management
- Interruption management
- I/O port access support
- Energy saving management
- System structure information management
- Memory cache control
- Physical timer
- Utility
- Subsystem and device driver operation
|
- Kernel internal status acquisition
- Execution trace
|
Device drivers
eT-Kernel follows the device driver specifications prescribed for driver interfaces and drivers. When transitioning programs that use a driver to a new hardware environment, driver interface standardization allows you to re-use applications such as middleware and libraries without changing interface parts.
Subsystem
A subsystem is a setup used for expanding T-Kernel functions. As shown in the diagram, subsystems operate in T-Kernel, with T-Kernel/OS offering a subsystem management function. T-Kernel can also be statically linked to or statically loaded. For example, middleware such as the file system and the TCP/IP protocol stack can be implemented as subsystems. User-created unique libraries, etc. can also be added as subsystems. By implementing middleware or user-created libraries as subsystems, a shared interface can be provided for upper-level applications. Also, since subsystems do not depend on a CPU or board thanks to the layer-type T-Kernel architecture, subsystems simply need to be recompiled to operate when changing hardware, with no repair necessary.
