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 realtime 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
|
|
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.
