Asserts

 

Assert Safely

 

Expert programmers use the assert() macro to seed their code with debugging statements. So should we all.

The macro must have no effect on the system – it shouldn’t change memory, interrupt state, or I/O, and it should make no function calls. The user must feel free to sprinkle these at will throughout the program. Disabling the asserts in released code must never change the way the program operates.

The macro generally looks something like:

#define
assert(s)
if (s)
{}else (printf("Error at %s %d: ", __FILE__, __LINE__)

It’s sort of an odd way to write code – if the condition is true (in which case assert() takes no action) there’s a null pair of braces. Why not test the negation of the statement “s”?

Links: http://www.ganssle.com/articles/adifasts.htm

Doing design and debug on real-time distributed embedded applications

Real-time system designers and embedded software developers are very familiar with the tools and techniques for designing, developing and debugging standalone or loosely coupled embedded systems. UML may be used at the design stage, an IDE during development and debuggers and logic analyzers (amongst other tools) at the integration and debug phases.

However, as connectivity between embedded systems becomes the norm, what used to be a few nodes connected together with clear functional separation between the applications on each node, is now often tens or hundreds of nodes with logical applications spread across them.

In fact, such distributed systems are becoming increasingly heterogeneous in terms of both operating systems and executing processors with tight connectivity between real-time and enterprise systems becoming the norm.

This article will identify the issues of real-time distributed system development and discuss how development platforms and tools have to evolve to address this challenging new environment.

The idea of a ‘platform’ for development has long pervaded the real-time embedded design space as a means to define the application development environment separately from the underlying (and often very complex) real-time hardware, protocol stacks and device drivers.

Much as the OS evolved to provide the fundamental building blocks of standalone system-development platforms, real-time middleware has evolved to address the distributed-systems development challenges of real-time network performance, scalability and heterogeneous processor and operating system support.

And as has already happened in the evolution of the standard real-time operating system, new tools are becoming available to support development, debug and maintenance of the target environment ” in this case, real-time applications in large distributed systems.

The Distributed-System Development Platform
From the individual application developer’s perspective, there are three basic capabilities which must be provided by an application development platform when a logical application spans multiple networked computers:

1. Communication between threads of execution
2. Synchronization of events
3. Controlled latency and efficient use of the network resources

Communication and synchronization are fairly obvious distributed platform service requirements and are analogous to the services provided by an OS. However for distributed applications they have to run transparently across a network infrastructure of heterogeneous OS’s and processors with all that implies in terms of byte ordering and data representation formats.

It should ideally use a mechanism that does not require the developer to have an explicit understanding of the location of the intended receiver of a message or synchronizing thread so that the network can be treated as a single target system from an application development perspective.
Links: http://embedded.com/design/networking/205920767

Fundamentals of Real-time Linux Software Design

A typical real-time application involves a task performing some operation within a deadline. For example: storing some data, or updating a display. The task often is designed to repeat such activities ad infinitum, beginning each iteration at the occurrence of a hardware interrupt. This interrupt may be caused by a human clicking a button, a temperature reading, data from a visual sensor, or innumerable other possibilities.

In this article, we’ll discuss Linux, with respect to aiding such systems. For starters, let’s assume that our real-time system involves the following:

• One or more user level tasks
• An interrupt handler
• A single CPU

If there is only a single task to worry about, lots of issues, such as kernel preemptibility, are no longer pertinent. If you are not dealing with hardware interrupts, then, do you really have a real-time system (we include timers here)? If your target system has multiple CPUs then you may have a means of distributing your tasks and interrupts in such a way that the issues discussed, again, are not important.
Links:  http://www.linuxdevices.com/articles/AT5709748392.html

Real-time Linux — what is it, why do you want it, how do you do it?

1. What does “real-time” mean?
2. Who (or what) needs real-time, anyhow?
3. How much real-time is really needed?
4. What are the alternative ways to add real-time to Linux?

In this article, we’ll try to clear away the smoke, and provide some perspective on the subject of real-time Linux.

Here’s the plan. First, we’ll define terms like real-time, hard real-time, soft real-time, and learn how real-time performance is characterized. Next, we’ll learn what sorts of systems need real-time, and how much they need. Then, we’ll compare some of the basic approaches used to add real-time to Linux. Stick around, ’cause at the end of the article, we intend to introduce you to a new, evolving “quick reference guide” to real-time Linux products and resources!

Links: http://www.linuxdevices.com/articles/AT9837719278.html

RTOS Vs. General Purpose OS

Many non-real-time operating systems also provide similar kernel services. The key difference between general-computing operating systems and real-time operating systems is the need for ” deterministic ” timing behavior in the real-time operating systems. Formally, “deterministic” timing means that operating system services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas. These formulas must be strictly algebraic and not include any random timing components. Random elements in service times could cause random delays in application software and could then make the application randomly miss real-time deadlines – a scenario clearly unacceptable for a real-time embedded system.

General-computing non-real-time operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. If you ask the developer of a non-real-time operating system for the algebraic formula describing the timing behavior of one of its services (such as sending a message from task to task), you will invariably not get an algebraic formula. Instead the developer of the non-real-time operating system (such as Windows, Unix or Linux) will just give you a puzzled look. Deterministic timing behavior was simply not a design goal for these general-computing operating systems.

On the other hand, real-time operating systems often go a step beyond basic determinism. For most kernel services, these operating systems offer constant load-independent timing: In other words, the algebraic formula is as simple as: T(message_send) = constant , irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS.

Links: http://www.electronicproducts.com/images2/z11micre1100.gif