[OpenTRV-dev] I2CEXT connector first pass: comments please.

Wed Sep 3 22:43:54 BST 2014

I'm sure you've been living and breathing this interface design, so please excuse my back to basics questions below - I'm just getting to speed with it all and trying to understand the use-cases for this interface.

Are the top 6 pins for in-circuit programming only? 
 - If they are for programming only, do they even need to be part of the shield interface?
 - If they are for expansion too, do they need a slave select in the mix otherwise it only supports one slave?

How do you see the I2C bus being used by these shields? 
 - Simple i2c slaves which provide a classic config and current values?
 - Something else much more elaborate and i2c master-y?
 - Are we only talking sensors, or is there a whole control/output side to this?

What is the primary comms to a RPi likely to be in these scenarios?
 - Probably Rx/Tx, I guess? 

Do you need an explicit interrupt (or wake-up) line on interface, so sensors can demand attention and/or bring the master out of sleep?

Hopefully they all make sense, thanks for being patient!

-- Rich.

On 3 Sep 2014, at 20:30, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:

> On 3 Sep 2014, at 19:16, gareth <EMAIL ADDRESS HIDDEN> wrote:
>>> From my experience i2c doesn't travel well - and grey beards have advised me that off board i2c wires are an excellent way to broadcast emc!
> OK, thanks for that.
> I think that our I2C runs like treacle because of the low CPU clock speed (1MHz) that is in use,  but I could still suggest keeping I2C traces as short as possible for example, and stacking boards no more than a couple deep maybe.
> Rgds
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> http://lists.opentrv.org.uk/listinfo/opentrv-dev

More information about the OpenTRV-dev mailing list