The code defining the default I2C pins is actually behind another layer (Behind PiicoDev Unified) and relies on the defaults being used in the machine.i2c libraries baked into the firmware already on the chip (the pins are different for other dev boards like the ESP32).
To configure a second bus you would have to feed through different I2C objects(Unified takes care of all of this for you). On the backend, this process starts in between lines 41-62 on the Pico.
To create your second string of devices it’s as easy as feeding different arguments through at initialisation (Here’s on taken from the BME280’s Git repo)
When learning a new topic, especially in the early stages, there can be a problem with picking the right search terms, and then understanding what one finds… often very “hit and miss” with many rabbit holes!
So the Core Forum gives excellent support, at a level that helps new users, and is amazingly responsive – from both the Core Team and key users.
Thank you everyone!
[A forum that actually supports its customers is amazing – it is unfortunate many other suppliers don’t feel this to be important, often never replying to a query]
Yeah this forum is quite good. It’s definitely a lot more than just a place for people to get their problems solved. There’s a real community vibe to it with everyone helping each other out and sharing projects they’re working on.
When investigating a Micropython driver for the SparkFun Honeywell Micro-Pressure sensor with @James46717Here
I did find an i2c bus sniffer using a Pi-Pico on GitHub Here that helped in getting working code.
As well as being an interesting project that dives into the Pico PIO state machines to run fast enough to capture the i2c bus traffic, one can also download a .uf2 file so it is easy to try if anyone is interested.