[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