I’m using 5 x PR33-26 transmitters, 1 x PR33-16 receiver, 1 x PR32-29 mux, and 1 x PR37-10 Arduino Mega2560/Due shield.
With regular (100kHz) clockspeed, my system works fine, but I need to use the “fast” (400kHz) clock speed in order to get my loop time where I need it. I don’t seem to be having any problems with the PR33-26s and the PR32-29 at “fast” speed, but whenever I enable conversions and reads of the PR33-16, sooner or later (within a minute or two) I get error returns from Arduino’s Wire.endTransmission() function in my Arduino Due code. I am presently unable to clear this error without a hardware reset.
Even before the transaction fails, the receive communication cycle seems inordinately long even in fast mode. Would continuous conversion mode help me here?
I have tried adding in the additional pull-ups on the PR33-16, to no avail.
After more analysis:
the intermittent stopping seems to be a result of electrical noise, generated by a combination of my test wiring, my test code - which drove four current source channels with the same ramp signal - and the rather lightweight 4-pin I2C connectors. My I2C connection was daisy-chained from the Due shield to the mux to the input module to the first output module. The second to the fifth output modules are connected to the output of the mux. The same power supply used to supply the mux and receiver logic is used as the reference for the current loops - that is marginally adequate for a test configuration, but clearly not suitable for a functional installation, and I know NCD support staff would scold me for even attempting it!
On doing the math for 100kHz vs 400kHz, it turns out the conversion time for four MCP3428 channels is 16.7ms, which is significantly larger than the difference in I2C time.
I guess the bottom line is that a) even with the 84MHz Arduino Due, I need a faster A2D receiver to get the loop rate I want, and b) these 4-pin connectors are OK for testing and experimentation, but they are not really solid enough for a serious installation.
Anyway, I thought I’d share this issue for the benefit of the party.
I’d still like anybody’s ideas on how to restart the system described above that has lost I2C sync by means of software commands.
Thanks for the post. We have definitely experienced the latency of the MCP3428, I feel your pain! With regard to speed, I think I may be the only one in our office that has experimented above 100KHz. I have tested up to 700KHz with certain I2C devices with great success, but each device seems to have a different tolerance for speed and noise. I wish I could provide you guidance to help get out of a locked situation, I am currently experiencing the same issue on an entirely different platform. Here is a thread that might help you, and I am also looking into exploring some of the methods describe here as well: https://www.microchip.com/forums/m175368.aspx
Thanks for that link, Ryan. Yes, I’m already using the manual clock method to yank any pending data out of a marooned sending slave. I use it on a power-on, and in the event that the read returns an error.
Here’s my code…
void clearI2CBus() {
pinMode(21, OUTPUT); // make absolutely sure clk pin is an output
digitalWrite(21,HIGH);
delayMicroseconds(100); // settle
for(int i=0; i<11; i++) {
digitalWrite(21,LOW);
delayMicroseconds(50);
digitalWrite(21,HIGH);
delayMicroseconds(50);
}
delayMicroseconds(100); // settle and exit
}
There seems to be something else preventing it from restarting, however, as while this works reliably on a power up (I know, 'cos the erratic start was why I investigated the phenomenon in the first place, and I don’t experience it any longer with this code in setup() ).
I’d really like a faster A2D module on I2C (pretty please, NCD? ) but meanwhile, I think I can get my loop time down to 25ms, or 40Hz, with four channels read, and that’ll do what I need it to.
I’ll use a separate power supply for the current loop supply, which will probably help some, and I’ll keep working on the soft boot code.
Thanks again for your help!
Thanks for the post! We will definitely consider faster ADCs, I discussed this topic at dinner last night with our lead engineer. Currently, high-end ADCs are reserved for high-end products, but we will continue our discussions internally.
) but meanwhile, I think I can get my loop time down to 25ms, or 40Hz, with four channels read, and that’ll do what I need it to.