Announcement

Collapse
No announcement yet.

Feature request: notification on I2c write completion

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Feature request: notification on I2c write completion

    When writing the semantic layer for an I2c device, it's often the case that after writing certain device registers, one has to delay a certain amount of time to allow the device to process the action before interacting further with the device. For example, with the Bosch BNO055 IMU, when changing operational modes, one must wait 19ms if one changed into config mode or 7ms otherwise.

    However, the current FTC I2c infrastructure provides no way of being notified when a write is complete. Absent this, we must guess as to the interval from queuing our write to it's actual issuence, and must do so pessimistically and thus suboptimally.

    The CDIM and the Legacy Module controllers do get such a callback, but they ignore it and don't do anything with it. It would be nice if that were passed on to the I2cDevice layer.

  • #2
    Hey FTC0417,

    Have you looked at I2cDevice.registerForI2cPortReadyCallback(...)? I think that is the method you are looking for.

    With this callback, last to register wins. But there should only be one device that needs to be notified about a given port at any one time. Any built-in drivers will register before the first op mode runs, so you won't have to worry about them taking over the callback.

    Comment


    • #3
      Jonathan, you are, of course, absolutely correct; I apologize for the lapse in cognition :-).

      Comment


      • #4
        Followup: am I correct in understanding that the portIsReady() callback can be used to determine that the write (if we're writing) has made it to the Core Device Interface Module but that it's not necessarily the case that the actual I2C write has yet been issued when the callback is received? I'm trying to explain symptoms I'm seeing, and this could be one cause (though there are others).

        Comment


        • #5
          Originally posted by FTC0417 View Post
          Followup: am I correct in understanding that the portIsReady() callback can be used to determine that the write (if we're writing) has made it to the Core Device Interface Module but that it's not necessarily the case that the actual I2C write has yet been issued when the callback is received? I'm trying to explain symptoms I'm seeing, and this could be one cause (though there are others).
          The callback is called when the port ready flag of the module is cleared
          for a particular port indicating that the last i2c transaction written to
          the module's port buffer has completed.

          Note that for legacy module connected servo/motor controllers the
          controller class itself registers for the port ready callback. This isn't
          an issue for the original poster, but just thought should be mentioned.
          This may be the case for other legacy module devices that have class
          implementations provided by the SDK also, but I have spent to time
          looking at that.

          Comment


          • #6
            Originally posted by skatefriday View Post
            The callback is called when the port ready flag of the module is cleared
            for a particular port indicating that the last i2c transaction written to
            the module's port buffer has completed.
            That makes good sense from a design perspective for the CDIM (that is, "if action flag is set then don't indicate port is ready until I2C write action has been completed") but I'm not sure it's consistent with what I'm observing (though as I say, there are perhaps other causes).

            One way of verifying this would be to hook up both USB and I2C sniffers and watch the traffic and the relative timings. Has anyone done this?

            Comment

            Working...
            X