IME update rates

I though I had posted this information sometime in the past, but if I did then it’s lost to history as I cannot find it now. Each of the programming environments has chosen to poll IMEs in a different way, here are some scope shots showing the update rates for each with a few comments.

EasyC V5.
Very slow with an update rate of between 16mS and 21mS. Adding more encoders does not increase this rate, bottom line is that encoder values will not be updated very often and there will be some jitter when calculating things like rpm (due to the variable and slow poll rate). It’s probably fast enough for most VEX code but if more than two or three IMEs are used it will be marginal. The slow poll rate is also why we don’t have quite so many issues with the I2C bus crashing due to static using EasyC.

ROBOTC V4.30
Polls at about a 1KHz rate, as soon as an I2C message is received another is sent. The interruption every so often (that gap in communications) is probably background code running.

PROS 2b10
Very similar to ROBOTC, they send a new message every 1mS. There’s a bit of a cheat here, “standard” I2C clock rate is 100KHz, the PROS firmware has pushed this a little higher to 130KHz so that they can receive the I2C data within the 1mS period.

ConVEX
I receive new data every 2mS (despite what I said in the other thread earlier), the reason is that the I2C message takes just over 1mS to receive, I then wait for the next 1mS time slice before sending another request, my choice to not push the bus quite so hard. This is the default ConVEX code, obviously it can emulate any of the above or even push poll rates higher.

Please don’t quote this post as the images are linked.

1 Like

This sounds like pure awesomeness…

Thanks Mr. Pearman. Great information. Now we know there’s no need to run 10ms wait loops in easyc with IMEs.

1 Like