[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