[Libre-soc-bugs] [Bug 746] I2C needs an Open Drain IO Pad

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=746

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Staf Verhaegen from comment #7)

> This should not be needed, your I2C master should already make sure oe=0
> when wanting 1 on output and oe=1 + o=0 when wanting 0 on output.

this is for an I2C master.

in STM32F Embedded Controllers, for convenience, it is the PHY that
[automatically] does this OE/O trick for you, and to do so the pinmux
GPIO settings must put the Pad into this "Open Drain" config mode.

(the ability to set an OD Mode has been standard practice for the entire
STM32F range since its inception)

if bit-banging as a software-controlled pad, then yes absolutely
it is perfectly fine to do - under software control - "rewrite
GPIO to OE and switch O".

...HOWEVER...

if there are separate CSR memory-mapped registers for OE as separate
and distinct from O

OR

if, internally, the CSRs are split (wishbone bus 32-bit to 8-bit)
internally such that OE is set on one clock cycle and O is set on
another

then you have a problem: glitching of the output.

so, software bit-banging control to emulate I2C has two problems:

1) it's bit-banging.  it takes up CPU cycles and requires great care
   in the design of the bit-banging.
2) very careful design of the GPIO CSR Banks is required

compared to adding an Open Drain Mode in the GPIO CSR Bank, which
is what all STM32F Series ECs do, the problems go away, both at
the hardware level and the software level (even if bit-banging
is used).

(In reply to Staf Verhaegen from comment #8)
> > This should not be needed, your I2C master should already make sure oe=0
> > when wanting 1 on output and oe=1 + o=0 when wanting 0 on output.
> 
> What I have seen is an I2C controller that puts always 0 on o and then
> control the output by only enabling or disabling oe.

interesting! yes that would work.  and would avoid output glitching
in software-level bit-banging.

Open Collector would be "always put a 1 on o".

anyway: the main point of this bugreport was: "is any change needed
to FlexLib IOPad Cell" and the answer is definitely "no".  so i am
closing this bugreport as resolved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.