Closed enelson1001 closed 3 years ago
Disclaimer: I've not read the whole data sheet so I might be missing something.
Based on table 9 in the spec it seems to me combining the existing write and read functions should work. My intention with these methods was that they do the ground work to follow the i2c spec and combining them yields the desired write/read sequences needed for the specific device assuming the expect_ack
, use_restart_signal
and end_with_nack
are correctly set.
The 16-bit register you refer to must the the command bytes, They are not an register address so they can we written with the write command.
I don't think I've used clock-stretching, but if it is handled by the underlying driver then it might work as-is. It is also an optional mode of the device so it is not a must to use.
Lastly, the delay between sending commands to the device can be easily handled by checking against a timestamp of the last command and waiting until 1ms has passed.
I plan on submitting a pull request for this sensor today or tomorrow. The PR will include a new function added to I2CMasterDevice called
read_block(uint8_t address, core::util::FixedBufferBase<uint8_t>& data, bool end_with_nack)
This new function does not include the i2c_master_write as the current read does but only implements the i2c_read.
This new function allowed me to read data from the SHT30.
You can close this discussion since we can discuss further in the PR. If you don't like the name of the function then the name can be changed during the PR process.
I'm working on adding the SHT30 - temperature and humidity sensor. The current I2C Master implementation would need updating. Reading data from the SHT30 is where I have the problem. The current I2C Master implementation for read from an i2c_device is performs a i2c_write + slave address + slave register(8bit) followed by a i2c_read + slave address + get the data. For the SHT30 it just needs the i2c_read + slave address + get data. I couldn't use the current i2c_read implementation because (1) it only supports a slave register (8bits) while the register on the SHT30 are 16 bit and (2) there needs to be delays between the write and read.
Question 1
Question 2
The SHT30 can also use clock stretching which I think means the delays would be handled by the I2C bus so we would not need to implement software delays. From the data sheet: When a command with clock stretching has been issued, the sensor responds to a read header with an ACK and subsequently pulls down the SCL line. The SCL line is pulled down until the measurement is complete. As soon as the measurement is complete, the sensor releases the SCL line and sends the measurement results. 2.1. Will the current I2C Master implementation have any problems with this? 2.2 Any threading issues?
Datasheet
I have attached the datasheet of the SHT30, if your interested.
SHT30.pdf
Lastly
Let me know how you want me to proceed.