ESP32 read I2C speed increase

[stefan.erni]

I did the test with an STM32F469 board. The STM32 does not have a break or only 1.3uSec
Just need 87uSec

STM32 read 6 Byte I2C Bus:

scope_74.png (60.51 KiB) Viewed 1772 times

[mnfisher]

Can find several folk complaining about this issue on the Web.
I'm away from home and can't check, but wonder what version of i2c flowcode's CAL layer is using. There is a version 2 see https://docs.espressif.com/projects/esp ... s/i2c.html
Which would seem to be the latest on a quick search?
Reading more carefully - v2 is for the slave. It does state clock should not exceed 400khz. So no further forward


Martin

[mnfisher]

https://docs.espressif.com/projects/esp ... s/i2c.html

Gives 4mhz as a max for scl. Multiple versions make life so much more complicated

[BenR]

The delay is likely in setting up the I2C write and making it thread safe etc. The IPE is fairly bulky and I assume it trying to work in all eventualities.

I had similar delays for SPI and even I/O was extreemly slow.

For SPI the setup delay was a significant factor slowing down GLCD writes and that's why I added the fast pixel buffer to queue up the SPI writes into as few blocks as possible so as to reduce the frequency of setup time delays.

With the I/O I dug into the IPE framework and eventually found the code that was writing the values to the registers and so managed to bypass all the layers on top. Could be a problem in terms of being thread safe but it certainly sped up the I/O a lot.

For I2C it's nice to have a benchmark which we can measure against which we now have. I'm hopefully becoming more free now as the big internal project I've been working on for 2ish years is coming to a close and so I should have much more time to play with Flowcode again and hopefully help look into things like this.

[stefan.erni]

Hi Ben, Hi Martin

That would be good if the break is no longer there.

If we make changes in the "I2C Flowcode's CAL layer" can we also look at why this does not work in IRQ macro?

simple use of I2C in IRQ:

SNAG-0001.jpg (58.68 KiB) Viewed 1159 times

[mnfisher]

Just back from my travels.

Had a little play using i2c_master.h and i2c_master_transmit_receive. This gives a bit of a boost to the speed - with a 22.4uS delay after sending the read address (again I am using an i2c eeprom, so this is 2 bytes). Then reading 9 bytes - there are two 'odd' delays at the last byte / final NACK.

It's a bit quicker - and I can 'push' the clock speed. The memory I am using works at 1.2MHz (but fails at 2MHz (and it was late so I only tried a few speeds) - the gyro might allow faster speeds - set in the first code block)

Time 190uS at 1.2MHz (209uS at 1Mhz)

[mnfisher]

Compiling with optimisation set to performance shaves a few ms off but the delays are consistent at any speed (so some setup code most likely)

I wonder if there are specific i2c pins (like with SPI) that give better performance?

Martin

[stefan.erni]

Hi Martin

The pins are ok to use

Standard I2C pins on the ESP32-WROOM:
SDA (data line): GPIO21
SCL (clock line): GPIO22

and I have found this but I don't know how to use it yet

polling mode can help to reduce your 50 µs pause because it avoids the overhead of interrupts. If you want to test it, try portMAX_DELAY as timeout for i2c_master_cmd_begin()

[stefan.erni]

Hi Martin

I am trying to test, but there is a small problem with i2cmaster.h
include:

2025-02-13_15-18-57.PNG (16.98 KiB) Viewed 1053 times

[mnfisher]

What version of the espressif tools are you using? I think I have 5.3 - and this seems to have been just introduced..

I also played with the hal-i2c code - but the address sent but no relation to the address passed to the send and receive function. It was rather harder to get it to compile too..

Martin