I just looked at the wiring for the Thunderboard Sense 2. It is crazy….
Normally all of the I2C devices on a board are wired to a single I2C Bus. But the designers of the Thunderboard decided to connect to three different I2C busses, even though the chip only has two controllers. Hence you have ended up in the strange situation where you need to multiplex a single controller across at least 2 sets of pins. To be honest I have never seen this before, but it is what it is…
I would start out by ignoring the hall sensor, then routing I2C_1 to PC4-5, and I2C_2 to PB6-7 and get all of your software running. Then go back and think about hacking the driver so you can flip I2C_2 between PB6-7 and PB8-9. Of course if you also have external I2C sensors on other pins life is even more difficult.
A better solution than hacking the driver I would be starting a sensor task that processes a work que. The work queue would contain requests for I2C read/write from the multiplexed sensors. The sensor task would get a request, reconfigure the mux (if necessary), complete the request and return the result, then work on the next request. Effectively the serial processing nature of the sensor task becomes your mutex, without the bother of trying to modify the Zephyr kernel. Since the hall and gas sensors are pretty slow, the overhead of the sensor task will be negligible.
From: Nikolaus Huber <nikolaus.huber@...>
Sent: Monday, November 23, 2020 10:02 AM
To: Lawrence King <lawrence.king@...>
Cc: Adam Podogrocki <a.podogrocki@...>; Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c
Thank you for your reply! Indeed, after rereading the data sheet I also realised my confusion. The problem with the rerouting however persists. The chip allows to reroute the SDA and SLC signal from either I2C peripheral dynamically during runtime by changing the location bitfields in the respective I2Cn_ROUTELOC0 registers.
This means, that for example on the Thunderboard 2 Sense development board, different sensors are connected to the same I2C peripheral, but through different pins. So I need to change the ROUTELOC0 register every time before issuing a call to Zephyr’s i2c driver. I was just curious if that is something common, that I’m unaware of, and if there would be a general (i.e. Zephyr idiomatic) way of doing that. I have read through the i2c driver implementation for the Gecko chip family now, and it seems, that that is not really taken care of. So I guess one could do this either within the application code, or do it in the respective sensor driver. Ultimately, I guess it would be nice to change the i2c driver implementation to take care of this, since there probably needs to be some form of mutex between rerouting the i2c peripheral, issuing the call, and routing it back to where it was before, and that mutex is per peripheral.
Thank you all very much for your replies! They really helped.