Closed dbrgn closed 4 years ago
rnestler
commented
4 years ago SHTC1 and W2 are the same digital core, they are just packaged differently. The only interesting thing is, that the W2 comes also in a W2_alt version with an alternative I2C address.
rnestler
commented
4 years ago Put features that are only available on some sensors behind those feature flags (e.g. low-power mode, which isn't available on SHTC1).
I don't think feature flags are the best solution for this. Wouldn't it be easier to just provide differently named structs which provide the additional methods?
dbrgn
commented
4 years ago SHTC1 and W2 are the same digital core, they are just packaged differently. The only interesting thing is, that the W2 comes also in a W2_alt version with an alternative I2C address.
Ok, that's not a problem, since the user supplies the address.
I don't think feature flags are the best solution for this. Wouldn't it be easier to just provide differently named structs which provide the additional methods?
Yeah, it seems that implementing chip selection with feature flags becomes a bit hacky, especially in CI. I'll try using a zero-sized generic type argument instead.
By the way, I found an SHTC1/SGPC3 devboard, so I should be able to test all variants :slightly_smiling_face:
Add feature flags:
shtc3shtc1shtw2genericPut features that are only available on some sensors behind those feature flags (e.g. low-power mode, which isn't available on SHTC1).
If no feature flag is specified, fall back to
generic, which uses conservative defaults (slowest timings). I'm not yet sure whether or not advanced features (like low power mode) should be disabled in that case or not. (Use case: A device that is compatible with multiple of these sensors and that can decide which features to use by querying the device ID.)@rnestler do you have some SHTC1 and SHTW2 devboards around for testing? I only have the SHTC3 at hand.