Added TCA9548A device binding

[asheesh1996]

Added support for TCA9548A multiplexer

Microsoft Reviewers: Open in CodeFlow

[dnfadmin]

All CLA requirements met.

[pgrawehr]

Thanks for the addition!

I have some minor comments and a suggestion.

[pgrawehr]

That was a good idea, but unfortunately, it fails in some use cases we have to consider.

Please ping me if you want me to make a suggestion to fix it. Of course, you can try yourself first.

[Ellerbach]

Thanks, nice addition, few comments

[krwq]

Really nice device. I think we can further improve usability though. See my comment above

[krwq]

We're heading in the good direction - this is pretty close now.

• I2cDevice implementation looks good, I'd recommend to make this class internal though (unless it offers anything extra on top of I2cDevice)
• Tca9548A - CreateI2cDevice implementation looks good (arguably int might be easier to use rather than Channel)
• Tca9548A - I'll recomend to also create CreateI2cBus method - I2cBus would only call to Tca9548A internal methods but nothing special other than that
• Tca9548A - you might want to make everything but CreateI2cBus and CreateI2cDevice and basic functionality internal
• you might also want to add slight improvement to not switch channel if it's already on the right one to avoid unnecesarilly writing to parent I2cDevice

Note that once this implementation provides I2cBus/I2cDevice we will be able to combine muxes together - that's the biggest benefit of doing this work.

[pgrawehr]

One question: Are there similar devices available that would use the same binding (Eg is there a TCA9548b)?

Because if so, the namespace should be more generic. (I'm not asking to implement those devices now, it's just about considering future extensions)

[pgrawehr]

If I read https://www.ti.com/interface/i2c/switches-and-multiplexers/products.html?keyMatch=TCA9548 correctly, there are other, very similar devices with 2 or 4 channels. The naming is [P|T]CA954x. So at least the last digit of the namespace should be changed to x. Not sure about what to do with the lead character, as it can be P or T.

[krwq]

@pgrawehr pick one, we should put all possible names in the README.md in the title so it's easier to find

[pgrawehr]

I have updated the project name and the namespace to TCA954x, since there are several similar chips available. No functional changes otherwise, therefore to actually support e.g. TCA9544A, additional changes (and probably an additional derived type) will be necessary.

[pgrawehr]

@asheesh1996 I cleaned up the documentation and the API slightly, but hopefully I have not changed the behavior (I have no way of testing). There were several methods that exposed the same functionality twice (e.g. the SwitchTCA9548AState method was removed, because the same can be achieved by calling SelectChannel with an empty set). Unless you have some objections, I think this is ready to merge now.

[Ellerbach]

Outside of this PR: @pgrawehr and @krwq we should discuss the I2cDevice disposal in bindings. Originally, we said we won't dispose them. because they have not being created in the binding. Now, there are quite some binding disposing them.
We have something similar for GpioController with a shouldDispose pattern. So maybe to be clear as well, like here but with a _shouldDispoeI2c, we may bring a bit of clarity.

[pgrawehr]

Yea, good point. I think, most of the time this is just confusing for the user.

[Ellerbach]

Few remarks, otherwise, all good for me.

[asheesh1996]

No issues, thanks for refactoring the code base :)

[pgrawehr]

@asheesh1996 Thanks again for this contribution!