Spread-spectrum clocking reduces EMI in embedded systems

For years now, government institutions have been regulating the amount of EMI (electromagnetic interference) an electronic device or system can emit. Their efforts primarily target lowering dissipated power and eliminating any interference to the function of other surrounding devices as a result of EMI. Spread-spectrum clocking is a popular implementation for reducing EMI in synchronous systems.

Spread-spectrum-clocking benefits

EMI is the energy resulting from a periodic source in which most of the energy becomes a single fundamental frequency. The influence of these unwanted signals can manifest itself in the limited operation of other devices and systems. In some cases, the EMI-generated disturbance can make it impossible for these devices or systems to operate. Because an electromagnetic signal must have a source, synchronous systems are ideal candidates for generating excessive EMI. Within a system, the coupling paths in PCBs (printed-circuit boards) transmit the generated EMI that affects other system components. However, EMI can occur even in the absence of a conductive medium, such as an electric conductor or dielectric. In most cases, EMI results from a combination of conduction and radiation.

The primary PCIe (PCI Express) model implements a synchronous-clocking scheme. That is, the same 100-MHz clock source generates the reference clock for PCIe devices. Furthermore, in the case of a motherboard, the traces on the PCB can act as coupling paths to facilitate the transmission of EMI to the surrounding devices. The disturbance that occurs can affect not only the system but also other surrounding systems when EMI travels through the atmosphere in the form of radiation.

One method of minimizing the EMI that a device generates is to keep the disturbing signals below a certain level. You accomplish this goal by modulating the disturbing signals across a wider frequency range, thus spreading the energy across a range of frequencies rather than concentrating it at one frequency. In PCIe systems, the modulation of the reference clock is spread-spectrum clocking.

The most common modulation techniques are center-spread and down-spread. The center-spread approach applies the modulated signal in such a way that the nominal frequency sits in the center of the modulated frequency range. That is, half of the modulated signals deviate above the nominal frequency, and the other half deviate below it. A down-spread approach also results in a range of deviated frequencies. However, in the down-spread approach, the modulated signals deviate below the nominal frequency.

Spread-spectrum clocking reduces EMI in embedded systems figure 1Many PCIe systems implement EMI-minimizing spread-spectrum clocking by spreading the spectral energy of the clock signal over a wide frequency band. In spread-spectrum-clocking systems, PCIe components generally must use a reference clock from the same source. This approach allows a transmitter PLL (phase-locked-loop) and a receiver-clock-recovery function, or clock-data-recovery circuit, to track the modulation frequency and remain synchronous with each other. If only one side of the link uses a spread-spectrum-clocking reference clock, the transmitter and receiver circuits cannot properly track one another. For example, if a PCIe add-in card interfaces to a spread-spectrum-clocking system and also implements a cable connection to a downstream card that is using a constant-frequency-clock source, the downstream interface will be unable to connect.

The PCIe base specification provides guidelines for modulating the reference-clock input to PCIe devices. At a high level, the PCIe specification uses the down-spread approach when using a 30- to 33-kHz-wave signal as the modulating frequency to the 100-MHz clock, resulting in a frequency range of 99.5 to 100 MHz (Figure 1).



Information is shared by www.irvs.info

Open Embedded: An alternative way to build embedded Linux distributions

As embedded processors have grown more powerful and feature-rich, the popularity of the Linux operating system in embedded applications has grown in leaps and bounds. Although the fact that Linux is open source and free of licensing fees is one major driver of its popularity, another key driver is the wealth of application software and drivers available as a result of Linux’s widespread usage in the desktop and server arenas.

However, embedded developers cannot simply pick up desktop Linux distributions or applications for use in their systems. Broadly speaking, embedded Linux developers face three main challenges:

1. assembling a compatible combination of bootloader, kernel, library, application, and development tool components for the processor and peripherals used in their hardware;

2. correctly cross-building a multi-megabyte image; and

3. optimizing the various kernel and user-space components to reduce the footprint and associated memory cost.

Solutions to these challenges are far from straightforward and for a development team to achieve them requires significant effort and experience. Commercial embedded Linux vendors offer pre-tested solutions for particular embedded processors, but for developers who prefer a ‘roll your own’ approach to Linux, the Open Embedded (OE) build environment provides a methodology to reliably build customized Linux distributions for many embedded devices. A number of companies have been using OE to build embedded Linux kernel ports along with complete distributions, resulting in an increasing level of support to maintain and enhance key elements of the OE infrastructure.

In addition, a growing number of embedded Linux distributions (such as Angstrom) utilize OE. Although these distributions are not formally part of OE, they add to the attraction of using OE by providing ready-to-run starting points for developers. A final attraction is that some of the newer commercial distributions from companies such as MontaVista and Mentor Graphics are now based on OE. These provide additional tooling and commercially supported distributions.

In this article we present an overview of the key elements of the OE build environment and illustrate how these elements can be applied to build and customize Linux distributions. The Texas Instruments Arago distribution, which is based on the Angstrom distribution, will be used as example of how to create a new distribution based on OE and the distributions that already use it.

Most of the Arago- or Angstrom-based example scripts shown here have been modified slightly to more concisely demonstrate key concepts of OE. Developers should access the original scripts at the websites listed at the end of the article to view complete real-world implementations.

An Overview of Open Embedded

OE is based on BitBake, a cross-compilation and build tool developed for embedded applications. Developers use BitBake by creating various configuration and recipe files that instruct BitBake on which sources to build and how to build them. OE is essentially a database of these recipe (.bb) and configuration (.conf) files that developers can draw on to cross-compile combinations of components for a variety of embedded platforms.

OE has thousands of recipes to build both individual packages and complete images. A package can be anything from a bootloader through a kernel to a user-space application or set of development tools. The recipe knows where to access the source for a package, how to build it for a particular target, and ensures that a package’s dependencies are all built as well, relieving developers of the need to understand every piece of software required to add a particular capability to their application. OE can create packages in a variety of package formats (tar, rpm, deb, ipk) and can create package feeds for a distribution.

Most OE users will typically begin by selecting a particular distribution rather than building individual packages. The advantage of using an existing distribution is that it will often be necessary to select certain package versions to get a working combination. Distributions address this key function. They often provide a ‘stable’ build in addition to a ‘latest’ build to avoid the inherent instabilities that come from trying to combine the latest versions of everything.

A key benefit of OE is that it allows software development kit (SDK) generation. While some development teams may prefer to build their complete applications in OE, others may have a dedicated team that builds Linux platforms for application development teams to use. In these circumstances, the Linux platform team can generate a Linux distribution as a SDK that is easily incorporated into the build flow preferred by an application team. As a result, there is no need for application development teams to be OE experts.

A critical aspect of the OE database is that much of it is maintained by developers employed by parties with an interest in ensuring successful Linux distribution builds on embedded devices. This maintenance effort is critical given the amount of change occurring in the Linux kernel and application space.

A Quick Look at BitBake

The build tool developers are typically most familiar with is ‘make’, which is designed to build a single project based on a set of interdependent makefiles. This approach does not scale well to the task of creating a variety of Linux distributions each containing an arbitrary collection of packages (often hundreds of them), many of which are largely independent of each other, for an arbitrary set of platforms.

These limitations have led to the creation of a number of build tools for Linux distributions, such as Buildroot and BitBake. BitBake’s hierarchical recipes enable individual package build instructions to be maintained independently, but the packages themselves are easily aggregated and built in proper order to create large images. Thus it can build an individual package for later incorporation in a binary feed as well as complete images.

One important aspect of BitBake is that it does not dictate the way an individual package is built. The recipe (or associated class) for a package can specify any build tool, such as the GNU autotools, making it relatively straightforward to import packages into OE.

To address the need to select specific versions of packages that are known to work together and to specify the different embedded targets, BitBake uses configuration files.

BitBake fetches the package sources from the internet via wget (or any other Software Configuration Management tool such as Git or svn) using the location information in the recipe (Figure 1 below). It then applies any patches that are specified in the package description, which is a common requirement when cross-compiling packages for an embedded processor. The package collection is specified in the higher-level recipes such as those for images and tasks.



Since many developers will want to use an existing distribution, BitBake enables a developer to override distribution defaults by placing customized recipes or configuration files earlier in the BBPATH search path. This enables developers to tweak a distribution for their own needs without having to directly modify (and then subsequently maintain custom copies of) the existing distribution files. This approach in OE is called ‘layering’ and each collection of recipes is called an ‘overlay’.

We’ll now examine some of the different recipe and configuration files to shed a more detailed light on how OE and BitBake work. We will start by looking at the recipe types.

Information is shared by www.irvs.info

Fleet data loggers tackle real-world testing

In order to simulate real situations for the communication networks in a vehicle it is necessary to perform extensive test drives in a real environment. Large amounts of data need to be acquired, recorded, and, afterwards, accessed.

Shortly before production maturity, in-depth testing in vehicles is typically conducted in the context of test drives. To achieve the greatest possible test coverage, some of these tests are performed under extreme environmental conditions. Whether they are winter tests in Finland at -30C, hot weather tests in Death Valley at over 50C, or week-long drives through the Brazilian rainforest at high humidity and on rough roads, in the end the vehicle and all of its components must operate smoothly. Iinstalled data loggers must be able to withstand these harsh conditions as well. This means that they must be mechanically rugged and operate reliably over a broad range of temperatures.

At first glance, it would seem reasonable to use a notebook-based solution for in-vehicle data logging. Together with a suitable network interface the notebook should be able to offer all required capabilities, because functionality can be implemented in software. However, commercially available notebooks cannot handle the required temperature range. Furthermore, the system must first be booted, which takes some time—even with fast notebooks. This implies another requirement for data loggers: Short startup times. Data must be acquired quickly enough for the first message on the bus to be logged.

Information is shared by www.irvs.info