An attractive, speedy route to developing complex, initially loosely specified applications that have a mix of real-time and non-real-time components is to take a fairly powerful x86-based PC-compatible single-board computer running Linux™, and use a slenderized custom software bundle on that machine to control a bevy of assorted small microcontrollers configured to handle the hard real-time tasks in the system.
You save development time principally from the fact that you can buy off-the-shelf hardware for most of the functions to be carried out on the PC; you can use an off-the-shelf operating system, and you can use ready-rolled device drivers that have already been debugged for you, for the most part.
You can also carry out your control software development using the actual target PC platform (possibly with minor extensions: more RAM, a hard disk, and so on) as the compiler host. Running the application, build environment, and native debugger directly on the target system can significantly shorten your development cycle. Furthermore, modularizing the real-time components of your application (stepper motor control, analog data acquisition, and the like) into separate microcontrollers helps you to develop those modules without having to worry about real-time interaction issues between multiple tasks running on a single processor.
Then, once your embedded application is tested and debugged -- and, more importantly, once the entire device's capabilities and system requirements are better defined through experiment and field-testing -- it is possible to take your well written Linux application and port it into a more deeply embedded environment.
The easiest path here is to use a platform running a Linux variant on some RISC microprocessor or SoC. If desirable, some functionality can simultaneously be shifted out of those external satellite microcontrollers into SoC hardware or firmware running in that 32-bit micro.
I recently demonstrated several practical examples of the above techniques in my second book, A Cookbook for Open-Source Robotics and Process Control (see Resources). That work focused on the electronics and firmware design of an autonomous underwater vehicle (a robot submarine). This series of articles essentially carries on from that work to demonstrate the second stage of refinement: porting the x86-based application to a PowerPC® environment, and redeveloping the hardware interfaces to fit the PowerPC (PPC) system.
This series of articles demonstrates what is involved in moving a semi-turnkey x86 Linux control application over to a more deeply embedded PPC platform. In the process, I'll also provide sample implementations showing some general techniques of interest in networked embedded appliances. The end result will be that you'll turn a bare-bones networked storage appliance into something that could be the core of a simple autonomous vehicle controller, with basic actuator controls, sensors, and rudimentary machine vision capabilities. Because most people probably don't need to build robot submarines (as much as most of us would like to), this article also explains how to design and implement web-based administration interfaces and other topics of wider applicability.
These articles adhere quite closely to the overall system hardware architecture I used in my earlier project. There are two reasons for this. First, one of the main goals of this text is to demonstrate the effort required to migrate from x86 to PPC, and the benefits you can expect to realize from this migration. Retaining as many system design similarities as possible helps you to make an apples-to-apples comparison.
The second reason for this decision is to demonstrate the original assertion, that it is extremely cost-effective, in terms of development time, to use a high-end platform like PPC to run the complex but non-hard-real-time tasks (networking, interfacing to peripherals like cameras, and so forth), and offload the hard-real-time tasks onto an external 8-bit microcontroller.
To put it plainly, if you follow the techniques used in this article, you can employ application-level programmers (who are plentiful and relatively inexpensive) to write the 32-bit side of the equation, and use a relatively small number of person-hours from experienced real-time programmers to write the 8-bit side. You simultaneously avoid the need to invest in complex RTOS implementation on the 32-bit side, and the need to develop complex device interface code on the 8-bit side.
Before getting into application specifics, it is useful to spend a few introductory words talking about the PPC family, to put it in context in the marketplace. Embedded PPC variants vie in a sector contested by other major competing cores: ARM, MIPS, and Intel® IA32- and IA64-compatible devices such as Transmeta's Crusoe, VIA's Eden and siblings, AMD's Geode (formerly from National Semiconductor), plus of course also mainstream desktop processors from AMD's and Intel's diverse CISC product lines. All of these devices are, by embedded systems standards, exceedingly powerful 32-bit microprocessors. They do not, however, cover exactly the same application spaces with equal effectiveness, and it is therefore instructive to describe some of the contrasts.
The x86-compatible family is (with a few exceptions that you can safely ignore) only employed as part of a more or less wholly PC-compatible hardware architecture. These processors are large and extremely energy-hungry; active cooling is almost universally required in x86 designs, and mains power is preferable. The dominant design factor steering x86-based designs is the baggage required by backwards compatibility (both in the CPU core and other support circuitry on the motherboard), and many people are doubtless aware of the history behind this. Vast effort has been invested to modernize the CPU and overall system architecture, but even the current 64-bit architectures are constrained to some degree by legacy considerations. There are relatively few true SoC offerings based around an x86-compatible core, and thus significant external circuitry is always required in x86 systems. It should also be noted that, unlike the vast majority of embedded devices, x86 chips lack on-chip JTAG or other hardware debugging interface support.
As a side note, the processor I used in my earlier prototype of the system under discussion in these articles was a 233MHz AMD Geode. This device is one of the most integrated, embedded-friendly x86 variants on the market at the moment. It turns out that this chip is an excellent comparison point with the specific PPC device used in this series of articles. The core speed is in the same ballpark; the peripherals are similar (although the single-chip integration level is comparatively low in Geode), and the target markets overlap.
With that thumbnail of the x86 out of the way, you now meet ARM, probably PPC's major competitor in consumer applications. ARM was originally designed by a group of mathematicians for use in a relatively obscure proprietary personal computer system. This core presently dominates the low end of the 32-bit market (in terms of shipment volumes) due in part to low power requirements, wide availability in many forms, and a clever instruction set architecture. For example, the so-called "Thumb" instruction set extension allows the microcontroller, though 32-bit in nature, to run quite efficiently out of 16-bit memories with about a 25% improvement in code density. (Narrower data buses generally imply a lower pin count on the microcontroller, and hence a lower cost). Thumb code can also be used in pure 32-bit hardware designs to reduce code volume significantly without unacceptably influencing execution speed. In the last two years or thereabouts, we have begun to see very cut-down ARM-based parts with a small amount of on-chip flash and RAM making their way into control applications formerly occupied by 8-bit devices. ARM is also the most common core used in PDA and smartphone applications.
PPC devices are aimed more directly at high-MIPS applications, frequently involving software DSP functionality; typical examples are cryptographic devices, high-throughput network appliances, and multimedia codecs. PPC scales up to very high performance levels. Although PPC-cored microcontrollers are considerably less power-hungry than CISC architectures, they don't offer quite the same MIPS/mW levels that ARM provides. However, this gap is narrowed somewhat (and direct comparisons are made very difficult) by other system design considerations. For example, deeply power-optimized ARM variants generally do not have complex general-purpose bus interfaces like PCI. Designs employing such parts are therefore severely constrained in terms of the peripherals they can use.
The above discussion is, of course, a generalization. All of these microcontrollers lie in different corners of a multidimensional spectrum, and there is considerable overlap; it doesn't make much sense to put them all on a one-dimensional, linear scale. Perhaps it would be fairest (though still dogmatic) to say that one tends to find ARM in low-system-cost, high-volume applications, particularly where power consumption is the prime criterion; x86 is typically found in applications where PC-compatibility is the prime selection criterion, and PPC is often found in applications where performance is the prime criterion. The specific advantages I was hoping to realize in moving to PPC were reduced power consumption, elimination of active cooling (required in my Geode design because of the combined power dissipation of the CPU and its mandatory companion IC), and enhanced performance in some digital image processing (machine vision) code.
At the start of this project, I set a budget limit of US$250 for acquiring all development tools, including a PPC-based evaluation board. I picked this number, not quite at random, but because it is in the expense ballpark where junior management is usually able to sign without requiring higher authority. This means that if you want to experiment with a forward-looking PPC design at work using the suggestions described in these articles, you only have to convince your immediate supervisor.
Note that PPC evaluation hardware is quite expensive compared to ARM hardware, and very expensive compared to x86 single-board computers. One of the reasons for this is that x86 boards are generally sold as black boxes with the intention that you design them into your system as ready-made modules. As such, they are relatively high-volume products.
In terms of what you would be paying to integrate these chips into your own custom design, x86 and PPC are similar in price, and ARM is cheaper than both. That statement has to be taken with a large grain of salt, however; it's not true for all performance comparison levels, and it is obviously heavily application-dependent.
After casting about the marketplace for a suitably low-cost PPC development system to demonstrate all this talk, I selected the Buffalo Technology Kuro Box. This is an off-the-shelf "hackerized" NAS appliance that happens to be based around a 200MHz MPC8241 (PPC603e core). It has 4MB of linear boot flash, 64MB SDRAM, 10/100 wired Ethernet, a USB 2.0 port (host-side), and an IDE interface. The Kuro Box is available locally in the USA from Revolution for US$160 (see Resources for a link). This price buys you something that approximates a turnkey system. You merely have to install a standard 3.5 inch IDE hard disk and run the vendor-supplied Windows® setup utility, which partitions, formats and loads the drive contents over a telnet connection.
As far as software tools go, you will use GNU/Linux as the operating system, and the native PPC variant of GCC (and its companion build environment; make, gas, and so on) for development on the 32-bit side. Later articles will discuss how to build the initial kernel image using a cross-compiler hosted on Linux or Win32.
You will also be building a multi-function interface peripheral that
provides your real-world interfaces; this peripheral will be based around
an Atmel AVR microcontroller. The development environment for the AVR is
either the Windows-based AVR Studio (from Atmel) or the open-source
tavrasm assembler (Toms Linux AVR
Assembler -- see Resources for a link). This latter
product is the preferred way of developing AVR code on a Linux host. All
of these software tools are free.
Note that there are slightly cheaper routes to PPC development -- for instance, cannibalizing a Nintendo GameCube console -- but these are not well-supported, to say the least. The Kuro Box is intended to be modified and customized by the end user, and it has official technical support forums to assist with this. The English-language forums aren't very well staffed -- but even so, using a Kuro Box is a significantly better-supported path than trying to hack a deeply protected appliance like a game console or Digital Video Broadcast (DVB) set-top box.
Figure 1 is a block diagram of the principal features of the Kuro Box. Note that it does not show all the MPC8241's peripherals; it only shows those parts of the chip that are involved in using the interfaces you'll use in these articles.
Figure 1. Kuro Box block diagram
The MPC8241 microcontroller provides (among other features) an on-chip PCI bridge, SDRAM and flash controllers, and two serial ports. The first serial port is connected to J1, the debug console port. The signal swing here is from 0V to +3.3V, and it is inverted for compatibility with RS232 level shifters. The second serial port is connected to the slave microcontroller (an AT90S2313). This micro handles power sequencing and fan tachometer feedback, and also provides a master watchdog for the MPC8241. The software bundle preloaded on the Kuro Box includes a daemon that kicks this watchdog periodically. CN1 on the motherboard is a standard 6-pin Atmel AVR ISP port connected to the slave microcontroller.
The board also offers a normal COP/JTAG debug port at CN5, although the connector is not stuffed. In order to use this port, you should add the 10K series VIO resistor R67 and a 4-way 1K resistor pack at RA11. The least expensive route to using the COP port is through a "wiggler" connected to your PC's parallel port; the cheapest commercially-available product for accessing the MPC8241's on-chip debugging facilities is the Macraigor Wiggler. This device lies outside the budget limit mentioned earlier, so its use won't be discussed in detail, though it will be mentioned in a later article dealing with kernel debugging.
To give you an idea of how compact a system of this kind can be, Figure 2 is a picture of the component side of the Kuro Box mainboard. This single board contains all the device's circuitry except the switch-mode power supply. Note the absence of a heatsink on the CPU.
Figure 2. Component side of Kuro Box mainboard
By now you should have a basic understanding of the overall system goals in this project, and the tools and components you'll use. The next article focuses on the structure of the kernel and file system in the device, with particular attention to the differences between x86-targeted and PPC-targeted software distributions. With all that infrastructure out of the way, you can start actually writing some application code.
-
Migrating from x86 to PowerPC is the only
developerWorks Power Architecture technology series on the entire Internet
that will help you build your own remote-controlled robot submarine army.
Missed a previous installment? Don't dismay: it's astonishingly easy to
read them all now.
- Need to
hack a serial
port onto your Kuro box? Lewin has posted all of the details to
his site.
- You can find ordering information and downloadable software for the
Kuro Box at Revolution's Web site.
- Note that there are slightly cheaper routes to PPC development -- for
instance, cannibalizing a Nintendo
GameCube console. But hacking the Kuro, unlike other budget-conscious
solutions, is officially
supported, making it a better choice.
- The Freescale MPC8241
product page includes a general feature list and a full datasheet for
the part.
- My second book, Open-Source
Robotics and Process Control Cookbook: Designing and Building Robust,
Dependable Real-time Systems (Newnes, 2004), describes in
detail the original x86 project architecture and reasons why I built the
device this way. (My first book, Embedded
System Design on a Shoestring (Newnes, 2003), is a useful primer
on low-cost prototyping techniques for 32-bit systems. If you're not
familiar with using the GNU toolchain in an embedded environment, this
book can be a helpful resource.)
- MontaVista Software's Hard Hat
Linux is the software platform shipped with the Kuro Box.
- Going forward, you will be using GNU/Linux as the operating
system, and the native PowerPC variant of GCC (and its toolchain and build
environment).
- If you are new to Linux, you will find the Linux Online site useful.
- The interface peripheral will be based around an Atmel AVR microcontroller
The development environment for the AVR is either AVR
Studio (for Windows) or the open-source Toms Linux AVR Assembler (or tavrasm
assembler) for Dos, Linux, FreeBSD, OS/2, Solaris...
- A Macraigor
Wiggler will come in handy in future installments of this series, when
we get to debugging.
- Learn more about PowerPC Linux ports and Free Software development
tools for PowerPC at PenguinPPC.
- Learn more about the history of Acorn Computers and ARM processors at
A technical
history of Acorn Computers (Version 0.6 Beta) or from the Wikipedia
article Acorn
Computers Ltd.
- An earlier developerWorks article discussed Linux
system development on an embedded device (March 2002).
- Linux on PowerPC isn't restricted to embedded systems; you can
also run Linux
on Mac (developerWorks, January 2004).
- For an overview of the Kuro box, and how it fares as an embedded system,
read how it did on the Zork Test (developerWorks, December 2004).
- Have experience you'd be willing to share with Power Architecture zone
readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside
IBM are welcomed. Check out the Power Architecture author
FAQ to learn more.
- Have a question or comment on this story, or
on Power Architecture technology in general?
Post it in the Power Architecture technical forum
or send in a letter to the editors.
-
Get a subscription to the Power Architecture Community Newsletter when
you Join the Power Architecture community.
- All things Power are chronicled in the developerWorks Power
Architecture editors' blog, which is just one of many developerWorks
blogs.
- Find more articles and resources on Power Architecture
technology and all things
related in the developerWorks Power
Architecture technology content area.
- Download a IBM PowerPC 405 Evaluation Kit to demo a SoC in a simulated
environment, or just to explore the fully licensed version of
Power Architecture technology.
Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years developing x86, ARM and PA-RISC-based networked multimedia appliances at Digi-Frame Inc. He has extensive experience in encryption and security software and is the author of two books on embedded systems development. He can be reached at sysadm@zws.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
