Chapter 1 - Introduction to ThreadX

Instead of layering kernel functions on top of each other like traditional microkernel architectures, ThreadX services plug directly into its core. This results in the fastest possible context switching and service call performance. We call this non-layering design a picokernel architecture.

ThreadX is written primarily in ANSI C. A small amount of assembly language is needed to tailor the kernel to the underlying target processor. This design makes it possible to port ThreadX to a new processor family in a very short time—​usually within weeks!

The following are highlights of the ThreadX advanced technology.

Most distributions of ThreadX include the complete C source code as well as the processor-specific assembly language. This eliminates the "black-box" problems that occur with many commercial kernels. With ThreadX, application developers can see exactly what the kernel is doing—​there are no mysteries!

The source code also allows for application specific modifications. Although not recommended, it is certainly beneficial to have the ability to modify the kernel if it is absolutely required.

These features are especially comforting to developers accustomed to working with their own in-house kernels. They expect to have source code and the ability to modify the kernel. ThreadX is the ultimate kernel for such developers.

Because of its versatility, high-performance picokernel architecture, advanced technology, and demonstrated portability, ThreadX is deployed in more than two-billion devices today. This effectively makes ThreadX the RTOS standard for deeply embedded applications.

ThreadX has been certified by SGS-TÜV Saar for use in safety-critical systems, according to IEC-61508 SIL 4. The certification confirms that ThreadX can be used in the development of safety-related software for the highest safety integrity levels of IEC-61508 for the "Functional Safety of electrical, electronic, and programmable electronic safety-related systems." SGS-TUV Saar, formed through a joint venture of Germany’s SGS-Group and TUV Saarland, has become the leading accredited, independent company for testing, auditing, verifying, and certifying embedded software for safety-related systems worldwide.

MISRA C is a set of programming guidelines for critical systems using the C programming language. The original MISRA C guidelines were primarily targeted toward automotive applications; however, MISRA C is now widely recognized as being applicable to any safety critical application. ThreadX is compliant with all "required" and "mandatory" rules of MISRA-C:2004 and MISRA C:2012. ThreadX is also compliant with all but three "advisory" rules. Refer to the ThreadX_MISRA_Compliance.pdf. document for more details.

ThreadX has been certified by UL for compliance with UL 60730-1 Annex H, CSA E60730-1 Annex H, IEC 60730-1 Annex H, UL 60335-1 Annex R, IEC 60335-1 Annex R, and UL 1998 safety standards for software in programmable components. Along with IEC/UL 60730-1, which has requirements for "Controls Using Software" in its Annex H, the IEC 60335-1 standard describes the requirements for "Programmable Electronic Circuits" in its Annex R. IEC 60730 Annex H and IEC 60335-1 Annex R address the safety of MCU hardware and software used in appliances such as washing machines, dishwashers, dryers, refrigerators, freezers, and ovens.

UL/IEC 60730, UL/IEC 60335, UL 1998

When time constraints are imposed on the application software, it is called the real-time software. Embedded applications are almost always real-time because of their inherent interaction with external events.

As mentioned, embedded applications have a dedicated purpose. To fulfill this purpose, the software must perform a variety of tasks. A task is a semi-independent portion of the application that carries out a specific duty. It is also the case that some tasks are more important than others. One of the major difficulties in an embedded application is the allocation of the processor between the various application tasks. This allocation of processing between competing tasks is the primary purpose of ThreadX.

Another distinction about tasks is that the term task is used in a variety of ways. It sometimes means a separately loadable program. In other instances, it may refer to an internal program segment. Therefore, in contemporary operating systems, there are two terms that more or less replace the use of task: process and thread. A process is a completely independent program that has its own address space, while a thread is a semi-independent program segment that executes within a process. Threads share the same process address space. The overhead associated with thread management is minimal.

Most embedded applications cannot afford the overhead (both memory and performance) associated with a full-blown process-oriented operating system. In addition, smaller microprocessors don’t have the hardware architecture to support a true process-oriented operating system. For these reasons, ThreadX implements a thread model, which is both extremely efficient and practical for most real-time embedded applications.

To avoid confusion, ThreadX does not use the term task. Instead, the more descriptive and contemporary name thread is used.

Prior to real-time kernels like ThreadX, most embedded applications allocated processing time with a simple control loop, usually from within the C main function. This approach is still used in very small or simple applications. However, in large or complex applications, it is not practical because the response time to any event is a function of the worst case processing time of one pass through the control loop.

Making matters worse, the timing characteristics of the application change whenever modifications are made to the control loop. This makes the application inherently unstable and difficult to maintain and improve on.

ThreadX provides fast and deterministic response times to important external events. ThreadX accomplishes this through its preemptive, priority based scheduling algorithm, which allows a higher priority thread to preempt an executing lower-priority thread. As a result, the worst-case response time approaches the time required to perform a context switch. This is not only deterministic, but it is also extremely fast.

The ThreadX kernel enables application developers to concentrate on specific requirements of their application threads without having to worry about changing the timing of other areas of the application. This feature also makes it much easier to repair or enhance an application that utilizes ThreadX.

A possible work-around to the control loop response time problem is to add more polling. This improves the responsiveness, but it still doesn’t guarantee a constant worst-case response time and does nothing to enhance future modification of the application. Also, the processor is now performing even more unnecessary processing because of the extra polling. All of this unnecessary processing reduces the overall throughput of the system.

An interesting point regarding overhead is that many developers assume that multithreaded environments like ThreadX increase overhead and have a negative impact on total system throughput. But in some cases, multithreading actually reduces overhead by eliminating all of the redundant polling that occurs in control loop environments. The overhead associated with multithreaded kernels is typically a function of the time required for context switching. If the context switch time is less than the polling process, ThreadX provides a solution with the potential of less overhead and more throughput. This makes ThreadX an obvious choice for applications that have any degree of complexity or size.

ThreadX provides a robust processor-independent interface between the application and the underlying processor. This allows developers to concentrate on the application rather than spending a significant amount of time learning hardware details.

In control loop-based applications, each developer must have an intimate knowledge of the entire application’s run-time behavior and requirements. This is because the processor allocation logic is dispersed throughout the entire application. As an application increases in size or complexity, it becomes impossible for all developers to remember the precise processing requirements of the entire application.

ThreadX frees each developer from the worries associated with processor allocation and allows them to concentrate on their specific piece of the embedded application. In addition, ThreadX forces the application to be divided into clearly defined threads. By itself, this division of the application into threads makes development much simpler.

ThreadX is designed with the application developer in mind. The ThreadX architecture and service call interface are designed to be easily understood. As a result, ThreadX developers can quickly use its advanced features.

All of the benefits of ThreadX accelerate the software development process. ThreadX takes care of most processor issues and the most common safety certifications, thereby removing this effort from the development schedule. All of this results in a faster time to market!

Because of its architecture, ThreadX is easily ported to new processor and/or development tool environments. This, coupled with the fact that ThreadX insulates applications from details of the underlying processors, makes ThreadX applications highly portable. As a result, the application’s migration path is guaranteed, and the original development investment is protected.