D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S
Real-Time Embedded Multithreading:
Using ARM Cores and the ThreadX RTOS
Author:
By Dr. Ed Lamie, Express Logic
Synopsis:
This article contains a discussion of
embedded multithreading used in
the ARM® processor family, and
Express Logic’s popular ThreadX®
real-time operating system (RTOS).
The ARM architecture is arguably
today’s most popular embedded
platform. Because of its inherent
simplicity, it can be found in a wide
variety of devices — from cell phones
to laser printers. Express Logic's
ThreadX RTOS is also simple and
addresses the same target markets
as the ARM processor family. ThreadX
is one of the most popular RTOSs
for the ARM processor, thus this article
has relevance for many embedded
developers, both those familiar with
ThreadX and ARM, and those who
have an interest in learning more
about them.
Information Quarterly
I ntroduction
Multithreading is a common approach to
the software design of a real-time embed-
ded application. In multithreading, sever-
al program segments (threads) share
access to the CPU based on priority or
event-association. This enables real-world
events to dictate the actual flow of opera-
tions performed by the system, and to
avoid system idle time by letting other
threads execute while one thread waits for
an external event.
Programs Time >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Thread-1
Thread-2
Thread-3
Idle Thread
Scheduler
ISR
Event-1
Event-2
Timeline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Idle
Running
Event
Diagram 1
A commercial RTOS is often used to man-
age the execution of a multithreaded real-
time system. The RTOS is software that
performs thread scheduling, interrupt
servicing, message passing, and other
services for the application threads. If a
commercial RTOS is not used, something
functionally similar might have to be cre-
ated by the developer. This article will
focus on the use of a commercial RTOS,
which is rapidly becoming the approach
of choice in embedded development.
Simplicity is a Feature
When approaching the design of a real-
time system, focus should be given to the
application. The RTOS, if any, is there to
make the application’s job easier, not to
[48]
add complexity and difficulty. Thus, sim-
plicity is an asset, or feature, of the RTOS.
In particular, the ThreadX RTOS is simple
and easy to use because of its following
characteristics:
1. Simple API. The Application
Programming Interface (API) should
be intuitive, readable, and consistent,
and there should be a manageably
small number of services that are easy
to find when needed.
2. Full Source Code. This is important
not so every user can modify the RTOS
for special needs, but so a developer
can look at exactly what the RTOS is
doing at any point, and thereby use
the RTOS most effectively.
3. Good Documentation. This is often
an overlooked feature, but good doc-
umentation can be a project lifesaver.
A well organized and clearly written
User Guide with relevant examples,
make a developer’s job easier.
4. Less Is More. An application that has
less RTOS code is easier to debug and
to understand. The more complex a
RTOS is, the more difficult it is to learn
and use. A small footprint RTOS not
only saves memory, but also probably
executes faster.
Volume 3, Number 2, 2004

ThreadX has a reputation for simplicity in
its user programming interface, making it
an ideal reference for a discussion of mul-
tithreading. To illustrate the simplicity of
ThreadX service calls, consider the exam-
ple in Figure 1, which sends a message to
a message queue.
tx_queue_send (&my_queue,
my_message,
TX_NO_WAIT);
Figure 1: Send a Message
In this example, the message called
my_message is sent to the rear of the mes-
sage queue called my_queue. The
TX_NO_WAIT option means that if the mes-
sage queue is full, the thread will not wait
or suspend, and the thread will not send a
message to the queue. All ThreadX service
calls follow this pattern of simplicity and
readability.
RTOS Building Blocks
for System Development
The basic building blocks of an embedded
application, used by the developer in var-
ious ways to manage application code,
are threads, mutexes, memory pools,
counting semaphores, event flags groups,
message queues, and application timers.
Figure 2 contains a complete list of these
building blocks, as provided by the
ThreadX RTOS. Using these building
blocks, the developer can structure a real-
time application quickly, and avoid much
of the programming effort often required
to create and manage an embedded sys-
tem.
The Thread – The Essential
Component
A thread is a semi-independent program
segment that performs some function
required by the application. Typically,
there are multiple threads that combine to
Threads Message Counting
Queues Semaphores
Mutexes Event Flags Memory
Block Pools
Memory System
Byte Clock and Interrupt
Pools Application Control
Timers
Figure 2: Building Blocks
Information Quarterly
D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S
make up a complete system. Threads are
executed in response to real world events
(interrupts) or are scheduled to execute at
certain intervals, such as every N millisec-
onds. ThreadX provides services that
enable threads to schedule themselves,
communicate with other threads, allocate
memory, and easily perform other com-
mon operations. Threads contain several
attributes that may be used to control
their execution or characteristics. Figure 3
shows some thread attributes.
Control Block
Stack
Priority Entry Function
Preemption Threshold
Time Slice
Figure 3: Some Thread Attributes
For example, a thread may adjust its
“Priority” to enable it to “catch up” on
processing if it detects that it is falling
behind. Similarly, a thread can adjust its
“Preemption Threshold” (a feature unique
to ThreadX) to prevent preemption by cer-
tain threads, which in turn helps prevent
problems such as priority inversion.
Thread Execution
If the developer wishes to have a certain
thread executed at a particular time, or
upon occurrence of some external event,
he or she must somehow connect that
thread to an interrupt that corresponds to
that particular time. The developer might
designate one thread to be executed to
process data when it arrives via Ethernet,
as indicated by an interrupt from the
Ethernet controller, for example. Another
thread might need to execute every 20
milliseconds, as indicated by an interrupt
upon the expiration of a timer. The RTOS
makes it easy to assure that the appropri-
ate thread is executed upon the occur-
rence of a particular event. ThreadX pro-
vides interrupt services and optimized
application timers for this purpose.
Interrupt Servicing
Interrupts are important elements of a
real-time system. Efficient processing of
interrupts enables the system to keep up
with more demanding applications where
interrupts occur with great frequency. The
time it takes for a system to respond to an
interrupt and begin executing instructions
[49]
at the beginning of an Interrupt Service
Routine (ISR) is called the Interrupt Latency.
Interrupt service routines can mark
threads as ready to run, triggering a con-
text switch if those threads are of higher
priority than the thread that was inter-
rupted. The ARM architecture provides a
facility for efficient interrupt processing
called FIQ mode. ThreadX enables zero-
latency processing of FIQ interrupts.
Context Switch
When one thread is executing and an
interrupt occurs, triggering the execution
of a higher priority thread, the previously
executing thread is interrupted, its context
saved, and the processor is directed to start
or resume execution of the instructions of
the new thread. This context switch must
be performed quickly, because real-time
systems can require many context switch-
es in a short period of time. On the front
end of interrupt service routines, only the
compiler’s scratch registers are saved ini-
tially. If it turns out that thread preemp-
tion is required, then the remaining regis-
ters in the set are also saved. ThreadX opti-
mizes context switching on the ARM
processor. Only those registers preserved
across function calls are saved (registers
v1-v4, fp, and lr). As a result, ThreadX per-
forms context switch on the ARM proces-
sor in only about 100 cycles, which is one
microsecond on a 100MHz processor.
Thread Communication
with Message Queues
Often, it is necessary for one thread to
exchange information with another
thread. Message queues provide the pri-
mary means of inter-thread communica-
tion.
rear front
msg_n || • • • || msg_3 || msg_2 || msg_1
Figure 4: A Message Queue
Threads can send or receive messages
to/from a message queue, which can store
a number of messages (a queue that can
store only a single message is commonly
called a “mailbox”). Figure 4 contains an
illustration of a message queue. Threads
can suspend themselves while attempting
to send or receive a message from a queue.
Typically, thread suspension involves
waiting for a message from an empty
queue, or waiting for room in a full queue.
Volume 3, Number 2, 2004

Each message queue can contain a num-
ber of fixed-size messages, each limited to
16 words in length. Messages larger than
16 words can be sent using pointers.
Mutual Exclusion Challenges
and Considerations
Since any thread can be interrupted at
any time, and a different thread might be
allowed to execute, the developer must not
assume that a processing sequence will
run to completion. For example, decre-
menting a counter, or adding an element
to a queue. Code sequences that must be
executed in their entirety in order to pre-
vent the possibility of corruption from a
new thread are called “Critical Sections.”
This is analogous to a “Test and Set” atom-
ic instruction found in most processors.
Real-time systems almost always require a
way to deal with issues such as protecting
a critical section, or else the wrong
sequence of events could destroy the valid-
ity of application data. ThreadX contains
an object that handles this issue, the
“mutual exclusion” semaphore, or mutex.
A mutex is the only ThreadX object that
can be owned by a thread. It is also the
only object with a priority inheritance fea-
ture. These properties make the mutex an
ideal object with which to provide mutual
exclusion protection for critical sections. In
Everything you need for designing advanced digital products
“
The most commonly
used embedded
processor core will be
the ARM architecture,
which, product
shipment wise, will
account for almost
Don’t miss your chance to be an integral part of this inaugural event!
two out of every three
For proposal submission and registration go to www.arm.com/developersconference
dollars. For sponsorship opportunities go to www.convergencepromotions.com
”
In-Stat MDR
Brought to you by:
Information Quarterly
D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S
order to protect its critical section, a thread
first “gets” a mutex (tx_mutex_get),enters
its critical section, and then gives up the
mutex upon completion of the section.
Only one thread can own a mutex, thus
providing the necessary protection.
Memory Allocation:
Byte Pools and Block Pools
Throughout the execution of an embed-
ded real-time application, it is often neces-
sary for the application to require more
memory than it was allocated upon its
start. This is to avoid wasting memory,
and to allow real-world events to dictate
where memory resources should be allo-
cated. When a thread encounters the need
for more memory, it asks the RTOS, which
manages available memory, to allocate
some for use by the thread. ThreadX pro-
vides two methods of memory allocation
and management: the Byte Pool and the
Block Pool. Byte Pools contain memory
that can be allocated to threads in sizes of
any number of bytes, similar to malloc().
Block Pools enable allocation of memory
in fixed-size blocks, user-defined. There
can be multiple byte pools and/or block
pools each one with a different size. In this
way, thread demands for various sizes of
memory regions can be managed most
efficiently.
October 19-21, 2004
Santa Clara Convention Center
Call for papers
[50]
fixed-size block
fixed-size block
fixed-size block
:
:
fixed-size block
Figure 5: Memory Block Pool
Application Timers
Application timers are maintained by
ThreadX to provide “count-down” services
to provide a variety of time-related duties.
Timers can be set up to operate once (an
one-shot timer), or for recurring operation
(a periodic timer). When a timer expires, it
generates an interrupt and a timer func-
tion (similar to an Interrupt Service
Routine or “ISR”) is executed. The timer
function can affect the processing or even
the scheduling of application threads,
depending on which threads have been set
up to execute when this timer expires.
Conclusion
ThreadX is an easy-to-use RTOS, and is
well suited to applications using the ARM
architecture. The RTOS services are power-
ful, concise, easy to learn and use, and
are optimized for the ARM environ-
ment.
Volume 3, Number 2, 2004