The table looks fine so far.
Some other terms to add/discuss are Controller/Device or Controller/Target for spi and i2c with Master/Slave as don't use and init/setup/open/create.

The table looks fine so far. Some other terms to add/discuss are Controller/Device or Controller/Target for spi and i2c with Master/Slave as don't use and init/setup/open/create.

Init/Setup terminology should be different for things that can also be deinited (e.g. stuff that could run in a bootloader)

Init/Setup terminology should be different for things that can also be deinited (e.g. stuff that could run in a bootloader)

How do you mean that?

I pushed some changes i did a while ago and totally forgot to push

How do you mean that?

If a struct can initialized and deinitialized, those members should use a different naming scheme than the member of a struct that only needs to be initialized.
This would let users clearly know when they can deinit something or not, without depending on an lsp and code completion.
Under normal circumstances there is no need to deinit something, bootloaders would be an example where users might want to deinit something.

Ah, this is a good question 🤔

Maybe we can use setup() or something

Merged that because we need it for the HAL discussion and we didn't had any expected bikeshedding