IDF 5.2 and 5.1.2 (stable): legacy i2c driver slowdown from another task
Posted: Sun Jan 21, 2024 9:23 am
Hi All!
Consider following situation: main task creates legacy i2c driver, initializes and uses it from time to time. A second task is responsible to accept and to answer TCP connect requests. On thing to do within the TCP task is to do a full OTA update. During update an i2c connected LCD display shows the progress. The following behaviour I observed:
- indicating the OTA update via queue and doing the staff within the main task => fast LCD update display
- calling the same functions from within the TCP task => LCD communication is slowed down by a factor of 100 (approx.) (850µs => 65ms)
for each write cycle.
Any hints what the reason is?
My hope is with IDF 5.2 and the new i2c master driver this behaviour is gone. Unfortunately, no reading is possible at the moment (see my other post).
Greetings
Christoph
Consider following situation: main task creates legacy i2c driver, initializes and uses it from time to time. A second task is responsible to accept and to answer TCP connect requests. On thing to do within the TCP task is to do a full OTA update. During update an i2c connected LCD display shows the progress. The following behaviour I observed:
- indicating the OTA update via queue and doing the staff within the main task => fast LCD update display
- calling the same functions from within the TCP task => LCD communication is slowed down by a factor of 100 (approx.) (850µs => 65ms)
for each write cycle.
Any hints what the reason is?
My hope is with IDF 5.2 and the new i2c master driver this behaviour is gone. Unfortunately, no reading is possible at the moment (see my other post).
Greetings
Christoph