Real-Time Embedded Multithreading Using ThreadX

Edward Lamie

• Publisher: CRC Press
• Year: 2019
• Print ISBN: 9781138460805
• eBook ISBN: 9780429530456
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

This second edition of Real-Time Embedded Multithreading contains the fundamentals of developing real-time operating systems and multithreading with all the new functionality of ThreadX Version 5. ThreadX has been deployed in approximately 500 million devices worldwide. General concepts and terminology are detailed along with problem solving of com

CHAPTER 1

Embedded and Real-time Systems

1.1 Introduction

Although the history of embedded systems is relatively short,¹ the advances and successes of this field have been profound. Embedded systems are found in a vast array of applications such as consumer electronics, “smart” devices, communication equipment, automobiles, desktop computers, and medical equipment.²

1.2 What is an Embedded System?

In recent years, the line between embedded and nonembedded systems has blurred, largely because embedded systems have expanded to a vast array of applications. However, for practical purposes, an embedded system is defined here as one dedicated to a specific purpose and consisting of a compact, fast, and extremely reliable operating system that controls the microprocessor located inside a device. Included in the embedded system is a collection of programs that run under that operating system, and of course, the microprocessor.³

Because an embedded system is part of a larger system or device, it is typically housed on a single microprocessor board and the associated programs are stored in ROM.⁴ Because most embedded systems must respond to inputs within a small period of time, these systems are frequently classified as real-time systems. For simple applications, it might be possible for a single program (without an RTOS) to control an embedded system, but typically an RTOS or kernel is used as the engine to control the embedded system.

1.3 Characteristics of Embedded Systems

Another important feature of embedded systems is determinism. There are several aspects to this concept, but each is built on the assumption that for each possible state and each set of inputs, a unique set of outputs and next state of the system can be, in principle, predicted. This kind of determinism is not unique to embedded systems; it is the basis for virtually all kinds of computing systems. When you say that an embedded system is deterministic, you are usually referring to temporal determinism. A system exhibits temporal determinism if the time required to process any task is finite and predictable. In particular, we are less concerned with average response time than we are with worst-case response time. In the latter case, we must have a guarantee on the upper time limit, which is an example of temporal determinism.

An embedded system is typically encapsulated by the hardware it controls, so end-users are usually unaware of its presence. Thus, an embedded system is actually a computer system that does not have the outward appearances of a computer system. An embedded system typically interacts with the external world, but it usually has a primitive or nonexistent user interface.

The embedded systems field is a hybrid that draws extensively from disciplines such as software engineering, operating systems, and electrical engineering. Embedded systems has borrowed liberally from other disciplines and has adapted, refined, and enhanced those concepts and techniques for use in this relatively young field.

1.4 Real-time Systems

As noted above, an embedded system typically must operate within specified time constraints. When such constraints exist, we call the embedded system a real-time system. This means that the system must respond to inputs or events within prescribed time limits, and the system as a whole must operate within specified time constraints. Thus, a real-time system must not only produce correct results, but also it must produce them in a timely fashion. The timing of the results is sometimes as important as their correctness.

There are two important subclasses of real-time constraints: hard real-time and soft realtime. Hard real-time refers to highly critical time constraints in which missing even one time deadline is unacceptable, possibly because it would result in catastrophic system failure. Examples of hard real-time systems include air traffic control systems, medical monitoring systems, and missile guidance systems. Soft real-time refers to situations in which meeting the time constraints is desirable, but not critical to the operation of the system.

1.5 Real-time Operating Systems and Real-time Kernels

Relatively few embedded applications can be developed effectively as a single control program, so we consider only commercially available real-time operating systems (RTOSes) and real-time kernels here. A real-time kernel is generally much smaller than a complete RTOS. In contemporary operating system terminology, a kernel is the part of the operating system that is loaded into memory first and remains in memory while the application is active. Likewise, a real-time kernel is memory-resident and provides all the necessary services for the embedded application. Because it is memory-resident, a realtime kernel must be as small as possible. Figure 1.1 contains an illustration of a typical kernel and other RTOS services.

Figure 1.1: RTOS kernel

The operation of an embedded system entails the execution of processes, and tasks or threads, either in response to external or internal inputs, or in the normal processing required for that system. The processing of these entities must produce correct results within specified time constraints.

1.6 Processes, Tasks, and Threads

The term process is an operating system concept that refers to an independent executable program that has its own memory space. The terms “process” and “program” are often used synonymously, but technically a process is more than a program: it includes the execution environment for the program and handles program bookkeeping details for the operating system. A process can be launched as a separately loadable program, or it can be a memory-resident program that is launched by another process. Operating systems are often capable of running many processes concurrently. Typically, when an operating system executes a program, it creates a new process for it and maintains within that process all the bookkeeping information needed. This implies that there is a one-to-one relationship between the program and the process, i.e., one program, one process.

When a program is divided into several segments that can execute concurrently, we refer to these segments as threads. A thread is a semi-independent program segment; threads share the same memory space within a program. The terms “task” and “thread” are frequently used interchangeably. However, we will use the term “thread” in this book because it is more descriptive and more accurately reflects the processing that occurs. Figure 1.2 contains an illustration of the distinction between processes and threads.

Figure 1.2: Comparison of processes and threads

1.7 Architecture of Real-time Systems

The architecture of a real-time system determines how and when threads are processed. Two common architectures are the control loop with polling⁵ approach and the preemptive scheduling model. In the control loop with polling approach, the kernel executes an infinite loop, which polls the threads in a predetermined pattern. If a thread needs service, then it is processed. There are several variants to this approach, including time-slicing⁶ to ensure that each thread is guaranteed access to the processor. Figure 1.3 contains an illustration of the control loop with polling approach.

Although the control loop with polling approach is relatively easy to implement, it has several serious limitations. For example, it wastes much time because the processor polls threads that do not need servicing, and a thread that needs attention has to wait its turn until the processor finishes polling other threads. Furthermore, this approach makes no distinction between the relative importance of the threads, so it is difficult to give threads with critical requirements fa...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication Page
• Table of Contents
• Preface
• 1 Embedded and Real-time Systems
• 2 First Look at a System Using an RTOS
• 3 RTOS Concepts and Definitions
• 4 RTOS Building Blocks for System Development
• 5 The Thread—The Essential Component
• 6 Mutual Exclusion Challenges and Considerations
• 7 Memory Management: Byte Pools and Block Pools
• 8 Internal System Clock and Application Timers
• 9 Event Notification and Synchronization with Counting Semaphores
• 10 Synchronization of Threads Using Event Flags Croups
• 11 Thread Communication with Message Queues
• 12 Advanced Topics
• 13 Case Study: Designing a Multithreaded System
• Appendix A: Memory Block Pool Services
• Appendix B: Memory Byte Pool Services
• Appendix C: Event Flags Group Services
• Appendix D: Interrupt Control Service
• Appendix E: Mutex Services
• Appendix F: Message Queue Services
• Appendix G: Counting Semaphore Services
• Appendix H: Thread Services
• Appendix I: Internal System Clock Services
• Appendix J: Application Timer Services
• Appendix K: ThreadX API
• Appendix L: ThreadX and the ARM Microprocessor
• Appendix M: ThreadX and the ColdFire Microprocessor
• Appendix N: ThreadX and the MIPS Microprocessor
• Appendix O: ThreadX and the PowerPC Microprocessor
• Index