|
by Bob
Perrin
Start ý Selecting
an Embedded PC ý Hello World ý Controlling
Resources ý Thank You, Intel ý Sources
and PDF
After attending the Embedded Systems
Conference (ESC) in San Jose, it became clear to me that embedded
'x86 products dominate the embedded-systems market.
Sure, there are still dozens of small
companies making custom hardware and development tools based around
other processors. For example, Parallax is still peddling the PIC-based
Basic Stamp, Z-World still produces 8-bit Zilog Z180-based controllers,
and Wilke has their 16-bit BASIC Tigers. Thumb through the Idea Box
ads in Circuit Cellar magazine and you can still find a handful
of companies selling non-'x86-based custom hardware and software.
But, the 800-lb gorilla on the block is the embedded 'x86.
I have experience with all the above
products and they're all fine in their respective niche, but after
the ESC, I decided to broaden my horizons to include the dominant
technology in the embedded-controller marketplace.
I went looking for a good how-to-use-an-embedded-PC
text. I found many articles, but they were either over my head or
devoid of details (or both). At long last, I found and purchased Ed
Nisley's book, The Embedded PC's ISA Bus: Firmware, Gadgets and
Practical Tricks [1]. This is an excellent text and I highly recommend
it to anyone attempting to build ISA cards, but it still didn't fully
satisfy my curiosity.
How do you get an embedded PC without
a keyboard, monitor, or disk drive to boot and run your application
code? How do you control the resources on an embedded PC from a C
program? I decided the best way for me to answer these questions was
to buy an embedded PC and tinker. After all, the best learning is
accomplished by doing.
WHAT IS AN EMBEDDED PC?
The first issue to address is the difference
between an embedded PC and an embedded 'x86. An embedded PC
falls into a subclass of the more generalized embedded 'x86
universe.
An embedded PC should run one or more
of the same OSs that a normal desktop PC runs. The development tools
used to write code for an embedded PC should be the same tools used
to write code for a desktop.
For example, Tern will sell you 'x86
hardware and Borland C for software development. However, Tern's products
don't support DOS. So the executable image generated by the Borland
tools must be handed off to a relocator written by Tern. I don't consider
these products to be truly embedded PCs.
The idea of taking executable code generated
by DOS-based tools for a DOS-based target system and relocating it
in memory on a target system without DOS just gives me the willies.
This isn't meant to be a slap at Tern's
product line, which is quite broad and successful (just check out
their web site to see how NASA used their 'x86s). It's just
to say that, if I'm going to use DOS tools to generate code for a
DOS system, I would feel better if the target system had DOS running
on it.
An embedded PC must make resources commonly
found on a desktop PC available to the application-code. These resources
include, at a minimum, a file system and a console. In the world of
embedded PCs, the file system is often not kept on a mechanical disk.
A flash memory-based or battery-backed SRAM file system is the usual
storage medium. The system console is often a serial port.
In my opinion, an embedded PC need not
have an expansion bus, such as PC-104 or Compact PCI, although most
do sport some expansion bus.
NEXT
Circuit Cellar provides up-to-date information
for engineers. Visit www.circuitcellar.com
for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com
or subscribe
online. ýCircuit Cellar, the Magazine for Computer Applications.
Posted with permission.
|