CuteFTP Professional is a software tool for transferring files between your PC and remote computers anywhere on the Internet, securely and efficiently, over multiple Internet protocols. Its built-in Connection Wizard will walk you through connecting to an FTP site in seconds and its user-friendly interface will have you transferring files in no time, even if you are a beginner. Whether publishing a Web page, downloading the latest digital images, software and music or transferring high-volume files between branch offices. CuteFTP Professional provides simple yet powerful tools for tackling the complex challenges of data management and helps achieve HIPAA, GLBA and Sarbanes-Oxley compliance.

360desktop gives your desktop a life!
Get almost unlimited desktop space; make desktop widgets from your favorite pieces of the web, plus create & share 360° interactive wallpaper.

More room for everything you like to do360desktop transforms your desktop into a panoramic workspace - with more space for everything. Slide around your new workspace quickly and easily between all your open applications, windows and widgets - it’ll spin you out.

Easily make desktop widgets from your favorite parts of the webSee something that you like online? You can now clip it and put it right on the desktop: any part of any webpage or grab your favorite web widgets, RSS feeds, games, videos - whatever you like - it’s totally up to you!

An endless selection of stunning 360⁰ wallpaperBring your desktop to life, with an endless selection of stunning 360⁰ wallpaper. Incredible web enabled 360’s, that can be inspiring, entertaining, branded, useful or just plain fun - whatever your interest, work or play.

Lien: cliquez ici

Une extension de Simscape avec les outils pour modéliser et simuler les systèmes électroniques et électromécaniques.

Plus d’information :

http://www.mathworks.fr

91563

link : http://www.linuxdevices.com/articles/AT2614444132.html

• Part 1: About this guide
• Part 2: A Linux-oriented Intro to Embeddable Single Board Computers
• Part 3: PC/104 and PC/104-Plus SBCs
• Part 4: EBX SBCs
• Part 5: Filling the gap between PC/104 and EBX
  
• Part 6: Tiny SBCs for Embedded Linux based projects
• Part 7: Mini-ITX Madness

Welcome to LinuxDevices.com’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, LinuxDevices.com 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 LinuxDevices.com 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 LinuxDevices.com 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 LinuxDevices.com 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
• PCMCIA
• 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 LinuxDevices.com 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 LinuxDevices.com 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, I²C/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, I²C/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).
• Mini-ITX.com — a website devoted to mini-ITX news and projects — Mini-ITX.com 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
• LinITX.org — portal for Linux on Mini-ITX hardware — LinITX.org 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

lien : http://www.embedded.com/columns/guest/204300438?_requestid=825265

traduction par translate.google : lien

Search for embedded Linux patents

lien : http://www.embedded.com/columns/guest/204801349?_requestid=825259

traduction par translate.google: lien

Embedded OS trends points to Linux…sometimes

While the use of Linux continues to sail along at a nice clip, the number of people kicking the tires is shrinking, for all the right reasons.

The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.

While Linux and complex RTOS products offer such attractive capabilities, they’re also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.

Linux’s complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.

But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system’s technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There’s little time to sort out configuration complexities, or to learn which of the many services are actually needed.

While Linux and complex RTOSs with similar features deliver abundant capabilities, they also occupy a fair bit of memory. If available memory is limited by physical footprint, cost, or power consumption constraints, or if low overhead and a rapid real-time response are needed, then it may be time to take an alternate approach. In such circumstances, a large Linux image or a complex RTOS might not cut it. What might be better is a smaller, simpler, more efficient solution, one that still meets the needs of the application, but doesn’t impose unnecessary complexity on top. For such needs, a small-footprint, low-overhead, simpler RTOS might very well be more suitable.

One of the newer trends in embedded software involves designing simpler solutions for applications that don’t need all the features. This concept applies to many embedded systems as they may not require virtual memory or hundreds of system services. Instead, many embedded real-time applications need just a few basic capabilities, such as priority-based preemptive scheduling, dynamic memory allocation and recovery, inter-task message passing, interrupt management, resource-locking semaphores, and timers.

Addressing these basic needs enables a simple RTOS to satisfy a large number of applications in consumer electronics, medical devices, industrial automation, test and measurement equipment, and wireless networking devices. Developers of these systems can minimize development time by choosing an RTOS that addresses their needs without excess complexity. Shortening development time pays additional dividends in lower development costs, faster time to market, and greater market share. For these applications, “less” actually is better, and delivers “more” for the developer.

The “less is more” adage is supported by findings in recent survey of embedded developers by Embedded Market Forecasters (EMF). This survey reveals that developers who recently used certain RTOSs tended to complete their projects on time or ahead of schedule more frequently than those who used other OS. This observation indicates that the RTOS used plays a role in the timely completion of embedded development projects.

By limiting the complexity of the RTOS, fewer services have to be learned and used, and this makes them more likely to be used correctly. Certainly, some applications require virtual memory and other complex features, but many don’t. It’s better to determine the needs of the application, and then use an RTOS that meets those needs without overkill. Several small, simple RTOSs are available commercially, and most offer full source code, royalty-free licensing, and commercial support. These offerings are generally simpler and easier to use than “full-featured” OSs with their large repertoire of services.

Another recent survey of embedded developers, this one by CMP, indicates that developers may already be taking steps away from complex systems. As the figure below indicates, the number of developers not considering Linux for their next project jumped from 34% in 2006 to 48% this year.

(Figure from “Annual study uncovers the embedded market,”Richard Nass, Embedded Systems Design, Sept. 2007.)

While one could conclude that Linux is losing its overall appeal, these results don’t necessarily indicate that. The results may imply that Linux is settling into the application areas for which it’s the best fit, and not being considered in other areas as much as it used to be. Developers initially caught up with the hype of a “free” OS may have come to realize that the complexity and downstream costs more than offsets the zero initial product cost, and therefore have turned to simpler approaches that ended up successful. Hence, they’re not considering Linux for future systems because they’ve found a better approach. Based on their experience, those developers will have a better knowledge of when and where Linux makes most sense and will be less willing to use Linux in the future unless it’s absolutely needed.

Recent comments on this survey data by leading editors who cover the embedded systems space support the conclusion that embedded developers are beginning to consider alternatives to Linux. For example, Rich Nass, editor-in-chief of Embedded Systems Design (ESD), in reflecting on the CMP survey data indicated that the industry has turned the corner on the embedded Linux hype in a report covering the embedded systems market. ESD Editorial board member Bill Gatliff seconded that motion in stating, “We’re finally turning the hype corner on Linux and realizing it’s not right for all applications.”

Michael Barr, a former ESD editor-in-chief, concurred with Nass and Gatliff, commenting, “There always seem to be some interesting new technologies, but they are not always adopted. But Linux actually succeeded, and a lot of people were using it in telecomm apps and so on, for stuff that looks like a PC. Clearly that trend is continuing, but obviously at a slower pace.”

Matt Assay of C|Net points to the unexpected cost of Linux as being a factor. “When I was involved in embedded Linux, the No. 1 drivers of adoption were cost and flexibility. …embedded developers were adopting Linux because it was perceived to be free. In fact, I can remember more than one occasion when a big OEM opted not to go with Lineo because we charged for commercial support, tried to go it alone, and came back to us to purchase support six to nine months later after they failed. Good service always costs money, whether you do that service yourself or pay someone else to do it. Either you pay in terms of your own time/resources or you pay in terms of someone else’s. There really is no free lunch.”

The “less is more” approach attracts developers that otherwise might opt to use Linux or a complex OS solution-not because Linux or large OSs aren’t good technology and ideal for many applications, but because they’re not the best choice for all applications, and developers are getting wise to this distinction. In many cases, developers realize that such large-scale solutions either can’t handle hard real-time, small footprint, low-cost requirements, or they’re overkill for those requirements and hinder rapid development. Projects with modest requirements are common, and those projects might be better suited to one of the many small RTOSs on the market.

For fast time to market, truly, less is more.

John A. Carbone is the vice-president of marketing at Express Logic Inc. He can be reached at jcarbone@expresslogic.com.

lien : http://www.embedded.com/columns/guest/207402542?_requestid=825240

en français par google.translate: lien

Si les champions de Linux embarqué disent que Linux embarqué est terrible, pourquoi tout le monde veut risquer leur produits ou leur entreprise? [...]

If embedded Linux champions are saying that embedded Linux is terrible, why would anyone want to risk their products or their company on it?

Robert Anderson
Xilinx

 

This paper is the first in a three-part series describing techniques and methods for using MATLAB as an executable specification for hardware development. Why use MATLAB as an executable specification for hardware when other options exist such as Simulink, C, or RTL? The answer is verification. Because when the application is signal processing, MATLAB offers a vastly superior environment for input vector generation and output waveform analysis.

Using MATLAB allows the algorithm developer to create a model that more accurately describes the characteristics of the final hardware implementation. This flow enables the algorithm developer to reduce design iterations, shorten development cycles, and assert more control over the hardware development process.

 

Link: xilinx_matlab

Most signal processing and communication projects nowadays at some point require translating MATLAB code into equivalent C code. Goals and requirements of the resulting C code can be diverse. Examples include:

While C code requirements vary widely, some translation pitfalls are common across all applications and teams. Many of these pitfalls derive from the fact that MATLAB is essentially an interpreted language. Consequently, it does not require a priori knowledge. I.e., MATLAB doesn’t know the type, shape, dimension or even the existence of any variable or function until execution.

Let us list some of the most common or bothersome pitfalls:

• MATLAB indexes array elements starting with 1 whereas C indexing starts with 0
• MATLAB is column major whereas C is row major. This means consecutive data in MATLAB are column elements whereas consecutive data in C are row elements.
• MATLAB is inherently a vector-based representation. This can make the translation challenging. In particular:
  • You must replace the simplest vector operations with a loop construct
  • Operators (such as times ‘*’) in MATLAB perform different operations depending on the type of the operands
  • MATLAB includes very simple and powerful vector operations such as the concatenation “[]“and column “x(:)” operators or “end” construct, which can be quite hard to map to C
• MATLAB supports “polymorphism” whereas C does not. I.e., you can write a generic function in MATLAB, which can process different types of input parameters. In C, each parameter has one given type, which cannot change.
• MATLAB supports dynamic extensions and sizing of arrays, whereas C code requires storage to be allocated explicitly using malloc/free.
• MATLAB draws on a rich set of libraries that are not available in C. Implementing such functions requires writing new code. Sometimes there are pre-exiting libraries and functions available for your target platform, but integrating them into your application can be problematic. In addition to running into licensing issues (such using GPL code for commercial application), interfacing with these libraries is non-trivial.
• MATLAB supports reusing the same variable for different contents (different types). C does not, as each variable has one unique type.

As we will see, the process of writing C code from MATLAB is trickier than it sounds.

Preliminary step - What are my inputs?
When converting MATLAB to C, the first thing you need is a description of your function’s input parameters. This is because MATLAB, being an interpreted language, does not require declaration of data type for any variable.

Complicating matters, MATLAB variables have the following features not available in C

• The ability to have a variable number of parameters
• MATLAB data types that have no C equivalent, such as “cell arrays”, a collection of heterogeneous types packed into slices of an array

Typically, information about input parameters can be found in comments embedded at the top of the MATLAB function, or in a report written by the MATLAB code implementer.

Conversion Examples
With the input parameters defined, we can now turn to the MATLAB code itself. To illustrate some basic issues with translating MATLAB to C, we will show three examples, which we will translate by hand.

Example 1 – Simple(?) MATLAB code
Let’s start with a simple example. The MATLAB code below take in a vector ‘x’, and returns all but the first two values, sorted in ascending order, that are greater than a given threshold.

In MATLAB, this is an easy feat:

We can run it on a simple case:

Even such a trivial example, which does not make use of any advanced matrix or mathematical features of MATLAB, presents a number of problems for the C implementer:

An example implementation, as written in syntactically correct C, is shown below (where the “my_sort” function still has to be implemented):

We have only scratched the surface, but clearly, there is nothing obvious about translating such simple MATLAB code into C.

Example 2: Polymorphism
MATLAB does not require knowing the type of the input parameters. This means that one single function can be called with different arguments. Moreover, the times operator ‘*’ in MATLAB can perform a cross-product, a norm or an element-by-element multiplication depending on the operands, as shown below.

In this case, the function “polymorph” performs two very different computations to compute ‘a’ and ‘b’:

• for ‘a’, it computes the norm of the vector ‘x_complex_matrix’ which is +30.
• for ‘b’, it computes the sum of the multiplication of ‘x_complex_matrix’ with a scalar (’x_real_scalar’). The result is 12 -6i

We can run this function in MATLAB:

When translating this behavior to C, you are likely to want to write two completely different functions for “polymorph’.

Here is an example of how this function would look like in C, assuming we know that the input matrix has 10 elements.

(Click to enlarge)
Example 3: Dealing with unintended array expansion
One of our favorite (and real-life) examples is the unintentional expansion of a pre-defined array in MATLAB.

The story goes like this: the MATLAB designer thinks that array ‘x’ is 14-elements long. He declares it to be that way and never worries about whether this is actually the case or not. The C implementer, taking his word for it, declares ‘x’ to be ‘double[14]‘.

After countless simulations and week-ends spent debugging the mismatches between the MATLAB code and the C code, it turns out x was actually 15-long (in some exceptional case) and that the C code was reading in incorrect values.

MATLAB, indeed, lets you write statements such as:

If N turns out to be 15 at some point, you are not going to get any hint: “x” is going to be automatically extended to 15 elements. Not so in C, with the consequences mentioned above.

Part2:

Complex functions and C interfaces

In the first part of this series, we showed how basic MATLAB operations can be translated into C code. This section focuses on translating more complex MATLAB functions or toolbox functions into C, and on integrating C algorithms derived from MATLAB into your application.

Implementing complex MATLAB functions
Of the many MATLAB functions used to develop algorithms, most do not have equivalents in the C language. For example, the C language does not have equivalents for basic MATLAB functions such as “find” (which automatically extracts elements from an array) or “sort” (which sorts array elements).

Some of these functions are fairly well known and can be found in C libraries or on the Internet. For example, it is easy to find sorting algorithms. Nevertheless, finding the most efficient implementation for MATLAB’s sort function can be quite an adventure, as noted in this article.

In addition, you may not be able to use the functions you find due to license restrictions. These include license restrictions on derivative work from copyrighted material (such as MATLAB files) or open-source (GPL) files. In such case, you may need to carefully and independently recode the algorithms by hand for your commercial application.

When you implement a MATLAB function in a language such as C, you may find it difficult to replicate MATLAB’s results. For example, image processing applications may use morphology functions such as “imresize” to resize an image. When implementing such functions, it is easy to end up with results that are a fraction of a pixel off from MATLAB’s results. (Even MATLAB 2006b and 2007a produce different results for the “imresize” function because they implement it differently). To replicate MATLAB’s results, you may need to recalibrate your algorithm in C. This might add significant delay to your project.

Some functions have implementations in both MATLAB and C. The standard math C library can be used to implement functions such as divide, sqrt, cos, sin, etc. in C when dealing with real scalar data. Things get more complicated once you start adding complex numbers and matrices into the mix.

For example, the operation “a/b” may be look like a simple divide operator in MATLAB.

When the operands are complex scalars, the operation is slightly more complicated in C:

If b is a matrix, “a/b” becomes a “matrix divide,” which is a lot more complicated to implement. A “matrix divide” requires solving a linear system of equations consisting of finding ‘x’ such that “a*x=b”. This is typically performed using complex matrix manipulations based on matrix QR decompositions. An example of this approach is shown in Implementing matrix inversions in fixed-point hardware.

Integrating with other functions and interface definition
When translating a MATLAB algorithm to C, you may be able to re-use existing code or leverage functions available in libraries. Your task then is to integrate the C code derived from your MATLAB algorithm with existing source code and libraries. To make this integration successful you need to make sure the interfaces of your different functions are compatible. In particular, you need to pay special attention to conventions on how complex and multi-dimensional variables are laid out in memory, when data are passed by references and by value, and whether indices start from 1 or 0.

Indices start with 1 in MATLAB and 0 in C
One difference between MATLAB and C is that MATLAB uses one-base indexing whereas C uses zero-base indexing. This means that the index of the first element of an array in C is 0, and is 1 in MATLAB.

You need to be aware of this when communicating index values between C and MATLAB functions, otherwise you may end up addressing elements that are off by one in your final C code.

Consecutive array elements are stored in columns in MATLAB and in rows in C
MATLAB use column-major order, which mean column elements are stored next to each other in memory. In contrast, C uses row-major order, which means that row elements are stored next to each other. (See Wikipedia for details on the two array layouts.) Array layout is critical for correctly passing arrays between C and MATLAB functions. It is also important when accessing a specific data element using a single subscript ((*a)[i] instead of a[i][j]), or for traversing an array without cache misses for good performance.

If your NxM MATLAB array is implemented as an NxM array in C, you need to watch out for single subscripts. In the example below, the 7th element of the array cst in MATLAB is cst(7) that stores the value “4″. The 7th element of the array cst in C is cst[7-1] that stores the value “7″. To access the value “4″ in the C code, you would need to access cst[4-1]. As a result, when arrays are addressed with single-subscript expressions, you might have to add some extra computation in order to access the right location within your array.

(Click to enlarge)
Some algorithms such as symmetrical filters do not depend on the orientation of the data, which means they produce the same outputs when traversing data row by row or column by column. In this case, it is not necessary to recompute single subscript expressions in your C code.

If you want the data in the C code to be located at the same positions as in MATLAB, your other option is to map the NxM array in MATLAB into a MxN array in C. In the example below, the 7th element of the array is cst(7) in MATLAB and cst_rot[7-1] in C and they both store the value “4″. This requires rotating the data when interfacing with other C code that expects data to be stored in row-major order. An example of this approach is shown here.

(Click to enlarge)
Rotating data into and out of your function requires extra memory and copying. In many cases, it is more efficient to translate MATLAB’s column-major code into a row-major C code.

Dealing with Complex numbers
Support for complex data is built into MATLAB. For example, the result of an FFT is simply stored into a variable “y=fft(x)”. The implementation of the complex data type itself is abstracted away from the programmer. In contrast, ANSI-C does not have a built-in data type for complex numbers. (Complex data support has been added as part of the C99 standard.)

Typically, there are two ways of implementing complex arrays:

• Separate or split complex: the real part and imaginary part are stored into two separate arrays (e.g. separate a_real[0] and a_imag[0])
• Interleaved: the real and imaginary parts of a given array element are stored next to each other in memory (e.g. interleaved a[0] for the real part and a[1] for the imaginary part)

Much like with row-major vs. column-major, the decision on which implementation to use depends on how data is accessed in the algorithm and most importantly on how data is communicated to external functions.

MATLAB stores real and imaginary parts in separate arrays. This makes calls to the “real” and “imag” functions trivial to implement. On the other hand, many programming environments (including C99, FORTRAN, etc) and common libraries (Intel MKL, LAPACK, BLAS, FFTW, etc.) make use of the interleaved complex data type.

Translating split complex data into interleaved complex data requires extra memory and copies. If your algorithm often calls functions that are only available with interleaved complex data, it is more efficient to translate MATLAB’s split complex arrays into interleaved complex arrays in C.

Passing arrays by reference
MATLAB programmers typically do not have to worry about whether data are passed by reference or by value. Internally, all arrays in MATLAB are kept as “references” as long as their values remain unchanged. A local copy of the array is created as soon as a value within the array changes, in order to prevent unexpected side-effects.

To replicate this semantics in C, you need to copy data explicitly. As an example, if an array is the input of a function, it may only be passed by reference if that array does not get modified inside of the function.

MATL