Hi Nate,
Pins that can be both inputs and outputs can't be both at the same time.
When they are set as inputs, you read the corresponding register and you
get the value that is input on the pin. When they are outputs, reads
from the register show the value that you set the pin to.
The pins that appear in the control register are normally outputs. You
have to tell the parallel port that you want them to be outputs before
you can read data from them (if they can be inputs).
For the data bits, bit 6 of the control register determines whether the
pins are inputs or outputs.
For the other lines, I have lost the reference that said that the Strobe
pin can be either an input or an output. If you refer to
http://www.beyondlogic.org/epp/epp.htm and
http://www.beyondlogic.org/ecp/ecp.htm its direction can't be changed.
If its direction can be changed then there is a bit somewhere that you
have to flip to explicitely say that you want Strobe to be an input.
Blaise
Quoted from Nate Jenkins on Wed, May 14, 2003 at 10:55:47AM -0700.
> I appreciate you looking at my code. I am pretty sure I am reading the
> respective ports, unless I am really missing something. The first time it I
> read the control port is in simreadonly.cpp line 41:
> ->->->-> else if( NOERRORS == pp.GetPort( atoi(argv[1]) ) )
>
> This function is defined in ModLapLinkInterface2.cpp line 28. GetPort reads
> the control port on line 100:
> ->->->-> READ_CTRL_REG();
>
> This macro is defined in the ModLapLinkInterface2.h file starting at line
> 115 and ending at line 124:
> ->->->-> #define READ_CTRL_REG() if( ioctl( m_nPort, PPRCONTROL,
> &m_ucByte ) ) \
>
> However, I am repeatedly reading the control port in simreadonly.cpp line 51
> in the main loop:
> ->->->-> pp.GetC( &ucCTRL );
>
> The function GetC(...) is defined starting at line 167 in
> ModLapLinkInterface2.cpp where it also utilizes the aforementioned macro. I
> am using the macros so I can use the same code in DOS as well as Linux. So
> I wouldn't have to change the function definitions since they can call which
> ever version is defined. Its is not there yet because I would have to
> define the DOS equivelents and include respective headers based on which one
> I wanted to use.
>
> So am I missing something major here? Or is it any clearer than mud now?
> :)
> How shall I make use of your suggestion to "access the register to change
> the direction of the bits"?
>
>
> Thanks,
> Nate
>
>
>
>
> ----- Original Message -----
> From: "Blaise Gassend" <blaise@gassend.com>
> To: "Nate Jenkins" <nate@uniwest.com>
> Cc: "Parport" <linux-parport@torque.net>; "Gregg C Levine"
> <yodathejediknight@worldnet.att.net>
> Sent: Wednesday, May 14, 2003 5:59 AM
> Subject: Re: [PARPORT] custom cabling
>
>
> > Hi Nate,
> >
> > I had a look at your code, and it seems to me that you aren't accessing
> > the econtrol register at all. I believe that you have to do so to change
> > the direction of those bits. I've never done this via the ppdev
> > interface, so I can't give you any specifics, but I'm pretty sure this
> > is your problem.
> >
> > > I have the status port of PC #2 accepting bit changes from data port of
> > > PC #1. However, no matter what I do, I cannot change the values of the
> > > control port of PC #2 from outside of PC #2.
> >
> > -- To unsubscribe, send mail to: linux-parport-request@torque.net --
> > -- with the single word "unsubscribe" in the body of the message. --
> >
> >
>
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed May 14 2003 - 14:23:22 EDT