replace i2c bus with bus for long twisted pairs

[jvoigts]

we currently spec an i2c bus on the daughter board connector, on a twisted pair. This is not ideal becuase of the TP. While i2c should work, maybe switching to something like rs-485 would be cleaner.

there seem to be solutions for this such as http://www.nxp.com/documents/application_note/AN11075.pdf

[jvoigts]

alternatively, a good i2c driver could mitigate the problem a bit - but it would still leave single ended signals on the cable.

http://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/i2c-bus-portfolio/i2c-bus-repeaters-hubs-extenders/i2c-bus-extender:P82B715

[jonnew]

There are also chips that can be used to convert spi to rs485 and include a complete UART, which is nice for ensuring data parity and handling communication buffering etc

https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX3140.html

[jonnew]

I think I like the solution in the first doc you posted though. Simple and effective.

[jvoigts]

The AN11075 requires two TPs though.

The MAX3140 in half-duplex rs485 looks like it'll work. We would break compatibility with reid's system though, wouldnt we?

[jonnew]

• Reid is not using i2c pins as far as I know, so not really.
• Half duplex is fine with me.
• Some potential issues with the MAX3140
  • Not to cheap: https://octopart.com/search?q=MAX3140
  • Maybe a strange part that we don't want to make integral to both the main board and all breakout boards?
  • There seem to several other cheaper, natively i2c capable, UARTs

http://www.digikey.com/product-search/en/integrated-circuits-ics/interface-controllers/2556697?k=&pkeyword=&pv154=67&pv154=301&FV=fff40027%2Cfff80319%2C9080021%2C908003a&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25

http://www.nxp.com/documents/data_sheet/SC16IS740_750_760.pdf

[aacuevas]

The method described in the AN11075 does indeed need another twisted pair from the vhdci connector, so we'd need to modify the pinout. It is, however, simple, efficient, can be done with different parts (no need for a specific IC, just any i2c buffer) and can be even made compatible with a single-ended i2c device.

Unless I've missed something, any solution including one of the many UARTs you've posted require a master controller on both sides. So the breakout board would need at the very least a small uC to read from them and perform the needed actions (reading from the config eeprom and sending the data back through the serial interface, for example), we couldn't simply "plug a memory and let the FPGA read it".

[jonnew]

Yes, I think you are correct about the required uC. This is because these guys can only be in the slave configuration. I have not found anything that will just kind of "loop back" the i2c words it receives, unfortunately. We could put a little uC there, but this causes ever more complexity. We might want it though for other things. e.g. if we have the uC, the breakout boards can be made more dynamic via their serial line...things like switching in/out termination resistors for instance. Pretty complicating though...

[jonnew]

Also, we need to contact Reid and see what he actually needs to preserve. I don't want to be bound by things that are not even required. We may just be able to use to pairs for i2c comms.

[aacuevas]

Yeah, let's ask Reid about his current implementation. Having a small uC can be useful in some boards but is a bit of an overhead on others while a simple eeprom is a very simple and lightweight solution (and nothing prevents a board from having uC with a slave interface in another address).

Also, I've been checking and most, if not all, i2c eeproms actually have the same address bits (which was a concern), so it makes things even easier.

[jvoigts]

Yea i agree that requiring a uC is not great. Would the AN11075 lock us into using this specific chip? If so i think that would be a deal breaker, simply because this is the one place where we require all daughter boards to behave the same way.

Have we ruled out CAN bus yet? Havent seen a lot of eeproms for that though.

It still seems to me that vanilla i2c might be not that bad - our spec specifically allows the use of this bus only for reading one id from an eeprom at/before startup, so we a) can run it at ridiculously low speeds if thats needed and b) we can totally shut these lines down once the device is powered up, so there is no real crosstalk concern. The big upside would be that we'd have so many potions for what eeprom chip to use, and the daughter board design becomes simpler.

[jonnew]

Has anyone contacted Reid to see if we can just allocate more lines for this purpose and do single ended communication correctly (with ground wire pairs)

It still seems to me that vanilla i2c might be not that bad

Design for the corners and the middle will take care of itself.