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

Richard Chilton EMAIL ADDRESS HIDDEN
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
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 




More information about the OpenTRV-dev mailing list