68hc11 interface with pci bus

David Kelly wrote:
> On Thu, Jul 27, 2006 at 01:45:03PM -0500, Mike McCarty wrote:
>
>>Note that the Centronics port has only limited amounts of
>>data in the reverse channel (like 5 bits, I think), and some
>>of those bits undergo logic inversion.
> It Depends. There are many different implementations of the parallel
> printer port on PC hardware. Not all were bidirectional. The design

Read what I wrote carefully. I did not specify "The PC Printer Port",
as you seem to think. I specified the "Centronics port".

> originally used by AST was widely copied. But since that time there have
> been a couple of "high performance" "standard" versions complete with
> bidirectional DMA. There were attempts to change the "standard" cable

Of course. ECP, for one.

> from DB25 at one end and huge "centronics" connector at the other to
> something suitable for high data rates. These cables can be found but
> USB and ethernet have mostly pushed parallel printer interfaces out of
> the public's interest.

Yes, but I quote the OP:

> He changed my project again..and now the title became....
> parallel port interface with MC68HC11A1 (MOTOROLA).

Note: parallel port interface

> This is an example of why the student is required to actually assemble a
> working demonstration, because its all the details and organization
> which is required which is the real lesson. The microcontroller is only
> a side bar.

This is an example of the instructor having his head up his butt.

It's also an example of vagueness on the part of the student asking
for help here.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that! Start a New Thread

Dear Mike,

These are the requirement that you asked for..
5 motors , reverse and forward only
DC , 5.5 volt
What else did you need..?

How to connect from printer port to 68hc11A1...??
I already bought the chip, board, capacitors, just a board left to solder....
I have to submit the board this wednesday....

Send instant messages to your online friends http://uk.messenger.yahoo.com Start a New Thread

>The other day, I was just beginning to start my new project on rs-232,
>but my lecturer have another idea...
>
?He changed my project again..and now the title became....
>parallel port interface with MC68HC11A1 (MOTOROLA).

Hmm, I will address this one, since it just so happens that I'm working
on a (legacy) project that involves the use of a PC/Centronics style
parallel interface.

There are a number of control and handshake signals associated with a
PC parport, but for simple one-way (host to device) communications, the
only signals of real importance are the 8 data lines, and the /STROBE
and /ACK handshake signals.

The following actions take place when the host sends a 8-bit value to
the device:

1. Host places a 8-bit byte value on the 8 data lines.
2. Host briefly asserts (brings LOW) the /STROBE line, signalling the
device that a value is present on the data lines to be read.
3. Device waits for the the /STROBE line go low, and then reads the
8-bit value presented on the data lines.
4. Device briefly asserts (brings LOW) the /ACK line to signal the host
that it has read the value on the data lines and that the device
is ready to accept the next byte of data.

The other signals on the parallel port - BUSY, /FAULT, PE (sometimes
named PAPEREND or PERROR), /AUTOFD, /INIT, /SELIN and SELOUT serve more
specialzed handshake and control functions and really do not have to be
implemented. Depending on what sort of control or driver you use on
the host side, you *may* have to tie some of the input lines (such as
BUSY, /FAULT, PERROR, and SELOUT) on the host side to the appropriate
levels to get the host to send data. If your host-side parallel port
driver provides the application with direct control over all the
parallel port signals (highly desirable), then you don't have to worry
about the extra handshake signals, unless you have some other reason
that you wish to implement them (such as, using them to provide a
serial back-channel to allow the device to send data to the host - more
on this in a bit)

The following link has a diagram showing the signals on a PC parallel
port connector:

http://www.hardwarebook.net/connector/parallel/parallelpc.html

The big problem with a standard PC parport is that it is a
unidirectional link; using a parport in a standardized configuration
allows for transmission of data from host to device only. A number of
standard (e.g. IEEE1284) and semi- or non-standard ways have been
devised to make a parport serve as a bidirectional link. The standard
way - IEEE1284 - is kind of complex and is probably overkill for your
application. One way that I have used in the past which is not
'standards-compliant' but works well is to use a few of the parport
handshaking signals (such as SELOUT, /FAULT and /SELIN) to implement a
unidirectional (device to host) synchronous serial interface. The
SELOUT input (to the host) is used as a data line, and the /FAULT input
is used as a clock. The /SELIN output from the host is used as a sort
of host-to-device handshake to 'pace' the transmission, allowing the
host to regulate the bit rate so it does not loose any data when it is
servicing tasks other than your program. I won't go into the precise
nature of the protocol here now, but I will cover it in detail if you
ask.

The HC11 has a built-in subsystem that partially automates the
device-side of the parallel port, allowing it to auto-latch data when
the host-side /STROBE is asserted, and auto-generate the /ACK signal
when the program (in the HC11) reads the latched data. One potential
drawback of using this subsystem is that the data port - PORTC - is
used to implement the external address/data bus on HC11 configurations
that use external memory. If you are running your project board in a
'single chip' mode with no external RAM/ROM then this is not a problem.
There are other drawbacks to using this subsystem that I won't get
into now but will cover in more detail if asked. Start a New Thread

Hi Mark, I am the person who is working on parallel port to 68hc11.
I already finsih the connection between the db25 to 68hc11a1
according what you gave me the other day. below is how i connected
them

Mode : bootstrap
pin 1 db25 to pin 28 (STRB)
pin 2-9 db25 to pin 8-1(port A), respectively
pin 10 db25 to pin 26 (STRA)
pin 11 db25 to pin 43(PD1/TxD)
pin 18-25 db25 to Ground
Port B as output (LED)

so, is there problem with my connection? and how can i know the
circuit is working?

as for future for my porject,i tend to use Visual Basic in buiding
user interface, any comment?

> only signals of real importance are the 8 data lines, and
the /STROBE
> and /ACK handshake signals.
>
> The following actions take place when the host sends a 8-bit value
to
> the device:
>
> 1. Host places a 8-bit byte value on the 8 data lines.
> 2. Host briefly asserts (brings LOW) the /STROBE line, signalling
the
> device that a value is present on the data lines to be read.
> 3. Device waits for the the /STROBE line go low, and then reads the
> 8-bit value presented on the data lines.
> 4. Device briefly asserts (brings LOW) the /ACK line to signal the
host
> that it has read the value on the data lines and that the device
> is ready to accept the next byte of data.
>
> The other signals on the parallel port - BUSY, /FAULT, PE
(sometimes
> named PAPEREND or PERROR), /AUTOFD, /INIT, /SELIN and SELOUT serve
more
> specialzed handshake and control functions and really do not have
to be
> implemented. Depending on what sort of control or driver you use
on
> the host side, you *may* have to tie some of the input lines (such
as
> BUSY, /FAULT, PERROR, and SELOUT) on the host side to the
appropriate
> levels to get the host to send data. If your host-side parallel
port
> driver provides the application with direct control over all the
> parallel port signals (highly desirable), then you don't have to
worry
> about the extra handshake signals, unless you have some other
reason
> that you wish to implement them (such as, using them to provide a
> serial back-channel to allow the device to send data to the host -
more
> on this in a bit)
>
> The following link has a diagram showing the signals on a PC
parallel
> port connector:
>
> http://www.hardwarebook.net/connector/parallel/parallelpc.html
>
> The big problem with a standard PC parport is that it is a
> unidirectional link; using a parport in a standardized
configuration
> allows for transmission of data from host to device only. A
number of
> standard (e.g. IEEE1284) and semi- or non-standard ways have been
> devised to make a parport serve as a bidirectional link. The
standard
> way - IEEE1284 - is kind of complex and is probably overkill for
your
> application. One way that I have used in the past which is not
> 'standards-compliant' but works well is to use a few of the parport
> handshaking signals (such as SELOUT, /FAULT and /SELIN) to
implement a
> unidirectional (device to host) synchronous serial interface. The
> SELOUT input (to the host) is used as a data line, and the /FAULT
input
> is used as a clock. The /SELIN output from the host is used as a
sort
> of host-to-device handshake to 'pace' the transmission, allowing
the
> host to regulate the bit rate so it does not loose any data when
it is
> servicing tasks other than your program. I won't go into the
precise
> nature of the protocol here now, but I will cover it in detail if
you
> ask.
>
> The HC11 has a built-in subsystem that partially automates the
> device-side of the parallel port, allowing it to auto-latch data
when
> the host-side /STROBE is asserted, and auto-generate the /ACK
signal
> when the program (in the HC11) reads the latched data. One
potential
> drawback of using this subsystem is that the data port - PORTC - is
> used to implement the external address/data bus on HC11
configurations
> that use external memory. If you are running your project board
in a
> 'single chip' mode with no external RAM/ROM then this is not a
problem.
> There are other drawbacks to using this subsystem that I won't get
> into now but will cover in more detail if asked.
> Start a New Thread