IoT I2C, Ft4232H Write-Read transaction with only new start condition, no restart condition

[SifuSteve]

In using the IoT libraries for I2C communication via FT4232H device to I2C slave devices, we have found that an additional I2C Write-Read command would help access more devices on the bus.

When using the TI USB to GPIO dongle, we are able to successfully access I2C devices with a Write-Read sequence. (Allows multi byte read) There are only repeated start conditions, no stop conditions until the end of the I2C transaction.

However, when we use the IoT Ft232H (FT4232h support included) we find the only command close to this Write-Read function issues a stop command and ends the I2C transaction. (During "restart" portion) This does not allow for proper I2C communication with this device, and others.

Please review and consider a new function or possibly a work around.

Cheers,

Steve

[SifuSteve]

To update, I have managed to clone the IoT repository and review the code. I do see a potential to modify the code (locally) and get it to work as I have suggested. However I a new to working with repos, and compiling them locally with modifications. (I'm a hardware guy)

Any pointers are greatly appreciated.

[pgrawehr]

@SifuSteve We're trying to help. Building the repo locally is easy, just run build.cmd in the repository root folder. After that, you can open the individual solutions to make any changes. Unfortunately, I don't fully understand what problem you're trying to solve. What kind of devices are those that don't work with the current implementation? Or is it just more difficult or slower to get them to work?

[SifuSteve]

@pgrawehr Thanks for the reply and offer to help.
The issue I am finding is that with devices like Si5361 or TPSM831D31 , if during a Write-Read transaction the device receives a "stop" condition, the devices will consider the I2C transaction complete and stop the communication.

This is why I receive all 0xFF while using the IoT code.

The devices, after the write command, expect another start command to continue and properly process the I2C transaction and provide the requested information These differences in I2C transactions, good vs. bad, were attempted to be shown in the scope photos I provided. The older, going obsolete HW dongle by TI shows the correct I2C transaction while the IoT shows the incorrect transaction for these devices.

With regards to building the IoT repo locally. I tried running the build.cmd but ran into a "NETSDK1004: Assets file not found" issue I am tracking down now. Edit Running from the cmd line appears to be working. Not sure what or where I ran the build.cmd from before.

Cheers,

Steve

[pgrawehr]

Ok, understood. @Ellerbach is our expert on FTXXX devices, so he might have an idea on whether the low-level driver even allows configuring the device in a way to make that work.

[SifuSteve]

@pgrawehr Thanks. From what I've seen in the IoT code, and seeing the FT4232H device perform this type of transaction with pyFTDI, I think it should be doable.

Since I have downloaded the git IoT source, and am able to compile it now, I will work on making a local copy and see if I can get it working.

Cheers,

Steve

[SifuSteve]

All,
I've tried to manipulate the code in order to get the functionality requested.
Unfortunately my lack of SW skill prevents me from compiling the code correctly, as I do not know how to properly add the additional subroutines to the current code and compile cleanly.

I have a rudimentary understanding and use of objects, but the level of this project is not in my area of expertise.

Again, I have high confidence the new I2C transaction will work and be beneficial. If anyone has suggestions to help move forward, I would help in anyway I can.

Cheers,

Steve

[Ellerbach]

It's indeed possible to adjust a lot of things. The original implementation follows the recommendations from FT and worked with quite some devices. If it does not with some others and a change needs to be dore: go for it.

Now, @SifuSteve to help you here with bringing your changes, here are couple of steps for you to follow, and please ask for help if needed:

• Fork the repository to your own github
• Clone your forked repository
• Important: create a branch (use Visual Studio or VS Code or even command line like git checkout -b branch-fix-ft-i2c)
• Make your changes in your code on this new branch
• One you've done the changed, run from a command line prompt on the root of the cloned repository: build.cmd This does allow to check that all is good, if you have code not inline with the expectation (style or naming) it will fal and tell you where.
• Commit and push the changes once done in your cloned repository
• You can then open a PR from your github forked repo. It will be proposed automatically, follow the steps

Then we will review. We may give you comments. And, if any change needed, you'll just make your changes on your branch, commit and push them on your branch. They will magically appear in the PR! And if further assistance needed, we can always, as maintainer clone your changes and push some changes as well for a better collaboration.

We're always happy to help especially for the first PR. It can be intimidating. We're patient :-) Now worry, e'll help you!

And one more time: THANK YOU for investigating, finding the problem and willing to contribute back for the large comunity.

[krwq]

[Triage] @SifuSteve can you point us to your version of the code? (regardless if it works or not) We can help you make a PR. Can you also point us to the python code you got working?

[SifuSteve]

@krwq , thanks for the reply. I will point you to what I see in the current IOT code that could be enhanced to support more I2C devices. I will refer you to a working example I forked and modified from the FTDISharp repository.

From what I see, the "WriteRead" function in "FT232HI2cDevice.cs"
calls the "write", then "read" functions in "FT232HI2cBus.cs" which issues a "stop" command after the initial "write" command.

This is fine for some I2C devices, but other I2C devices do not respond well to a "stop" condition and will not send any data of the subsequent "read" call. Some I2C devices expect another "start" command and not a "stop" command.

The enhanced feature would be to issue another "start" command, and save the "stop" command for after the read process is finished.

As an example of the enhanced I2C call, I am successfully using a modified version of the FTDISharp code for this "Write/Read" function. I2C.cs
Here you will see that after the initial "Write" command another "Start" command is issued and the "Stop" command is not issued until the very end of the "Read" transaction is completed.

Like I mentioned in a previous post, I am a hardware engineer and the level of IOT code is a little beyond my comprehension. The level of obfuscation in the MS IOT code is confusing for me. In contrast, the FTDISharp code is easier for me to understand and I was able to use it, and modify it to support FT2232H/FT4232H devices and fix a read bug.

I am open to continue the dialogue here, but I don't want to waste your time in possibly teaching me how to navigate the MS IOT code to make the change and release a PR.

Cheers,

Steve