Al:
My product (a fiber-optic multiplexer) uses a 10 MHz 80186 with
1 MB RAM and 1 MB EPROM (half disabled). There are a few other
system components -- 3 SCCs (Zilog's 2-channel "Serial
Communications Controllers" -- a few ports have RS-232), one 8256
multifunction chip (which also has an async port), 3 banks of DIP
switches, a very few LEDs, a bus interface (buffers a subset of the
80186 bus) and lots of parallel I/O (96 lines plus watchdog timer on
proprietary chips). The RAM is capacitor-backed-up (holds data for
about 2 weeks!), and there's a real-time clock -- the MC14618, but
there may be a problem, because I don't think the software team ever
used it. Size: about 12"x15", runs on +5 Volts at about 5 Amps, 100%
"through-hole" technology. Anyway, this product's getting to be
pretty old, and if you're (very) interested, I could qualify a
couple of these and send them to you with enough documentation to
keep you busy for a long, long time.
I think it's still a reasonable embedded-implementation
representation (except for the proprietary parallel I/O and 8256).
Of course, you'd use the AMD chips these days, because they're
faster, cooler, and probably have a few more features, and it would
all shrink down to one-tenth the size and power. Certainly my whole
interest in your project is applications like this.
> What sort of features are required for this type of system? It
seems to me
> that a filesystem is not all that important with no storage. Are
device
> drivers, interrupt handling and memory management the types of
features
> required?
Anything that can help with debug is great. So, if an IBM PC
could be rigged up to emulate this system, and then be replaced with
the real thing later, that's a fabulous plus. Otherwise, I'd think
the whole filesystem issue is less important. But these days, I
think in terms of embedding real linux...
> What sort of real-time features to such operating systems
generally have?
(scared I'm going to sound pre-schoolish with this one) You of
course need to be able to time events -- to set a timer, suspend and
have good expectation that you'll get control back when you ask for
it.
> What type of API is the application code going to use? Is the UNIX
system
> API any use at all?
Probably fine. I'm sure interested in others' answers.
> Are embedded applications run as stand-alone binaries, or do they
get
> linked into the kernel and run as kernel threads?
I think of kernel threads as a hassle to debug -- it's nice to
have OS protection. But in this case, perhaps there is no protection
to offer. It still seems like there should be a clear delineation
between the kernel (and drivers) and the application...
--Bill Ewing
