Does my computer have a Microcontroller in it?

Nowadays, the most common setup is to have a "chipset" that supports the microprocessor by handling the interfaces to the rest of the system. The usual term for these (derived from Intel, IIRC) is the northbridge and the southbridge. The northbridge handles the high speed stuff -- system memory, AGP bus, etc; the southbridge handles most of the rest, which including managing the parallel port.

It is possible to make system or BIOS function calls that interoperate between user space and the parallel port. A bit harder under the NT family than it was with MSDOS but do-able. A good place to start for info on this is

As a general rule, however, I find it easier to do this sort of thing with a serial port link to a stand-along microcontroller board. Tell the microcontroller what to do and let it handle the details.

A parallel interface chip mapped so that dumping a byte to a certain address looks (to the CPU) like it just wrote the byte to memory, probably...

Reverse the concept if you've got a bidirectional PP, or some other type of port that's capable of both input and output - The port gets data from somewhere. It sets a flag (probably, but not necessarily, an interrupt - several methods are easily available, and several more that aren't quite as easy can be used) to indicate it has something for the CPU to work with, then when the CPU services that interrupt (or polls the flag, or...) the system software knows to tell the CPU "Yo! Stupid! Read this byte of "RAM" and do something with it!"

Likewise, any other output (or input) device can be (relatively) easily mapped to look like RAM from the CPU's viewpoint. From there, it's just a matter of adding code that "does the dirty work".

This only directly "notices" devices on the motherboard, but the same concept can be applied to slot-installed stuff like a SCSI card, USB card, and so on - The OS takes a poll of the slots at startup, figures out that slot "X" has a "Super-whiz-bang 2000" output device in it that knows to look at location $0XYZ, and sets up interrupts, handlers, and the other needed "stuff" so that the CPU can go on believing it's simply talking to a byte of RAM (at location $0XYZ) on the motherboard. Your program calls a routine that needs to write data to the S-W-B 2K, which triggers any of several possible methods that tell the CPU to write the byte your routine supplied to $0XYZ. From there, it becomes an "SEP"(1) as far as the CPU is concerned, and your program keeps on truckin' along. Again, for input, reverse the concept.

(1) What? You don't know what an SEP is???? OK, where have you been hiding since the publication of the Hitchhiker's Guide To The Galaxy series???? An SEP is "(S)omebody (E)lse's (P)roblem".

Technically, yes. The PC does have a microcontroller in the keyboard. All PCs (after the original PC and XT) have had a microcontroller in the keyboard to read keys, light LEDs and communicate with the PC.

An earlier post describes the parallel port and chipsets. You might want to look at Jan Axelson's "Parallel Port Complete", and look at the website for the book.

There's a lot of good information for beginners there.

Chris

You might want to consider a PIC chip like the 16F268 that communicates to/from the PC via a serial port connection. Then the PIC chip would do the LCD and LED controlling.

I'm in the process of a project where my PIC is imbedded in an electronic ignition controller. The PIC measures the RPM and controls the ignition and reports back RPM and spark advance to the PC. My laptop then commands spark delay adjustments. All this is done via a serial link, COM1 RS-232.

----------------------------------- In the older PC's, even early Pentiums, and in any of the very simple pre-plug-n-play parallel port cards, the interface card is actually just made of a few TTL chips, latches and buffers and demux's and such (see my example circuit here:

and the main processor is indeed the one which sends the data to it.

But in later machines, they used universal I/O chips and chipsets that automated this process a bit, but which, to be compatible with the original hardware, had to totally, or nearly so, emulate the original I/O card made with simple buffers, latches, and decoders. While these chipsets were probably made with a processor core, they didn't have to be, and even early UARTs are not truly processors in any sense, but are internally just an elaborate array of shift registers and simple latches and logic.

I/O is something a processor does on its bus, a controller is just a processor with I/O latches, decoders, and logic off its address, data, and control bus. A microcontroller is just a microprocessor with the I/O drivers on-board, in one chip. Even a processor can be made with nothing but TTL chips, if you wanted to fill your shop with your computer and heat your shop with it.

-Steve

Your computer does have resident I/O instructions. Windows NT, 2K, and XP just prevent you from using them to talk to the parallel port, unless you use a special driver ike GIVEIO. If you have Win9x or anything that can run real-mode DOS you can talk to the port directly through the I/O bus.

Bob Masta dqatechATdaqartaDOTcom D A Q A R T A Data AcQuisition And Real-Time Analysis