VL53L0X Register Map?

[wayne23]

Posted on June 13, 2016 at 21:32

Having previously used with the VL6180X, I expected the VL53L0X to be similar in architecture.  However, while I found a somewhat useful data sheet, it does not seem to contain a register map.  It seems I'm supposed to use the example source code to understand how to program the VL53L0X.  However, I find the example code to be written in a way I'd almost call obfuscated because of the dense use of &sharpdefines to recursively redefine things.  It's taken me nearly 2 hours to unravel and understand just the VL53L0X_DataInit() function.  Is there a register-level description of the VL53L0X available?  If so, I can't find it.

Wayne #vl53l0x

[smenor]

Just throwing in another « this is absurd »

How is it too big of an ask to get a simple register map with a few basic flows for calibration and taking measurements ‽

Your ToF sensors seem great but this makes them either entirely unusable for our application or will require us to spend who knows how many extra hours reverse engineering the map from your not exceptionally well written device driver.

[smenor]

[dislike and boo]

It's great that you did the fine tuning but it's not at all hard to put the register map in a data sheet along with a few simple bits of pseudocode that show users how to do standard calibration and measurements.

[Tvan .13]

I have searched the ST website and I end up here, seeing this conversation.

I mean, SERIOUS??

So what if I can't use your API because I run my software on a different processor and platform.

The product being complex is fair enough. And I don't need to know the intricate details of every available register.

But the very very least ST should provide is the registers that do matter for an application engineer. And example code to show the proper way of initializing the sensor and getting proper data out of it.

It's not sufficient to say: look at the reversed engineered code of third parties.

The sensor looks great, with the capabilities that I need for my project. But without proper documentation, it's very hard to develop software that ensures reliable functioning of the sensor and the system.

Please provide at least that: a "user register map" with explanation on what effect the value in that register has. And some (pseudo)code showing how to kickstart it into a properly working configuration.

[smenor]

This /\ was exactly my problem - we're using a Nordic chip not an ST microcontroller (and no we're not changing) and literally just a list of registers along with some pseudocode would have gotten us there. Instead we finally gave up and found a work-around in our current device (mounting the ToF sensors at an angle other than perpendicular to the glass significantly decreases cross-talk interference and still is usable in our application for anyone looking for a work-around) and we're absolutely ripping these out of our future designs and putting something else that's properly documented in.

[Tvan .13]

As I am at the start of this development I am open to suggestions for a properly documented TOF sensor that is affordable and (during this crazy ties) "available".

Feel free to post suggestions here or at "tjarke" in the google mailbox

Currently I am checking the API. As I have to doubt everything when documentation is lacking, so doubting if I have the proper API code at hand to analyze, it took me some unnecessary time to figure out why the datahseet mentions I2C address 0x52 while the API uses 0x29. There are no comments and it took me some time to figure out that 0x29 is the higher 7 bits of the address. Just one example of wasting time on searching for the undocumented "obvious".

[smenor]

I don’t have any advice but if you don’t need to use crosstalk correction you can much more easily get the algorithm bits / usable pseudocode for normal use from the Adafruit and apology arduino libraries (the ST one is nicely structured and passably commented but you have to go back and forth between N files to get the registers and values so I found it much harder to work from and ended up just using it as a reference)

You can really feel that nobody building anything is directly involved in making these data sheets. They have another newish cool part with multiple zones and when we implemented that in a design there was no footprint and the drawings they have had some parts but left us guessing at many dimensions.

[Tvan .13]

Crosstalk is probably an issue in my design. Currently I'm checking the MIKROBUS implementation and build on from there. Thanks