Does my computer have a Microcontroller in it?

J

jm

Guest
I know it has a Microprocessor, but does it also have a
Microcontroller? For example, I am (from a project I found) going to
have my PC control some LEDs and a LCD display. But since the
microprocessor doesn't have resident I/O, etc., then what is it that
actually sends data through the parallel port to the outside world?

How does it fit together here? I hope you understand. Thanks.
 
On 1 Oct 2004 14:12:05 -0700, john_20_28_2000@yahoo.com (jm) wrote:

I know it has a Microprocessor, but does it also have a
Microcontroller? For example, I am (from a project I found) going to
have my PC control some LEDs and a LCD display. But since the
microprocessor doesn't have resident I/O, etc., then what is it that
actually sends data through the parallel port to the outside world?

How does it fit together here? I hope you understand. Thanks.
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.
http://www.webopedia.com/TERM/S/Southbridge.html

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 http://www.lvr.com/parport.htm

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.

--
Rich Webb Norfolk, VA
 
In article <c67e4bdd.0410011312.f2f079f@posting.google.com>,
john_20_28_2000@yahoo.com (jm) wrote:

I know it has a Microprocessor, but does it also have a
Microcontroller? For example, I am (from a project I found) going to
have my PC control some LEDs and a LCD display. But since the
microprocessor doesn't have resident I/O, etc., then what is it that
actually sends data through the parallel port to the outside world?
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".

--
Don Bruder - dakidd@sonic.net - New Email policy in effect as of Feb. 21, 2004.
Short form: I'm trashing EVERY E-mail that doesn't contain a password in the
subject unless it comes from a "whitelisted" (pre-approved by me) address.
See <http://www.sonic.net/~dakidd/main/contact.html> for full details.
 
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.

"jm" <john_20_28_2000@yahoo.com> wrote in message
news:c67e4bdd.0410011312.f2f079f@posting.google.com...
I know it has a Microprocessor, but does it also have a
Microcontroller? For example, I am (from a project I found) going to
have my PC control some LEDs and a LCD display. But since the
microprocessor doesn't have resident I/O, etc., then what is it that
actually sends data through the parallel port to the outside world?

How does it fit together here? I hope you understand. Thanks.
 
jm wrote:
I know it has a Microprocessor, but does it also have a
Microcontroller? For example, I am (from a project I found) going to
have my PC control some LEDs and a LCD display. But since the
microprocessor doesn't have resident I/O, etc., then what is it that
actually sends data through the parallel port to the outside world?

How does it fit together here? I hope you understand. Thanks.
-----------------------------------
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:

http://www.armory.com/~rstevew/Public/LPT/LPTskmtc_wid.html

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
--
-Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public
 

Welcome to EDABoard.com

Sponsor

Back
Top