Exact match. Not showing close matches.
'[PIC] How to make a EPP parallel port using a 16F8'
I am working on a data transfer project which demands bidirectional communication between a PIC microcontroller and a PC parallel port. Priority should be given to PIC-to-PC transfer, which will be commanded by an interruption. I thought about using the EPP protocol. I am using the PIC16F877, which has a slave parallel port. I wonder if anybody has done something similar to that, so I will not have to design hardware and software from scratch.
Any help will be very appreciated.
Prof. Antônio A. F. Quevedo, Ph.D.
Chief of Department
DEB/FEEC - UNICAMP - Brasil
Campinas - SP - Brazil
> I am working on a data transfer project which demands bidirectional
> communication between a PIC microcontroller and a PC parallel port.
Is your PIC based item going to be the peripheral end? With PC
acting as the host side? I assume so from the rest of your messsage.
I've just done a IEEE-1284 compliant parallel interface where the
PIC product is the host with various laser printers as peripheral.
Code was done for a paying customer, so I can't release it. Plus
it uses 18F instructions. But I'm willing to answer questions.
I _strongly_ recommend getting a copy of the IEEE standard
1284-2000 "IEEE Standard Signaling Method for a Bidirectional
Parallel Peripheral Interface for Personal Computers". It is
very clearly written with nice timing diagrams, event descriptions,
and phase transitions.
Downside is that it costs $108 for PDF from IEEE web site (with a
discount if you are an IEEE member). You may have access to it
through your university library. I found the standard to be a better
value than the $30 I spent on the book "Parallel Port Complete". I
would have saved lots of time if I had bought the standard first.
> Priority should be given to PIC-to-PC transfer,
This implies that your PIC will be acting as a peripheral to a PC.
How much data (octets per second) are you planning on sending from
the PIC to the PC? If low, reverse nibble mode is easiest and may be
adequate. Next up is reverse byte mode. Surprisingly, a couple big
name printer makers chose not to implement reverse byte mode in their
printers [guess how I found that out]. For high volume data transfer,
there's ECP. ECP has optional run length encoding, so that might be
an advantage if you have lots of easily compressed data to transfer.
> which will be commanded by an interruption.
In general, the peripheral side doesn't generally request service.
The host asks. This shows the printer orientation of the parallel
port interface and it's master/slave roots.
> I thought about using the EPP protocol.
EPP is basically an ISA bus with a long cable in the middle. My
reading of the standard is that it's deprecated. EPP is totally
host side driven.
I'd probably use ECP or reverse byte mode. Do you have control of
the PC side driver software?
> I am using the PIC16F877, which has a slave parallel port. I wonder
> if anybody has done something similar to that, so I will not have to
> design hardware and software from scratch.
I've never used the slave parallel port.
We use the AMD 74LVX161284 interface chip. It handles 3.3V logic
to 5V cable translation and provides proper termination resistors
for bidirectional data bus, control lines, and status lines. We
hook the 74LVX161284 pins directly to the DB25S connector. AMD
recommends a 74F1071 diode array to improve the ESD immunity.
We assigned data bus to an arbitrary 8-bit port. The 4 control lines
and 4 status signals were grouped together on another 8-bit port. We
are host side, so nAck signal is tied to a port B interrupt pin.
Particularly since you want to transfer data from the PIC to the
PC, I'd build the product to be IEEE 1284 compliant.
Since all 1284 compliant peripherals must implement reverse nibble
mode, it behoves you to order the 4 peripheral status output lines
in the data bit order mandated by IEEE 1284. I'd map them as:
nFault/nDataAvail status signal, data bit 0 (and data bit 4)
Select/Xflat status signal, data bit 1 (and data bit 5)
PError/AckDataReq status signal, data bit 2 (and data bit 6)
Busy/PrtrBusy status signal, data bit 3 (and data bit 7)
By hooking the status lines to the appropriate port pins, you don't
have to flip bit positions around in software when doing nibble mode
If PIC is acting as peripheral, ensure that the nStrobe/nHostClk
signal is hooked to a pin that can generate an interrupt on falling
edge. You probably also want to tie nInit (reset) line to a pin
that can generate an interrupt on falling edge.
If PIC is acting as host side, ensure that the nAck/nPtrClk signal
is hooked to a pin that can generate an interrupt on falling edge.
> Any help will be very appreciated.
Please contact me privately if you are interested in a having us
do either the hardware or the software under contract.
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...