VL53L1X time-of-flight sensor.

[markCwatson]

The driver utilizes ST Microelectronics library (which exists in modules\hal\st\sensor\vl53l1x). Platform specific headers and source files used by the library are included and adapted for Zephyr.

The driver can be configured in proj.conf to use an interrupt/polling methods and use of the XSHUT pin on the VL53L1X. All uses were tested successfully.

A sample application was developed to test the driver. Due to Zephyr's desire to limit the number of sample applications for specific drivers, it was decided to not include the sample app in this PR. There is a similar app for another time-of-flight sensor (the VL53L0X). It was recommended to adapt this other sample app to be configurable to use either the VL53L0X or the VL53L1X.

Signed-off-by: Mark Watson [email protected]

[markCwatson]

@MaureenHelm The compliance checks or failing rn due to typedefs. The STM library has some typedefs that I cannot remove. Some of the platform/HAL .h/.c files need to be adapted to work with zephyr. Therefore, some files from the library need to be included in the driver and certain definitions modifies to work in zephyr. The typedefs, for example, which are currently causing the compliance checks to fail, are types used throughout the library and cannot be changed. However, there is a similar driver for the (different) vl53l0x sensor that already lives in drivers/sensor in zephyr that uses a similar library by STM, and also has these typedefs, but doesn't appear to be an issue since it is in the main zephyr tree.

[cfriedt]

@markCwatson - you will still need to rebase on main and resolve conflicts manually. I would be happy to re-approve after that.

[markCwatson]

Thanks a bunch @cfriedt. @MaureenHelm @erwango @avisconti @nashif @stephanosio, sorry to tag you all again, this branch had a conflict that needed to be resolved, so I had to address it. Would love to get this approved/merged so I don't have to keep doing this and bug everyone to give their approvals again LOL

[MaureenHelm]

Arg....another merge conflict, so now this needs another rebase. :(

@yperess this has been a recurring problem since you reworked tests/drivers/build_all/sensor/i2c.dtsi. We need to think if there's a better way to organize this test to avoid the churn.

[markCwatson]

Arg....another merge conflict, so now this needs another rebase. :(

@yperess this has been a recurring problem since you reworked tests/drivers/build_all/sensor/i2c.dtsi. We need to think if there's a better way to organize this test to avoid the churn.

Thanks @MaureenHelm. I addressed the merge conflict. I appreciate everyone taking the time to come back again and again to give their approvals. I am going to tag everyone once again and kindly ask for their approvals so we can push this through before the next merge conflict arises: @cfriedt @erwango @teburd @avisconti @nashif @stephanosio

[yperess]

Arg....another merge conflict, so now this needs another rebase. :(

@yperess this has been a recurring problem since you reworked tests/drivers/build_all/sensor/i2c.dtsi. We need to think if there's a better way to organize this test to avoid the churn.

I'll take a look and run some ideas by you. I'll make an issue for it so we can discuss options.