200 ms delay does not solve it, anyways that would add 40 seconds to every power up. It definitely seems to fit everything @Mr_John_Smith is saying (except this is I2C instead of SPI). If I access the display after each read (which is inherently a 15 ms delay), I can finish reading 200 bytes at light speed. If I don’t access the display and keep the config on the EEPROM, it takes several minutes. The display is configured at 400 khZ and the EEPROM is at 200 kHz. Do they need the same timing?
@jwizard93 I will have to double check what is happening to temp but I don’t think that is the issue if accessing the other device on the I2C line immediately after a read is solving the issue.
@Justin Already tested it removing all debug prints and only print to the display (which is how I found that printing to the display after each read solves the symptom)
Could it be a result of setting the I2CDevice.Config every call to read if it is already set? I am not creating a new object… I made it so I could pass in configurations but ended up using separate methods in the class anyways
If I just make this part a “Loading…” screen in my program, it finishes in half a second…because I am displaying a string after each read. Would prefer to not have to make it a loading screen though because this could be a sign of problems to come later
@hwalker_MIWV I hope keeping them both at 200 kHz solves your issue. Does it align with either I2C device’s datasheet that they need to go at this speed? I wonder if you looked at an analyzer if you might see a problem similar to the one in the link above.
EEPROM is rated for 400 kHZ based off the 2V I am powering at, 1 MHz if fully powered (didn’t work for me though). Powered at 3.3V the display is rated for 300 kHz max which is why I had it set to 200 kHz. It didn’t occur to me that they might need to be the same frequency until I was typing my response to the questions everyone asked above.
I NAK your NAK. It’s capable, all within the spec, so shouldn’t be a problem, but I agree if you can use the same why wouldn’t you. And honestly, bus speed is often not a determining factor in overall performance of systems, so its often irrelevant to try to “maximise” the bus speed in a vain effort to eke every performance nanosecond out of it, so just run where everyone is happy and be done with it. I think I said previously why would you make the power situation more tenuous by powering these devices at different power levels (and then have to worry about logic level challenges) but…
I’d always try to use the highest speed that is within tolerance of all - you’d ordinarily be hard pressed to find multiple devices that didn’t have a sufficient range to get an overlap. (and I am not sure what you meant by minimum maximum )