Add a STM32 Digital Temperature Sensor and add it to STM32H7 family DTS

[aurel32]

Tested on a Nucleo h7a3zi board, it gives similar results as the analog temperature sensor.

[erwango]

Thanks for this addition @aurel32.
To be complete, we'd need a way to at least build this driver in CI (using samples/sensor/die_temp_polling ?)

[aurel32]

I have just pushed a new version renaming the sensor to stm32_digi_temp, the device tree compat to st,stm32-digi-temp and the node label to digi_die_temp.

I have added a board overlay for the die_temp_polling sample. It outputs:

*** Booting Zephyr OS build v3.6.0-4233-gefac3ef4f2b8 ***
CPU Die temperature[digi_dietemp@58006800]: 30.4 °C
CPU Die temperature[digi_dietemp@58006800]: 30.1 °C
CPU Die temperature[digi_dietemp@58006800]: 30.1 °C

...

[FRASTM]

Thanks a lot for adding this new driver !
It's a interesting enhancement

[erwango]

Few late comments that I forgot to commit, sorry.

[erwango]

Thanks for the changes!

One very last request and this will be fine to me:
Unless I'm wrong, you'll need to add nucleo_h7a3zi_q as integration platform to the sample to ensure it is taken into account in test campaigns.

(We'll also need to tune this later on to get it ran on our test bench, but we'll take care of it).

[aurel32]

One very last request and this will be fine to me: Unless I'm wrong, you'll need to add nucleo_h7a3zi_q as integration platform to the sample to ensure it is taken into account in test campaigns.

That should be done now.

[erwango]

Thanks!

[ubieda]

Non-blocker suggestion: should we have a fail-safe on the while-loop and k_sem_take()? I'm thinking of returning -ETIMEDOUT or similar in case the happy-path does not work.

[aurel32]

Do we really need to do that with K_FOREVER. Looking at the documentation, it could return:

• 0 – Semaphore taken.
• -EBUSY – Returned without waiting.
• -EAGAIN – Waiting period timed out, or the semaphore was reset during the waiting period.

It seems that the -EBUSY case can only happens when using K_NO_WAIT. For -EAGAIN, the period timeout can't happen as K_FOREVER is used, and the semaphore reset also can't happened as it is only initialized in stm32_digi_temp_init as part of the driver initialization.

Therefore I don't think we need to add a while loop around it. In addition, I haven't found such a structure (with K_FOREVER) elsewhere in the Zephyr's code.

[ubieda]

Perhaps I didn't explain myself:

WRT the while-loop: I'm referring to

	while (READ_BIT(dts->SR, DTS_SR_TS1_RDY) == 0) {
		k_yield();
	}

WRT the semaphore: I'm alluding of a scenario where the semaphore is not given, therefore the execution path is blockde. Handling such case involves changing the semaphore from K_FOREVER to a specific timeout and handling the error-codes you described.