This article first appeared in the May 1989 issue of Embedded Systems Programming magazine.

One of the challenges the embedded systems developer faces is writing software for custom hardware when that hardware exists only on paper. Unlike the development of applications for general-purpose machines, there's initially no platform on which to test the software as it's developed. Historically, the only recourse has been to use simulation software or an emulator without the hardware. Both cases offer limited help in refining such critical areas as operator interfaces and target system interaction, and both make it hard for the customer to see early on how the system will behave.

In the last few years I've solved this problem by building and using partially operational simulator hardware, or POSH for short. POSH was used to simulate a 500-IC, 68000- based embedded system, but it fit on a single six-by-nine-inch, wire-wrapped circuit card built at the start of the software development cycle. The POSH device was then hooked up to the Microtek Mice-II emulator, allowing the software development team to test much of their software months before the full breadboard system was available.

There's currently a move toward completely simulating the hardware environment with software. While this approach is certainly useful, it lacks the ability to conveniently attach existing hardware and fully test the interaction. Nothing is more frustrating than designing software to work with a device as it was specified, only to discover that the hardware has one or more features that weren't implemented as stated in the specification. POSH allows such devices to be hooked up and tested with real software so that hardware peculiarities can be found and circumvented quickly. This is something no existing simulator can do.

Use of the POSH device cut months from our actual development time. One advantage was that the hardware and software teams had to hammer out the interfaces in the first weeks of the contract rather than putting it off. The most commonly used parts of the code were thoroughly tested by use in a real environment. The real-time operating system initially ran with nothing but stub tasks; as code was completed, it was inserted and could be run in the actual target environment. The customers were able to see early in the project how the final system would behave, suggest improvements, and approve such details as the operator interface months before the final hardware was completed. POSH more than paid for itself by reducing the delays we had experienced in the past as a result of inevitable last-minute surprises and changes.

What's needed
Before designing a POSH device, you need to know several things. First, you must know what the final embedded application system will do. In a big company, this data may come in the form of a preliminary specification document, whereas a small shop may reduce it to an idea in the heads of one or two key individuals. Either way, the POSH designer must have this information. Next, the hardware and software teams need to determine how much and what needs to be simulated. This can usually be reduced to a very limited number of functions. The fewer the functions simulated, the less hardware there is to build. Of course, taking this to extremes can be false economy.

System functions can usually be divided into the "real needs," the "very handy," and the "might also like." The real needs are generally very few, allowing room on a small circuit card for those needs plus a couple from the "handy" category. Once this much is determined and agreed upon by the participants, the box can be sized to determine its projected cost and schedule.

Next, several decisions must be made: how the interfaces to these functions will work, where in memory or I/O space they're located, and how they'll be accessed. The key here is to hammer out a definition that will hold for the final product so changes won't impact schedules later. Probably the best scheme is to take the time to design the actual interfaces to these functions and see if they can be used in the POSH device. When this is possible, it provides further assurance that the software and hardware interfaces are well understood and will probably work in the final product. Of utmost importance at this point are the cooperation and communication of the hardware and software teams. The best case is when each team comes to the meeting willing to listen to what the other side can offer and what it needs.

Once the interfaces are hammered out, the POSH hardware can be designed. Ideally, it would be an enclosed, self-powered, freestanding unit (see Figure 1). The enclosure prevents most of the falling-paper-clip sort of damage that can short out and ruin the hardware. The fact that the power supply is contained in the unit makes it unlikely that it will have to be retrieved periodically from some technician's bench. And a freestanding unit makes it much more convenient to place the system and emulator in the offices where the software team actually works. This way, they'll have constant and ready access to the device.

View the full-size image

In most cases, the active electronics can be put on a single wire-wrapped board. The board should be mounted inside the enclosed in such a way that it can be easily removed when modifications are required. Connectors should be used to connect the board to the enclosure wiring and to any outside wiring necessary for the application. The connectors make the system easier to disassemble and reassemble, whether to make changes or to take the whole system to the sales area for a demonstration. The emulator socket should have a zero-insertion-force (ZIF) connector to put the least possible strain on the emulator cables and connectors.

One issue that must not be overlooked is safety. Most of us who work with embedded systems get used to the fact that there's a small risk of injury from the electronics in a project. Usually the low-power electronics are unlikely to be of much danger to anyone, but a unit like POSH can be quite dangerous if not built with safety in mind. One danger is the exposed wiring in the power supply area. That 120-volt AC input must be shielded in such a way that no one can inadvertently come in contact with it.

Furthermore, if the devices with which you interface use high voltages or currents, the connections must also be carefully shielded. Never assume that anyone will be extra careful around POSH, since you never know what your chief salesman (or his client) may do when showing off your system.