Is the reference to Temp held on to? What do you do with it if not displaying its contents? I’m wondering if maybe there is an issue with the compiler not thinking this loop serves a purpose and optimizing it away or something like that. I was also thinking ildasm would put that question to rest very easily if you agreed it could be an issue.
Do you have a lot of Debug.Print’s?
Try the above code with a 200ms sleep after the Read. You might be reading too often.
I used to have a peculiar problem with an SPI bus. It was shared between 2 chip selects on 2 different devices. Whenever I would switch from one device to another (their configurations was different), the device that I switched to would give problem. In the end what I did was create a dummy intermediary device that I would switch to between calls. This solved my problem, but I never figured out why.
This sounds like timing issues with chip select/unselect. Datasheet might give a clue.
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
Seems having two devices on same buss operating at different speeds might be an issue? What happens at same speed?
I haven’t tried same speed yet I will now
Yay that fixed it! First I put them both at 400 kHz which gave the same issue but got them both working great at 200 kHz
I wonder if you had a similar problem as I showed here. I think it was chalked up to a bug.
@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.
It would be interesting to see what the speed rating are for the devices?
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.
i2c bus doesn’t need to run at the same speed, but obviously your situation / code calls for it. Could it be a bug in netmf’s i2c handling? Possibly
Bad engineering practice to depend upon mixed speeds working. Very device and speed dependent. I say NAK to it.
lol shots fired
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 believe the highest speed, of any device on the bus, must be the minimum maximum of all the devices.
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 )
“the highest speed that is within tolerance of all”