your commits messages will need rewording

https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md#commit-conventions

your commits messages will need rewording

https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md#commit-conventions

Could you be more accurate ?

your commits messages will need rewording
https://github.com/RIOT-OS/RIOT/blob/master/CONTRIBUTING.md#commit-conventions

Could you be more accurate ?

Each commit should target changes of specific parts/modules of RIOT. The commits use the following pattern:

area of code: description of changes

You can use multi-line commit messages if you want to detail more the changes. For example:

periph/timer: Document that set_absolute is expected to wrap

Most timers are implemented this way already, and keeping (documenting)
it that way allows the generic timer_set implementation to stay as
simple as it is.

so you commit messages should be for example

driver/abp2: driver for SPI sensors prepare for I2C

tests/driver/abp2: test implementation

or something similar

the scheme is <arena of work>: <description>

Why?

Why should we Block that usecase (one might have a mix of both in one experiment or just have multiple sensors) the design hints just point into the direction of there will only be one sensor

simple example speed/flow (pito) and pressure measurement would need one differential and one absolute sensor (or two absolute) (ofcause these can be two spi (different cs), but with these hints i2c would not work (neither 2 i2c sensors nor can it be combined with spi)).

I feel a little uncomfortable with the i2c integration hints (code) and pseudo_module, please remove. Talked to other maintainers and we seem to align on that. The comments "i2c communication should go here" -even though it is obvious ( everywhere where spi is called i2c would also be)- is ok for me.

I didn't make up the pseudo-module thing myself; I was advised to do so by a maintainer. I spent quite some time on this driver, which is OK, because I like to return some effort to the open source community. Despite the long period of inactivity in this PR, I could do minor changes, like the timer stuff. But changing the pseudo-module structure would take me much more time (I didn't work with RIOT for a while), with the risk that some other maintainer asks to reestablish it when I'm done.

* implementation wise it would be better to be able to use spi and i2c the at the same time -> the current hints are not the right direction (the module would provide either one or the other interface and work only for one i2c adress.

* at some places this will seem like this driver supports i2c (eg if you list available modules) but it isn't -- this leads to: "hey RIOT supports abp2-i2c" -- "just the implementation is missing".

* since you do not intend to write it, it will probably not exist.

OK, the I2C version is not implemented, but I may do it later, because I will probably buy an I2C sensor in a future project. I just don't know when. I understand that you strive for high quality standards, but you know the saying, the best is the enemy of the good. In the end, I'm afraid this driver will only be used by me.

If you want to hint: "hey the is something open TODO" write a TODO

The failing tests on mobi3 are not caused by your code, the build server is currently having issues.