Status of new I2C API

Dear RIOTers and maintainers,

I would like to know the current status of the new I2C master API. It’s been a long time since we heard about it. I’m willing to work on it and maybe others are also interested.

I’m fully aware that such a big rework will take some times and a lot of efforts but this task has to be done.

Would it be useful to create a task force ?

What do you think ?


Hi everyone,

sorry for the late reply. The remodeling of the I2C (master) API should indeed be tackled ASAP (as every newly merged implementation just adds to the work)… But this is not new and I/we have been talking about this for ages now…

I won’t be able to drive this nor to spend time on this. It would be great, if anyone else could step up and take the lead. @Dylon: is this maybe a job for you?!

The current state:

  • tracking issue: #6577 [1]
  • new interface proposal: #4926 [2]
  • first thoughts on automated, HIL-style test setup: [3] (see mostly tests/softi2ccli/main.c)

The former idea was, to rename the ‘legacy’ i2c functions (as proposed in #6575 [4]), merge the new API and then rework all the implementations and device drivers in a step-by-step manner. But with more thoughts and recent experiences, the way to proceed is probably using the feature-branch approach as recently done for for the new ietif remodeling.

So the steps that I see are:

  1. finish the work on the testing setup [3], as in-depth testing is the key for the remodeling (lessons learned from the SPI remodeling…)
  2. implement the proposed interface [2] on some more (restricted) target platforms (e.g. nrf52 TWIM) to verify, that the API details do actually work on all the CPUs that we support…
  3. rewrite existing periph drivers, adapt device drivers, and test everything thoroughly. This will take significant time and effort!

Best, Hauke

[1] [2] [3] [4]

Hi again,

fixup to my previous mail: the new proposed API is better presented in #6576 [1]…

Cheers, Hauke