Skip to main content

skip to main content

developerWorks  >  Power Architecture technology | Linux  >

Migrating from x86 to PowerPC, Part 1: Robots and networked appliances on a shoestring

Low-cost real-time development with Linux on PowerPC

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Lewin Edwards (sysadm@zws.com), Author, Freelance

04 Jan 2005

This series on embedded development shows you how to migrate a project prototype from x86 to PowerPC. This initial installment explains the realities and rationale of the project: it introduces the robotic submarines that were the start of the project (and where they came from), and describes the Linux/GCC development environment and the bare-bones Kuro Box PowerPC development board.

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.

The project

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.

Learning the lingo

This project description is primarily aimed at experienced embedded developers. But what about the people who just want a robot submarine? Here's some jargon defined, for those who aren't sure what all the acronyms and terms mean.

ISP In-System Programming. An ISP port allows you to program a microcontroller in-circuit, without needing to socket or desolder it.

JTAG A standardized boundary-scan interface connector, originally designed for manufacturing testing, but frequently used to access on-chip debugging capabilities.

NAS Network Attached Storage. A NAS device, at its simplest, is simply a box that contains a hard disk and appears on your network as a shared drive. It is an embedded file server application.

OCD On-Chip Debug. A kind of port (such as JTAG, or DebugWire) used to connect a debugger to a chip. Generally accessed by a wiggler.

stuffed A synonym for "populated", used of connectors.

wiggler A dumb interface module which connects a parallel port to the OCD port on a microcontroller.

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.



Back to top


PowerPC versus x86

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.



Back to top


PowerPC versus ARM

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.



Back to top


The setup

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.



Back to top


The Kuro 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
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
Component side of Kuro Box mainboard


Back to top


In the next installment

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.



Resources



About the author

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.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful		Extremely
useful
 


Back to top