#did you try I2C at 400 kHz?
lethal river
That shaved off a few microseconds, but the i2c traffic isn't starting until after the reset has been released by the other chip:
desert atlas
Did you try manipulating the pin in board.c? That's ok, right, because this is for a particular board?
I don't know where the time is going, but you could flip some pins at various points in main() and see where the time is being spent.
lethal river
To do something in board.c I would have to know how to send bytes over i2c as minimally as possible. I suppose I could look at the pico's common_hal_busio_i2c_write etc.
desert atlas
To do something in `board.c` I would have to know how to send bytes over i2c as ...
you could use the common-hal routines and use an I2C object that is on the stack.
but maybe just do some instrumentation of main.c to see if we've missed any deliberate delays. I forget if there's a delay for brown-out detection waiting, for instance
probably not for RP2040. Also could change PICO_XOSC_STARTUP_DELAY_MULTIPLIER, but I'm not sure that wait time is significant
lethal river
I'll have to timebox any further investigation since this is but one thing on one of my plates. worst case scenario I just tested that my drivers work just find using the blinka shim for micropython. that said I'm partial to CP
desert atlas
Try PICO_XOSC_STARTUP_DELAY_MULTIPLIER=32 or 16. That is an easy change.
but I think the difference might be like a msec
or maybe much longer
sly void
boards/lilygo_twatch_s3/board.c is an example of a board that does i2c stuff in board_init.