Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk <wd@denx.de>]

Dear Stephan,

in message <FCEAKDJJAPHPLJFINDAJCEGCDEAA.Stephan.Linke@epygi.de> you wrote:
>
> There are two drivers, both are manualy manipulating bits at the same I/O port.
> Both drivers use the following mechanism to change the value of their pin: they
> read the value from the data register changeing the value and writing the result
> back to the data register (hopefully an atomic access). This works fine since
> for normal output pins you can read the output value and for input pins it's a
> don't care. As soon as one of the drivers use open drain pins something changes.

You must define for your driver(s) what they shall do, and  implement
it that way.

> You can't read the output value any more sou you are starting to drive the
> output pin of the other driver with the input value. Which can be a verry bad
> idea.

Wrong.

Correct is:  You  cannot  read  the  output  value  from  the  _data_
register,  because external logic might drive a the level low even if
your output bit says "high".

Note 1: There is nothing  that  prevents  you  from  using  a  simple
        integer  variable  to latch the value you write to the output
        port. This is so simple that I'm really surprised you did not
        come up with this solution yourself. And  of  course  such  a
        "buffer" can be shared between several drivers, too.

Note 2: Actually I don't think _anything_  changes  between  actively
        driven output and open drain. I think the value you read from
        the  inputs will ALWAYS reflect the actual value at the pins.
        You may want to test what happens when you configure  a  port
        as  actively  driven  output, write a 1 bit to it, ground the
        output pin, and then read back the data  register.  I  bet  a
        case of beer that you will read a 0 bit.

	And no, I will not pay for the CPU you just fried.


> That's why I aggree open drain I/O's are a good feature but in detail they are
> difficult to deal with. The only solution I came up with was a non atomic access
> to data and open drain register and I don't what to block IRQ changing a single
> pin in let's say the I2C driver. So our current solution is to make the
> suspicious pin an input (preventing 10BT from being switched from half to full
> duplex).

??? I must be missing something. I wouldn't  think  such  complicated
stuff is necessary here at all.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A mouse is an elephant built by the Japanese.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/