eSolid RT Kernel Specification

Source code

The source code of the kernel and all of it's ports are published under free software license, which guarantees end users (individuals, organizations, companies) the freedoms to use, study, share (copy), and modify the software.

The GPL grants the recipients of a computer software the rights of the Free Software Definition (written by Richard Stallman) and uses copyleft to ensure the freedoms are preserved whenever the work is distributed, even when the work is changed or added to. The GPL is a copyleft license, which means that derived works can only be distributed under the same license terms.

For more details visit: https://gnu.org/licenses/gpl.html

Consistent Application Programming Interface

All objects declared in Application Programming Interface are following these naming rules:

• All objects except macros are using CamelCase style names
• All functions, structures and unions are prefixed with: es
• All typedef-ed types are prefixed with: es and postfixed with: _T
• All macro names are in UPPERCASE style, words are delimited by underscore sign
• All macro names are prefixed with: ES_
• All Global variables are prefixed with: g

All API objects are named following this convention: es{group}{action}{suffix}()

• Group:
  • Kern - General Kernel services
  • Thd - Thread management
  • ThdQ - Thread Queue management
  • Sched - Scheduler invocation
  • SchedRdy - Scheduler Ready Thread Queue management
• Suffix:
  • none - normal API object
  • I - I class - Regular Interrupts are locked

All Port Interface objects are named using the rules stated above with certain differences:

• All functions, structures and unions are prefixed with: port
• All macro names are prefixed with: PORT_

Preemptive multi-threading

eSolid RT Kernel uses a preemptive scheduler, which has the power to preempt, or interrupt, and later resume, other threads in the system. The scheduler always runs ready thread with the highest priority.

Round-Robin scheduling

Round-Robin scheduling is very simple algorithm to implement and it is starvation free. It employs time-sharing, giving to each thread a time slice or quantum. Processor's time is shared between a number of threads, giving the illusion that it is dealing with these threads concurrently. This scheduling is only used when there are two or more threads of the same priority ready for execution.

Deterministic

All algorithms used in eSolid RT Kernel implementation are belonging to Constant Time Complexity category. Constant Time O(1) functions needs fixed amount of time to execute an algorithm. Their execution time does not depend on number of inputs.

Configurable

The kernel provides two configuration files kernel_cfg.h and cpu_cfg.h which can be used to tailor the kernel to application needs.

In addition, the kernel implements a number of hooks which can alter or augment the behaviour of the kernel or applications, by intercepting function calls between software components.

Portable

During the design stage of the kernel a special attention was given to achieve high portability of the kernel. Some data types and algorithms are tailored to exploit new hardware features.

Static object allocation

All objects used in eSolid RT Kernel can be statically allocated. There is no need to use any memory management functionality which makes it very easy to verify the application.

Unlimited number of threads

eSolid RT Kernel allows applications to have any number of threads. The only limiting factors for the maximum number of threads are the amount of RAM and ROM memory capacity and required processing time.

Error checking

All eSolid software is using design methods very similar to approaches of contract programming paradigm for software design. The contract programming prescribes that Application Programming Interface should have formal, precise and verifiable specifications, which extend the ordinary definition of abstract data types with preconditions and postconditions. These specifications are referred to as contracts. The contract for each method will normally contain the following pieces of information:

• Acceptable and unacceptable input values
• Return values and their meanings
• Error and exception condition values that can occur during the execution
• Side effects
• Preconditions
• Postconditions
• Invariants

The contract validations are done by assert macros. They have the responsibility of informing the programmer when a contract can not be validated.

Profiling

This feature is not implemented.