Sensor start after boot time or restart because low bat (I2C)

[MarkusK]

Hello,

it's a nice concept to include sensors via the device tree and simply enable them in the project file. But I feel like I'm losing control of the sensor a bit. I don't have access to the direct sensor functions of the library. The sensor is initialized directly when booting. For example, what happens if I have a separate battery-powered sensor and I need to replace the battery? After that I have to restart the SoC (Zypher) as well, otherwise the sensor no longer works in many cases because it has to be reinitialized. I can't seem to invoke the initialization manually.

The same if I want to plug a sensor on and off? With I2C communication I can do this directly, but with the device tree the sensor apparently only works via the driver if it is active at system start.

Do I understand something wrong? Or is there a more convenient solution for this? Switching the power mode didn't work on the SHT31 and I don't want to have to patch drivers either. Then I prefer to program the sensors directly via I2C.
And how do I integrate the header file of a sensor? For the CCS811, for example, this works with
#include <drivers/sensor/ccs811.h>

Why doesn't that work with the mcp9808 or sht3xd header file?
#include <drivers/sensor/mcp9808.h> or #include <zephyr/drivers/sensor/mcp9808/mcp9808.h> didnt work.

Also what is with error handling? If i unplug a sensor i get error code -5 with calling the function rc = sensor_sample_fetch(mcp9808_dev); Is there an explanation what this code means?

Regards
Markus

[Edvin]

Hello Markus,

There are a lot of things going on under the hood if you use the Zephyr configurations, and especially for the sensors, where almost everything is done in the background.

As an option, you can try to use the I2C drivers from Zephyr, which will still set up most things in the background, but it will allow you to decide what to send over I2C more directly, leaving you with more control. Alternatively, you can use the NRFX drivers for the TWI (TWI=I2C), allowing your application to decide when to initialize the I2C, and what you want to send at what times.

Best regards,

Edvin

[MarkusK]

Hi Edwin,

thanks for your answer. I am still quite new to the nrf connect sdk and zephyr. I used nrf5 sdk before. I'm still trying to get used to the new structure from zephyr. I am working already a long time with sensors and for my opinion, it is difficult to make a simple interface like in zephyr which satisfies the needs of all sensors. Even if it is nice for fast testing a sensor, I would prefer to have access to the direct library of a specific sensor.

I already successfully use the i2c driver from zypher and it was not difficult after I found out how to get the device tree reference from the i2c device.

What is the advantage from the nrfx drivers for TWI and how can i use them? Do i have to disable I2C support in zephyr then (device tree and project file)? Which library i have to include? I heard that for IMUs for example it is better to control them directly over I2C because of the high frequency of the sensor data. Is it ok to use the zephyr i2c driver then or is the nrfx driver better suitable?

Regards Markus

[Edvin]

MarkusK said:

What is the advantage from the nrfx drivers for TWI and how can i use them?

The Zephyr drivers actually use the nrfx drivers under the hood. But some times, the nrfx drivers are more versatile, because the Zephyr drivers needs to cover all possible ICs. But there are some cases where you need to use the nrfx drivers to set the correct clock speed for a peripheral, and things like that. And other times, if you want to disable a peripheral, there is no easy way to do so using the zephyr implementation, so you would need to use the nrfx drivers in those cases. The advantage of using the Zephyr drivers is that it is often more plug-n-play. 

MarkusK said:

Do i have to disable I2C support in zephyr then (device tree and project file)?

No, but you need to not enable the I2C drivers in your prj,conf file, but rather enable the NRFX equivalent. (CONFIG_NRFX_TWI=y in this case).

MarkusK said:

I heard that for IMUs for example it is better to control them directly over I2C because of the high frequency of the sensor data. Is it ok to use the zephyr i2c driver then or is the nrfx driver better suitable?

That depends on whether the frequency of the I2C that the IMU uses is supported in the zephyr driver, and if not, whether it is supported in the nrfx driver.

Or if you mean that the processing of messages takes longer in the Zephyr driver, and the frequency of incoming messages is high, then it may be true, but I would think that this would be neglible.

Best regards,

Edvin