You are currently browsing the category archive for the ‘documentaire’ category.

link :

Welcome to’s guide to Linux-friendly Embedded Single Board Computers!

In light of the rapidly diverging shapes, sizes, and architectures for embedded system single board computer (SBC) platforms, and recognizing the growing importance of Linux to the embedded market, has created this Quick Reference Guide to Linux-friendly Embedded Single Board Computers (SBCs), which we hope will assist you in pinpointing solutions that match your Embedded Linux based system requirements.

This guide is organized in six parts . . .

  • About this guide — you are reading it now.
  • A Linux-oriented Intro to Embeddable Single Board Computers — this whitepaper by founder Rick Lehrbaum provides a useful introduction to embeddable single board computers, including the history and development of the single board computer (SBC) market, descriptions of the prevailing SBC industry standards, predictions for the future, and considerations for using SBCs in Linux-based embedded systems.
  • PC/104 and PC/104-Plus SBCs — an introduction to this extremely popular pair of industry standards for highly compact, modular, self-stacking embedded single board computers.
  • EBX SBCs — an introduction to this increasingly popular industry standard for medium-sized, modularly expandable embedded single board computers.
  • Filling the gap between PC/104 and EBX — while no standards currently exist in this size domain, a growing number of companies are offering small single board cmoputers that fit mid-way between the size of PC/104 and EBX. Will a standard emerge?
  • Tiny SBCs for Embedded Linux based projects — a brief survey of some of the many non-standardized tiny embedded single board computers that are currently available for use in a broad spectrum of projects.
  • Mini-ITX Madness — mini-ITX has become a key form factor for embedded Linux devices largely due to the widespread availability of a rich variety of boards, cases, and system components at commodity prices.

Please note that this guide will be updated frequently, so be sure to check back periodically for the latest info. Also, be sure to take advantage of the abundant information available via the search engine, by searching with « SBC » or « single board computer » as the keyword — search the news, articles, links, and products databases. Another good way to locate Linux-friendly single board computers is to review the lists of supported third-party SBCs that are provided by many of the embedded and real-time Linux distribution providers. To pursue that path of investigation, consult the Quick Reference Guides on Embedded Linux Distributions and Real-time Linux Distributions.

What’s an SBC?

Early microcomputers typically consisted of half a dozen (or more) circuit boards — plugged into a backplane — which implemented the central processor unit (CPU), memory, disk controllers, and serial/parallel port functions. These backplane-based microcomputers were used for data acquisition, process control, and R&D projects, but were generally too bulky to be used as the intelligence embedded within devices.

By the early 80’s, integrated circuit (IC) technology had advanced to where functions that previously occupied entire circuit boards could be crammed into single « large scale integration » (LSI) logic chips. LSI chips for CPU, memory, storage, and serial/parallel ports now made it practical to implement complete microcomputer systems on a single board — without backplanes. The Z80-based « Big Board » (1980) was probably the first such single board computer (SBC) that was capable of running a commercial disk operating system (CP/M).

The embedded SBC market

Like the Big Board, the « Little Board » (Ampro, 1983) used a Z80 CPU and was targeted specifically at the CP/M operating system. But it was much smaller in size, matching the footprint of a floppy disk drive (5.75 x 8.0 in.). Thanks to its unique combination of compactness, simplicity, reliability, and low cost, the Little Board made it practical for a commercial disk operating system to be easily embedded directly within devices that were not themselves computers.

Thus was born the embedded SBC market, which by now has become crowded with hundreds of SBC manufacturers producing thousands of different SBC products that target a vast array of embedded and dedicated computing applications.

Initially, every SBC product was completely unique — both architecturally and physically. This was largely due to the inherent diversity of embedded system requirements, combined with the wide assortment of processors and peripheral controllers that were available. Moreover, there were no standards to influence SBC developers’ choices of functional and mechanical specs.

The dawn of the PC-compatible SBC

By the mid ’80s, there was growing interest in IBM PC compatibility in embedded and other non-desktop applications, for two key reasons . . .

  • Hardware leverage — PC chipset and peripherals compatibility could produce systems that were lower cost, simpler, and easier to support
  • Software leverage — PC compatibility could make it possible to take advantage of the PC’s operating systems (first MS-DOS, then Windows), languages, tools, and application software

Some of the resulting PC-compatible microcomputers were based on the form-factor of the IBM PC (« ISA bus ») plug-in card. Others were implemented as standalone (non-backplane) systems on a single board. Still others were adaptations of popular industrial backplane buses (STD, VME).

In the case of embeddable non-backplane SBCs, the trend towards PC compatibility quickly became a stampede. Consensus also emerged around several popular form-factors . . .

  • Little Board (5.75 x 8.0 in.) — complete systems on a single compact board, expandable with plug-on function modules
  • ISA « slot boards » (full-length, 13.8 x 4.8 in.; half-length, 7.1 x 4.8 in.) — SBCs in the IBM PC plug-in card format which, though backplane-oriented, could also function as standalone SBCs (without backplanes)
  • PC/104 modules (3.6 x 3.8 in.) — compact, rugged, self-stacking modules featuring a reliable pin-and-socket board-to-board expansion bus

And with the coming of PCI, these were joined a decade later by . . .

  • PC/104-Plus — PCI added to PC/104
  • EBX — PC/104-Plus added to Little Board

Not all SBCs jumped on these popular form-factors. Nor did they all go the PC-compatible (x86/DOS/Windows) route. Throughout the multi-decade history of single-board computers, there have been — and continue to be — non-standard board sizes and processor architectures that target unique application requirements or fill niches not well matched to the standardized form-factors and popular « Wintel » (PC compatible) architecture.

Strongly blowing winds of change

Today, several significant factors seriously challenge the SBC market status quo . . .

  • Exploding demand for embedded intelligence — even the tiniest and least expensive products and devices are now expected to have at least rudimentary embedded intelligence. Many also require user-friendly graphical and/or speech interfaces.
  • Ubiquitous connectivity — there is growing need for everything electronic to be interconnected, whether by wires or wireless. These devices must often be capable of inbound or outbound Internet connectivity and must support numerous standardized protocols (TCP/IP, PPP, HTTP, FTP).
  • Evolving peripheral and bus interfaces — although popular interconnection standards can sometimes seem immortal (consider Centronics and RS232), new interfaces do gradually supplant the old. Nearly two decades after the PC’s birth, the ISA bus has finally been replaced by PCI. USB is now replacing the venerable serial, parallel, and PS/2 ports. Ethernet is everywhere and FireWire (IEEE-1394) is beginning to make a strong showing. SCSI never made it to mainstream in PCs (other than the Apple’s). We may well stand on the verge of backplane-free systems whose only expansion mechanism is via medium- and high-speed serial interfaces (USB, IrDA, FireWire, Ethernet, . . .).
  • Application-oriented system-on-chip processors — numerous highly integrated ARM, MIPS, PowerPC, and x86 based one-chip systems are being developed to match the specs of a wide array of high volume and cost sensitive appliance-like products. Today, these « application-on-chip » processors represent tantalizing fodder for a new breed of high-integration, high-performance — and highly cost-effective — SBCs. Many of these SOCs have abandoned x86 compatibility for the sake of cost/power/integration benefits.
  • Embedded Linux — in just a few short years, Linux has exploded onto all aspects of the computing scene, offering a low cost, open source solution with strong support for open standards, networking, communications, Internet, graphics, . . . and more all the time. Despite its origins as a Unix clone for PCs, Linux now supports as broad a range of processors as any « traditional » embedded OS. Consequently, full-featured OS support for diverse architectures (beyond x86) has increased dramatically in the last several years, due to the rapidly evolving capabilities and growing architectural neutrality of Linux, resulting in a more level playing field among competing processor architectures.

Considering all these factors, it becomes evident that conditions are ripe for change in the embedded SBC market!

A little chaos theory

Prior to the embedded SBC market coalescing around the PC architecture and a handful of form-factor standards, it was nearly impossible to locate two SBCs that bore much similarity with to other. The PC architecture brought a degree of order (in several shapes and sizes) to that chaos, by serving as a unifying force — a situation which persisted for nearly two decades.

Today, with the established norms disrupted by new interfaces (USB, FireWire, Bluetooth), architectures (MIPS, PowerPC, ARM), and operating systems (Linux), the embedded SBC market had better prepare itself for a new phase of its lifecycle — one that will initially be characterized by a heightened diversity of operating systems, processor architectures, peripheral interfaces, and physical form-factors.

A few words about Linux on Embedded-PC SBCs

These days, most manufacturers of PC-compatible single board computers claim to support embedded Linux on their products — either directly, or via third-party relationships with embedded Linux software providers. However, be careful not to get too complacent when the sales rep says « Sure, we support Linux. »

In general, Linux support for PC-compatible embedded SBCs tends to be straightforward — provided: (1) the chipsets used are mainstream and fairly current; and (2) the chipsets have been used in the normal manner. Always ask the SBC vendor what specific versions of Linux they have tested, how they conducted the tests, which interfaces on the SBC were exercised, and what functions are either untested or unsupported.

Specifically, areas to watch out for include . . .

  • Display controller modes beyond VGA
  • LCD panel control signals
  • SCSI
  • Onboard solid-state disks
  • Nonstandard functions like watchdog timers, digital I/O, and analog I/O
  • Ethernet (in some cases)

Knowing that Linux drivers or in-kernel support exists for the chips used is encouraging, but that’s not sufficient. SBC manufacturers often take shortcuts to save money or board space, and in the process may unwittingly sacrifice compatibility. In short: there’s no substitute for testing!

Fortunately, if you are using Linux in your embedded SBC based system, you can at least take heart in the knowledge that driver source code is readily available and that there are plenty of Linux-aware programmers around who can help you untangle any problems that may arise.

Originally derived from the form-factor of the « MiniModules » used to expand Ampro’s Little Board SBC, PC/104 has now become one of the most popular embedded system standards. The compact (3.6 x 3.8 in.), rugged, PC-compatible module standard takes its name from the self-stacking 104-pin pin-and-socket bus that contains the same signals as the ISA bus (PC bus) P1 and P2 connectors. PC/104-Plus adds the PCI bus, using a second (120-pin) board-to-board bus connector.

Because PC/104 and PC/104-Plus modules tend to be made from standard PC desktop and (more often) laptop components, most manufacturers of these products claim that they support embedded Linux — either directly, or via a third-party relationship with one of the embedded Linux software providers.

By now, PC/104 is so broadly supported that it’s not practical to list individual suppliers — of which there are many hundreds worldwide. Instead, we refer you to the following resources which provide PC/104 technical, product, and vendor information . . .

  • The PC/104 Consortium — a nonprofit trade association devoted to supporting and promoting PC/104 technology, and maintainer of the PC/104 and PC/104-Plus standards. Definitely, the place to start. details
  • E-Zine of PC/104 Controlled Systems — a commercial PC/104 portal with PC/104 related news, articles, FAQ, and product/vendor listings. details
  • PC/104 Embedded Solutions Magazine — a commercial publication devoted to PC/104 related news, articles, and product/vendor information. Subscriptions are free to qualified individuals. details

Also be sure to use the search engine with the keyword « PC/104 » (also try « PC104 », « PC-104 », and « 104 ») — check the news, articles, products, and links databases.

The 5.75 x 8.0 in. Embedded Board eXpandable (EBX) specification, which was derived from Ampro’s proprietary Little Board form-factor, resulted from a collaboration between Ampro and Motorola Computer Group.

As compared with PC/104 modules, these larger (but still reasonably embeddable) SBCs tend to have everything of a full PC on them, including application oriented interfaces like audio, analog, or digital I/O in many cases. Also it’s much easier to fit Pentium CPUs — whereas it’s a tight squeeze (or expensive) to do so on a PC/104 SBC. Typically, EBX SBCs contain: the CPU; upgradeable RAM subassemblies (e.g. DIMM); Flash memory for solid state disk; multiple USB, serial, and parallel ports; onboard expansion via a PC/104 module stack; off-board expansion via ISA and/or PCI buses (from the PC/104 connectors); networking interface (typically Ethernet); and video (typically CRT, LCD, and TV).

Motorola Computer Group maintains an EBX information area where you can find an EBX backgrounder and the EBX spec. The EBX spec and related information are also available from Ampro’s whitepapers area.

As is the case with PC/104, most EBX SBC manufacturers offer support for embedded Linux on their products — either directly, or via a third-party relationship with one of the embedded Linux software providers.

Here are a few manufacturers of EBX form-factor SBCs that reportedly support Linux: Adastra Systems, Advantech, Ampro, Arcom Controls, Embedded Planet, Lanner Electronics, Octagon Systems, Motorola Computer Group, VersaLogic, WinSystems.

Refer, also, to the PC/104 resources sited earlier in this guide since EBX is, after all, based on PC/104 technology. In addition, try using the search engine with « EBX » as the keyword — check the news, articles, products, and links databases.

A growing number of companies offer small SBCs that fit within a size gap between the PC/104 (13 sq. in.) and EBX (46 sq. in.) form-factors. Unfortunately, no dominant standard for such « half-EBX » sized boards has emerged, so each supplier’s product family tends to implement a unique approach and few are interchangeable with each other.

Being 1.5 to 2 times the size of PC/104 modules, and given the availability these days of highly integrated system-on-chip processors as well as highly integrated peripheral controllers, SBCs in this size range have sufficient board space to fit just about all the functions a small Embedded Linux based system is likely to require. In addition, many of these SBCs can also be expanded using PC/104 or PC/104-Plus modules, or via PCMCIA or CompactFlash cards. Another benefit of the larger size of these SBCs, in comparison with PC/104 form-factor SBCs, is that they can more readily accommodate the size and heat dissipation requirements of high performance CPUs — in case your application needs it.

Although no formal standardization effort for this size domain (in the gap between PC/104 and EBX) is currently underway either on the part of the PC/104 Consortium or elsewhere, several candidate form-factors appear ready and willing to serve this niche . . .

Advantech’s « Half-Biscuit » — called a 3.5-inch disk drive form-factor by its originator, this family of 5.7 x 4 in. form-factor SBCs typically contains all of the functions of a full PC system. Versions are available from Advantech based on 486, National Geode, and Transmeta Crusoe processors (details here). The form-factor is also reportedly supported by several other Taiwanese manufacturers including Aaeon, Axiom, ICP, and Lanner. Unlike the Ampro and JUMPtec-Adastra alternatives, the Half-Biscuit provides « real world » I/O and power connectors, and does not require a baseboard for use in a system.

Ampro’s EnCore — Each compact (100 x 145 mm; 3.9 x 5.7 in.) EnCore module includes a processor, system and Flash storage memory, plus a set of standardized peripheral interfaces (IDE, floppy, Ethernet, serial, parallel, USB, and sound), while some also provide graphics controllers for CRTs and flat panels. The modules interface with customer-developed « custom logic boards » via a combination of PCI bus and standardized I/O signals, without regard to processor architecture. Since all EnCore modules have consistent feature-sets, physical dimensions, and interface connector locations, a single custom logic board design can support multiple processor architectures simply by exchanging Encore modules. The modules implement the PC/104-Plus PCI bus, but not the ISA bus. Ampro currently supports the EnCore form-factor with 486, Pentium, Pentium III, MIPS, and PowerPC processors, making the form-factor an interesting candidate for a processor architecture independent module standard (details here).

Kontron’s ETX COMs — ETX COMs (computer-on-modules) are highly integrated and compact (3.7 x 4.4 in.) SBCs that can be used in a design application much like an integrated circuit component. Each ETX COM integrates core CPU and memory functionality, the common I/O of a PC/AT (serial, parallel, etc.), USB, audio, graphics, and Ethernet. All I/O signals as well as a full implementation of ISA and PCI buses are mapped to four high density, low profile connectors on the bottom side of the module. JUMPtec-Adastra launched the standard before being aquired by Kontron. Kontron sells ETX COMs with National Geode, Intel Pentium, and Intel Pentium III processors (details here). At least two other companies now support the ETX form-factor, including Advantech and TMC Technology. Additionally, Kontron recently announced plans for an upgrade to its ETX format based on PCI Express, called ETXexpress.

Kontron’s E2Brain — Kontron says it hopes its E2Brain specification can do for RISC boards what standards such as PC/104, EBX, EPIC, ETX, and COM Express have done for x86. The company has shipped at least one Linux-friendly E2Brain board, and published the E2Brain specification. It hopes to establish a consortium of OEMs and board vendors around the specification, it says.

Kontron’s SpeedMOPS — Kontron is positioning its 5.8 x 3.8 inch (22 sq. in.) SpeedMOPS form-factor as a « stretched » version of PC/104-Plus that approximately matches the footprint of a 3.25-inch disk drive. Kontron says that by positioning the processor outside the PC/104-Plus stack envelope, the SpeedMOPS format enables optimal cooling of high-performance CPUs. The company has said that it is negotiating for an extension to the PC/104 specification to accomodate the speedMOPS form-factor for high-performance applications.

PC/104 Consortium’s EPIC standard — Five SBC vendors launched EPIC (the « Embedded Platform for Industrial Computing » standard) in March 2004. The EPIC spec defines a 4.5 x 6.5 inch (29.4 sq. in.) board, and allows I/O connections to be implemented as either pin-headers or PC-style (« real world ») connectors. The standard provides specific I/O zones to implement functions such as Ethernet, serial ports, digital and analog I/O, video, wireless, and various application-specific interfaces. EPIC was subsequently adopted by the PC/104 Consortium, and has been picking up vendors ever since.

VITA’s ProcessorPMC (PrPMC) — VITA’s PrPMC standard generalizes the PCI Mezzanine Card (PMC) specification (which was developed for CompactPCI board expansion) so that the PMC form-factor can be used to implement CPU modules. PrPMC modules provide board-to-board connectors which provide PCI and I/O signals to a baseboard, and also have a « front bezel » for optional external I/O connectors. The highly compact (2.9 x 6.0 in.) modules can operate both as host and slave modules on an appropriately configured PCI bus. A number of vendors have announced PrPMC SBC modules which support operation under Embedded Linux, including RadiSys and Technobox. One notable disadvantage of PrPMC is that its dimensions are highly constrains due the requirements of being a mezzanine bus.

A growing number of extremely small, yet highly integrated, single board computers (SBCs) make it increasingly easy to embed Linux in a wide range of applications, from handheld devices to embedded instruments. Typically, you can get all the functions of a full computer system — including CPU, program memory, « solid-state disk », serial and parallel ports, display interface, and network interface — in less than a dozen square inches of space. A few even manage to cram an embedded Linux computer into under three square inches!

Some of these products also provide CompactFlash or PCMCIA slots, which facilitate both memory and peripheral interface expansion. Many now include support for operation from batteries, making them ideal platforms for specialized handheld and portable equipment.

One noteworthy concern relative to this class of products, with the exception of PC/104 form-factor SBCs (which are too numerous to include here), is the utter lack of plug-and-play interoperability among these tiny modular systems. Although there is the hint of a trend toward matching the size and connector styles of DIMM or SIMM memory modules, there is no consistency whatsoever in how their signals are assigned to the module connectors. Also, with many of these products taking advantage of the latest high-integration system-on-chip processors (StrongARM, Elan, Etrax, etc.), which are not typically x86 compatible, PC compatibility has become the exception rather than the rule.

However, despite their lack of plug-and-play interoperability, the availability of embedded Linux ports for these tiny SBCs, combined with their excellent integration/size ratios, make these products highly appealing for applications that can’t tolerate the size of standards-compliant SBCs. The hope, of course, is that using one of these tiny single-module-systems will eliminate the costly, risky, and time-consuming process of developing a custom embedded computer.

Here, then, is a sampling of some « teeny weeny » embedded-SBCs that support embedded Linux . . .

Acunia Zingu — this 2.7 x 3.6 in. SBC is based on an Intel Xscale i80200 processor with up to 850 MIPS performance. Includes up to 128MB SDRAM and 32MB Flash, plus built-in controllers for video, UART, AC97 Audio codec, PCMCIA, and I2C. Power consumption is under 2.5W. details

ADS Bitsy — this 3 x 4 in. SBC is based on a 206 MHz Intel StrongARM SA-1110 processor (plus SA-1111 companion chip) and consumes just 450 mW. Includes: serial, USB, audio, digital and analog I/O, a Type II PCMCIA slot, plus a 1024 x 1024 resolution color LCD controller. details

Aleph One « Balloon » board — Aleph One is shipping a one-ounce, one-watt, 206MHz StrongARM-based single-board computer (SBC) that comes pre-installed with embedded Linux and features an « open source » hardware design. Aleph One encourages device designers to freely use the design, and contribute back implementation details useful to others. Aleph One says its « Balloon board » is ideal for use in contol systems, portable devices, wearable computers, instrumentation, and robotics. details.

AMC Technologies NETdimm — the NETdimm SBC module in AMC’s 5.25 x 1.5 in. dimmPCI form-factor, based on a Motorola Dragonball processor equipped with up to 32MB SDRAM and up to 8MB Flash, and with built-in controllers for Ethernet, an LCD, 2 serial ports, and an SPI port. Runs uClinux. Other versions are available which replace the NETdimm’s Ethernet and LCD functions with CANbus or digital and analog I/O.

AMD GX SOM-144 — Based on a Geode GX 533@1.1W processor, the Geode GX SOM-144 comes with an RDK that includes Linux drivers. It measures 4 x 2.7 inches (100 x 68mm), and targets applications where power, size, performance, and reliability are critical, AMD says. details

Arcturus Networks uCdimm, uCsimm — The soDIMM-sized (1.7 x 2.7 in.) uCdimm (details), pictured here, is based on a Motorola DragonBallVZ and provides 2 SPI interfaces, 2 RS232 ports, 22 digital I/O’s, up to 640×512 LCD control, and 10 Mbit Ethernet. The older « SIMM-sized » (3.5 x 1 in.) uCsimm SBC (details) is based on a Motorola DragonBall 68EZ328 with 2.7 mips performance, and includes: 2MB Flash, 8MB DRAM, 21 digital I/O, serial, I2C/SPI, 10 Mbit Ethernet, and a 640×480 LCD controller.

Axis Developer Board — a small form-factor SBC based on the 100 MHz Axis ETRAX 32-bit RISC system-on-chip processor. It is usable as either an ETRAX evaluation board or as a small embedded computer. Includes: 10/100 Mbit Ethernet, serial, parallel, RTC, 2MB Flash, 8MB DRAM, and 2KB EEPROM. details

C Data CompactFlash Computer — this tiny Linux-based computer fits entirely on a Type II CompactFlash (CF) card which can be mixed and matched with third-party CF-cards to create miniscule, modular Linux systems based entirely on CF cards. The module is based on a 66MHz Freescale MPC5272 SoC and includes 32MB SDRAM and 8MB flash, and runs uClinux. Details here and here

Cogent CSB637 — A tiny SBC that measures 1.75 x 2.5 (63.5 x 44.5mm), and is based on an Atmel AT91RM9200, a low-power SoC (system-on-chip) with an ARM920T core that Atmel says delivers 200 MIPS. The Cogent board supplements the Atmel microcontroller�s functionality, according to Direct Insight, offering interfaces that include 10/100 Ethernet MAC and PHY, USB, Dual SDIO, 4 UARTs, SSI, SPI, and CompactFlash Interfaces, an onboard LCD/CRT Controller. Also included are 64MB SDRAM and 8MB flash memory and an « efficient » 3.3V Regulator. details.

CompuLab ARMcore-GX — A tiny low-cost processor module based on a 400MHz Intel PXA255. The ARMcore-GX measures 2.6 x 1.7 inches (66 x 44mm) and costs $51 in quantities of 1,000, and is available with a PC/104 carrier board. details

CompuLab 586CORE — a tiny (3.1 x 2.4 in.) PC-compatible SBC based on the AMD Elan SC520. Includes: 16-64 MB DRAM, 1-136M Flash disk, 69000-based SVGA graphics, 10/100 Mbit Ethernet, USB, 2-4 serial ports, PS/2 keyboard/mouse, IrDA, 32 digital I/O, RTC, sound, IDE/floppy interfaces, plus ISA and PCI expansion buses. details

Cambridge Signal Processing (CSP) DSP Stamp — A 1-inch-square module based on a digital signal processor (DSP) that runs uClinux natively. The DSP Stamp comes preinstalled with a serial bootloader and uClinux, and a development board is also available. A Bluetooth camera reference design is expected Q4, 2004 details.

DDC Linux Rocket — Data Design Corp’s claims its micro-miniature SBC provides a powerful Linux system on a truly tiny board. Based on a PowerPC 405GPr processor clocked up to 400MHz, the « Linux Rocket » includes DDC’s custom PPC Linux kernel and flash filesystem, and targets kiosk, industrial monitoring and control, instrumentation, set-top-box, and vending machine applications. details

Digi International ConnectME/Picotux — A network-enabled Linux system barely larger than a standard RJ-45 Ethernet jack, « Picotux » is based on the DigiConnect ME module from Digi International, along with a 2.4.27 uClinux port developed by Hans Kleinhenz. details

Embedded Planet EP8260 — physically, this PowerQUICC II (MPC8260) based SBC matches the footprint of a PC/104 module (3.6 x 3.8 in.) is not considered a PC/104 module. Includes: up to 32MB Flash and 128MB SDRAM, 10/100 Ethernet, and a PCMCIA Type II slot. Expandable via the PowerPC expansion bus. details

Embedded Planet RPX Super — physically, this PowerQUICC II (MPC8260) based SBC matches the footprint of a PC/104 module (3.6 x 3.8 in.) is not considered a PC/104 module. Includes: up to 32MB Flash and 128MB SDRAM, 10/100 Ethernet, and a PCMCIA Type II slot. Expandable via the PowerPC expansion bus. details

Esfia M170S — A low-cost module for POS (point-of-sale/service) devices, RFID tunnel readers, biometric access control terminals, and other test, industrial, and medical applications, the ARM-based M170S measures 2.42 x 1.77 inches (61.5 x 45mm), costs $64, and is available with a wireless-enabled carrier board. details

Esfia M170P — A tiny ARM7-based SBC (single-board computer) that measures just 1.97 x 1.57 inches (50 x 40mm) and costs $64 in quantities of 5,000, the M170P targets rugged handheld devices, and is available with an evaluation kit that includes Linux. details

Forth-Systeme DIMM-520, ModNET50 — the tiny « DIMM-sized » (2.7 x 2.0 in.) DIMM-520 (details), pictured here, is based on the 32-Bit 133 MHz AMD ElanSC520 x86 system-on-chip. It includes: 64MB SDRAM, 16M Flash, PCI bus interface, 2 serial and 1 parallel ports, 100 Mbit Ethernet, and PC motherboard core logic. The ModNET50 (details) uses NetSilicon’s NET+ARM system-on-chip to integrate a RISC processor, 100 Mbit Ethernet, 2 serial ports, RAM, Flash, and other functions on a tiny SBC.

General Micro Systems Spider — This standalone SBC measures 2.8 x 1.9 inches, boots from on-board flash, includes a DC-DC converter, and is based on an IBM PowerPC chip running either 400 or 800 MHz. A companion I/O card is available, with dual Ethernet ports and more. The Spider targets distributed control, telecom server blades, handhelds, and military/aerospace applications. details

Gumstix XM, BT, and Basix options — Gumstix has added extended memory and on-board Bluetooth options to its line of tiny gumstick-shaped XScale SBCs (single-board computers). It has also launched a new low-cost model priced at $99. The company now offers nine « Connex » and « Basix » SBCs priced from $99 to $189. Details

Gumstix — This unique SBC features an oblong shape 0.79- by 3.1 inches (20- x 80mm), targeting wearable devices such as collar PCs. It is based on an an Intel XScale PXA255 processor, and includes 4MB of Flash RAM, and 64MB of SDRAM. Expansion interfaces include MMC, SD, and SDIO. The board draws under 200mA, according to Gumstix, and can be powered by 3 AAA NiMH batteries. details

HCV Wireless BlueMod — this tiny (2.75 x 2.1 in.) SBC was specifically designed for Bluetooth wireless communication. It runs uClinux on a 32-bit 50 MIPS CPU with 8MB SDRAM and 2MB Flash. I/O includes serial, GPIO, USB (device), and connection to external adapters via a processor expansion bus. details

Inhand Fingertip, Elf — the tiny (2.75 x 2.75 in.) Fingertip « PDA platform » (details), pictured here, is based on a 200 MHz Intel StrongARM 1110 CPU; it also includes: up to 32M Flash, up to 16M SDRAM, audio, 3 serial ports, SPI port, USB, 12 digital I/O lines, 320×240 LCD display/touchscreen interface, battery support, and CompactFlash expansion socket. Also based on an SA-1110 processor, the slightly larger (12 square in.) Elf (details) has a built-in PCMCIA slot, 16MB DRAM and up to 8MB Flash onboard memory, plus many of the same features as the Fingertip. InHand’s Fingertip3 (details) is the company’s first SBC based on an XScale processor.

Intec WildFireMod — A tiny ColdFire-powered CPU module claimed to be the smallest Linux SBC (single-board computer) with Internet connectivity, a reasonable amount of memory, and « massive control functionality. » The WildFireMod measures 1.9 x 1.7 inches (49 x 44mm), and targets data acquisition systems, communications, electric and internal combustion motor controllers, robotics, automotive, avionics, and industrial control. Details.

Intrynsic CerfBoard — a tiny (2.2 x 2.4 in.) SBC based on a 133 or 206 MHz Intel StrongARM 1110 CPU. Also includes: up to 16MB Flash, up to 8MB SDRAM, 16 digital I/O lines, 10 Mbit Ethernet, USB, serial port, audio CODEC, LCD interface, and CompactFlash+ socket. details

JUMPtec DIMM-PC — a family of « DIMM form-factor » (2.7 x 1.6 in.) PC-compatible SBCs. The DIMM-PC/586 (pictured here) is based on a ZF Micro ZFx86 system-on-chip processor and includes: 32MB SDRAM and 32MB Flash memory, plus interfaces for 10/100 Mb/s Ethernet, USB, serial (2), parallel, keyboard, floppy, and IDE. Additional models are based on 486 and 386 processors. details

Kontron X-board GP8 — A highly integrated device in the very compact 67 x 49-mm X-board COM (computer-on-module) form-factor. Dubbed the X-board GP8, the SBC is built around an Intel Xscale 80219 microprocessor and Silicon Motion SM501 chipset. details.

Kontron E2Brain EB8540 — A fanless 4.3 x 2.9-inch RISC-based « computer-on-module » designed to enable Linux and VxWorks device developers to concentrate on product design and application-specific software, rather than on implementing their own processor cores. The E2Brain is based on an 800MHz Freescale MPC8540 PowerQUICC III processor that delivers 1,850 DMIPS. It targets industrial automation, transportation, medical technology, and defense. details

Kontron E2Brain EB425 — Claimed to be the first Computer-on-Module (COM) based on Intel’s XScale IXP42x network processor, the EB425 « E2Brain » measures 2.95 by 4.33 inches (75 x 115 mm) and targets low-power real-time applications. It supports Linux and VxWorks. details

LART — an « open licensed » small SBC (4 x 3 in.) design from the Technical University of Delft (Netherlands). It is based on a 220 MHz Intel SA-1100 StrongARM and includes: 4MB Flash and 32MB DRAM memory, serial and parallel ports, and bus expansion. Expansion boards provide: Ethernet, USB, keyboard, mouse, touch input, and video. details

Lineo uCdimm, uCsimm — The soDIMM-sized (1.7 x 2.7 in.) uCdimm (details), pictured here, is based on a Motorola DragonBallVZ and provides 2 SPI interfaces, 2 RS232 ports, 22 digital I/O’s, up to 640×512 LCD control, and 10 Mbit Ethernet. The older « SIMM-sized » (3.5 x 1 in.) uCsimm SBC (details) is based on a Motorola DragonBall 68EZ328 with 2.7 mips performance, and includes: 2MB Flash, 8MB DRAM, 21 digital I/O, serial, I2C/SPI, 10 Mbit Ethernet, and a 640×480 LCD controller.

Logic Card Engine — a compact (2.37 x 2.67 in.) family of tiny Linux-supported SBCs which include features such as onboard Flash (up to 32MB) and SDRAM (up to 32MB) memory, integrated LCD controller, touch panel support, serial, audio codec, Ethernet, Compact Flash and more. Sharp and Renesas processors are currently supported, and the SBCs include « production quality » BSPs and bootloaders. details

SNMC QS850 — a tiny (3.1 x 2.1 in.) networked PowerPC SBC based on a Motorola MPC850. Includes: 8-64 MB SDRAM, 2-16 MB Flash, up to 2 Ethernet ports, 3 serial ports, up to 64 channels HDLC, 49 digital I/O lines. Supported by SNMC’s QSLinux Embedded Linux. details

SSV DIL/Net — The DIL/Net 1110 (details) is based on a StrongARM 1110 processor, and is available with pre-installed GUI driven by a Linux-based X11 server supporting up to SVGA resolutions. A gum-stick form facter version (3.2 x 1.1 in.) details is also available, as is a gumstick version that runs on a Softcore processor, for Ethernet products with very long life cycles details.

SSV DIL-40 DNP/5282 — The first of a planned family of DIL-40 SBCs that measure 2.2 x 0.9 inches, matching the pin footprint of 40-pin « DIP » (dual-inline-package) ICs. The DNP/5282 is based on a 66MHz Freescale Coldfire processor, and comes preinstalled with uClinux. details.

Strategic Test Max-PC — a matchbox sized (2.3 x 1.2 in.) SBC based on a 100 MHz 486 processor, plus 16MB RAM and 16MB Flash. Onboard controllers handle VGA, RS232 serial, parallel port, timers, keyboard, iRDA, and PCMCIA. details

Strategic Test Triton-Eco — A tiny, inexpensive single board computer (SBC) based on a 400MHz PXA255, an Intel XScale processor popular in PDAs and smartphones. The Triton-Eco SBC comes with Linux 2.6 pre-installed, and costs $135/$99 in quantities of 10/1000. details

Techsol Medallion — a family of tiny (4 square inch) SBC modules. The HY7201 is based on a 60 MHz ARM-720T RISC processor, and includes 32MB of SDRAM and a 32MB DiskOnChip Flash disk, plus built-in controllers for 2 UARTs, CRT/LCD VGA, touchscreen, IrDA, USB (host and device), multimedia card, and GPIO. details

Toradex Colibri — An SODIMM format computer module based on the Intel XScale PXA270 processor. The Colibri is optionally available with Linux pre-installed. details

TQ-Components TQM850 — a tiny (2.1 x 1.8 in.) SBC based on a 50 MHz Motorola PowerPC MPC850. Includes: up to 8MB Flash and up to 64MB SDRAM, plus dual-serial and dual-CAN (field bus) interfaces. Expands via 120-pin board-to-board connector on bottom. details

What is mini-ITX?

Mini-ITX is an ultra-compact (6.7 x 6.7 in.) mainboard form-factor developed by Via Technologies Inc. Mini-ITX targets a new generation of quiet, small footprint, connected, information and entertainment systems and enables the creation of an exciting new generation of small, ergonomic, innovative, and affordable embedded systems through its high level of integration and vastly reduced size of less than 33% that of the FlexATX mainboard form-factor.

The mini-ITX form-factor, as originally defined by VIA

VIA launched mini-ITX as a way to showcase its inexpensive chipsets for computer hobbyists, but the form factor has since gone into many other embedded markets. Its success has brought a vast proliferation of cases, power supplies, slim-line drives, Flash-to-IDE adapters, and other handy computing components that have helped drive the form factor into applications such as living room PCs and commodity hardware-based dense computing applications.

Additionally, the charms of mini-ITX have not been lost on industrial board vendors such as Kontron and others. Of course, it’s important to note that mini-ITX motherboards from industrial single-board computer (SBC) vendors typically offer thicker PCBs, more rugged designs, and better build quality, compared with mini-ITX boards aimed at the consumer market. They also have correspondingly higher prices and minimum order volumes.

Key Mini-ITX resources:

  • Mini-ITX form-factor whitepaper — The above drawing comes from VIA’s original whitepaper defining the mini-ITX form-factor. The full mini-ITX whitepaper is available here (PDF download).
  • — a website devoted to mini-ITX news and projects — provides comprehensive coverage of mini-ITX news, projects, and hardware, along with a mini-ITX FAQ and an online store for purchasing selected mini-ITX boards, enclosures, and other related hardware. details
  • — portal for Linux on Mini-ITX hardware — is a community site devoted to running Linux on mini-ITX solutions. The site includes forums, information, news, downloads, etc. Running Linux on mini-ITX hardware is ideal for DVD/MP3 players, firewalls, mail servers, web servers, dns servers. The list is endless! details


Inventor Country Date
‘Clavecin Électrique’ Jean Baptiste Delaborde France 1759
The Electro-mechanical Piano Msr Hipps Switzerland 1867
The Musical Telegraph Elisha Grey USA 1876
The Singing Arc William Duddel UK 1899
The Telharmonium Thaddeus Cahill USA 1897
The Choralcelo Melvin Severy USA 1909
The « Intonarumori » Luigi Russolo Italy 1913
The Audion Piano Lee De Forest USA 1915
The Optophonic Piano Vladimir Rossiné Soviet Union 1916
The Theremin Leon Termen Soviet Union 1917
The Sphäraphon Jörg Mager Germany 1921
The Staccatone Hugo Gernsbak Germany 1923
KurbelSphäraphon Jörg Mager Germany 1923
The Pianorad Hugo Gernsbak Germany 1926
The Dynaphone René Bertrand France 1927
The Celluphone Pierre Toulon & Krugg Bass France 1927
The Clavier à Lampes A.Givelet & E.Coupleaux France 1927
The Klaviatursphäraphon or Sphaerophon Jörg Mager Germany 1928
The Ondes-Martenot Maurice Martenot France 1928
The Superpiano E. Spielmann Austria 1928
Piano Radio-Électrique A.Givelet & E.Coupleaux France 1929
The Givelet A.Givelet & E.Coupleaux France 1929
The Sonorous Cross Nikolay Obukhov France 1929
The Hellertion B.Helberger & P.Lertes Germany 1929
The Trautonium Dr Freidrich Trautwein Germany 1930
The Ondium Péchadre H. Péchadre France 1930
The Rhythmicon Henry Cowell & Leon Termen USA 1930
The Terpsitone Leon Termen USA/USSR 1930
The Theremin Cello Leon Termen USA 1930
The Westinghouse Organ R.C.Hitchock USA 1930
The Sonar N.Anan’yev Soviet Union c1930
Saraga-Generator Wolja Saraga Germany 1931
The « Ekvodin » V.A.Gurov Soviet Union 1931
The Trillion Tone Organ A. Lesti & F. Sammis. USA 1931
The Variophone Yevgeny Sholpo Soviet Union 1932
The Emiriton A.Ivanov & A.Rimsky-Korsakov Soviet Union 1932
The Emicon N.Langer USA 1932
The Rangertone Organ Richard H.Ranger USA 1932
L’Orgue des Ondes Armand Givelet France 1933
The Electrochord Oskar Vierling Germany 1933
Syntronic Organ I.Eremeef & L.Stokowski USA 1934
The Polytone Organ A. Lesti & F. Sammis USA 1934
The Hammond Organ Laurens Hammond USA 1935
The Photona Ivan Eremeef and L. Stokowski USA 1935
The sonothèque L. Lavalée France 1936
The Heliophon Bruno Hellberger Germany 1936
The Grösstonorgel Oskar Vierling Germany 1936
The Welte Licht-Ton-Orgel E.Welte Germany 1936
The Singing Keyboard F. Sammis USA 1936
The Warbo Formant Orgel Harald Bode & C. Warnke Germany 1937
The Melodium Harald Bode Germany 1937
The Kaleidophon Jörg Mager Germany 1939
The Novachord L Hammond & C.N.Williams USA 1939
The Voder & Vocoder Homer Dudley USA 1940
The Univox Univox Co. UK 1940
The Multimonica Harald Bode Germany 1940
The Pianophon 1940
The Ondioline Georges Jenny France 1940
The Solovox Hammond Organs Company USA 1940
The Electronic Sackbut Hugh Le Caine Canada 1945
The Tuttivox Harald Bode USA 1946
Hanert Electric Orchestra J. Hanert USA 1945
The Minshall Organ USA 1947
The Clavioline M. Constant Martin France 1947
The Melochord Harald Bode Germany 1947
The Monochord Dr Freidrich Trautwein Germany 1948
The Free Music Machine Percy Grainger & Burnett Cross USA/Australia 1948
The Electronium Pi René Seybold Germany 1950
The Polychord Organ Harald Bode USA 1950
Dr Kent’s Electronic Music Box Dr Earle Kent USA 1951
The Clavivox Raymond Scott USA 1952
The RCA Synthesiser I & II Harry Olsen & Hebert Belar USA 1952
The Composertron Osmond Kendall Canada 1953
The Chombichord Harald Bode/ Constant Martin France 1953
The Chombichord Harald Bode/ Constant Martin France 1953
Spatiodynamique and Cybernétique Tower Nicolas Schöffer France 1955
The ANS Synthesiser Eugeniy Murzin Soviet Union 1958
Oramics Daphne Oram UK 1959
The Siemens Synthesiser H.Klein & W.Schaaf Germany 1959
The Side Man Wurlitzer USA 1959
Milan Electronic Music Studio director: Luciano Berio Italy 1960
DIMI & Helsinki Electronic Music Studio Erkki Kurenniemi Finland 1961
Moog Synthesisers Robert Moog USA 1963
The Mellotron & Chamberlin Leslie Bradley UK 1963
Buchla Synthesisers Donald Buchla USA 1963
The Donca-Matic DA-20 Keio Corp Japan 1963
The Synket Paul Ketoff UK 1963
Tonus/ARP Synthesisers Philip Dodds USA 1964
PAiA Electronics, Inc John Paia Simonton USA 1967
MUSYS Software David Cockrell & Peter Grogno UK 1968
EMS Synthesisers Peter Zinovieff & David Cockrell UK 1969
GROOVE System Max Mathews USA 1970
The Optigan Mattel Inc. USA 1970
The Electronium-Scott Raymond Scott USA 1970
Con Brio Synthesisers USA 1971
Allen Digital Computer Organ Ralph Deutsch/Allen Organ Company USA 1971
Roland Synthesisers Roland Corporation Japan 1972
Maplin Synthesisers Trevor G Marshall Australia/USA 1973
The Synclavier New England Digital Corporation USA 1975
Korg Synthesisers Korg Japan 1975
EVI wind instrument Nyle Steiner USA 1975
EDP Wasp Chris Hugget UK 1978
Yamaha Synthesisers Yamaha Corp Japan 1976
PPG Synthesisers Wolfgang Palm Germany 1975
Oberheim Synthesisers Thomas Oberheim USA 1978
Serge Synthesisers 1979
The Fairlight CMI Peter Vogel & Kim Ryrie Australia 1979
Simmons Drum Synthesisers Simmons UK 1980
Casio Synthesisers Casio Ltd Japan 1981
The McLeyvier David McLey USA 1981
Kawai Synthesiser Kawai Musical Instrument Co Japan
The Emulator Emu Systems USA 1981
Waldorf Germany
Oxford Synthesiser Company Chris Hugget UK 1983
Akai Musical Instruments Akai Corporation Japan 1984
Ensoniq Synthesisers & Samplers USA 1985
Steinberg Software Steinberg Germany
GEM Synthesisers
Crumar Synthesisers
Kurzweil Synthesisers/Samplers Raymond Kurzweill USA/Korea 1983
Sequential Circuits USA
Alesis Corporation Keith Barr USA 1984

document: how-to-use-usb-without-knowing-usb.pdf

Technical Papers:

How to Use USB without Knowing USB

John Hyde
USB Design by Example

USB is now a mature technology yet many people are not using it since they perceive it as « too complicated. » To date, all USB books and most USB technical articles have presented USB as a « technical wonder » and the reader is flooded with details such as packet types and descriptor parsing. Not surprisingly, many people who could take advantage of USB are holding back. This paper treats USB as a tool that can be used to solve real world problems in embedded systems design.


USB est une technologie mature encore beaucoup de personnes ne l’utilisez pas car ils le perçoivent comme « trop compliqué ». À ce jour, tous les livres de USB et la plupart articles techniques de USB ont présenté USB comme une «merveille technique», et le lecteur est inondé avec des détails tels que les types de paquages et de l’analyse du descripteur. Sans surprise, beaucoup de personnes, qui pourrait tirer avantage de l’USB, freinent. Ce document traite USB comme un outil qui peut être utilisé pour résoudre des problèmes mondiaux dans la conception de systèmes embarqués.


Ce document travaille sur beaucoup d’exemples, en commençant par un seul bouton et se terminant en y intégrant le contrôleur USB hôte. Il ya trois sections distinctes, ce qui couvre l’introduction essentielle USB mais a expliqué la terminologie relative à RS232 qui vous le savez déjà, je puis construire une gamme de systèmes embarqués qui s’attachent à un hôte USB tels qu’un PC, Mac, Linux, ou de n’importe quel port USB-aware OS; je puis ajouter un périphérique de stockage de masse à un produit embarqué. Vous découvrirez que l’ensemble des bas-niveau USB questions ont été déjà résolu et vous pouvez utiliser ces éléments constitutifs pour résoudre vos défis de conception des systèmes embarqués. Ces exemples sont téléchargeables à partir

document:  newport_carrier_voip.pdf

 Newport Networks

With recent technological advances in Voice over IP (VoIP), the communications industry has, at last, reached a position of strength. In the past, the technology lacked the maturity to deliver a profitable and sustainable VoIP business model; but with recent breakthroughs they have now reached a position in which carriers can introduce profitable, carrier-class VoIP services.

This white paper explores the business and technical requirements facing the carrier in the delivery of carrier-class VoIP services and, in particular, looks at the role of the Session border controller in overcoming these historic challenges.


Pub: Mini-ITX, Embedded Solution(, smart assembly, korenix.
Security has become a hot global topic. Banks make a point to advertise the security of their online services. Credit cards boast built-in security chips. The press regularly reports of computer vulnerabilities and attacks wrecking havoc among unsuspecting computer users.Even more disturbing, we hear news of hackers penetrating highly sensitive financial and government institutions. There is an ongoing war between the « good guys », trying to bring to life the promise of computer and Internet technology, and the « bad guys » using the same for nefarious purposes.I too, was recently hit by a « phishing » attack. I received an e-mail from Bank of America Military Bank Online (so it seemed). The e-mail spoke of a modification to my account that, while innocuous, still required that I log in to acknowledge the change. I browsed the web site; it appeared genuine.
However, I never served in the military so I reported the incident to Bank of America and was told they had received similar reports. The (authentic) Bank of America web site had an FAQ on these types of attacks, including screen shots to help spot phishing. Amusingly, a common indicator is spelling errors.

While my big phishing story was merely fodder for dinner conversation (pun intended), it reminded me of the great need for constant vigilance. Concern and curiosity led to a little research. I inquired about my workplace for similar experiences and received numerous stories of stolen electronic identities, malware, more phishing attempts, etc.

I checked into some of the security tracking sites and discovered some alarming statistics. I learned there have been over 800 successful hacker attacks on the Department of Homeland Security. According to CERT, in 2007 there were over 7,200 network vulnerabilities logged.

Many of these types of vulnerabilities can be prevented, and it largely depends on how computer information systems are designed and implemented. The problem is that developing and promulgating highly secure systems is not easy, especially with our dependence upon legacy systems that have been around for years and were never designed with security in mind.

But, in this age of innovation and automation, can’t we invent something to solve these problems? If computers can fly (and land) airplanes, drive cars, and fix a kitchen oven via the Internet, can’t they help ensure that the software we develop is secure?

Yes, they can.

One promising solution comes from a relatively new branch of software development tools called static source analysis. In a nutshell, a static source analyzer is a tool that examines software source code and looks for defects that can result in security holes.

Much of the world’s software uses programming languages – such as C, C++, and Java – that are a double-edged sword: while powerful and flexible, these languages also permit programmers to shoot themselves in the foot.

Many of my fellow engineers regularly wrestle with a slew of programming pitfalls: « uninitialized variables, » « buffer overflows, » and « race conditions », to name a few.

The good news is that static analyzers can catch these flaws and report them to the developer before the product is ever deployed. That is great stuff, you might think, but how does this help make a computer more secure? First, let’s look at what makes systems vulnerable.

Hacking for Dummies
If you believe the stuff you see in the movies, you might think that hackers are a bunch of non-conforming geeks with green spiky hair who spend most of their time hanging out at techno dance clubs. Oh yeah, and in their spare time, they break into highly secure systems mostly to play pranks or perhaps to « borrow » a few bucks to support their whirlwind lifestyle. The reality is a bit different.

While there is a fair share of rebels among hackers, many belong to organized, well funded groups. They spend weeks developing ways to break into a particular system. Much of the work is drudgery, poring over thousands of lines of source or machine code. With the increasing use of open source software, much of the code is readily available making the hackers’ jobs much easier.

While less glamorous than what Hollywood studios illustrate, the hacker’s labor can result in something far more sinister than what you see on the big screen. Instead of pranks, hackers are targeting the nation’s power grid, the financial industry, and the most sensitive military secrets.

An attacker tries some or all of the following:

Find a Back Door  » the hacker will look for a way to get into a system through non-traditional means, for instance pretending to be another computer instead of a user. Once a hacker breaks in, they may download a program that creates a password for later use. In the process, the hacker hides evidence of the break-in.

Know the System Better than the Developer  » since large systems are often implemented by hundreds or even thousands of developers, portions of the implementation will be less understood than others  » too many cooks, so to speak. A hacker doesn’t need to understand the entire system  » only the most vulnerable parts.

Look for Paths Less Traveled  » every application or system has components that are used more frequently compared to others that execute less often. The 80/20 rule usually applies: 20% of the code runs 80% of the time.

That means 20% of the code is probably more reliable and secure. Conversely, the remaining 80% of less traveled code could be riddled with security holes that go undetected for years. When it comes to security, the aphorism « a chain is as strong as its weakest link » couldn’t be more appropriate: all the hacker needs is one way in, and a path rarely taken is a fertile place to look.

Time It Well  » the hacker who succeeds in breaking in will often get only one chance to strike before the attack is detected. Therefore, the attack must be carefully timed.

Figure 1: Static source analyzer showing how two separate lines of code, when combined, form a defect. Each line by itself is correct, but the combination of the two produces a possible NULL pointer dereference defect. Source: Green Hills Software

Hackers Meet Their Match
When it comes to the grunt work of understanding the source code and looking for vulnerabilities, hackers have a bag of tricks known to expose vulnerabilities.

Static source analyzers (Figure 1, above) are designed to detect exactly the scenarios that are likely to cause vulnerabilities, revealing them to the programmer before the system is released. By running the code through a static analyzer, hackers lose their one chance of a strike. In effect, an ounce of static analysis prevention is worth a pound of cure against a successful attack.

These are some of the hacker’s all time favorites, and the ways static analyzers battle them:

1) Buffer Overflow  » Whenever a system needs to store a piece of data, like a user name, it needs to allocate a piece of memory, or a buffer. When the buffer is being filled with data (for instance a user types in their login name), it is easy to go beyond the pre-allocated amount of memory, if a programmer wasn’t careful.

That would make the system start reading or writing over some other data (like data that tell the system which code to execute next). Crafty hackers can this way insert a program of their own into the system. If their program gets access to the system, they can create new passwords, and in the process hide the evidence of their break-in.

Solution: static source analyzers are able to easily catch buffer overflows. They track the amount of allocated memory and look for accesses into the buffer. When they detect a buffer access that is beyond the initially allocated memory, static analyzers report an error. This way the error is fixed well before the system is released and exposed to hacker attacks.

2) Broken Invariant (e.g. uninitialized variable)  » In languages like C and C++, variables are constructs to create a state that the system uses to make decisions. A program can have thousands of variables, and each one needs to be explicitly given the initial value by the programmer.

If a programmer fails to give a variable an initial value that makes sense to the system, the system may behave unpredictably. If the system is behaving in unpredicted and untested ways, unforeseen security holes can quickly open up.

Solution: static analyzers keep track of variables when they are initialized and with what values. Static analyzers can also distinguish if a variable is used just for its own value (in which case the value itself needs to be something expected), or if a variable is used as a pointer to an object that describes some more complex state (in which case the object that is pointed to and the variable both need to be something expected). Again, static analyzers can check for that.

3) Resource Leak  » Ideally, a system is supposed to run forever. As one of its fundamental functions, a system grants resources to applications running on a system. Resources like memory, disk access, accesses to media ports, etc. are limited by the hardware that’s installed.

When resources are no longer used by an application (e.g. an application releases a resource or gets terminated), the system needs to « recycle » them for the next application that requests them.

If a programmer fails to instruct the system to reclaim these resources, a hacker can create a vulnerable scenario where, for instance, more and more memory is allocated until the memory pool is entirely exhausted. This often leads to « denial of service » attacks, because the system is busy looking for resources that are simply not available.

Solution: Static analyzers can be customized to understand the types of resources a system can grant. Systems will have different ways of allocating, using, and reclaiming resources  » also known as the API (Application Programming Interface).

A static analyzer can ensure that a program’s use of a system resource can only occur after a resource has been allocated through a special API set of instructions. Also, a static analyzer can make sure the program releases the resource through the API instructions once it is no longer going to use it, thus preventing a resource leak.

4) Stack Overflow – this vulnerability is much harder to detect, and can be especially dangerous in today’s multi-threaded systems. A function stack is a piece of local memory that a program must have pre-allocated in order to successfully run.

The biggest problem with function stacks is that the programmer must know how much memory to allocate when a new thread is created. Accurately computing that number can be difficult. What ends up happening is that most programmers basically make an educated guess of how much memory is needed (and sometimes throw in a few extra kilobytes, just for good measure).

If this sounds like the wild west of programming, that’s because it is. If programmers get this value wrong (i.e. too small), a function stack of one thread of execution may corrupt a function stack of another and cause subtle, hard to reproduce bugs which are nearly impossible to find. Worse yet, they often slip through tests and QA processes making their way into the released code.

Solution: until recently, static analyzers had no way of battling this issue. What made this impossible to detect was that there was nothing wrong with the source code, but with the interaction between the compiler (tool that translates source code into machine code) and the way a program was structured to execute. The solution comes in a new design of static analyzers, which integrates them into the compilers. This synergy of static analyzers and compilers results in a whole new class of problems that can be detected.

Next in Part 2: Implementing Security

As a Director of Engineering at Green Hills Software, Nikola Valerjev is responsible for managing teams that plan, design, and develop new products, including the DoubleCheck static source analyzer. He also manages teams that evaluate new and existing solutions from the user perspective. Mr. Valerjev holds a Bachelor of Science and a Master of Engineering degree in computer science from Cornell University. He has been with Green Hills Software since 1997.

Blog Stats

  • 245,109 hits


Meilleurs clics

  • Aucun

RSS Flux inconnu

  • Erreur, le flux RSS est probablement en panne. Essayez plus tard.