avsa242/sht3x-spin

Parallax P8X32A/Propeller, P2X8C4M64P/Propeller 2 driver object for the Sensirion SHT3x Temp/RH Sensor

sht3x-spin

---

This is a P8X32A/Propeller, P2X8C4M64P/Propeller 2 driver object for the Sensirion SHT3x (30, 31, 35) combination temperature and relative humidity sensors.

IMPORTANT: This software is meant to be used with the spin-standard-library (P8X32A) or p2-spin-standard-library (P2X8C4M64P). Please install the applicable library first before attempting to use this code, otherwise you will be missing several files required to build the project.

Salient Features

• I2C connection at ~30kHz (P1: SPIN I2C), up to 1MHz (P1: PASM I2C, P2; max tested speed 840kHz)
• Measurement in one-shot (with clock-stretching) or continuous modes
• Supports all three measurement repeatability modes and five data rates
• On-chip heating element operation
• Reading the sensor's serial number
• Supports alternate slave address
• Set interrupt thresholds
• Optional reset pin

Requirements

P1/SPIN1:

• spin-standard-library
• 1 extra core/cog for the PASM I2C engine (none if the SPIN I2C engine is used)
• sensor.temp_rh.common.spinh (source: spin-standard-library)

P2/SPIN2:

• p2-spin-standard-library
• sensor.temp_rh.common.spin2h (source: p2-spin-standard-library)

Compiler Compatibility

Processor	Language	Compiler	Backend	Status
P1	SPIN1	FlexSpin (5.9.23-beta)	Bytecode	OK
P1	SPIN1	FlexSpin (5.9.23-beta)	Native code	OK
P1	SPIN1	OpenSpin (1.00.81)	Bytecode	Untested (deprecated)
P2	SPIN2	FlexSpin (5.9.23-beta)	NuCode	FTBFS
P2	SPIN2	FlexSpin (5.9.23-beta)	Native code	OK
P1	SPIN1	Brad's Spin Tool (any)	Bytecode	Unsupported
P1, P2	SPIN1, 2	Propeller Tool (any)	Bytecode	Unsupported
P1, P2	SPIN1, 2	PNut (any)	Bytecode	Unsupported

Limitations

• TBD

sht3x-spin's Issues

Implement raw data methods

Implement methods to return raw Temp/RH sensor data from the device, for those that wish to do their own processing on the data. Right now, only a method that returns temperature in hundredths of a degree (e.g. 21.05 degrees C would be returned as 2105 centi-degrees C) and the equivalent for RH is implemented. This is due to fixed-point integer-only math.

Make better re-use of code

Initially, code re-usability was actually better than it is now, but it was found to not work 100% of the time. This is mostly in reference to the lower-level I2C bits that happen in the driver. There were methods dedicated to reading bytes off the bus, rather than having separate instances in each calling method like now, but it turns out the way some registers are read from/written to isn't done exactly the same way as the others.
Some commands require an I2C stop (P) condition after the write header and command word are sent, while others expect the opposite. Some read transactions require delays added to parts of the transactions or they won't function properly. Others don't have this requirement.

Clean up RH/Temp methods

The GetRH/Temp-related methods need to be cleaned up. Currently, there are four relevant methods:

GetTempRH(repeatability) - This is the one that actually retrieves the data from the sensor. The data are stored in two VAR words, one for temperature, one for RH.
GetTempC - This calculates and returns the temperature in hundredths of a degree Celsius for whatever the contents of the temperature word are.
GetRH - Works the same as GetTempC, for RH.
GetTempRH(ptr_word__temp, ptr_word__rh) - This calls GetTempC and GetRH and writes their return values at the address of the calling parameters.

Most of this mess was created by re-implementing things during development as things broke.

Calculate thresholds based on TempScale()

The temp interrupt threshold parameter is currently only accepted as Celsius. Read TempScale() to determine the correct scaling for the parameter given.

Implement proper I2C transaction validation

Proper handling of I2C transactions aren't handled (i.e., an unexpected NAK from the sensor), at least not consistently.

Support compile-time selection of I2C engine (P1)

For applications where data acquisition speed isn't as critical, but memory usage is, or an extra core can't be spared, support for the SPIN I2C engine should be added.

Interrupt thresholds don't get written

The interrupt thresholds aren't actually getting written - if a new threshold is written, and then read back from the chip, it returns the POR default value, $CD33.
Two issues:

1. the (required) CRC byte isn't actually getting written in writeReg(), because the nr_bytes param is still set to 2, so only the first 2 bytes of ptr_buff, the threshold itself, are written. Without this byte, the sensor rejects the updated threshold.
2. If the code is fixed to include the CRC byte, then the next command to read back the threshold still fails, because the sensor doesn't acknowledge the command ($E11F). Adding an arbitrary delay after the stop condition seems to fix this, though there isn't any mention of additional delays required when setting alert thresholds in the appnote.

Implement methods to set tracking alerts

Implement methods to get/set tracking alerts for RH and Temp.
Once an alert is supposed to be triggered, verify the ALERT pin is asserted on the device and the relevant bits in the status register get set.

Continuous measurement mode inop

Setting the operating mode to continuous (opmode(CONT)) has no effect. Nothing can be seen on the I2C bus when this method is called.

Add interrupt demo

Add code to demonstrate the sensor's interrupt capabilities.

Investigate implementation of repeatability mode

Investigate a better way to implement repeatability mode. Maybe make the mode a global VAR state and have a discrete method to set it (SetRepeatabilityMode)?
Right now it's set on every call to GetTempRH

Validate periodic measurement mode

The periodic measurement mode (ContinuousRead, FetchData, Break) functions haven't been validated. In a very cursory initial test, they didn't seem to function properly, if at all.

IntTempLoClear() returns 0 when querying current setting

When IntTempLoClear() is called with an out-of-bounds value to query the current threshold, 0 is returned for most cases.