TargetOS™ High-Performance Real-Time Kernel

The TargetOS kernel is fast, small, and preemptive. It has the following benefits and features.

Benefits

Supports implementing real-time applications as multiple semi-autonomous tasks. Tasks are always in one of five states: running, ready, blocked, suspended, or delayed.
Provides for task communication and synchronization, both with other tasks and with interrupt service routines.

Tasks are implemented as light-weight threads assigned a priority at time of creation.
Task priorities can be dynamically changed with OsSetTaskPri(). The new priority takes effect immediately. Tasks pending in a priority queue are dynamically re-ordered in the queue.
A task’s priority is temporarily boosted when holding ownership of a mutex being requested by a higher priority task (priority inheritance).

Semaphores and queues perform either priority or FIFO scheduling of pending tasks. Semaphores are counting semaphores. Message queues have either a fixed maximum size or grow freely, limited only by the amount of available memory.
Mutexes operate like binary semaphores with ownership and priority inheritance to avoid the problem of priority inversion.
Events can make multiple tasks ready with a single system call. Events are posted to a nexus which may contain any number of blocked tasks. Tasks waiting for an event use a 32-bit mask to select which events they respond to.
Timers can be used in a wide variety of system calls. Semaphores, messages, and events can be posted after a fixed delay or posted repeatedly at fixed intervals. Application functions can be called after a fixed delay, or called repeatedly at fixed intervals. Timers can be stopped, tested for expiration, and/or deleted at any time.

Interrupt latency does not increase as the number of tasks, semaphores, queues, etc., increase.
The execution time of every service call is independent of the number of tasks, queues, semaphores, etc., in the system, except for the delete and get identifier calls which are infrequent operations.

Timer-related processing that is variant, such as sorting the timer queue, is performed in the background using daemon tasks. Minimal work is performed up front when a system call requires timer processing, allowing the CPU to return more quickly to the application.
Fast execution. Benchmark results are here.

The scheduler can be configured as non-preemptive, a requirement for some third-party communication protocol stacks. When non-preemptive, running tasks always keep the CPU until making a service call that blocks.
If configured as preemptive, the scheduler always runs the highest priority ready task. The running task is preempted whenever an interrupt makes ready a task with higher priority than the currently running task.
Preemption can be temporarily disabled with OsLockTask(). Preemption is re-enabled by either calling OsUnlockTask(), or by making a service call that blocks.
Tasks may be configured for round robin scheduling among tasks of the same priority. The time slice value is configurable and may be examined or modified at any time.

A compile-time option promotes all service call errors to fatal errors that cause an error message on stderr and a break into the debug monitor. Helps catch simple programming errors that can otherwise waste valuable time.
Kernel objects (tasks, semaphores, queues, mutexes, nexuses, timers) are created dynamically upon request by the application. There is no configuration file to edit and maintain as the application grows. The only limit is the amount of available memory.
Lite version of the kernel available with reduced API and RAM footprint.

isrCreate() creates an entry in the CPU’s vector table and installs “wrapper” routines that save and restore the minimal registers required to allow the service routine to be written in C.
The CPU vector table is initialized at startup with default vectors that allow bus errors and spurious interrupts to be reported on the stderr console.
Interrupt service routines have their own stack allocation.
Supports nested interrupts.

Displays the percent of CPU time used by each task and ISR. Displays the stack low water mark for each task. Displays a log of past system calls including the time of the call, the name of the task or ISR making the call, and the values of the parameters used. Allows interactive querying of the state of each task, semaphore, etc.
Application programs, device drivers, etc. can extend the monitor by adding name strings and code for additional commands.

Integrated with CrossStep™, Blunk’s IDE for embedded development that includes an integrated project builder, kernel-aware source code debugger, on-chip debug connections for board bring-up and Ethernet debug connections for fast application development.

Provided with source code, default compiler settings, linker command files, build files, and a re-entrant Standard C runtime library.
Blunk Microsystems provides board support packages for a range of commercial CPU boards and provides competitive bids on board support packages for custom designs.

Includes source code, User’s manual, sample applications, and one year of technical support.

A full set of middleware components (networking stacks, file systems, USB stack, and graphics library) are available that are developed and supported by Blunk Microsystems and are fully integrated with TargetOS.