Advanced Topic: Writing an I2C Driver

[Tom Eng]

Hi Folks,

We have a new addition to the online documentation. It is a tutorial that demonstrates how to write an I2C Driver to integrate a 3rd party I2C device (like a sensor) with the FTC software development kit.

This is an ADVANCED topic which requires understanding of advanced programming issues. You can find the tutorial at the following link:

https://github.com/ftctechnh/ftc_app...-an-I2C-Driver

Tom

[GearTicks]

Thank you very much for the post on the Wiki. Our team has always used its own driver framework based on I2cDevice, so now that that is no longer possible with the REV module, it is very helpful to have instructions for how to do it with the synchronous framework.

One thing I was wondering was whether it was possible (and if so, how) to disable the background reading. It looks like the poll read is initialized as soon as the sensor object is constructed, which will happen as long as it is in the configuration file. We often have several I2C devices on our robot but we rarely use more than one at once. For example, last year we had a BNO055 IMU and a TCS34725 color sensor. In our framework, neither would start reading until we asked them to. Since we didn't use either in tele-op, we could use the same config file for tele-op and autonomous and just never reference them in tele-op. And in autonomous, we only used our color sensor while driving along the wall and looking for the white tape. In order to improve the heading update rate, we would turn on the poll read on the color sensor right before driving along the wall and turn it off right after.

Some thoughts about the wiki page:

• The instructions reference the value ADDRESS_I2C_DEFAULT but never declare it. I think it would be helpful to show that it is I2cAddr.create7bit(0b11000), rather than forcing readers to check out the example to see how it is defined.
• Why the insistence on hexadecimal instead of binary in the code? Java 1.7 allows the 0b indicator for binary numbers. I think it would be easier for a beginner to understand how to write a driver if they could just use the binary numbers given by the datasheet. Also, when writing bitmasks, it is much easier to understand what bits are set when they are written in binary rather than hexadecimal. And similarly, when verifying that the manufacturer ID gives the correct values, why not use Integer.toHexString(tempSensor.getManufacturerIDRa w()) instead of tempSensor.getManufacturerIDRaw() since you are comparing it to a hexadecimal value from the datasheet?
• The instructions say "Now in the robot configuration menu, we can see that the sensor has been added to the list of I2C devices" but the picture shown does not list the new device
• There are several places where the instructions compare different binary values, which I think are intended to be stacked on top of each other, but they appear next to each other because there is only one newline separating them in the markdown.
• The code never reads from register 0, DEVICE_ID_REVISION, or RESOLUTION, so FIRST could instead by set to CONFIGURATION and LAST to MANUFACTURER_ID to minimize the number of registers being read from
• I am aware that Register.LAST.bVal - Register.FIRST.bVal + 1 gives the length of the read window, but this is never explained to the reader. I think this is non-obvious to someone who has never written an FTC I2C driver.
• An easier (and more readable) way to sign-extend the 13-bit value is to write dataRaw << 3 >> 3. (The left-shift removes dependence on the 3 alert bits and the signed right-shift will copy the sign bit to the leading 3 bits.)
• Bitflags can be written more clearly as, e.g. 1 << 13 instead of 0x2000. This way only requires one to count the bit position of the desired flag from the datasheet, rather than necessitating a conversion to hexadecimal. Likewise, 0xFFEF is ~(1 << 4).
• Rather than write flag checks as (value & flagMask) == flagMask, it's shorter to just write (value & flagMask) != 0.
• Why use final in the definition of writeShort()? I'm all for using final wherever possible but this is the only place it is used in the guide. It's probably best to be consistent.
• Aren't teams being encouraged to omit the throws InterruptedException on runOpMode()?

On an unrelated note, why did FIRST decide not to make the Wiki a wiki? The whole idea of a "wiki" is to allow community contributions. Since FIRST does not seem to have a ton of time to devote to writing Wiki articles, why not allow for the community to suggest edits or write new pages?

[4634 Programmer]

One thing I was wondering was whether it was possible (and if so, how) to disable the background reading. It looks like the poll read is initialized as soon as the sensor object is constructed, which will happen as long as it is in the configuration file. We often have several I2C devices on our robot but we rarely use more than one at once. For example, last year we had a BNO055 IMU and a TCS34725 color sensor. In our framework, neither would start reading until we asked them to. Since we didn't use either in tele-op, we could use the same config file for tele-op and autonomous and just never reference them in tele-op. And in autonomous, we only used our color sensor while driving along the wall and looking for the white tape. In order to improve the heading update rate, we would turn on the poll read on the color sensor right before driving along the wall and turn it off right after.

The REV hubs have four separate buses, so there shouldn't be a need to disable polling. (And if you're using 2 hubs you have 8 separate buses)

[GearTicks]

The REV hubs have four separate buses, so there shouldn't be a need to disable polling. (And if you're using 2 hubs you have 8 separate buses)

But doesn't it still take longer to execute USB transactions each loop cycle if you are poll-reading more sensors?

[Philbot]

But doesn't it still take longer to execute USB transactions each loop cycle if you are poll-reading more sensors?

It depends what hardware you are using.

If you are using the new REV Expansion Hub, the SDK does not read the I2C devices in the background (consuming time).
It does read any I2C Device (configured as part of the current Robot Configuration) ONCE on loading the configuration, but after that, it only reads it when your opmode tries to access it's data.

So, if you have two color sensors (each on different ports so you don't need to change addresses) you can just stop reading them when you don't need color information.
This will eliminate any extra overhead for them.

However, this is not the case on Modern Robotics Hardware. Configured I2C devices still slow down the loop cycle even if you don't read them.
I'm not completely sure why this is, but the good news is that overall, I2C operations have been sped up, so you may want to go back an re-evaluate the throughput on any MR sensors to see if it's still an issue for you.

Phil.

[Tom Eng]

On an unrelated note, why did FIRST decide not to make the Wiki a wiki? The whole idea of a "wiki" is to allow community contributions. Since FIRST does not seem to have a ton of time to devote to writing Wiki articles, why not allow for the community to suggest edits or write new pages?

Hi GearTicks,

Unfortunately, I believe that if FIRST wanted the community to write new pages, we would have to grant write access to the repo. If you do have suggested edits or would like to generate new pages, feel free to create a post on this forum with suggestions and/or PM me with your suggestions.

Have a great season and thanks so much for your participation in and contributions to this forum!!!

Tom