Low-cost real-time development with Linux on PowerPC
|2005-01-06 17:39:51 来自：IBM开发者社区|
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.
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.
PowerPC versus x86
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.
PowerPC versus ARM
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.
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
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.
The Kuro Box
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.
In the next installment