drivers/srf02: Update to new i2c API #9423
Conversation
|
My srf02 may have some issues, it seems to work... just not reliably. This behavior is in the master as well. On the scope everything looks fine. (It basically will intermittently respond to a correct address). If someone can test it on different hardware that isn't possibly broken that would be great! |
|
It may be that or it may be this from the datasheet (although it shouldn't keep doing this)
|
|
|
||
| /* read the results */ | ||
| i2c_acquire(dev->i2c); | ||
| i2c_read_regs(dev->i2c, dev->addr, REG_HIGH, res, 2); | ||
| i2c_read_regs(dev->i2c, dev->addr, REG_HIGH, res, 2, 0); |
There was a problem hiding this comment.
not your fault and I know this is (more) about adapting to the new I2c iface ...
but what if read_regs fails? This function will return garbage then, right? To me it would make more sense to change the function to int srf02_read(const srf02_t *dev, uint16_t *val) write result to val and return 0 in success and errors accordingly.
However, that would at least be a separate commit, if not a PR -
There was a problem hiding this comment.
I agree with @smlng, we will have to change later the behaviour of many drivers.
For now, we can stay like this.
| } | ||
|
|
||
| uint16_t srf02_read(const srf02_t *dev) | ||
| { | ||
| uint8_t res[2]; | ||
| uint8_t res[2] = {0xFF, 0xFF}; |
There was a problem hiding this comment.
why 0xff instead of 0x0, just curious 😄
There was a problem hiding this comment.
ah, you use that below to get invalid/failed reads, but then see my other comment on how this (IMHO) should be fixed instead.
|
Can someone test this device on a second CPU arch before we merge it ? |
|
I can try, if @MrKevinWeiss provides the sensor 😄 |
|
Tested on remote-revb with |
|
Here we go ! |
drivers/srf02: Update to new i2c API
drivers/srf02: Update to new i2c API
drivers/srf02: Update to new i2c API
Contribution description
Update the srf02 sensor driver to the new I2C API.
Issues/PRs references
#6577