I2C Address Search macro - how to stop when no device found?

[kokoshell]

Hi Jan, when playing with I2C addr/device bus search noticed that there is no way to stop the macro and return to prompt (Ctrl+C would be great to have ) other than …unplug the board from USB !

[ian]

Thanks! I pushed a fix and it will be in the auto compile.

What’s odd is that it worked before… It was simply that I did a uint8_t i < 256 so it was stuck in a loop. It worked perfectly earlier though which always concerns me…

Thanks again! That was a silly bug.

note: the auto build has the second AMUX switching speed fix, not the first.

[ian]

The link:

Bus Pirate 5 auto build: main branch

Here’s a fresh compile: ci-buspirate5-main-f8b8705.zip Build time: 16.99 seconds Git pull log @f8b8705: Updating ae64b9c…f8b8705 Fast-forward amux.c | 5 ++±- mode/hwi2c.c | 6 ++±– syntax.c | 12 +++++++±— 3 files changed, 14 insertions(+), 9 deletions(-)

[kokoshell]

Nope the infamous glitch is still here in this one f8b8705 …

[ian]

Thanks, sorry about that, just a second.

[ian]

There’s a new auto build, but it does not completely solve the issue. If I2C are pins 0 and 1, then if you drop IO2 low a 2 the glitch will show up again on IO1 (SCL) but not SDA.

The 4067 is break before make, so it shouldn’t be bleed through between channels. I need to spend some time with the datasheet to see what the input capacitance of the 4067 is, and recheck the switching speed.

[kokoshell]

I2C seach macro seems to be working fine for now. However I see some unnecessary toggling of SCL/SDA lines in between I2C packets … is this intended or side effect ? SCL and SDA should be released after each packet right ?

[ian]

The I2C PIO program has a hard time recovering from error states, so I do multiple stop conditions to get it unstuck. It does the same thing for any bus error conditions.