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

Damon Hart-Davis EMAIL ADDRESS HIDDEN
Thu Sep 4 06:33:34 BST 2014


Hi,


On 3 Sep 2014, at 22:43, Richard Chilton <EMAIL ADDRESS HIDDEN> wrote:

> 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? 

Primarily

> - If they are for programming only, do they even need to be part of the shield interface?

I’m trying to minimise connectors, space, etc.

> - If they are for expansion too, do they need a slave select in the mix otherwise it only supports one slave?

Good point, well made.  What I don’t think I can do is dedicate extra lines for that; this is only meant to be about exposing existing lines.  But maybe I need to think a little harder on that...


> How do you see the I2C bus being used by these shields? 
> - Simple i2c slaves which provide a classic config and current values?

Simple, at least for now.

> - Something else much more elaborate and i2c master-y?
> - Are we only talking sensors, or is there a whole control/output side to this?

Sensors primarily,  Possibly some I/O expansion.  Anything else is a bonus.

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

Correct.

> 
> 
> 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?

Another good point, thanks!

> Hopefully they all make sense, thanks for being patient!
> 
> -- Rich.

Really good questions, thanks.

I should possibly bring a couple of GPIOs to extra pins that can be INTs and/or CS for SPI, probably pulled high with weak pull-ups (ie active low).

Rgds

Damon







More information about the OpenTRV-dev mailing list