i2c: busy wait in s_i2c_send_commands is not very power efficient. (IDFGH-12076)

[KJ7LNW]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

While researching #13136, I noticed that s_i2c_send_commands does a "busy wait" while waiting for the interrupt handler to (eventually) finish the i2c transfer.

Correct me if I'm wrong, but this isn't very power efficient; at low i2c clock rates, it isn't computationally efficient for other tasks, either, because it spins the CPU waiting for the transfer to complete:

while (i2c_master->trans_done == false) {};

Wouldn't this be better for power consumption?

while (i2c_master->trans_done == false) {
  esp_light_sleep_start();
};

or if FreeRTOS is involved, maybe this would be better to suspend the busy wait until the next systick?

while (i2c_master->trans_done == false) {
  taskYIELD();
};

[KJ7LNW]

If FreeRTOS is always expected to be in the build for this driver, then maybe the synchronous version should suspend the task with task = xGetCurrentTaskHandle(); vTaskSuspend(NULL); and the callback should resume it with vTaskResume(task); return true; in the callback handler.

This provides not just better CPU sharing and power-usage efficiency, but an 8x performance improvement over 1kHz systicks and ~75x over 100Hz systicks. Here is a simple sync vs async benchmark:

• async with task suspend/resume: 7506 samples/sec
• sync with vTaskDelay(1); is limited by the systick rate, so the best it can do is ~995 samples/sec, or 99 samples/sec with the default of systick at 100Hz.

Test project:
https://github.com/KJ7LNW/esp32-i2c-test/tree/master

n.b.: I'm not sure if xGetCurrentTaskHandle() is a thing, but I found a reference to it here.

[nebkat]

@mythbuster5 I believe this hasn't been sufficiently documented since the new driver was added.

The previous API used a FreeRTOS queue to receive messages once commands were completed, while now the API is truly CPU blocking.

I have had TWDT trigger because of this when device is offline.

[KJ7LNW]

@nebkat, and @mythbuster5: Please see PR #13322 which would close this issue.