All DatabasesMacTech Vol 09-1993
Controller
Volume Number: 9
Issue Number: 7
Column Tag: Hardware Interface
Developing Embedded Controller Software
A unified solution to embedded cross-development applications of the
Macintosh
By Chris J. Magnuson, Hewlett-Packard Company
Note: Source code files accompanying article are located on MacTech CD-ROM or
source code disks.
About the author
Chris Magnuson works as an embedded software engineer at Hewlett-Packard
Company, designing software for a variety of instruments. He can be reached on the
Internet at chrism@col.hp.com.
Have you ever wanted to produce an electronic gadget to solve a problem you had
encountered? Have you ever had a great idea for an electronic gizmo that you could sell
to the masses? Many obstacles can stand in the way of translating an idea into a viable,
functioning piece of electronic equipment. But as with all things, a little perseverance
and some information will get things rolling in the right direction. Most gadgets will
require a microprocessor (also called an embedded controller) to provide control and
handle user interfacing to the system. This article will give you the information you
need to use your Macintosh as a software development platform to create your
embedded controller idea.
Even if you have no experience designing electronic hardware and can only write
software, you can still get an idea out of your head and into your hands. If your
application calls for some sort of special hardware, like a data acquisition system or an
audio digitizer, try to enlist the help of a knowledgable friend or other
electronic-savvy designer to design the digitizer for you. One source to find
individuals like this is your local university engineering college. Or try posting
something on the Internet sci.electronics notes group. When the hardware is designed
and the data is translated to digital streams, the software becomes the enabling link in
the chain. And several companies produce SBC (single board computer) products that
are microcontrollers with RAM, ROM, Input/Output (I/O) facilities and timers ready
to run, needing only a power supply to activate them. So you don’t necessarily have to
design an embedded control computer. Check a copy of Radio Electronics magazine or
Embedded Systems Programming magazine for advertisements on these SBC products.
Get copies of catalogs from electronic component suppliers such as Digi-Key to
familiarize yourself with the types of switches, display units and packaging
components available for your project.
Before you start coding, there are a few issues that need to be addressed. It is
an extremely good idea to design the system on paper before you start implementing.
One reason for this is because assumptions made during the analysis portion of the
project can ripple down to the implementation phase and cause problems of untold
magnitude should the assumptions prove false. Careful planning and investigation can
minimize your disappointments. An embedded controller system is usually
“realtime,” meaning that there are some expectations of its performance with regard
to how the user interacts with it. An example of a bad analysis-phase assumption
would be that there are no expectations for display speed. If your project uses some
sort of display device you may want to make sure that the display can be written to fast
enough that the user will not be waiting for the system to respond to his inputs. In
other words, figure out whether the software you will need to write can run quickly
enough to satisfy display update rate constraints. This may sound a bit like the
“chicken and egg” paradox, but you can formulate some idea of how long your program
will take to do various tasks once you start writing down what those tasks are. The
mere act of translating your idea into verbage on paper can bring problems to your
attention, and the earlier they are discovered the better your project will perform.
To make your idea a reality, you’ll need some hardware and software tools. The
hardware tools are probably more difficult to understand for software designers, but
are often needed to facilitate debugging and system implementation. There are a
variety of hardware tools available for solving embedded development problems. They
include in-circuit microprocessor emulators (called emulators or ICE), logic
analyzers, EPROM programmers and ROM emulators, to name a few. Many of these
devices will interface with your Macintosh via a serial cable. Be aware that the
standard modem cable supplied with peripherals such as 2400 baud modems may not
work, and that a high-speed modem cable that supports hardware handshaking (such as
that supplied with a 9600 baud modem) is much more likely to be needed. In
summary, there are two different Macintosh serial interconnection schemes that
require two different cables.
ICE equipment can be thought of as nothing more than a large box of electronics
that simulates the operations of your system microprocessor chip (Fig. 1). This
seems inefficient, but the reason ICE are used is because they allow you to inspect the
inner workings of the processor in the system, much like Macsbug allows you to see
what the Macintosh is up to. The emulator will also have RAM available, which means
that your program software can be downloaded into the emulator RAM and run from
there. This is useful for simulating ROM if your code will eventually reside in ROM.
The emulator can communicate with the Mac via one of the serial ports in conjunction
with a terminal data communication program. When your system does not work, you
will need to understand why, and tracing the execution of the code on the hardware may
be the only way to determine the cause of the failure. This hardware trace capability
is one of the great benefits of microprocessor emulators, since you are getting a bird’s
eye view of the activity on the microprocessor busses and have the capability to stop,
step or set breakpoints for program execution. Although the emulator trace
information will often be in assembly mnemonics, there is a workaround for this so
that high-level code like C or Pascal can be displayed along with the assembly code it
produces. More on this later.
Figure 1: In-circuit emulation (ICE)
Be sure to understand that the ICE will require some room for the probe head to
fit in your embedded system. The probe head is usually a bit larger than the
microprocessor chip and your hardware must have room to accomodate it. When you
buy an SBC ask the vendor if they can socket the microprocessor with a ZIF
(zero-insertion force) socket and get clearance measurements from the emulator
vendor to make sure that this will not be a problem. The SBC vendor will probably
have some information for you concerning which emulators have successfully probed
their product. Also, make sure that the mechanical design of your gadget (i.e. the case)
will not interfere with emulator probing.
MACHINE 1 - State Listing
Label ADDR TI 34010 Mnemonic Time
0 3FEDF650 MOVE @3FED0020h,A8,0
1 3FEDF660 0020h data read 536 ns
2 3FEDF670 3FEDh data read 528 ns
3 3FED0020 031Eh data read 400 ns
4 3FEDF680 CMP A8,A9 400 ns
5 3FEDF690 JREQ (JRZ) 015h 536 ns
6 3FEDF7F0 MOVE @3FDCC010h,A7,0 664 ns
7 3FEDF800 C010h data read 536 ns
8 3FEDF810 3FDCh data read 536 ns
9 3FDCC010 CC2Eh data read 400 ns
10 3FEDF820 MOVE @3FDCC000h,A8,0 400 ns
Figure 2. Logic analyzer inverse assembly state listing from HP16500A logic
analyzer
A logic analyzer is a powerful tool for examining the workings of your system. A
logic analyzer differs from ICE equipment in that the ICE is in the circuit in place of
the microprocessor, while the logic analyzer probes are on the circuit. This is an
important distinction, because it makes the difference between having program
execution control and register-peeking capability (as with the ICE) and having only
address/data bus information (as with the logic analyzer). Even so, the logic analyzer
is versatile, because most logic analyzers have facilities to enable them to make sense
of the information they find on the busses and produce mnemonic or disassembled
displays (Fig. 2) that show where your code is executing. The logic analyzer can be set
up to trigger on a certain event (arrival at a certain address range in the code, for
example) and start storing all activity after the trigger point for examination in this
mnemonic assembly code format. In this way system crashes can be tracked to the root
cause by doing successive traces on suspected portions of the code. If necessary, many
logic analyzers can be programmed using simple commands via a serial port if task
automation is desirable (such as dumping all the data from the logic analyzer to a
computer for storage).
Similar to the ICE equipment, many logic analyzers will have mechanical
requirements to probe your system. Logic analyzers often work in conjunction with
something called a preprocessor (different than a preprocessor for a software
compiler). The preprocessor is a small circuit card that allows you to insert the
microprocessor chip in it, attach the logic anlyzer cables to predefined connectors,
then put the preprocessor in your circuit. It is still possible to get valuable
Referenced by (40):