I2C frequency stuck at 20MHZ

[bonmotwang]

I am testing I2C right now.
Followed the sample code.

Code: Select all

static esp_err_t i2c_master_init()
{
    int i2c_master_port = I2C_MASTER_NUM;
    i2c_config_t conf;
    conf.mode = I2C_MODE_MASTER;
    conf.sda_io_num = I2C_MASTER_SDA_IO;
    conf.sda_pullup_en = GPIO_PULLUP_ENABLE;
    conf.scl_io_num = I2C_MASTER_SCL_IO;
    conf.scl_pullup_en = GPIO_PULLUP_ENABLE;
    conf.master.clk_speed = 400000;
    i2c_param_config(i2c_master_port, &conf);
    return i2c_driver_install(i2c_master_port, conf.mode,
                              I2C_MASTER_RX_BUF_DISABLE,
                              I2C_MASTER_TX_BUF_DISABLE, 0);
}

But doesn't matter what I put for clk_speed.
I always get 20MHZ on the scope on CLK line and DAT line.

Did I do anything wrong?

Thanks

Paul

[mikemoy]

Her is mine, works fine.

Code: Select all

#define I2C_EXAMPLE_MASTER_SCL_IO          GPIO_NUM_5       // gpio number for I2C master clock
#define I2C_EXAMPLE_MASTER_SDA_IO          GPIO_NUM_4       // gpio number for I2C master data


    i2c_config_t conf;
    conf.mode = I2C_MODE_MASTER;
    conf.sda_io_num = I2C_EXAMPLE_MASTER_SDA_IO;
    conf.scl_io_num = I2C_EXAMPLE_MASTER_SCL_IO;
    conf.sda_pullup_en = GPIO_PULLUP_ENABLE;
    conf.scl_pullup_en = GPIO_PULLUP_ENABLE;
    conf.master.clk_speed = 200000;

    if (i2c_param_config(I2C_NUM_0, &conf) != ESP_OK)
    	return false;

    if (i2c_driver_install(I2C_NUM_0, I2C_MODE_MASTER, I2C_EXAMPLE_MASTER_RX_BUF_DISABLE, I2C_EXAMPLE_MASTER_TX_BUF_DISABLE, 0) != ESP_OK)
		return false;

[ESP_Sprite]

Not relevant to the problem, but note that both your code will break if esp-idf is updated and i2c_config gets an extra field. The proper way to initialize it would be something like

Code: Select all

i2c_config_t conf={0};

which will fill all un-referenced fields with zero.

[bonmotwang]

Thanks. will do the zero at the beginning.
Is it related to HSPI? I am using HSPI on other I/O lines which is 20MHZ.
Thanks
Paul

[bonmotwang]

Removed HSPI code. still the same.
Put on the ESP32_WROVER_KIT to do some test now.

[mikemoy]

Not relevant to the problem,

Can you elaborate on why its not relevant to the problem? this is where one sets the I2C clk speed at.

[ESP_Sprite]

Can you elaborate on why its not relevant to the problem? this is where one sets the I2C clk speed at.

Because as far as I can see, he sets all members in the later code manually, so it works perfectly fine for now. It's just not very future-proof.

[mikemoy]

mikemoy wrote: ↑
Fri Jun 28, 2019 2:39 pm
Can you elaborate on why its not relevant to the problem? this is where one sets the I2C clk speed at.

Because as far as I can see, he sets all members in the later code manually, so it works perfectly fine for now. It's just not very future-proof.

But thats just it, the OP says its not working fine now. He cannot change the clock speed.
As for future proof, if they add another field just add the new field in. Initializing it all to 0 may not be something you want to do which will break it just the same.

[ESP_Sprite]

But thats just it, the OP says its not working fine now. He cannot change the clock speed.
As for future proof, if they add another field just add the new field in. Initializing it all to 0 may not be something you want to do which will break it just the same.

We guarantee there will be no backwards-incompatible API changes between versions with the same major version number, so given that the addition is made in a minor version upgrade, we'll make sure that the field having 0 will generate the same behaviour as non-existence of the field in previous versions. Even between major versions, we'll probably make sure that initializing a field to 0 will do 'the expected default'.

[mikemoy]

We guarantee there will be no backwards-incompatible API changes between versions with the same major version number, so given that the addition is made in a minor version upgrade, we'll make sure that the field having 0 will generate the same behaviour as non-existence of the field in previous versions. Even between major versions, we'll probably make sure that initializing a field to 0 will do 'the expected default'.

Good to know, thanks