Closed nashif closed 8 years ago
by Kuo-Lang Tseng:
The patch has been developed and posted by Mariusz Ryndzionek :https://gerrit.zephyrproject.org/r/#/c/2648/
by Kuo-Lang Tseng:
Patch merged.
by ethan gao:
Kuo-Lang Tseng Something to confirm, Has this sensor been available on Quark SE Devboard yet? I mean no extra component to employ this sensor, thank you !
by Kuo-Lang Tseng:
ethan gao I believe yes, it is available on Quark SE devboard (Baohong Liu can confirm). Just to call out that the driver was done by Mariusz Ryndzionek and our team only did the code review and didn't test it.
by Baohong Liu:
ethan gao I just pulled out the latest code from the repo. Even the compilation for this driver is failing. (I used master, top of the tree).
by ethan gao:
Well. the build failure results from the latest code update of ASSERT() in commit d2e1f875d78b62982b2e7257fe0ad1367a2a643c, I bypass that commit to go ahead for quick verification. Of course, the use of ASSERT in sensor needs to be tweaked in the next.
by Kuo-Lang Tseng:
ethan gao Can we raise a bug in Jira for that?
by Andrew Boie:
Kuo-Lang Tseng It's not a bug.
The __ASSERT() macro used to have a bug where if CONFIG_ASSERT=n, improper arguments to __ASSERT() would still pass the build. The build would still fail if CONFIG_ASSERT=y.
What the patch changed is now if __ASSERT() is used improperly if CONFIG_ASSERT=n, the build fails.
We found this issue when we started doing CI builds with CONFIG_ASSERT=y and a whole bunch of stuff started failing.
The drivers which are using __ASSERT() improperly (and never tested with CONFIG_ASSERT=y) need to be fixed. They probably need to use __ASSERT_NO_MSG() instead.
by Andrew Boie:
It appears that all the sensor drivers were using __ASSERT() incorrectly. Here's a patch which fixes them: https://gerrit.zephyrproject.org/r/#/c/3467/1
by Kuo-Lang Tseng:
Andrew Boie Great. Thanks for clarification and the patch.
by Sharron LIU:
Back to "Resolved" status, so that @Ethan can re-verify with Andrew's patch.
by ethan gao:
Verified I2C address 0x48 within range -55 to 150 at conversion rate 8Hz.
by ethan gao:
Its close depends on the patch merged in ticket GH-494, so changing it to close once that patch is merged formally.
by Sharron LIU:
Closing as GH-494 patch got merged.
Related to GH-348
Reported by Anas Nashif:
Support the TMP112 sensor using the sensor interface.
http://www.ti.com/product/TMP112
This sensor is readily available on some boards supported by Zephyr (Quark SE Devboard).
(Imported from Jira ZEP-358)