G30 Proccessing Lag

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.

G30 SPI Problem

@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 :slight_smile: )

“the highest speed that is within tolerance of all” :grin:

oh, yeah, I guess we both concur then :slight_smile:

I agree with your statement. :hugs:

1 Like

What the heck was all that about then? You guys agreed to agree :confused:

haha I agree!

I am just going to keep them the same speeds and be done with it because I am only transferring about ~200 bytes once on every powerup and thats it.

PS everyone check out @Mr_John_Smith new dSpin stepper driver its pretty lit

Yes, I agree that we agreed to agree.