drivers: sensor: mcp9600: Support extra functionality from the IC

[naNEQ]

Introduction

The MCP9600 IC has some advanced functionality, such as an internal digital filter, a burst mode etc., that is currently inaccessible from the drivers. My proposal is to enable access to set of features (or part of). For reference, the datasheet of the part can be found here.

Problem description

I wouldn't say there is any problem here that we try to solve. It can be seen as an improvement of the current driver.

Proposed change

Once this change is implemented, the application can configure and use the more advanced features of the IC, such as the internal digital filter that is applied on each temperature sample, or the burst mode, where the IC samples for certain period and then goes to sleep mode to conserve power.

Detailed RFC

We can include the following features:

• Get the Device ID and the revision ID from register 0x20. This can be useful to distinguish between MCP9600 and MCP9601 and potentially decide if any fixes have to be applied.
• Get the status from register 0x04. This can be useful to read out the temperature Alerts
• Set the thermocouple type supported and enable the filter at register 0x05
• Set the device configuration register (0x06), to enable and configure burst mode, or change the ADC resolution
• Configure the four Alerts (1-4) via registers 0x08 - 0x13

As a lower priority, we could also support the following:

• Get the junction temperature delta (register 0x01)
• Get the cold-junction temperature (register 0x02)
• Get the raw ADC data (register 0x03)

Proposed change (Detailed)

What needs to be done is to create a new mcp9600.h header file in the include/zephyr/drivers/sensor directory, with the necessary function (and perhaps struct) declarations. The ccs811 has implemented similar additional functionality.

The modify the existing mcp9600.c file to implement the extra functions.

Dependencies

Just to be clear, I don't propose any modifications to the generic sensor API. Only the mcp9600 driver will be affected. Therefore I don't see any special dependencies.

Concerns and Unresolved Questions

n/a

Alternatives

n/a

[aasinclair]

Hi @naNEQ .

Adding additional functionality to an existing driver is always welcome, and doesn't need an RFC.

For this specific example, one time configuration (e.g. thermocouple type, adc resolution) can be specified in devicetree and set at init. Reading status can be done with either a custom channel ID, or get_attr, depending on what fits best.

[naNEQ]

Hi @aasinclair,

that makes a lot of sense and also great for the tips. I suggest then to close this issue, and any further discussions can be taken later on, upon a potential merge request.