Build a Super Simple Tasker

Almost all embedded systems are event-driven; most of the time they wait for some event such as a time tick, a button press, a mouse click, or the arrival of a data packet. After recognizing the event, the systems react by performing the appropriate computation. This reaction might include manipulating the hardware or generating secondary, “soft” events that trigger other internal software components. Once the event-handling action is complete, such reactive systems enter a dormant state in anticipation of the next event.1

Ironically, most real-time kernels or RTOSes for embedded systems force programmers to model these simple, discrete event reactions using tasks structured as continuous endless loops. To us this seems a serious mismatch–a disparity that’s responsible for much of the familiar complexity of the traditional real-time kernels.

In this article we’ll show how matching the discrete event nature typical of most embedded systems with a simple run-to-completion (RTC) kernel or “tasker” can produce a cleaner, smaller, faster, and more natural execution environment. In fact, we’ll show you how (if you model a task as a discrete, run-to-completion action) you can create a prioritized, fully preemptive, deterministic real-time kernel, which we call Super Simple Tasker (SST), with only a few dozen lines of portable C code.2

Such a real-time kernel is not new; similar kernels are widely used in the industry. Even so, simple RTC schedulers are seldom described in the trade press. We hope that this article provides a convenient reference for those interested in such a lightweight scheduler. But more importantly, we hope to explain why a simple RTC kernel like SST is a perfect match for execution systems built around state machines including those based on advanced UML statecharts. Because state machines universally assume RTC execution semantics, it seems only natural that they should be coupled with a scheduler that expects and exploits the RTC execution model.

We begin with a description of how SST works and explain why it needs only a single stack for all tasks and interrupts. We then contrast this approach with the traditional real-time kernels, which gives us an opportunity to re-examine some basic real-time concepts. Next, we describe a minimal SST implementation in portable ANSI C and back it up with an executable example that you can run on any x86-based PC. We conclude with references to an industrial-strength single-stack kernel combined with an open-source state machine-based framework, which together provide a deterministic execution environment for UML state machines. We’ll assume that you’re familiar with basic real-time concepts, such as interrupt processing, context switches, mutual exclusion and blocking, event queues, and finite state machines.

Links: http://embedded.com/columns/technicalinsights/190302110

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

Is symmetric multiprocessing for you?

Multicore architectures can provide the performance boost you’re looking for, but the software is certainly more complicated.

For the past thirty years, computing has enjoyed continual boosts in performance, primarily due to increases in clock speed, pipelining efficiency, and cache size. Recently, however, traditional microprocessor optimization has hit the proverbial wall. Although tweaks such as further cache size increases can continue to nudge system performance, it’s clear that Moore’s gains are behind us. Meanwhile, embedded systems continue to grow in software complexity, with consumers expecting that all the bells and whistles will continue to come in ever shrinking cost, size, weight, and power footprints.

Microprocessor designers have concluded that the best path toward meeting the growing demand for performance with controlled footprint is to employ multicore architectures, in which the main premise is to partition the software and parallelize or offload execution across multiple processing elements. Symmetric multiprocessing (SMP) is one such architecture, consisting of homogenous cores that are tightly coupled with a common memory subsystem, as shown in Figure 1. SMP is a de facto standard on the desktop, but adoption in embedded applications has been slow, with recent surveys showing only a small percentage of designs using single-chip SMP-capable devices.

So if your design is in need of some extra horsepower, how can you determine whether SMP is a sensible choice? Several key requirements enable you to realize the promise of SMP. First, the software must be partitioned and parallelized to take advantage of the hardware concurrency. Second, operating systems must provide the load-balancing services required to enable distribution of software onto the multiple processing elements. And finally, you will need to learn and use development tools specifically tailored to the difficult task of multicore system debugging so you can find concurrency problems quickly and avoid time-to-market delays.

Links:  http://www.embedded.com/design/multicore/205203908

Is a De Facto Standard Already Forming for Embedded Virtualization?

The brave new world of gadgets with limitless and irritation-limiting potential depends on virtualization.

It’s going to be impossible to exploit 3G and WiMAX and VoIP and Android, for starters, without virtualization, not to mention the other promised front-end Internet devices and the sheer infrastructure of the whole edifice.

The new multi-core silicon and chipsets can’t manage the new services without virtualization. They need it for performance, cost, customization, security and manageability.

So it may be of more than just passing interest to note that VirtualLogix – which you may or may not remember as Jaluna – is currently holding three aces in its hand, namely, Cisco, Intel and Texas Instruments, all of which have now invested money in the little French company and its real-time virtualization skills.

If things keep breaking this way, we’ll eventually be talking de facto standard.

TI is the latest to ante up some undisclosed amount as part of a collaboration agreement aligning VirtualLogix’ virtualization roadmap with its big friend’s embedded application-specific multi-core semiconductor direction.

Links: http://opensource.sys-con.com/read/472214.htm

Connecting Embedded Applications to the Internet

Where the Internet may have been a dedicated network for computer data
exchange in it’s infant years, today more and more small (non-PC based)
intelligent “machines” are connected to the Network of Networks. The
prediction is that by 2005, the amount of non-PC users on the Internet will far
exceed the amount of PC’s!
Today, a highly integrated microcontroller can handle the functional control of
these machines. To connect the microcontroller to the Internet, one must
implement a protocol stack on the device. To function, this protocol usually
requires a powerful processor, a complete operating system, and a large
amount of memory. In this case, the implementation of a stand-alone Internet
protocol stack could be a solution.
In order to design an embedded system, one must design both the hardware
around a microcontroller and the software. Depending on the target hardware
as well as the complexity of the problem, the developer has to decide whether
to use an operating system. According to market analysis, more than 75% of
the embedded applications use a proprietary or free operating system, about
25% do not use an operating system. Big operating systems usually have
Internet protocols already built-in, whereas deeply embedded systems do not
yet provide a TCP/IP (Transmission Control Protocol/Internet Protocol) stack.
However, a 8- or 16-bit microcontroller may not have enough resources for the
implementation of an operating system. Software implementations without
operating systems can be found in less complex applications often using small
microcontrollers with strict hardware and runtime restrictions. The choice of
writing standalone code is often made because of the need to optimize memory
usage, code size, and run-time behavior. Since the writing of this standalone
code is target specific, it is often not portable to other targets.

Links:   

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2304.pdf