Embedded system engineering magazine 2006.01,02

</Feature>

ESE Magazine Jan/Feb 06

36

Minimizing interrupt response time: 4 simple rules

<Written by> David Kleidermacher, Green Hills Software, Inc. </W>

A failure to meet a response time requirement in a real-time system can be catastrophic. Sound programming coupled with proper RTOS interrupt architecture can ensure a minimal yet guaranteed worst case response time.

1. Keep interrupt service routines (ISRs) short

Avoid loops and other constructs which increase latency. When an interrupt fires, the microprocessor typically disables interrupts before executing the ISR. By keeping ISRs simple, developers avoid the common pitfall of leaving interrupts disabled for too long, increasing the latency of higher priority interrupts.

2. Do not disable interrupts

A major contributor to increased latency is the number and length of regions in which the operating system disables interrupts. By disabling interrupts, the kernel increases latency of high priority events that arrive in those disabling windows. Most operating systems employ what we call a Simple architecture, which is easy to implement: in order to prevent preemption, the kernel disables interrupts for the duration of the critical section

By disabling interrupts, the Simple RTOS is sacrificing the latency of the highest priority event to avoid problems caused by handling of lower priority interrupts. A better solution, implemented in the Advanced architecture, is to never disable interrupts in kernel service calls. Not only does the Advanced RTOS guarantee the minimum possible latency for the highest priority interrupt, but also the worst case latency can be trivially proven.

3. Avoid improper use of operating system API calls in ISRs

ISRs commonly do not require kernel API access: the ISR performs basic operations before acknowledging the interrupt and returning. A more complex ISR is required to wake up a thread, such as by releasing a semaphore, for higher level processing. The RTOS vendor should limit ISRs to a small set of service calls that are necessary and deterministic.

As an example of the peril regarding API usage in ISRs, consider a queue of threads waiting for a resource (e.g. a semaphore). Many Simple RTOSes use an ordinary linked list to hold the queue of threads. When the

resource becomes available, the first thread, regardless of its importance relative to other waiters, is provided the resource. In contrast, the Advanced RTOS automatically wakes up the highest priority waiting thread. Some Simple RTOSes have a service call that pulls the highest priority thread out of the queue and jams it onto the front. One problem with this approach is its usability: the developer must remember to insert prioritisation calls and determine where in the code they belong. Worse, the RTOS must search linearly through the unordered list to find the highest priority thread; real-time behaviour is lost.

The Advanced architecture provides a sec- ond-level handler, sometimes termed a callback, to perform higher level processing when the kernel has returned to a consistent state. If the developer must add a callback in the ISR and then write code in the callback to do the service call, this makes programming more difficult. Not to worry: the Advanced RTOS hides the details of two-level handling by allowing the use of a standard API call which places the callback on behalf of the programmer.

There are some important advantages to the Advanced architecture’s optional two-level handler. By pushing work into the callback (where interrupts are enabled), the Advanced RTOS reduces the temporal footprint of the ISR, in turn reducing the latency for higher priority interrupts (Figure 1). Note that the overhead of the twolevel handling is negligible: a callback entails merely placing a function address on a list for the kernel to call; no heavyweight processing or memory is required.

4. Properly prioritise interrupts relative to threads

When a thread is awakened for higher level processing of the most important event, this thread becomes the most important thread in the system. The thread must complete its processing within a fixed period of time.

In the Simple RTOS, the thread runs with all interrupts enabled. Any low priority interrupt can fire, delaying the most important thread and

Figure 1: Reducing latency for higher priority interrupts.

Figure 2: Minimum response time for events.

www.ghs.com

Embedded PCs		Packaged PCs		LCD Displays
Fieldbus		Flash Storage		Touchscreens

Fanless Pentium M PC Systems

Microspace PC range

Pentium M and Celeron M Processor 1.4G/600MHz

Passive cooling no fan Aluminium case IP50 -40 to 70 deg C

Low power consumption 8 to 30V DC

Vehicle approved CE and E1

100/10 Base-T LAN, miniPCI WLAN, Digital I/O

6 USB 2.0, Audio

3 parallel displays

Fieldbus option

BT878 Framegrabber

DVD-R/CD-RW option

CF & preheat HDD

GPS and GSM option

GSM Sleep/Wake

4 COM option

PC/104 expansion PC/104+ expansion

from £770 net 600MHz 256RAM 40GB HDD

Miles Industrial Electronics Ltd

Phone: [phone]

Buy Online

www.milesie.co.uk

embeddedpcdesign

Compliant. Brilliant!

Designed to provide a fully customised embedded solution with minimal engineering and adaptation costs, the new GX2 ETX is a complete processor core which will enable a custom product to be developed and brought to market quickly and easily.

Geode GX533 processor ETX

400 MHz

512MB DDR RAM

[phone] [e-mail] www.embeddedpcdesign.com

</Feature>

ESE Magazine Jan/Feb 06

38

Application portability across RTOSs and connection media

<Written by> Terry Wright, RTI </W>

Middleware for embedded systems is beginning to make an impact on the embedded space.

ODAY’S EMBEDDED devices are	embedded devices than just putting the compo-	real time diagnostic tools available
connected than ever before. Indeed,	nents together; embedded systems designers	(Stethoscope, MemoryScope, ProfileScope
hard to conceive of a device that does	need to manage the available resources, be it	,CoverageScope and TraceScope) so their expe-
require connection capabilities in	the amount of work the CPU can be expected to	rience in the real-time environment is widely
Ttoday’s world. There is a plethora of connection	do or the amount of memory available and	acknowledged. Such experience, coupled with
mechanisms, from the ubiquitous Ethernet and	required. Embedded devices are usually expect-	their long-standing involvement in Publish-
serial connections, to USB, Wi-Fi and fabric	ed to operate 24/7 without failure, and some	Subscribe middleware and the drive for open
technologies. RTOS vendors deliver an essential	safety critical systems need to have built in	standards, motivated RTI to chair the OMG stan-
service to developers by providing an efficient	redundancy and automatic failover.	dardization committee for the DDS specification.
and productive environment for system design	Effective Data Distribution middleware must	RTI designed their implementation of the
and integration. As well as providing an opti-	also cater for real-time requirements. How is task-	DDS specification (NDDS4.0) to be RTOS-friend-
mized platform for single node application
development, the modern RTOS environment	Developers now frequently have to deal with
must integrate the huge range of device drivers
and protocol stacks needed to meet increasingly	applications which span multiple connected nodes
complex distributed system requirements, and
also facilitate hardware to software integration.
What has changed in recent year’s is that
system developers now frequently have to deal
with applications which must span multiple con-
nected nodes; they also have to run across mul-
tiple hardware transport mechanisms connecting
those nodes, and even across multiple different
OS’s, from the deeply embedded RTOS through
RT Linux and up into the enterprise space where
standard Unix and Windows systems are run-
ning. This is where middleware solutions are
needed, providing the simplifying model of a sin-
gle API that spans multiple OS’s and CPU types.
Much as in the enterprise space, where mid-
dleware has been a key application enabler for
many years, the embedded device space is now
recognizing its increasing importance to cost effec-
tive application development and deployment.
Open standard
Data Distribution Services (DDS) is an embed-
ded middleware solution that delivers common
data distribution capabilities for almost any con-
nection mechanism and RTOS or enterprise OS,
but tuned to the real-time performance and
memory requirements of what are, after all,
highly demanding embedded devices and sys-
tems. Even better, the DDS mechanism is a pub-
lished open standard developed and supported
by the Object Management Group (OMG), which
is already being adopted by a number of embed-
ded software developers and vendors.
Of course there is more to developing	which developed some of the most widely used

Copyright © 2006 Kontron AG. All rights reserved. Kontron and the Kontron logo and all other trademarks or registered trademarks are the property of their respective owners and are recognized. Rev. #G041eu01-WMH

				3
			C
		l-
	ne
Pa
e

Our info hotline:

Tel. + 44 1243 523500

www. kontron-emea. com u ks a l e s @ ko n t ro n . c o m

14.02. - 16.02.06

Ha l l 1 2 , B o o t h 4 0 4

ePanel - C3

ΨFull featured SBC, e.g. for mobile applications

ΨReal Low-Profile

ΨSupports digital and LVDS displays

ΨLow power x86 compatible CPU

ΨVIA Eden CPU 300 MHz to 1 GHz versions

ΨMPEG2 hardware decoder

ΨWide range power supply (8 - 28 Volt)

ΨTouch Screen Support

ΨPrepared for wireless connections via PC-Card-Slot or MiniPCI-Interface

ΨFlexible I/O Concept via adapters

If it‘s Embedded, it‘s Kontron.

</Feature>

The fourth RTOS

<Written by> Kevin Pope, Quadros Inc. </W>

Cores combining MCU and DSP architectures require a different kind of RTOS.

HE EMBEDDED software market has	optimized for the interrupt-driven control envi-
historically developed two fundamentally	ronment of the MCU, or for the data-flow envi-
different RTOS architectures, each designed	ronment of DSP? In the same way that silicon
Tserve the needs of the underlying proces-	has been forced to converge, a fourth RTOS

The question is how to fit more features and functions into an ever decreasing physical space

ESE Magazine Jan/Feb 06

40

Table 1: Single stack advantages

Multitasking Architecture
for Control Plane Processing	for
One stack per task	All
Multiple priorities
Preemption between priorities
Context saved and restored as needed	No
Can wait for an event	Cannot
Lower priority than threads	Run

• Q u a l i t y a n d r e l i a b i l i t y by d e s i g n • L o n g t e r m s u p p l y •

PERFORMANCE IN THE EXTREME

Intel® Pentium® M Processor embedded SBCs for demanding environments

MAT 1100

•Intel® Pentium® M Processor 1.4,1.8,2.1G

•5V only PICMG 1.0

•-30°C option

•Ideal upgrade for Pentium® III and Pentium® 4 designs

•Far lower power than the Pentium® 4

•Intel® Extreme 2 Graphics

•Optional High Performance Graphics using ATI 9000, dual screen, DVI/DFP, LVDS

•2 Serial, 4 USB, dual Gigabit Ethernet, Sound, CompactFlash

MAT 1111

•Intel® Pentium® M Processor 1.4G (738), 1.8G or 2.1G

•Intel® Celeron® M Processor 600Mhz

•Low power 12 watts to 36 watts depending on CPU and loading

•EBX size, Mini PCI, PC/104-Plus, CompactFlash

•Heat spreader plate to support sealed system design

•Fanless option

•Extended temperature -30°C power on option

•Intel® Extreme 2 Graphics, LVDS, CRT

•High Performance Graphics using ATI, dual screen, DVI/DFP

•Two independent video input channels; mux up to 4 inputs

•5V only

-30°C Power On

12 to 36 watts -

for fanless sealed system design

Contact us

Europe & rest of world: Microbus plc

Tel: [phone] Fax: [phone] email: [e-mail] www.embedded-pc.com

Two Philips 7130 for PAL/NTSC input

	For full specifications go to our website
USA & Canada:	www.embedded-pc.com

	Microbus Inc
	Tel: [phone] or [phone]
	Fax: [phone]	<> Microbus
	email: [e-mail]
	www.embedded-pc.com

Designed and manufactured in the UK

B e t t e r b y d e s i g n

</Feature>

ESE Magazine Jan/Feb 06

42

XP & real-time systems

<Written by> Paul Fischer, TenAsys Corp </W>

A virtual machine approach combines a Windows interface with an RTOS.

T

designers component Unfortunately, substantial plexity, and headaches. tem, where Windows

reduces the cost of goods and complexity, and simplifies the coordination of Windows with real-time processes.

Typical real-time Windows solutions utilize a Windows driver inserted in the Windows kernel, an approach that presents many software design challenges. A true dual-OS solution employs virtual machine technology where the non-determinis- tic application elements execute on a “Windows virtual machine,” and deterministic software executes on a “real-time virtual machine” (see figure). A significant advantage of this virtual machine approach is the leverage application developers gain by using a single standard development tool for both environments.

Interval timers

Real-time processes and threads running on the RTOS virtual machine need access to highspeed interval timers for accurate, low-drift time measurements and for generating exact periodic intervals to insure precise control of real-time systems. x86 APIC uniprocessor and multi-processor systems, the vast majority of embedded and desktop Windows platforms built today, are excellent candidates.

To insure efficient implementation of realtime threads, developers need an environment that supports direct access to I/O and memory, a fixed priority scheduling system with priorityinversion protection, and simplified interrupthandling services. They can then create and deploy sophisticated real-time applications without having to write complex and cumbersome device drivers for access to real-time hardware, simplifying development and debugging of control and data acquisition algorithms.

The net gain of the virtual machine “singlecomputer dual-OS” approach is elimination of redundant computer and communication hardware and faster communication and coordination between the real-time and Windows appli-

real-time applications to operate as part of the Windows kernel. Kernel mode code has privileged access to the entire memory space, including the Windows kernel and other device drivers; it lacks address isolation and memory protection. A real-time thread running on such a system can easily overwrite other processes: both real-time and Windows processes. Because such programming errors are difficult to detect in kernel mode and result in spurious but critical failures, achieving reliable operation through this method often requires extensive testing and debugging. Many such errors are not detectable until the system has been deployed in the field. Creating a complex, multi-threaded, real-time application to run inside the Windows kernel is contrary to the notion of building reliable, safe, and dependable real-time applications.

On the other hand, using a virtual machine to add real-time responsiveness to Windows, as TenAsys’ INtime does, enables the RTOS to maintain reliable operation of real-time processes in the event of a Windows crash. The virtual machine approach to real-time Windows allows real-time applications to run in user-mode, not kernel-mode. The result is improved reliability and robustness, as well as simplified programming and debugging. Each real-time process runs in a separate 32-bit protected memory segment. These segments are distinct from those used by Windows and provide address isolation and protection not just between the real-time processes, but also between real-time processes and non-real-time Windows code.

Dual-core enhancements

Using two virtual machines to share a single CPU platform that supports Windows and real-time, works for a large number of real-time Windows applications. Typically, applications with cycle times of one millisecond or slower are served quite well by this arrangement and have been deployed

Win32 APIs

INtime APIs

Inter-OS

Communication

INtime

Virtual Machine

Figure 1: A virtual machine implementation on an Intel Architecture processor.

on the current crop of desktop and industrial motherboard platforms (uniprocessor and hyper-thread- ed Pentium 4 class processors running at 1-3GHz).

However, some applications demand faster cycle times. For these applications the solution is dual-core processors. Higher speed cycle times mean higher bandwidth controllers, a desirable trait because it leads to improved performance and throughput.

Dual-core processors easily support two operating systems by dedicating one CPU to the RTOS. The CPU instruction cycles of the dedicated core are available 100% of the time to the RTOS. The CPU cycles of all remaining cores become the exclusive property of the Windows virtual machine. Contention for key CPU resources such as pipelines, cache, and the FPU are avoided. Coordination between the two processors is accomplished by using built-in interprocessor communication mechanisms, eliminating context switch. In this scenario, interrupt latencies are reduced by an order of magnitude, from 10-30 microseconds down to 1-3 microseconds. Loop cycle times in the 50-200 microsecond range are able to operate with high precision and accuracy. The advent of inexpensive dual-core hardware means an order of magnitude improvement in the quality and bandwidth of control algorithms can be obtained on a realtime Windows platform!

An RTOS that shares the CPU with Windows, using virtual machine technology, allows embedded Windows applications to take full advantage of the Windows’ standard user interface, network capabilities, development tools, and off-the-shelf software and still deliver the performance required

of critical, hard real-time tasks.	<End/>
www.tenasys.com

NO SLOWING DOWN. EVER. The market won’t care who gets there first. We'll work with you to architect the best embedded solution for your company. And you can start now because we are already doing it. Get your product out there. Fast.

PEDAL TO THE METAL.

www.radisys.com

</Feature>

ESE Magazine Jan/Feb 06

44

MILS: High-assurance security

<Written by> Joe Jacob, Objective Interface Systems </W>

As it becomes possible to connect systems through the Net, how can you preserve their integrity and security?

NOW THAT the Internet and high-speed communications have made it possible to connect military and aerospace systems throughout the world through the

U.S. Department of Defense’s Global Information Grid (GIG), information networks are more vulnerable than ever. An emerging software architecture, Multiple Independent Levels of Security (MILS), was designed to increase the level of security for safetyand mission-critical systems. It combines the best of the safety and security worlds to create a better solution than either could have devised. It draws upon FAA DO-178B Level A Safety technology and Common Criteria EAL7 Security requirements to enable highassurance security for mission-critical embedded and real-time systems, including high-assurance weapons, training and communications systems and C4I platforms. MILS dramatically reduces the size and complexity of security-critical code, thereby allowing faster and more cost-effective development and evaluation.

The central idea behind MILS is to partition a system in such a way that (1) the failure or corruption of any single partition cannot affect any other part of the system or network, and (2) each partition can be security-evaluated and certified separately, so that no partition needs to be evaluated at a higher level than is required for its particular function.

The MILS architecture

To support these partitions, the MILS architecture is divided into three layers, the Separation Kernel, Middleware and Applications.

Separation kernel: The MILS separation kernel divides the computer into separate address spaces and scheduling intervals, guarantees isolation of the partitions, and supports carefully controlled communications among them. Because the separation kernel performs these functions and only these functions, the source code can be small—roughly 4,000 lines of C language code. This makes it fast and practical to verify using formal analysis methods (mathematical verification) and to do the exhaustive testing and comprehensive documentation required for the highest level certifications. The separation kernel requires the highest level of authentication, and is the only piece of software that runs in privileged mode. Therefore, no other code, not even device drivers, has the ability to affect the processor’s protection mechanisms.

Everything else, including all middleware, runs in user mode. The small size of the separation kernel is a manifestation of the most important MILS design objective:

It is because of this rigorous inspection and evaluation that the MILS separation kernel can be trusted. Green Hills Software, LynuxWorks and Wind River each plan on delivering commercially available Separation Kernels.

Middleware: In the MILS architecture, middleware has a broader meaning that just traditional middleware. Most of the traditional operating system functions have been moved from the operating system to “middleware services,” e.g., file systems, device drivers, trusted path, etc. Middleware services include a Partitioning Communications System (PCS) to extend the scope of the separation kernel to inter-system communication. It also includes traditional middleware like CORBA (Common Object Request Broker Architecture), DDS (Data Distribution Service) and Web services. Middleware resides in the same kind of partition as the application that it supports, either co-resident with the application or in a partition by itself. Middleware runs in unprivileged (user) mode, making these services subject to separation kernel policy enforcement. The services that previously ran in privileged mode as part of the operating system, such as memory allocation, device drivers, I/O primitives, file systems, and network stacks, now run in user mode in the MILS middleware layer.

Applications: Applications manage, control, and enforce their own application-level security policies, such as firewalls, crypto services and guards. Instead of the fail-first patch-later approach, trusted components are mathematically verified so that they are “NEAT”: Nonbypassable, Evaluatable, Always invoked, and Tamperproof.

The importance of the PCS

When we create a distributed system configuration, we would like it to be as safe or secure as if it were just a single processor. We accomplish this by implementing end-to-end enforcement of the basic MILS separation kernel policies. The PCS is the enforcement mechanism. The collection of MILS nodes in a distributed system is called an enclave, and the PCS is present in each node in the enclave. The PCS fits between the applications and the partitions implementing

Processor

Figure 1: The basic MILS architecture.

www.ois.com/mils

Why use an RTOS?

<Written by> Tomoyuki Uda, Managing Director, eSOL, Inc </W>

T

</Feature>

An RTOS incorporates useful services that you would otherwise need to implement, debug, and maintain yourself

Most RTOS kernels provide the following set of features:

Multiple threads

An RTOS allows multiple threads of execution, implemented as tasks or processes, depending on the nature of the RTOS.

Preemptive, priority-based scheduling

A preemptive scheduler allows interrupts and higher priority tasks to interrupt the currently running task.

Synchronization services

Multitasking kernel allow tasks to wait for other tasks to complete work, or wait for an event to occur. These services typically include mutual exclusion mechanisms (mutex and/or semaphores), event flags, data queues, etc.

Interrupt and exception support

The RTOS kernel provides a way to handle hardware interrupts and exceptions through installing interrupt and exception handlers.

to perform its functions, and the RTOS handles the hardware interface. Most commercial RTOSes support many CPUs and specific boards.

An RTOS incorporates useful services that you would otherwise need to implement, debug, and maintain yourself in your own code library. Applications using an RTOS can dynamically allocate resources when they are required. Sharing resources reduces the overall memory requirements for the application.

Choosing an RTOS

When you consider how to design your application on the Nios II, you can choose to not use an RTOS at all, to use a free RTOS, or to use a commercial RTOS. If you do choose to use an RTOS, there are freely available solutions and commercial solutions.

The following factors should be considered when choosing an RTOS:

Cost

Developers often adopt open-source solutions because they are free. While the licensing

system shortens the support and development cycle.

PrKERNELv4

PrKERNELv4, from sCOS, is the base of a full RTOS suite called eParts that provides a real time kernel, TCP/IP connectivity with PrCONNECT2, an embedded file system with PrFILE2, integration with a graphical user interface library, and more. The entire eParts product suite is fully integrated into Altera’s development environment for Nios II. Support is also integrated with several Altera third party partners’ software and tools, such as Lauterbach’s Trace32, the MorethanIP 10/100/1000 MACNET Core and the SLS USB Core

Conclusion

Choosing an RTOS doesn’t need to be complex. When choosing an RTOS, consider the features you need as well as associated development costs for porting, support, and software licensing. <End/>

www.esolglobal.com

ESE Magazine Jan/Feb 06

45