Replies: 1 comment
-
Your understanding is correct, this is something we had to fix during multiranger development. The solution was a little bit creative: since there is no implemented way to guarantee that one deck will be initialized before another, I used the only guarantee I had in the current system. I initialized the multiranger sensors in |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am working on designing a set of top & bottom decks that implement similar functionality to the flowdeck and multiranger (plus some additional features), and I'm trying to understand the initialization process when both of these decks are present.
Looking at the hardware and firmware, it seems that the multiranger has the ability to disable its VL53L1X's by way of the PCA9534 IO expander. The flowdeck, however, has its VL53L1X permanently enabled. Since all of the sensors are on the same I2C bus, this implies that the flowdeck must be initialized first to prevent an address conflict.
Is this a correct assessment? My understanding from the multiranger driver is that the sensors are enabled and programmed with an address one at a time, then left enabled. If this happens before the flowdeck is initialized, it seems the flowdeck's VL53L1X would be programmed with the same I2C address as the first multiranger sensor.
I can't find any explicit mechanism in the code to enforce this order, but the flowdeck is listed before the multiranger in
src/deck/drivers/src/Kbuild
, which I think means its driver struct ends up earlier in the deckDrivers section and would be initialized first.I just want to make sure I understand this correctly, and that there's not some other dependency enforcement mechanism that I'm overlooking.
Thanks,
Philip
Beta Was this translation helpful? Give feedback.
All reactions