Flowcode Support Board

Hi Ben

I am trying to sample an I2C IMU with 8Khz with an ESP32. I read just the Acceleration X,Y,Z axis
The I2C bus runs with 1Mega.
Generally it works for sampling.
But I can only use 2kHz. I looked at a sample and there is a long "Break" from 113uSec.
Can I make this break shorter somehow?

One IMU, One Sample: Program part:

How are you reading the sensor ? Can you post the code - the delay must be due to 'something' happening that is taking 112uS - so a print to UART / write to SD or somesuch - the reads should be continuous unless the task doing the read 'yields' (a delay - or call that does so (UART Prints do I think))) or is doing 113uS worth of work between reads?

I'm assuming ReadNRegisters - reads all registers correctly using in the 'bursts' on the trace - and the delay is between calls to this?

The i2c should run okay - unless the sensor is using clock-stretching to delay things (is it capable of being read at 2kHz or does it do some data processing ?)


Martin

Good idea Martin.
Instead of switching everything off, I made a new program
Now I have tested the senor in a small test program without Sd-card and uart and no IRQ.
It is the same.
123uSec
Then I tested other components and there is also a waiting time. This is different depending on the component, but between 69uSec to 123uSec

This is just one sample MAX17043: This is just one sample LSM9 all 9axis: And my testprogram

Hi Stefan,

That's probably the wrong version - doesn't do an i2c read? (Unless CellGauge1::ReadStateOfChargeByte() does this?)

Martin

Hi Martin

I have deleted this CellGauge1 from the program .
It's still the same.

I have switched to software I2C as a test.
There is no pause with the I2C software,

These 2x8 clock and break is this a mistake?

Hardware I2C: Software I2C:

That's bizarre. It looks like the transaction write to set the register address followed by the a pause before the transaction read?

But would expect the same if using software i2c and you are not seeing that.

Do you see the same at 100/400kHz or is it just with 1MHz i2c? The mcu should be able to easily do 1MHz - I'll try and test on an i2c chip but don't imagine it will struggle..

The gyro sensor read n regs (component) doesn't do anything odd does it?

Martin

Yes the component is working at 100/400kHz/1MHz
but all speed have the same 2x8 clock in advance

If i sample with 2K the signal from 3 axis off the IMU is perfect,


Show the clocksignal:
1MHz
400kHz
100kHz show the "unnecessary" 2x8 clock in advance:

One byte will be the device address, then one for the register address.

No idea why hardware mode is getting such a long pause though.

Read_n_regs just does ransaction_write(address, reg) transaction_read()

Strange.... Especially as not in software mode..

I tried it directly with the code abstract layer.
I can display the values with the UART.
But with the oscilloscope I measure the same duration
Total 174uSec with a break of 73uSec
What I still don't understand is the command “Write start address” with this parameter 0x8001

Program:

I've just tested using a i2c eeprom - and set for a similar scenario. So doing the same (effectively) as GetNRegs - using hardware i2c there is a delay of ~75uS before the read. This doesn't happen with software mode.

Setting the high bit (0x800n) of the number of bytes to send doesn't send a 'stop' on the i2c - then the read can follow.

This gives a total time to read 10bytes (I went one better )of 2.46ms in software mode. and 256uS in hardware mode - so it's probably worth using hardware mode anyways? Still odd though - might be the sensor is holding SDA low for some processing?

Software then Hardware i2c


Martin