Merged
Conversation
Not sure how this got added, but we have *.cmake in .gitignore since these files have environment-specific config.
The driver includes the HAL for the target stm32 family instead of using i2c.h from the application, so that it can remain independent from the application code. This allows for reconfiguration of the application, or consolidation of application files without impacting driver code.
Includes the define for the driver to not include floating point code. This may be the preferred approach over having the define in the driver cmake config, in which case, that define should be removed and docs should be updated.
Also updates existing read function to be a direct I2C read option
Uses new code for the write function while maintaining the previous write function as an option for direct writes to a sensor register.
Moves the define to disable floating point from the driver cmake config to the application level. This is a more appropriate location, since the application should decide whether or not it is using floating point.
nkanderson
requested review from
PlayerZ3R0,
anthlee396,
reecewayt,
riamahaj and
thisisnotanELF
nkanderson
commented
May 11, 2025
| * @param[in] i2c_handle Pointer to the stm32 I2C peripheral handle | ||
| * @return 0 if successful, non-zero otherwise | ||
| */ | ||
| int8_t bme_read_direct(uint8_t reg_addr, uint8_t *reg_data, uint32_t length, void *intf_ptr); |
Collaborator
Author
There was a problem hiding this comment.
In case this wasn't totally clear from the comments, these "direct" variant read and write functions follow the I2C transaction descriptions from the datasheet, so they may be useful for I2C interactions with the sensor that do not go through the Bosch-provided code and the bme device struct. As Nitin and Anthony discovered though, there are certain cases where they conflict with the implementation in bme68x.c, so they should not be used as the read and write function pointers on the bme device struct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The initial goal with this PR was going to be to incorporate only the fixes for the BME68x driver that @anthlee396 and @PlayerZ3R0 made related to the humidity and gas resistance values. As I started working through it though, it seemed to make more sense to move forward with the existing work to remove non-U0 targets rather than simply use the multi-target approach still in place on the
mainbranch. As a result, this PR incorporates work from #31 and #32.The first set of commits from @reecewayt are entirely from #31, so if any reviewers of this PR have already reviewed that one, you can skip or skim over those commits. The remaining commits are largely a collection of small changes to update the BME68x driver to target the U0 and incorporate the fixes mentioned above. This includes small cmake config changes from #32. Commit 41f7a14 is the largest, and comes directly from the changes to the CubeMX-generated code from #32.
It may be easiest to review the BME68x-specific changes commit-by-commit, as they are small and have descriptive commit messages, so they should be pretty self-explanatory. I'm happy to walk through this though with anyone who would like a real-time review.