In the article "Linking User Interface and Database Objects" (DDJ, December 1991), we described the software architecture of the Infolio, a portable data-collection tablet that uses a pen as the input device. Here, we examine the Infolio's hardware architecture--and the trials and tribulations we encountered during the design and development stages--from an embedded system perspective. Why this perspective? Because one of the unique aspects of the Infolio is that it's built around microcontrollers typically used with embedded systems, not the microprocessors commonly used in portable computers. Our focus in this article is on hardware design constraints and the decisions we made concerning them. We hope this information will be useful to others designing and developing embedded systems.
Because we designed Infolio to be a lightweight, low-power consumption, low cost, portable pen-based database computer, and because we had an aggressive product development schedule, we were faced with a number of hardware constraints:
Given the high-level design constraints, we developed a hardware architecture that makes extensive use of processor and memory card technology. Figure 1 shows a block-level representation of the Infolio hardware.
The Infolio makes use of multiple processors: the Motorola MC68331 as the core processor, the Motorola MC68HC05C4 as the power management processor, the Hitachi 63484 to handle graphics, and the Intel 80C51 to control the digitizer.
The most interesting processor in the system is the MC68331. Initially positioned by Motorola as an embedded controller, the 331 is basically a 68020 with a 16-bit external bus and a lot of what would traditionally be system "glue," or peripheral logic, integrated onto the die.
One reason we were drawn to the 331 was its 68020-like core, the CPU32. The CPU32 core is a silicon subcomponent that Motorola incorporates into a range of microprocessors. The 68020 architecture, of course, is well-known among engineers with UNIX workstation experience. Our own background is primarily UNIX and Macintosh, so we expected to experience little or no learning curve.
Another reason we chose the 331 is because it is a fully static part. The clock speed can be dynamically adjusted from 0 Hz (low-power stop mode) to 16 MHz, depending on the system activity.
A third reason is that the 331 is based on the IMB (Inter-Module Bus) concept. Peripherals are integrated onto the die with the CPU32, interfacing via an internal memory-mapped bus. The 68331 includes a SIM (System Integration Module) with ten chip selects, a periodic interrupt timer, a software watchdog timer, and system clock controls. Additionally, a Queued Serial Module is included which provides both a 2-wire asynchronous Serial Communications Interface and a 16-word-deep Serial Peripheral Interface. A General Purpose Timer module is available which provides input capture/output compare and pulse-width modulation functionality.
Yet another reason for selecting the 331 was that the controller has a background mode which allows, through serial communication over multiplexed device pins, an integrated development system and/or a debugger to be developed. Finally, the 331 is relatively inexpensive--under $25 in volume quantities--and provides up to five times the processing power of an Intel 80286.
The 8-bit MC68HC05 microcontroller controls the hardware side of system boot, manages most of the system interrupts, and processes pen information before passing it on to the main processor. This device is responsible for controlling the power to the various modules of the hardware, thus controlling the five different power states of the system: awake, relaxed, napping, sleeping, and off.
Both the Hitachi 63484 and the Intel 80C51 have very specific tasks. The 63484 was chosen because it provides reasonably high-level graphics commands (lines, polylines, circles, fills, bit-blts, and so on) at a relatively low cost. We also chose this processor because of our schedule pressures -- it eliminated the need to write low-level graphics routines; it also helped reduce our system code size (which we limit to 1 Mbyte). As Figure 1 shows, graphics memory is completely controlled by the 63484 and is not available as a system resource. (Incidentally, notice that the graphics memory is the only memory on the motherboard.)
The video memory is partitioned into six frame buffers split into two layers having three buffers each. This arrangement is shown in Figure 2. The first layer (the "paper") contains the screen image, and the second layer (the "acetate") displays the pen's "ink." Each layer has only one active buffer at a time; typically, the inactive buffers are used to cache fonts and icons that can be "bit-blitted" to the active paper layer for higher graphics performance. The screen image the viewer sees results from logically ORing the paper and acetate layers' active buffers. All images use 1 bit per pixel; the video subsystem is currently a monochrome design. We've placed all device-dependent code, including the 63484 graphics driver, in the micro kernel. This minimizes the impact on applications if the Infolio software system were ported to another architecture.
The fourth processor in the system, the Intel 80C51 microcontroller, came to us as part of a technology licensing agreement with our digitizer supplier, CalComp. We do no programming of the part ourselves; we simply submit system-level requirements to the digitizer. The '51 scans the gridlines of the digitizer to detect pen position, tilt, pressure, and height of the screen surface.
Other interesting aspects of the architecture are the memory map and memory card-based storage mechanisms (See Figure 3.) The 68331 has only 24 address lines, so the memory space is limited to 16 Mbytes. But because the processor provides lines which distinguish code access from data access, we essentially have 32 Mbytes of memory space. (Note that both Infolio system and application software run in supervisor space. As described last month, the software kernel is a cooperative-multi-tasking, nonprotective system.)
Infolio has no magnetic storage media. The decision to develop a completely solid-state system grew out of the requirements for long battery life and high data integrity in a field environment. Users may freely insert and remove memory cards--while the machine is running--without fear of losing data. The system has three PCMCIA (Release 2.0) memory-only card slots. While one slot holds a mixed memory card containing system ROM and RAM (1 Mbyte of each), the other two slots hold cards of up to 8 Mbytes each. (Card capacities will grow as semiconductor vendors introduce higher-density ICs.) Additionally, there is a virtual card which exists as a partition of system RAM. These cards may be used both for user data storage and third-party application storage. As discussed last month, all data is stored as a hierarchical collections of objects--including application objects--and objects may be freely moved, copied, cloned, and linked between memory cards.
The memory card address space can be viewed as an 8-Mbyte block into which a card is mapped when activated by the system. The system has a notion of an active "data" card and an active "code" card. As the database is manipulated by an application, links are typically encountered which, when traversed, may cause the system to map, or swap another card into the 8-Mbyte data space. Likewise, as applications execute from memory cards, function calls may jump to and from code residing on various cards, causing the system to map the appropriate card into the 8-Mbyte code space.
Memory cards have access times ranging from less than 100 ns to 250 ns, so execution of code and access to user data is quite fast when compared to disk access and load times. Therefore, although the system may be running at a clock speed of only 8 or 13 MHz, user interaction occurs in real time.
Early in the product definition stage of the Infolio we decided that, to simplify the design, we would not support a development environment on the machine itself. Therefore, all application development is done on a host system (Sun SPARCstation or an IBM-compatible PC), then downloaded to the Infolio. This frees the system from the complex requirements of native development, and allows developers to work with familiar compilers and debuggers. In our case, we use the 68332 cross compiler from Intermetrics.
However, we still had to bootstrap our own software development effort. This was achieved in two ways. As discussed last month, the complete Infolio software system executes on the SPARCstation and the PC. By creating an emulation environment on these machines, we were able to develop most of the system without the hardware even being present. About five percent of the system software (50 Kbytes) is hardware specific and is written and maintained for each of our platforms: Infolio, SPARCstation (under OpenWindows), and the PC (under Microsoft Windows).
The second part of our bootstrap strategy was to use the Hewlett-Packard HP64749 In-Circuit Emulator (ICE), combined with Intermetrics XDB symbolic cross debugger to develop and debug the Infolio-specific code as well as any problems with the high-level code. For the first six months of development, we used the Intermetrics' ITools MC68332 compiler and assembler (on the SPARCstation) to cross compile/assemble our ANSI C code into a hex file, which we then downloaded through XDB into the HP64749 emulator memory.
Although this development environment was generally useful and beneficial, we encountered problems which caused significant delays. The main problem was that we originally wanted to move system ROM from address 0 in the memory map to address 0x800000 after system boot. This would allow us to map the memory cards at address 0, hence performing no address translation on pointers (or links) stored on the cards.
Because one of our design requirements was to have the data on a card be independent of where the card sits in memory space, we manipulate card addresses as if they are relative to 0. But because we were unable (even with substantial help from both HP and Intermetrics) to change the memory map and still use the ICE, we had to make hardware changes to move the card memory to the top half of the 16-Mbyte space, and we had to make software changes to add/subtract the card's base address when accessing card data. A second problem was our inability to shift the MC68331 System Integration Module's memory map from its default position at the top 2 Kbytes of the 16-Mbyte space to its alternate position at the top 2 Kbytes of the 8-Mbyte space. This proved to be a problem only when interacting with the emulator, however, and our production system uses the alternate location.
A third problem was a fairly slow turnaround time for software changes. We were using a mixed environment (HP emulator, SUN workstation, and Intermetrics tools), so the only viable path at the time for downloading code was via XDB through the SUN's serial port to the emulator at 19.2 Kbaud. Because of the protocol used, it took nearly an hour to download 512 Kbytes of code.
The last problem was that as our system code grew past 512 Kbytes, we could no longer use the in-circuit emulator's emulation memory. This actually proved to be the catalyst for a major hardware change. Originally, we had I Mbyte of ROM and 512 Kbytes of SRAM on the motherboard to hold the system code and data. After putting together early prototypes of the Infolio, we found that the small size and intricate design made it difficult to continually take the units apart to update the system ROM. This fact, combined with the inability to use emulation memory (due to size limitations) led us to take all memory off the motherboard and use a PCMCIA card to hold the system code and data.
Since moving the system code to a memory card, several problems have been eliminated. A major one, update speed, is much improved because we can now cross compile to a binary file and download that file through the Infolio's serial port directly onto a memory card. That card is then moved into the system slot for use. A 1-Mbyte serial download now takes less than ten minutes at 38.4 Kbaud. We also are able to run the ICE with this configuration by not using the emulation memory and allowing the ICE to write to system "ROM" in order to insert software breakpoints to support XDB. We use 2-Mbyte SRAM cards for development, with the lower half holding system code and the upper half holding the stack, system heap, and the virtual data card.
Needless to say, we couldn't expect third-party developers to go through the process just described; application development tools would obviously have to be provided. However, because the Infolio is viewed as an embedded system, the development environment threatened to be especially tricky to create.
Consequently, we created a development kit to support application development for the Infolio. As shown in Figure 4, developers can employ the user interface layout editor and/or the database structure editor to define the application-specific data structures and their user presentation. These tools produce code templates to which the developer can add specialized task handlers. Custom event handlers can be attached to user interface objects if there is a need to respond immediately to an event. For example, the application might do special processing on a value in a database object when the user taps the pen on a particular check-box object. Developers can also create applications without the graphical editing tools by using the Application Programming Interface directly.
On the development host (SPARCstation or PC), developers can compile and debug their application code using familiar tools (on the PC, Borland's C++ in ANSI C mode, and Turbo Debugger, for example). The developer's code is then linked to a library we provide, which is essentially the complete Infolio system, resulting in a single large executable that can be debugged on the host. Note that, on the Infolio target, applications are objects that exist in a fully late-bound flexible form.
To debug the application code on the target, we've developed a symbolic cross debugger which operates through the MC68331's background mode. A special connector joins the host to the Infolio via the expansion port. The symbolic cross debugger communicates with the target to set/get variable values, get stack information, set software breakpoints, and control execution.
There were four keys to developing the system to our design requirements and time constraints. As discussed last month, our object-oriented architecture made maximum use of code reusability and standardized communication and so helped keep the system code compact and made it quicker to develop. Next, Motorola's 68331 provided a simple, well-known architecture to work with, and its on-chip integration reduced board real estate and power demands. Using intelligent coprocessors also reduced the chip count and code development effort. Thirdly, the software emulation of the system let us develop code concurrently with the system hardware, and also allowed a more comfortable and productive application development environment. Finally, the use of in-circuit emulation and cross debugging at the source-code level expedited the process of developing Infolio-specific code and of debugging early problems with the high-level code.
Copyright © 1992, Dr. Dobb's Journal