Spent some more time with i2c timings (before realising the issue we were chasing was memory related) & created some refined timings that are more resilient to widely varying pullup networks.
the standard timings (loaded on boot) work well at ~90kHz with only a crow on the bus w/ weak pullups & a just friends module with about 18" of bus cabling. the speeds dynamically speed up when a 'normal' amount of pullup current is applied (black pcb TT used in testing) up to about 150kHz. that bus is resilient with about 36" of cabling & shows no signs of slowing down even with the larger capacitance.
there is also a 'fast mode' as described in the v4.0 firmware which speeds up to around 350kHz when there's enough pullup current. this should not be needed (it's barely a 2x speedup of raw comm's and the slow part of i2c is the signal generation/consumption, not transfer speeds). left in for some weird edge case.
ii.fastmode(true) will give fast rates.
lastly, you can directly set the timing register in the i2c driver by passing fastmode a 32b hex value which represents the timings you want (eg. ii.fastmode(0xA0420B07)) which allows for experimentation, though this is mostly just a development tool and not something that needs to be documented in userspace.
switching fastmode would previously affect pullups, which is fixed here.
ii message send retry has been limited to 1 retry (would previously be unconstrained until success).
Spent some more time with i2c timings (before realising the issue we were chasing was memory related) & created some refined timings that are more resilient to widely varying pullup networks.
the standard timings (loaded on boot) work well at ~90kHz with only a crow on the bus w/ weak pullups & a just friends module with about 18" of bus cabling. the speeds dynamically speed up when a 'normal' amount of pullup current is applied (black pcb TT used in testing) up to about 150kHz. that bus is resilient with about 36" of cabling & shows no signs of slowing down even with the larger capacitance.
there is also a 'fast mode' as described in the v4.0 firmware which speeds up to around 350kHz when there's enough pullup current. this should not be needed (it's barely a 2x speedup of raw comm's and the slow part of i2c is the signal generation/consumption, not transfer speeds). left in for some weird edge case.
ii.fastmode(true)will give fast rates.lastly, you can directly set the timing register in the i2c driver by passing
fastmodea 32b hex value which represents the timings you want (eg.ii.fastmode(0xA0420B07)) which allows for experimentation, though this is mostly just a development tool and not something that needs to be documented in userspace.switching fastmode would previously affect pullups, which is fixed here.
ii message send retry has been limited to 1 retry (would previously be unconstrained until success).