1
Discussion - Software / Re: FT4222 I2C - recovering from read/write errors.
« on: August 03, 2023, 02:57:38 PM »
I posted another topic specifically about detecting FT_SetTimeouts() timeouts in a write/read, but wanted to update this one.
On the system I am working with, I have seen it successfully write/read over 41 million messages (7-112 bytes in length) with zero errors. It's field proven and works well. When we introduced some RF (or possibly power line noise, unclear), the whole communications layer will start having problems. Often, when one of these READ errors is seen, the comms are done until the program is restarted. I am testing just Closing and Re-opening the FTDI connection to see if that is enough. BUT, if a slave device got stuck while clock stretching, I suppose that wouldn't help. FTDI did add a "bus reset" function in one of the recent DLL versions and this sends the clock pulses to try to un-stick a slave, so I have put that in to.
I hope there is a best practices list somewhere rather than "throw stuff at the wall and see if it sticks" like I am doing.
On the system I am working with, I have seen it successfully write/read over 41 million messages (7-112 bytes in length) with zero errors. It's field proven and works well. When we introduced some RF (or possibly power line noise, unclear), the whole communications layer will start having problems. Often, when one of these READ errors is seen, the comms are done until the program is restarted. I am testing just Closing and Re-opening the FTDI connection to see if that is enough. BUT, if a slave device got stuck while clock stretching, I suppose that wouldn't help. FTDI did add a "bus reset" function in one of the recent DLL versions and this sends the clock pulses to try to un-stick a slave, so I have put that in to.
I hope there is a best practices list somewhere rather than "throw stuff at the wall and see if it sticks" like I am doing.