How to use TSL2591 component with esp_lcd (i2cdev + manul i2c driver use)

[jChereck]

I imagine it should be possible to use both of these in the same project relatively easily since they're both official components, but I'm stumped.

TSL2591 uses i2cdev to handle i2c communications internally, while esp_lcd uses the i2c drivers directly.

if I initialize i2c with i2cdev_init() I get an error when using i2c_new_master_bus(), and vice versa if I initialize them in the opposite order.

I can't just use one initialization, because i2cdev throws an error if I initialize via the drivers, and if I initialize via i2cdev I have no way to get the master bus handle to pass into my esp_lcd initialization.

I think I must be missing something here, since I would imagine these components should work together just fine, but as far as i can tell at the moment I would need to rewrite how one of the components works to get them to coexist.

How can I use both of these components together?

[trombik]

tl;dr The answer is: you cannot.

i2cdev.h does NOT simply provide short-hand functions or thin wrappers of underlying esp-idf functions. It handles resource management and, most importantly, thread-safe operations with locking because the older i2c.h from esp-idf does not guarantee thread-safety. The newer i2c_master.h introduced buses, devices and thread-safe functions, which is quite similar to what i2cdev.h has been providing. Because two implementations do the same thing, you cannot mix them up.

We can rewrite i2cdev.h so that the drivers and i2c_master.h can co-exist but it will break older esp-idf versions. In addition, esp8266 does not, and probably will not, have i2c_master.h.

[jChereck]

Okay so to check my understanding:

• i2cdev is legacy now, it was intended to solve threading issues with the old i2c drivers
• i2cdev can't coexist with the new drivers because it manages all i2c internally

Potential paths forward:

1. fork i2cdev and make a version of it that would coexist with i2c_master.h, and use for this project/similar situations when using esp-idf v5.0+ on anything other than esp8266
2. fork and update the TSL library to use i2c_master.h since this is the new standard
3. find an older SSOLED library that uses i2cdev

What would you recommend doing? I imagine 2 is likely the best/most proper route forward.

What would you do for knocking a quick and dirty prototype together? This project has grown a bit large for what was meant to be a simple proof of concept.

Also thanks so much for helping me out. It would have taken me a lot longer to come to that conclusion and I likely wouldn't have been very confident in it.

[trombik]

I have no idea. It is your project. You don't have to worry about backward compatibilities unlike us. Our drivers have business logic only other than initialization and de-initialization. Give whatever a try and you will see it.

[jChereck]

Yes, I will look into it. Apologies if it sounded like I was trying to get you to do any of the work for me, I was just trying to make sure I headed off in the correct direction.

Out of curiosity, am I right in understanding that i2cdev is going to be phased out because of the new i2c driver, or do you think it will be kept alongside it?

Can I suggest this gets added into the documentation somewhere? I'd be happy to try to do so, but I'll admit I'm a bit shy about contributing to projects this large and well organized. I would think that a note at the top of the i2cdev docs here would be helpful to others.

Also I noted the i2cdev component in the components library seems to link to the old UncleRus documentation instead of the new documentation inside of esp-idf-lib

Thanks for tagging quinkq to see if he could give me some help, that was very kind of you.

[trombik]

Out of curiosity, am I right in understanding that i2cdev is going to be phased out because of the new i2c driver, or do you think it will be kept alongside it?

I have no plan to drop i2cdev.

Can I suggest this gets added into the documentation somewhere?

The official documentation is at: https://esp-idf-lib.github.io/i2cdev/.

Also I noted the i2cdev component in the components library seems to link to the old UncleRus documentation

The link is correct.

Thanks for tagging quinkq to see if he could give me some help, that was very kind of you.

You are welcome. If my work is helpful for you, please consider financially support my work. It took me a full two weeks to migrate the old monolithic repository to multiple repositories, to publish all the drivers on ESP Component Repository, and to revive the project again. I help people here and students with my business. Few people helped me, notably @quinkq. How would you help people?

[jChereck]

The official documentation is at: https://esp-idf-lib.github.io/i2cdev/.

I meant adding a note that i2cdev can't be used directly with i2c_master.h. Perhaps this seems obvious to everyone else, but a small note at the top of the i2cdev documentation would have saved me a lot of confusion.

[trombik]

@quinkq any advice from your side?

[quinkq]

Hi @trombik,

@jChereck I definetly agree that one should expect for esp-idf-lib and ESP-IDF I2C components to be working together.
While using the same underlying ESP-IDF I2C master driver, both ecosystems evolved separately. And like @trombik said currently i2cdev manages I2C buses through its own abstraction layer with thread-safe mutexes, while ESP-IDF components expect direct access to i2c_master_bus_handle_t. When both tried to initialize the same I2C port, you get resource conflicts since each thought it owned the bus exclusively.

I've tried to devise a quick fix for you, however I really can't spare any time this week to test it properly:

Add to i2cdev.h:

/**
   * @brief Get shared I2C bus handle (requires sensor initialized first)
   */
  esp_err_t i2cdev_get_shared_handle(i2c_port_t port, void **bus_handle);

Add to i2cdev.c:

esp_err_t i2cdev_get_shared_handle(i2c_port_t port, void **bus_handle)
  {
      if (port >= I2C_NUM_MAX || bus_handle == NULL)
          return ESP_ERR_INVALID_ARG;

      if (!i2c_ports[port].installed || i2c_ports[port].bus_handle == NULL)
          return ESP_ERR_INVALID_STATE;

      *bus_handle = (void *)i2c_ports[port].bus_handle;
      return ESP_OK;
  }

Usage:

  // Initialize i2cdev
  i2cdev_init();

  // Initialize your sensor first! It creates the bus + stores handle internally
  tsl2591_init_desc(&sensor, 0, sda_pin, scl_pin);

  // local variable to hold that above bus reference
  i2c_master_bus_handle_t bus_handle;
  // Fetch bus handle for sahring with esp_lcd
  i2cdev_get_shared_handle(I2C_NUM_0, (void**)&bus_handle);

  // Now esp_lcd can use the same bus
  esp_lcd_new_panel_io_i2c(bus_handle, &config, &io);

In theory this should unify I2C ecosystem where allowing mixing any esp-idf-lib sensor with any ESP-IDF component, so both TSL2591 and esp_lcd should work on the same I2C bus with proper thread synchronization.

@trombik I might try adding PR in some near future once i get some spare time and proper testing setup.

[jChereck]

Thank you so much, this was extremely helpful. I like to think I'd have gotten there myself at some point, but I think that point would have been quite a ways down the line.

The changes you showed here worked perfectly once I figured out how to use override_path in the components file.

I imagine it would be best practice to use i2c_dev_take_mutex(oled_dev.i2c_dev) to protect the i2c bus when I'm writing to the lcd, Wouldn't it?

Though looking at i2c_dev_take_mutex it seems to be only taking a mutex for the specific device, and looking through the i2c transmit functions I don't see any mutex/thread saftey mechanisms, though I could easily be missing something obvious there.

[jnischler]

i have the same problem with the i2s driver requiring the i2c_master_bus_handle_t
are you planning on adding this function natively to the library ?

[quinkq]

Hi @jnischler, i might look into it next weekend.

[jnischler]

I have created a fork and added a simple helper function.
Did the trick and works well.

I have created an PR if you are interested feel free to accept or request changes.

https://github.com/esp-idf-lib/i2cdev/pull/6/files

[jnischler]

To you this "fix" you first need to create another dummy device and use the bus.

We could improve the helper function to set up the bus handle.

But for my usecase this wasn't required.

Before adding it to the library as a native feature I think it would be better to improve the function.