Require a Device Address in the I2C Bus Configuration Menu

[AlecHub]

For validation purposes, greater clarity, and to simplify programming, you should be required to specify the I2C addresses of the devices on a I2C Bus in the I2C Bus Configuration Menu as follows:

The @DeviceProperties annotation of the I2cDeviceSynchDevice<> driver implementation could specify the properties of the device's I2C address [FIXED, FINITE_SET, FINITE_RANGE], type of address [7-bit, 8-bit, 10-bit], and a default.

When adding a device in the I2C Bus Configuration Menu, the Address of the device can be populated with a default non-conflicting address (or error if non-conflicting addresses have been exhausted on the bus). The driver implementation could provide a method that verifies the existence of the device (reads or writes a register on the device).

You shouldn't have to hardcode I2C addresses in your OpModes. I2C addresses should be required to be entered in the I2C Bus Configuration Menu where devices and addresses can be validated at configure-robot time, and addresses can be changed without having to re-build the RC App.

I am a novice when it comes to I2C devices. Am I missing something?

[NoahAndrews]

Thanks for the suggestion. You did an excellent job providing a visual and technical summary of your idea.

However, extremely few I2C devices have the ability to set an arbitrary address. By far the most common case is that you have two address choices, and you pick between them by pulling a pin either to high or to ground, which is not applicable to most sensors FTC teams are using.

As a reminder, every I2C port on Control Hubs and Expansion Hubs has its own dedicated I2C bus, so you don't have to worry about I2C address conflicts. I notice in the screenshot that you have all Modern Robotics sensors. Those are the only sensors I can recall seeing that allow you to set arbitrary I2C addresses, so I can understand why this feature would be valuable to you. Changeable I2C addresses were only necessary for the old Modern Robotics CDIM, which is no longer supported.

This use-case seems to only benefit teams who have heavily invested in the legacy MR sensor ecosystem and have made a custom wiring harness to allow multiple sensors to be on the same I2C bus. For the amount of effort, complexity, and testing needed, this is an unlikely feature to be added. However, we do appreciate the suggestion.

[AlecHub]

Thanks for the suggestion. You did an excellent job providing a visual and technical summary of your idea.

However, extremely few I2C devices have the ability to set an arbitrary address. By far the most common case is that you have two address choices, and you pick between them by pulling a pin either to high or to ground, which is not applicable to most sensors FTC teams are using.

As a reminder, every I2C port on Control Hubs and Expansion Hubs has its own dedicated I2C bus, so you don't have to worry about I2C address conflicts. I notice in the screenshot that you have all Modern Robotics sensors. Those are the only sensors I can recall seeing that allow you to set arbitrary I2C addresses, so I can understand why this feature would be valuable to you. Changeable I2C addresses were only necessary for the old Modern Robotics CDIM, which is no longer supported.

This use-case seems to only benefit teams who have heavily invested in the legacy MR sensor ecosystem and have made a custom wiring harness to allow multiple sensors to be on the same I2C bus. For the amount of effort, complexity, and testing needed, this is an unlikely feature to be added. However, we do appreciate the suggestion.

It is very nice to have 8 I2C busses on a bot. This season many teams will only have 4 I2C busses on their bot during competition due to the worldwide shortage of Expansion Hubs. Still, 4 busses are nicer than the maximum 2 busses that were allowed in the Modern Robotics iteration of the control system. Still, 2 busses are nicer than the maximum 1 bus allowed in many many real world situations.

Nicer things are often a mixed blessing. If all your I2C devices are on their own dedicated I2C bus then students haven't learned the essentials of I2C. If students haven't learned the essentials of I2C after spending 10 years in FIRST robotics programs, then that would be damaging to FIRST's brand.

Therefore, I highly recommend that teams put all their I2C devices on the same I2C bus, starting with Bus 0 where the imu lives. Use Bus 1, 2, 3[,4,5,6,7] only if necessary for performance, address conflicts, or cable management.

Likewise, educational value is the motivation behind the architectural changes I am suggesting for the next design iteration of the SDK. We feel the suggested changes bring substantive educational value to teams.