You are currently browsing the category archive for the 'robotique' category.
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 :
Le constructeur suisse Samsys de système d’alimentation de barres pour tours propose un ravitailleur innovant, le Winning’Sam, pour automatiser le chargement/déchargement de pièces pour tours et centres d’usinage.
Lors du choix et de l’achat d’une machine-outil type tour, il est difficile d’imaginer sur le long terme quels seront les types de pièces qu’elle sera amenée à usiner dans le futur. Faut-il s’orienter vers une automatisation pour travailler en barres ou lopins, ou bien trouver une solution qui permet le ravitaillement automatique des barres et des lopins ? Jusqu’à présent, pour pouvoir usiner tous les types de pièces, le client devait souvent s’orienter vers l’acquisition de deux machines différentes, d’où d’évidents problèmes d’encombrement. Sans compter la nécessité d’investir dans deux systèmes de programmation.
Pour solutionner en partie ses problématiques, Samsys vient d’être lauréat du Trophée Industrie 2008 dans la catégorie Machines-Outils/Outils, avec un système innovant de chargement/déchargement de pièces pour des tours et centres d’usinage.
Le Winning’Sam et quelques détails illustrant ses usages et ses innovations
© Doga
Un “service complet” de chargement, déchargement et rangement
D’après Samsys, le Winning’Sam est à ce jour le seul dispositif au monde qui permet de ravitailler en automatique des lopins, des arbres et des pièces coulées. Il offre de multiples possibilités : chargement des barres, récupération des pièces usinées (même délicates), et récupération des chutes à l’aide d’un portique avec séparation des pièces usinées et des copeaux. Winning’Sam est ainsi une nouvelle génération combinant les avantages du robot et du ravitailleur qui, pour un même investissement, anticipe les besoins à venir et offre de nouvelles perspectives de ravitaillement avec une mise en œuvre simple et rapide.
Samsys a ainsi conçu un “serviteur” universel pour tours et centres d’usinages, capable d’assurer un “service complet” de chargement, déchargement, rangement et autres manipulations éventuellement requises, en un seul système.
L’ensemble manipule, charge et décharge des lopins et des pièces de forme, soit des lopins (Ø 5 à 100 mm, longueur jusqu’à 200 mm), des arbres (Ø 5 à 60 mm), des pièces de forme (Ø 5 à 100 mm, longueur jusqu’à 200 mm), des barres rondes et profilées (5 à 80 mm de diamètre, longueur jusqu’à 1 600 mm). Le système permet la récupération, le stockage, le magasinage automatique des pièces usinées et la récupération contrôlée des chutes matières, telles que les fins de barres.
Les avances rapides des axes du portique et du ravitailleur de barres atteignent, respectivement, 45 m/mn et 60 m/mn et autorisent en conséquence un chargement/ déchargement rapide et performant. Tous les éléments constituant le système, portique, ravitailleur, bac à chute, déchargement, contrôle, magasin de barres et lopins… sont amovibles et peuvent être déplacés ou ajoutés en fonction des besoins. Tout est accessible et pensé pour faciliter la maintenance.
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, 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).
- 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://systeme.developpez.com
Vous cherchez
Architecture des ordinateurs
Systèmes d’exploitation
Systèmes temps réels
Systèmes embarqués
Systèmes répartis
Réseaux : Généralités
Réseaux : Bus
Parallélisme
Grilles de calcul
Sécurité
Compression audio et vidéo
| While there has long been a large audience interested in robotics, there have also been a number of barriers to entry, both real and perceived. Robots are not widely available in traditional retail stores. If one could find a programmable robot, the cost was often times non-trivial. In addition, the ‘robot’ that could be purchased was often in the form of a kit and required hardware knowledge and skills. And if one could both find and afford a robot, there was a perception that programming one must be difficult.
RoboChamps is a new robotics programming league that removes those barriers to entry and makes robotics available to a broad audience. RoboChamps is based in simulation, which removes the barriers to entry of availability, cost, and deep hardware knowledge. RoboChamps is more specifically built on top of the simulation functionality provided in Microsoft Robotics Developer Studio 2008, which means that participants can program their robots using the .NET languages they are already familiar with. In addition, a simulated robotics competition provides the opportunity for participants to engage in rich simulation environments and use robots that are unattainable via other means. For example, RoboChamps participants have the opportunity to navigate a rescue robot in a city struck by disaster, program a car to drive autonomously in a traffic filled city and drive a rover on the surface of Mars – all scenarios that would be financially prohibitive for most individuals. RoboChamps is a league, and like most leagues has a season that is comprised of a series of competitions. In this league, these competitions are referred to as Challenges. These provide participants with a rich 3d, physics-enabled environment and a robot, and challenge participants to solve tasks in an environment-specific scenario. The RoboChamps season culminates in an end of season tournament. The top four in the tournament will participate in a finals event where they will take their simulation code and apply it to real robots. |
||||
The Amazed Challenge is designed to measure your ability to program a simulated, autonomous robot that successfully navigates a 3-D virtual maze from beginning to end.
 |
The BristleBot is a simple and tiny robot with an agenda. The ingredients? One toothbrush, a battery, and a pager motor. The result? Serious fun.(YouTube video here.)The BristleBot is our take on the popular vibrobot, a simple category of robot that is controlled by a single vibrating (eccentric) motor. Some neat varieties include the mint-tin version as seen in Make Magazine (check the video), and the kid’s art bot: a vibrobot with pens for feet. |
|
|
|
The starting point is of course the toothbrush. We need one that has more-or-less uniformly angled bristles. (While it may be possible to take one with straight bristles and bend them to suit, I haven’t tried.) If the bristle length is nonuniform (as it is here), it may take scissors to make the bristles all the same. |
|
 |
 |
Cut off the handle of the toothbrush, leaving only a neat little robotics platform. |
|
 |
 |
Next, we need a vibrating pager motor or other tiny motor with an unbalanced output shaft. If you should happen to find a small enough motor you can always add the weight yourself, but usually motors this size are made for pagers anyway. I got mine on eBay for a few bucks; you can also get them here, for example.The kind that I got are happy to run on almost any common voltage– probably a range of 1-9 V. As a power source, you can use an alkaline or lithium coin cell or watch battery, either 1.5 V or 3 V. To hook the motor to the battery I soldered short copper wire leads to the motor terminals. |
|
|
|
|
The last substantial ingredient is some foam tape. Apply a small piece to the top of the toothbrush robotic platform, which will be used to hold the motor in place. |
|
 |
 |
Attach the motor to the foam tape. The tape provides a spacer so that the rotating weight does not hit the toothbrush head. It also provides a strong, flexible connection to the base that is able to handle the severe vibration that this robot experiences. A first approach to hooking up the battery might be to stand it on end. However, the battery itself is not held in place very well this way and will fall out shortly. |
|
|
|
|
A better method is to bend one of the leads down flush with the foam tape, so that you can *stick* the battery to the foam tape as well and still make an electrical connection. The other lead contacts the other side of the battery, and the motor can run.
The completed BristleBot, running and ready for action. When you set one down, you may notice that it tends to steer left or right. We have found that battery and motor placement, bristle shape (one stray long bristle can interfere with the motion, and motor rotation direction all influence the behavior- so be sure to try flipping the battery upside down if you have trouble getting yours to go straight.Now and for the record, this is one of many different kinds of vibrobots– there are a lot of other designs out there if you go and look. We have heard of and seen many other vibrating robots, and we know that even using a brush with angled bristles for propulsion has been done before. However, this particular miniature implementation may be unique, and is certainly fun. Very few robots that you can build so easily are so rewarding. With the right parts, you can make one in a few minutes. It might be great fun to make a bunch of them to race them competitively. |
|
Des robots autonomes, inspirés de certaines espèces de rongeurs dont le sens du toucher est très développé, pourraient être capables d’intervenir dans des conditions de visibilité restreintes.
Le règne animal inspire les chercheurs en matière d’innovation. Notamment lorsqu’il s’agit de développer des technologies se rapprochant de certains mécanismes biologiques et/ou des sensations propres aux êtres vivants, telles que le toucher. Le projet Biotact (Biomimetic technology for vibrissal active touch), financé par l’UE et lancé en début d’année 2008, est soutenu par le septième programme-cadre (7ème PC), qui lui alloue environ 5,4 millions d’euros (sur un coût total de 7,8 millions d’euros). Dix partenaires originaires d’Allemagne, de France, d’Italie, du Royaume-Uni, des États-Unis, d’Israël et de Suisse, étudient dès à présent les mécanismes sensoriels permettant à ces rongeurs de percevoir les formes et les surfaces, et ce, grâce à leurs moustaches !
Les moustaches « capteur-détecteur » du rat
« L’utilisation du toucher dans la conception des systèmes d’intelligence artificielle a été très négligée jusqu’à présent », explique Ehud Ahissar professeur à l’institut Weizmann en Israël. Le rat commun (Rattus norvegicus) et la musaraigne (Suncus etruscus) figurent parmi les meilleurs exemples d’animaux dont le sens du contact est particulièrement développé, le rendant beaucoup plus efficace que le sens tactile par le bout des doigts des humains. « Chez les créatures nocturnes, ou celles peuplant des sites peu éclairés, l’usage du toucher est largement préféré à la vision en tant que premier moyen d’obtenir ou de recevoir des informations physiques sur l’environnement ambiant ».
Le rat de laboratoire, spécialiste du toucher
©Biotact
Comment le rat utilise-t-il sa « moustache » pour explorer son environnement et comment le cerveau traite-t-il cette information ? Et qu’est-ce qui rend la « moustache » du rat beaucoup plus efficace que le bout des doigts d’une personne normale ? Il semblerait que ces animaux effectuent un mouvement de va et vient très rapide avec leurs appendices qui assurent par là même, la fonction de détecteurs. C’est ce « balayage » actif et répétitif qui ferait la différence et leur permettrait de déterminer la forme et la surface des objets et de capturer leur proie. D’après les recherches effectuées par le consortium, les signaux partent des moustaches et parcourent des voies parallèles qui fonctionnent en boucles d’informations fermées, en surveillant en permanence les signaux qu’elles reçoivent et en adaptant leurs réactions en conséquence. Les chercheurs pensent que les interactions complexes entre ces boucles sont responsables du contrôle riche et précis du mouvement.
De nombreuses applications à portée de moustache
« L’objectif de cette recherche est d’aider à obtenir une meilleure compréhension du cerveau d’une part et de faire progresser la technologie de l’autre ». Elle devrait permettre d’aboutir à un traitement de l’information plus efficace et à des avancées technologiques importantes dans le domaine de la robotique. Les robots conçus selon ce principe pourront être utilisés pour les travaux sur l’intelligence artificielle, en incorporant certaines des caractéristiques d’un vrai cerveau.
Un robot tactile dans le concept ScratchBot
©Biotact
Les applications technologiques montreront probablement de nombreux avantages par rapport aux systèmes robotiques conventionnels. Les chercheurs pensent à la réalisation de machines pouvant être utilisées, par exemple dans des missions de sauvetage, dans des interventions en milieu inhospitalier ou en visibilité réduite, voire même dans l’exploration spatiale. En tout cas, une nouvelle génération de capteurs et de robots est en vue avec des machines dotées d’une sensibilité au toucher.
Source: cliquez ici.
The Embedded Systems Conference Silicon Valley is a great opportunity to learn about new technologies and hone your skills, all while having fun.
(03/30/08, 07:00:00 PM EDT)
When the Embedded Systems Conference was first proposed about 20 years ago, someone quipped that a more apt name would be the “Everything you ever wanted to know about embedded systems but were afraid to ask” Conference. While the story may be apocryphal, the overwhelming bounty of information and resources the name implies captures the essence of the upcoming Embedded Systems Conference at the McEnery Convention Center in San Jose, Calif., April 14 through 18.
And you need not be afraid to ask. Indeed, there are likely to be events, classes, and demos that you haven’t even thought to ask about. The show will be bursting at the seams with exhibits, demonstrations, classes, and tutorials on every aspect of embedded systems design.
At the core of the show, spread over five days, are 180 or so papers and classes and 12 two-day tutorials on all of the key areas of interest to embedded systems developers:
• Architectures and low power.
• Analog design and data conversion.
• Digital signal processing and multimedia.
• Hardware design, including programmable logic.
• Linux and open-source software.
• Multicore.
• Operating systems.
• Project management.
• Real-time design.
• Security.
• Software design.
• Tools.
• Verification and debugging.
• Wired and wireless networking.
A wealth of other events will make the conference even more apt to satisfy your need-to-know appetite, including:
• Embedded Teardowns.
• Build Your Own Embedded System.
• Career Fair, Disruption Zone.
• MSP430 Day.
Wired and wireless sensor networks
One constellation of classes sure to spark interest is the topic of wired and wireless control-network design.
In “Working with USB/Ethernet Software for Distributed Sensor Networks (ESC-223),” Eric Gregori will go into detail in how to combine USB and Ethernet into an effective home networking scheme. Matt Maupin will provide an overview of Zigbee, WirelessHART, the SP100 network stack, and Freescale’s Synkro Networking Protocol in “IEEE 802.15.4: Providing the Foundation for Wireless Sensing and Control (ESC-343).” In “Intelligent Sensor Signal Processing (ESC-523),” Priyabrata Sinha suggests that the move toward ubiquitously wired and wirelessly connected sensors will force embedded systems designers to put even more intelligence into the sensor nodes for evaluation and decision making rather than rely on a centralized approach.
Because sensor nodes are minimalist by nature, many of the resources available for such operations as debugging and updating become problematic due to the lack of MCU pins to do such tasks in the background. To overcome such problems, David Johnson, in “Zero Wire Debugging Using Inductive Technology (ESC-320),” describes how to use inductive coupling to create a debug interface that requires no extra debug pins and no extra circuitry on the application hardware side. See Figure 1.
Multicore hardware and software development
Among the several classes and tutorials on multicore hardware and software development, several presentations stand out. In “Architectural Design of Software for Multicore Systems (ESC-351),” David Kalinsky suggests that many of the design assumptions serving as the underpinning of multitasking software design for the past 20 to 30 years are no longer valid when designing software for multicore SOCs. He will explain which of the old assumptions are still valid, which have to be modified, and which need to be replaced.
The interconnect scheme the developer chooses is important in a multicore design. In “Interconnections for Multicore Systems (ESC-531),” Sanjay R. Deshpande will provide a detailed analysis of the various approaches, how to choose the right one for your design, and the tools and building blocks you will need to achieve your goals.
A crucial aspect of designing with multicores is the operating system. In his class on “Understanding Multicore Embedded Operating System Issues (ESC-432),” Michael Anderson will discuss what operating systems need to support multiple CPU cores, in terms of performance, power, interrupts, caching, and cache coherency.
More under the Linux sun
Three classes stand out in the selection on Linux development:
Three classes stand out in the selection on Linux development:
• Pthreads. In “Introduction to Posix Threads (ESC-308),” Doug Abbott will provide an intensive course in asynchronous programming in the Unix/Linux Environment. He will discuss using Pthreads as an alternative to the heavyweight “process model”, historically used by Unix systems, including Linux, to split a large system into smaller, more tractable pieces.
• Mobile Linux. If you want a better idea of what is needed to implement a Linux application on a mobile device, try Robert Mueller-Albrecht’s class on “Linux Kernel Debugging on Embedded Low Power IA Systems (ESC-440).” In it he will go into the methodologies needed to isolate problems on an embedded system using the example of Mobile Internet Devices, and how to build, deploy and debug on these types of platforms.
• Asynchronous DMA. Given the advent of storage technologies in embedded and mobile systems, “Asynchronous DMA (ADMA): Taking Linux out of the Data Path (ESC-451),” presented by Haluk Aytac, will be of major interest to Linux developers. He will describe a Linux Asynchronous DMA interface recently created for an SoC to make use of its DMA engines, which boost performance of a RAID system by off-loading data path tasks to DMA engines.
Must-see classes and sessions
Other presentations notable for their timeliness and technical insight include:
• Operating-system independence. In “Operating System Independence (ESC-452),” James W. Grenning will present a class on how to use some of the existing portability standards, as well as packages like POSIX and ACE, to help preserve your software investment and allow it to migrate to new platforms.
• High availability. To help developers in building high-availability systems able to tolerate both expected and unexpected faults, David Kalinsky is presenting “Principles of High Availability Embedded Systems Design (ESC-306).” He will discuss the basics of high availability and fault management, basic hardware N-plexing, and voting issues as well as software fault tolerance techniques such as the static method of Nversion programming.
• High performance FPGA design. Caltech’s D.W. Hawkins, a regular presenter at ESC, will teach a session on “High-Speed Signal Processing with FPGAs and CPUs (ESC-446).” He will detail the design of a high-performance data processing system containing multiple FPGAs, embedded CPUs, and general-purpose CPUs for use at the Owens Valley Radio Observatory.
• Fault management. In “Fault Detection in Embedded Systems (ESC-360),” Lorenzo Fasanelli, Lorenzo Lupini, and Massimo Quagliani describe a practical approach to the issue of fault detection and an overview of the techniques to enhance embedded systems debug capabilities.
• MEMS versus Quartz. Wan-Thai Hsu will take a comprehensive look at the use of MEMS resonator oscillators versus quartz crystal oscillators for timing and clock applications in “The Future of Timing–MEMS vs. Quartz (ESC-181).”
• Peer code review. In “Best Practices for Peer Code Review (ESC-300),” Jason Cohen will conduct a class on the best ways to do efficient, lightweight peer code review. His emphasis will be on methods that have been proven to be effective by scientific study and extensive field experience.
• Real-time friendly C++. Finally, Scot Salmon does his best at “Making C++ Real-Time Friendly (ESC-527).” In addition to taking attendees through many of the gotchas in the language that make life difficult for developers in real-time designs, he will go into detail about the improvements to the language that remove such tricks and traps such as “memory allocations behind your back.”
Other things you don’t need to ask about
In addition to everything you’ve come to expect, this month’s conference offers a number of other services and venues to both entertain and educate:
• Embedded Teardowns. Don’t forget to check out the Live Teardowns on successive days: the Sony 11′ OLED TV on Tuesday, April 15; and the Orlon Space Suit, the Gibson Robot Guitar, and the Sony Rolly on Wednesday, April 16.
• Build Your Own Embedded System. Each fully paid conference attendee will be given a Windows CE 6.0 R2-based Via Artigo Box embedded development kit. You’ll be able to take the kit from class to class and use it to try out concepts and build an embedded design.
• ESC Career Fair. We have all used the ESC as a venue for finding jobs and making professional contacts that might lead to further opportunities. Formalizing this practice, the Career Fair is a service for registered attendees, provided by TechCareers, so job seekers can meet potential employers and conduct on-site interviews.
• The Disruption Zone. In this venue, software and hardware companies will demonstrate what they think are revolutionary technologies that will change the embedded systems industry.
• MSP430 Day. On Tuesday, April 15, and Wednesday, April 16, you can meet the experts from Texas Instruments and learn how to use the MSP430 MCU, get the latest product updates, participate in live technical demonstrations, and receive a FREE eZ430-RF-2500, the latest low-power wireless development tool (a $49 value).
For more information about the conference, go to www.cmpegevents.com/web/esv. I’ll post more detail on Embedded.com about other interesting papers from the conference.
Bernard Cole is the web editor for Embedded.com and the Embedded.com newsletter. He has written for EETimes and IApplianceweb.com. You may reach him at bccole@acm.org.
Toaster Device Sample
This sample provides a step by step guidance on how to integrate code between the Microsoft Windows Vista DDK and Microsoft Robotics Studio using C++/CLI programming language.
This tutorial is provided in the language. You can find the project files for this tutorial at the following location under the Microsoft Robotics Studio installation folder:
Sample location
Copy Code
Samples\Technologies\Interop\ToasterList
Here are the steps we have to do:
Prerequisites
Software
This tutorial requires the Windows Vista DDK also called WDK, which is available online
The actual work with the WDK is outside the scope of this tutorial, instead we are going to take an existing part of the Toaster sample from WDK and turn it into a Microsoft Robotics Studio DSS service.
The Toaster sample that we are going to use is the “toaster” application, which lists the available toaster devices and their information, which is located in the “WinDDK\6000\src\general\toaster\exe\toast” directory of your Vista WDK installation. Refer to that location on documentation about the toaster application itself.
This sample is designed for use with Microsoft Visual C++/CLI 2005. (Note that this is incompatible with earlier, 2003 or before, edition of C++ with managed extensions) You can use:
- Microsoft Visual C++ 2005 Express Edition.
- Microsoft Visual Studio 2005 Standard Edition.
- Microsoft Visual Studio 2005 Professional Edition.
- or Microsoft Visual Studio 2005 Team System.
You will also need Microsoft Internet Explorer or another conventional web browser.
Getting Started
To create the service you have to use Visual Studio 2005, and the Microsoft Robotics Studio Command Prompt. Due to this we will have to do some changes to reuse the source out of the WDK. Let’s take it step by step:
Step 1: Create a new DSS C++ service
Open a Microsoft Robotics Studio Command Prompt. Create a new C++ DSS service with the following command:
Console
>bin\dssnewservice.exe /service:myToasterSvc /language:cpp
This will create a folder with the service code in it. Open the solution from there with you Visual Studio 2005 C++ editor.
Step 2: Add toaster application code
From WinDDK\6000\src\general\toaster\exe\toast location in your WDK installation copy the toast.c file to your myToasterSvc service directory, and rename it to have a cpp extension. In Visual Studio right click on Source Files and select Add->Existing Item.. and point to the toast.cpp file that you just created. Since the whole project is managed, we need to explicitly say that this file will contain unmanaged code, by putting #pragma unmanaged in the beginning of toast.cpp.
Step 3: Configuring build
To build the project we need to add the build settings from the DDK sample in our project. They are configured in the sources file in WinDDK\6000\src\general\toaster\exe\toast directory and in the build environment command shell settings. Right click on you project in Visual Studio and select Properties. Here is the list of items you need to change:
- Under C\C++ -> General add to Additional Include Directories the following folders: WinDDK\6000\src\general\toaster\inc and WinDDK\6000\inc\api from your WDK installation.
- Under Linker -> General add to Additional Library Directories the following folder from WDK: WinDDK\6000\lib\wnet\i386
- Under Linker -> Input add setupapi.lib to Additional Dependencies
- Under Configuration Properties -> General change Character Set property from Use Unicode Character Set to Use Multi-Byte Character Set.
After you add these setting you should be able to compile your project, and get a couple of code errors due to syntax change from c to c++ for the toast.cpp file.
Step 4: Fixing toast.cpp
From the previous step after compilation you should see the following 2 errors:
- error C2440: ‘=’ : cannot convert from ‘void *’ to ‘PSP_DEVICE_INTERFACE_DETAIL_DATA’
c:\Microsoft Robotics Studio (1.5)\myToasterSvc\toast.cpp 155 - error C2664: ‘SetupDiGetDeviceInstanceIdW’ : cannot convert parameter 3 from ‘BYTE *’ to ‘PSTR’
c:\Microsoft Robotics Studio (1.5)\myToasterSvc\toast.cpp 306
The first problem can be fixed by just adding a cast:
C++
deviceInterfaceDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA) malloc (predictedLength);
The second problem just needs the right cast:
C++
fSuccess = SetupDiGetDeviceInstanceId(hdi, &deid,
(PSTR)currentToaster->szCompInstanceId,
MAX_PATH, NULL);
After these errors are fixed you should be able to compile your service without errors. The toaster code that we added does not do anything useful, because we need to add the integration between it and the service code.
Step 5: Integrating code
The service that we are going to create will have as it’s state a list of toaster devices that are present in the system. To get the toaster device we will reuse the PrintToasterDeviceInfo() function, but change slightly how it works. We will want to gather the toaster device information, but instead of printing it to the console we will populate our service state with it. Here are the steps needed to make that integration happen:
Drop main method
Since we are going to reuse only the PrintToasterDeviceInfo() function we will not need the main function in the toast.cpp file. Our service will be started by the DSS runtime, so we don’t need this entry point.
Define new header file
Let’s create a header file for the toast.cpp file, by right clicking on your project and selecting Add -> New Item… -> Header File (.h) and call it toast.h.
Specify header files in source files
The header file that we created will be used in toast.cpp file and in myToasterSvc.cpp.
Define new data structure
In toast.h file, move the #include <wtypes.h> from the toast.cpp file to it and let’s define a structure that we will use to share the data between our managed and native functions. We will want to get the data between managed and native functions in as few calls as possible due to the performance hit of switching between managed and native code. Since we don’t know the length of the data that we want to get from the PrintToasterDeviceInfo() function, we will use a linked list so that it’s easy to expand. Here is what the structure should look like:
C++
typedef struct TOASTER_INFO {
TOASTER_INFO(){nextToasterInfo= NULL;}
TOASTER_INFO* nextToasterInfo;
CHAR szCompInstanceId[MAX_PATH];
CHAR szCompDescription[MAX_PATH];
CHAR szFriendlyName[MAX_PATH];
} *P_TOASTER_INFO ;
Change function signature
PrintToasterDeviceInfo() function with its current signature does not provide any information to the callers other than if it has found anything or not. Let’s change it so that it will also provide the new structure that we created. Make sure it’s declaration is in the toast.h file, here is what it’s new signature should look like:
C++
BOOL PrintToasterDeviceInfo(P_TOASTER_INFO* pFirstToaster);
Add allocation logic
Now let’s change how this function works in the toast.cpp so that it allocates and populates the TOASTER_INFO structure correctly. Since we don’t know up front how many devices we will find, we will allocate memory inside the loop where we enumerate over each toaster device. Since we don’t know if we will find even one, but our function will return the pointer to the first item in the linked list, we will need a custom logic to create the first element, and then any next element. Here is what that code should look like:
C++
if(*ppFirstToaster == NULL) { *ppFirstToaster = new TOASTER_INFO; currentToaster = *ppFirstToaster; } else { currentToaster->nextToasterInfo = new TOASTER_INFO; currentToaster = currentToaster->nextToasterInfo; }
Populate the structure
Add the local variable that we will point to the current Toaster that we are working with: P_TOASTER_INFO currentToaster;. Next remove the szCompInstanceId, szCompDescription and szFriendlyName local variables and change the code that used them to point to their versions in the currentToaster local variable. Finally remove the calls to the printf function we will no longer need them.
Create new state
Now let’s change the service part of our code. Since we want the toaster information represented in the state of our service we need to