MS8607 (PHT Click) sensor data over I2C and a driver on nRF52840 DongleReading

Question

Hello! I have started building an IoT test node using nrf52840 Dongle and MicroE MS8607 (PHT Click) sensors (please see the setup below). The functionality we are interested in is reading the sensor data over i2c and sending it via UART to the PC. 
 The whole solution will be realized under Zephyr RTOS, therefore i2c configuration needs to be adapted as per Zephyr official docs: I2C Zephyr Project Documentation ; Zephyr API for i2c Bus . 
 
 At the current stage it will be at user space, using kernel functions, i2c and UART for serial communication. I am developing under Linux Ubuntu 22.04 LTS, using Sublime Editor for code writing, Linux console for building an app and CuteCom for serial communication testing. nRF Connect for Desktop and it's tools as well as VS Code IDE aren't used. 
 Since I am pretty new into the embedded software development field (mostly did web-app programming), there are main things I am confused about: 
 
 How to declare ic2 device combining nrf libraries, Zephyr packages and taking into account the manufacturer's recommended settings. 
 What is an approach and key-points of writing a driver for this particular solution? 
 The main confusion lays within where to start optimally as I am a bit with how to ensure all the compatibility as well as I haven't seen any sample solutions or demos for this sensor. 
 
 * Native PHT Driver from manufacturer (MikroE): 
 pht.zip 
 Has anyone out here already worked with MS8607 (PHT Click) sensor on nRF52840 Dongle (PCA10059) through Zephyr RTOS? 
 Would appreciate any guidelines and approach. 
 
 Thank you in advance! 
 p.s: Undoubtedly, it would be better to start with something more user clear (such as nRF52840 Development Kit or Arduino) but this time it is not an option, and I need to develop a solution using only the above mentioned hardware. 
 Sincerely Ingrid 
 Setup 
 
 Sensor Data sheet: ENG_DS_MS8607-02BA01__C3.pdf

haakonsh · Accepted Answer

I suggest you drop MikroE's driver completely as it is written for a different system and rather use the manufacturer's. TE Connectivity has a generic driver: https://github.com/TEConnectivity/MS8607_Generic_C_Driver/blob/master/ms8607.c.

For Zephyr integration:

The MS8607 contains two I2C slaves with different I2C addresses, so you might need to create 2 child nodes under the I2C bus node that you intend to use.

I suggest that you study the drivers of other I2C sensors in zephyr and note how it uses the I2C drivers. F.ex zephyr\drivers\sensor\lis2dh\lis2dh_i2c.c

Here's a typical I2C Devicetree node for an lis2dh12 sensor:

&i2c1 {
	compatible = "nordic,nrf-twim";
	status = "okay";
	clock-frequency = <I2C_BITRATE_FAST>;

	pinctrl-0 = <&i2c1_default>;
	pinctrl-1 = <&i2c1_sleep>;
	pinctrl-names = "default", "sleep";
	lis2dh12: lis2dh12@19 {
		compatible = "st,lis2dh12", "st,lis2dh";
		reg = <0x19>;
		irq-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
	};
};

Note that most sensors in Zephyr uses a higher abstraction Sensor API on top of their drivers, and you will need to ignore that. Unless you want to use the Sensor API for your device, then you will need to write a Sensor driver implementation for the ms8607 as well.

nRF Connect for Desktop and it's tools as well as VS Code IDE aren't used.

I strongly advice you to use these tools, they exist for good reason.

p.s: Undoubtedly, it would be better to start with something more user clear (such as nRF52840 Development Kit or Arduino) but this time it is not an option, and I need to develop a solution using only the above mentioned hardware.

If you don't have access to a compatible debugger (DK has one) you are setting yourself up for failure.

ingridal · Answer

I will check them thank you. The overall approach is much more clearer now, and I will start working within the available resources. 
 Referring to your comment about the lack of a compatible debugger makes me worry either - does not seem a good perspective for developing an efficient solution but it is an issue to solve within our team. 
 Really appreciate your time and consideration.

haakonsh · Answer

You're doing pretty good tbh, it seems you've got a good understanding of how to write a device driver for zephyr. I think what's missing is mostly down to debugging/verification. For instance, you should verify that the commands you send to the sensor are valid. I suggest you scope the serial communication to the sensor and verify that the data you transmit and receive are as expected. About enums and bit-fields: i f a given bit-field is represented numerically by a set of enums, it is vital that you never assign a numerical value to variable containing such a bit-field other than what can be represented by the given enum: enum ms8607_pressure_resolution { // Numerical value: ms8607_pressure_resolution_osr_256 = 0, // 0 ms8607_pressure_resolution_osr_512, // 1 ms8607_pressure_resolution_osr_1024, // 2 ms8607_pressure_resolution_osr_2048, // 3 ms8607_pressure_resolution_osr_4096, // 4 ms8607_pressure_resolution_osr_8192 // 5 }; From "Figure 3: Command structure for pressure and temperature sensing" in the sensor's datasheet we find the OSR bit-feld in the command byte for the pressure and temp sensor: Command byte hex value Bit number 7 6 5 4 3 2 1 0 bit name PROM CONV - Typ Ad2/ Os2 Ad1/ Os1 Ad0/ Os0 Stop Command Convert D1 (OSR=2048) 0 1 0 0 0 1 1 0 0x46 Here you can see that the 3 bits named Os0 - Os2 makes a bit-field that represents OSR, and where an OSR of 2048 is represented numerically as the binary number 0b011, or 3 in decimal. I've only included the one command in the table above, but from the complete table it will be clear that if you assign a numerical value to the OSR bitfield that is larger than 5 (0b101) the command byte will be undefined. Worse, if you assign a numerical value to the OSR bit-field greater than what can be represented by 3 bits ( > 7dec, or 0b111) you can overwrite the other bits in the command byte. F.ex. cmd = ms8607_pressure_resolution_osr_8192 * 2; // 5 * 2 = 10 Here cmd will have the value of 10dec or 0b1010. This means that now the Typ bit has the value 0b1 and the OSR bit-field has the value 0b10. This command byte might still be a valid command according to the datasheet, but it will the one you want. The lession here is that you need to validate, or at least sanetize input parameters, and that can easily be done with enums. You can for instance add a line to ms8607pt_conversion_and_read_adc() to check whether OSR is of a valid value or not: if((cmd & (0x7 << 1)) > (ms8607_pressure_resolution_osr_8192 << 1)){ // Throw error! OSR > 5 is invalid! } // (0x7 << 1) == 0b00001110 // (ms8607_pressure_resolution_osr_8192 << 1) == 0b00001010

MS8607 (PHT Click) sensor data over I2C and a driver on nRF52840 DongleReading

Top Replies