Add sensor firmware upload API support

[avisconti]

Add sensor API to perform a "firmware upload". This new driver API is then used as a vehicle to upload a ISPU configuration into lsm6dso16is sensor (see ST ISPU for more details).

This PR is also changing the lsm6dso16is driver and modifying the x_nucleo_iks4a1 shield sample.

[github-actions]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_st	zephyrproject-rtos/hal_st@9f81b44 (master)	zephyrproject-rtos/hal_st#26	zephyrproject-rtos/hal_st#26/files

Additional metadata changed:

Name	URL	Submodules	West cmds	module.yml	Blobs
hal_st		🆕

⛔ DNM label due to: 1 project with PR revision and 1 project with metadata changes

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[thedjnK]

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

[avisconti]

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs.
Am I missing something?

[thedjnK]

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

[avisconti]

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

host_firmware is part of the repo but is not relevant inside zephyr. Would that be an issue anyway?

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

OK, these two examples are in fact what it has to be uploaded.

[thedjnK]

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

host_firmware is part of the repo but is not relevant inside zephyr. Would that be an issue anyway?

It can't be hosted on a zephyr repo

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

OK, these two examples are in fact what it has to be uploaded.

But they're binary blobs right? Like I can't take them and use them on some other device?