How do you take VL53L1 readings with I2C?

[DOCon.1]

I'd like to use a ST VL53L1 to measure distance, but am thoroughly confused by the API. It uses a standard I2C protocol per the datasheet.

In lieu of instructions on how to configure and take readings, the datasheet points to a separate document: UM2133. This describes an API as a set of C function calls, ideally from Linux. I've no idea how to get started with this. I'm not even using C (Rust).

Is there a fallback I2C register-based API to use? How do you call a C function from I2C? I've never come across a device that works this way before! What does it mean by Host? What does Linux have to do with an I2C IC? Thank you.

I just want to have this thing send readings over DMA to my STM32.

[AlexCloned]

As an ST customer I highly recommend you to use evaluation kit P-NUCLEO-53L1A2, if you are using VL53L1CB, or evaluation kit P-NUCLEO-53L1A1 if your device is VL53L1CX. You can start from a functional example there, evaluate sensor capabilities, and then do the workarounds to adapt it to your hardware.

So far (jan-2022) UM2133 library is only usable through that hardware and through STM32CubeMx environment. Yes, it is a bit weird to find a datasheet that un-completely describes a product unless you use a dedicated library, that today still does not support other hardware than Nucleo expansion boards.

I understand this line of devices is the state of the art in ToF sensors, it is in constant evolution, and until it is stabilized the only way to get supported by ST is through the use of these set of libraries.

[John E KVAM]

First let me say - I'm old. Heck your parents are probably my age. And when I started there were over 50 popular compilers. I learned Fortran and APL, I had a go at Cobol. And there were lots and lots of others.

But Linux was written in 'C', and that held great sway except in the scientific community. Then C++ added complex numbers (and a bunch of other stuff that were not important) and we were all happy.

But Rust is a new one on me.

The problem with the VL53L1s are their complexity. It's not one or two registers you have to twiddle, but thousands. When the chip was invented we put in so many registers so we could adjust the sensor because we didn't really know the answer. And we used c-code to converge on the right settings. Publishing the register map of hundreds and hundreds of registers would just cause you to run away. I suppose you could do it, but in then end you would hate ST.

Over time we converged on a solid core of settings, and developed the VL53L1X Ultra Lite Driver. It's only a few hundred lines of the most simplistic code we could develop. No structures were allowed. Nothing that was not plainly obvious.

If I were going to try to use the VL53L1X, I'd start with the STSW-IMG009

VL53L1X ULD API (Ultra Lite Driver Application Programming Interface)

and I'd convert it.

It's so fundamental, with a little luck, it's a matter of syntax.

If you don't use the STM32, the only inventing you will have to do will be the hardware interface where the functions have to communicate with the I2C.

• Consider C2Rust. The C2Rust project is developing a tool that translates C to semantically equivalent Rust. There is an online demo of it working here.

Might give that a shot.

• john

[DOCon.1]

Thank you very much - that answers my question, and the design decisions (Many regs, lots of ways to configure, and an official software API) makes sense in context. I'll dive into that library, either to use as a reference, or use FFI (Or the C2Rust info you posted).

Do you need to use the Eval board as Alex said, or will the IC on its own work with STSW-IMG009 ? Thank you.

[DOCon.1]

• (See reply above, vice Answer)

[John E KVAM]

I always suggest getting the Eval board. There are two things you have to consider.

One, is the physics of light. It doesn't do exactly what you expect unless you really study it. The Eval board will enable you to figure out if the sensor will work in your application.

An next you need an running example. The examples we put into the release can assist you in trying ideas out. There are lots of ways to set up the sensor and with the eval board you can try them out. The code is free, the STM32_CubeIDE is free and using those you can try things.

But the sensor itself takes commands via I2C and returns answers the same way. In our code if you don't want to use the STM32, you don't have to. (But don't tell my collogues in the STM32 group.) But you need to write the interface between the sensor and the CPU. Basically the platform layer - in platform.c

• john

[DOCon.1]

Thank you for the detailed information. I'll order an eval board, and have a go at porting the ULD library. I skimmed it, and it seems quite approachable!​

​

The fact I'm using an Stm32 for the MCU is a coincidence, but it can't hurt here!​

[John E KVAM]

I had a go at the C2Risk. It was a horrible failure. Apparently it did not like the typecasting of the error returns. First thing to do is switch that back to an int and it will work better. Bu then I had to move to something else.

Good luck.

• john

[DOCon.1]

I appreciate the effort there! I'm hand-translating it; almost done. I figured the auto translater would have trouble ​with accessing the I2C peripheral at least. I'm trying to use a type alias for the int returns; if that doesn't compile, I'll just use an int as you said, or the rust Result type.