Slow I2C conncection for IMU reading

Hello PYNQ community,

I am using a precompiled v2.4 Image on a default PYNQ-Z1. I try to read my IMU ( which I connected to the pynq via PMOD. I print the data following the Grove_IMU example on terminal with the script below. But the speed at which it publishes is really slow at around 2 Hz. Is there anything I can do to speed it up significantly?

Thank You in Advance.

The test-code:

from pynq.overlays.base import BaseOverlay
from pynq.lib import MicroblazeLibrary
from pynq.lib.pmod import Grove_IMU
from pynq.lib.pmod import Pmod
from pynq.lib.pmod import PMOD_GROVE_G3

base = BaseOverlay(‘base.bit’)

mb_info = {‘ip_name’:‘iop_pmoda/mb_bram_ctrl’ ,‘rst_name’:‘mb_iop_pmoda_reset’}
gr_pin = PMOD_GROVE_G3
imu = Grove_IMU(mb_info, gr_pin)

sample_counter = 0
while True:
print("acc1: %s "%imu.get_accl())
print("gyro1: %s "%imu.get_gyro())
print(“mag1: %s “%imu.get_compass())

How fast do you need it to be?

There will be some overhead from the Python call.
The main driver code runs on an IOP (MircoBlaze) in software. You can see the software here.

I see some 10-60ms delays between i2c calls. I presume this was due to some timing issues. You may be able to optimize this code a little.

If you need substantially better performance, you may need to write a custom hardware module for this IP. Remember this is still an i2c peripheral which will be a limiting factor for performance, particularly if you need multiple I2C calls per function.


1 Like

Would it be possible to use the i2c from the PS directly?

Yes, it is possible use the i2c from the PS, but this may not be the best thing to do.
It would be helpful if you could answer the question “How fast do you need it to be?”.


@cathalmccabe considering the delay that you mention, I would say 35ms average would be fine. As it is an IMU, to have at least 20 Hz would work.

What would be the issue to use directly the I2C from the PS? Wouldn’t it remove the overhead of going through the microblaze?

Thanks for the help.

I need it to be above 20 Hz, but currently get a maximum of 2 Hz. So the 10-60 ms delay between the i2c calls shouldn’t make it that slow?

You should not include print into your measurement. Also, logging might be faster than just a single read performed multiple times.