pkg/bme680 driver: add support for I2C/SPI BME680 driver

[dylad]

Contribution description

This PR adds support for I2C/SPI BME680 sensor as package.
In a previous PR, @aabadie proposes to support this driver as a package because its quite complicate and Bosch already provides a working driver on their repo [1].

This driver is labelled as WIP because I'm not fully happy and I need some advises/reviews to enhance it. Furthermore, I only tested the I2C part on a custom board. I'll need some help to test the SPI part before merging this PR.

Testing procedure

run the dedicated test application using
make -C tests/pkg_bme680_driver
You may need to modify some params to match your hardware. (Comments are very welcome here)

Issues/PRs references

#9909

[1] https://github.com/BoschSensortec/BME680_driver

[gschorcht]

@dylad Thanks for your contribution.

Before we start adding drivers as packages, we should discuss and find an agreement for some questions that came up with my PR #10363.

• How can we identify a package as a driver within the package directory which is inflating if more drivers are realized as packages. Should we use driver_ as prefix as I did, or should we use _driver as suffix as you did. To have something like categories, I would prefer prefixes. Or should we start to sort packages in categories in different sub-directories? In any case, we should have a common naming scheme?

• You have added the package as "Bare Metal". This gives the application full access to the functionality of the sensor, but makes it difficult to use it when the application just to follow the RIOT approach for sensor drivers, where a sensor is configured with a parameter set and is ready to use as soon as it is initialized with this parameter set. I think there should be at least a small wrapper module in drivers which defines the typesbme680_t and bme680_params_t and provides the functions bme680_init and bme680_read. You might take a look to my PR # 10363 to get an idea how I solved it.
  In addition, sensor drivers should provide SAUL capabilities. This would also be possible with the small wrapper driver module.

• And last but not least, how should the documentation looks like? Would the documentation of the vendor be enough?

[dylad]

How can we identify a package as a driver within the package directory which is inflating if more drivers are realized as packages. Should we use driver_ as prefix as I did, or should we use _driver as suffix as you did. To have something like categories, I would prefer prefixes. Or should we start to sort packages in categories in different sub-directories? In any case, we should have a common naming scheme?

I have no strong opinion on it, maybe a dedicated sub-directory could be better ? But we will need to modify a bit the build system I guess. In any case, I propose to open an issue to regroup all the discussions in a specific place.

You have added the package as "Bare Metal". This gives the application full access to the functionality of the sensor, but makes it difficult to use it when the application just to follow the RIOT approach for sensor drivers, where a sensor is configured with a parameter set and is ready to use as soon as it is initialized with this parameter set. I think there should be at least a small wrapper module in drivers which defines the typesbme680_t and bme680_params_t and provides the functions bme680_init and bme680_read. You might take a look to my PR # 10363 to get an idea how I solved it.
In addition, sensor drivers should provide SAUL capabilities. This would also be possible with the small wrapper driver module.

I think it's a good approach to unify drivers and package drivers, it will require some extra works but I think it's worthwhile. We must define how it will look like before.

And last but not least, how should the documentation looks like? Would the documentation of the vendor be enough?

For this point, my suggestion is to keep the API documentation from the original repo but we also must document any patches or adaptation level to RIOT in order to explain how it works.
In addition, we can provide a wiki page for each package driver with more details and examples if needed.

I'll create an issue to centralize discussions about package drivers.

[maribu]

Readme copied from U8g2 without updating contents to bme680

[LloydKM]

Should be:

#ifndef BME680_SPI_MODE

[dylad]

Sorry for the delayed answer,
I plan to put more work on it after the RIOT summit in September.
But thanks for the reviews :)

[roberthartung]

@dylad Are you still working on this? Some of my colleagues need a driver within RIOT.

[dylad]

@roberthartung
This is on my todolist but I have an issue with my custom hardware. I'm waiting for my order so I can fix my board and work on it again. (Hopefully soon ?)

[dylad]

Close in favor of #12717