Hello Siegfried

Let me guess ... you have only one pin available for the serial transfer?
If you have two or more pins there's no point in using only one pin (except
for the fun of it of course).

Have you tried to make one port pin work as two port pins?
Let's say you need a serial input line and input from a photodetector.
If these two tasks never interfere with each other, then you can use one
input pin to read two devices. If you have this in mind while constructing
the hardware, then there's no problem. (I don't know how often you can
use a solution like this, but I did in a recent design.)

photodetector, active low  ---------------------+
                                                |
                                               __
                                               /\   <-- DIODE (low Vf)
                                               --
serial input line, active low ---|RESISTOR|-----+----------- PIC port pin

-----------------------
Conny Andersson / LiTH


> Hello PICcers,
>
> I am planning a project, where a PIC has to communicate with a PC.
> Normally, you would use the serial port or any other standard ports of a
> PC to build up a connection with a PIC. But I thought to (ab)use only one line
> of the parallel port for the communication (and of course a ground line) - and
> the parallel port should still be used for the printer:
>
> The parallel port of a PC has a line called 'Autofeed'. If activated, the
> printer automatically adds a line-feed, when it receives a carriage return.
> Since this function is not needed normally, I thought of setting the line to
> an appropriate voltage level on the printer's side, and use this line instead
> for communication with my PIC.
> This autofeed line of the parallel port has the advantage, that it can be
> programmed to be an open collector output or an input (as far as I think to
> know).
>
> The PC should send a command to the pic via the line, and the pic should reply
> with a status message. So the data transfer goes in both directions, a message
> will consist of about 3-30 bytes.
>
> I still have some doubts, if this kind of interface would work. I have not
> made any experiments yet, but I hope that someone can give me an answer or a
> comment to the following questions:
>
> What would be a suitable transfer protocol? The PC-control-program (it
> will be a plain DOS-program) has to program the port line directly and
> therefore needs a reliable time base. Can a PC-timer be used for this purpose:
> the timer used for producing sound beeps? How exactly can a PC produce signals
> of a desired length, as various interrupts and other events can interrupt
> the execution of the 'normal' program?
>
> I thought of two transfer methods:
>
> 1. a 1-bit is coded as a long impulse, a 0-bit is coded as a short impulse.
> but if the program is interrupted during a short impulse, the short impulse
> may become a long impulse!?
>
> 2. a 1-bit is coded as a long low impulse, followed by a short high impulse,
> a 0-bit   is coded as a short low impulse, followed by a long high impulse;
> if both impulses are long, the bit is erratic and discarded, and immediately
> sent again. I would consider this as rather reliable!?
>
> Thanks,
> Siggi
>
>
> Siegfried Grob,                                   |
> student of electrical engineering,                |
> university of ulm, germany                        |
> e-mail:  siegfried.grob@student.uni-ulm.de        |
> tel&fax: +49 731 25148                            |
> --------------------------------------------------'
>