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

[will23]

Posted on October 28, 2016 at 12:03

As old as this post is, and unanswered by anybody, I feel I have to add my voice to this.  It is pathetic that ST don't provide a proper data sheet with a complete register map and it probably needs an application note to so we can get on with developing products with the VL53L0X in rather than having to suffer your poor obfuscated WIN32 oriented horror show of a software implementation.  It is far from lint free.  It is not close to compiling for me (ADI Blackfin CCES).  It is odd, non standard, layered, confusing and of no interest to me.  Get a grip.  Give us the data sheet we need not some code to reverse engineer to get to a confused understanding of a register map and what we should do with it.

Please.

I have just completed writing a driver for your LSM6DS3, I had not realised I was so lucky in having a data sheet with a register map and detailed descriptions in ... why not do the same for the VL53L0X?  What are you hiding? :)

[mrosing]

Posted on October 28, 2016 at 16:04

If this was on DSPRelated I'd punch the ''have a beer!!'' button.  I completely agree.

[mrosing]

Posted on November 14, 2016 at 21:23

Here is the reply I got from ST support:

Resolution Summary:

SOLUTION PROPOSED BY SUPPORTER - 14/11/2016 18:03:12 :

---------------------------------------------------------------------------------

Hello,

VL53L0X is a complex device. 

Registers description is not possible for this device due to complexity.

It contains hundred of registers with inter-dependance and not straight forward content.

Then, the choice has been to not provide a register list, but instead develop an friendly API.

You can download the API and user's manual on st.com/VL53L0X. </span>

Regards, 

ST Support

============================================

The assumption is that we engineers are too stupid to comprehend the complexity of the device so it's all hidden behind an API so our poor little minds don't have to deal with.

Some of the microprocessors I deal with come with 1800 page manuals that reference several 800 page documents that deal with the peripherals.  If ST thinks this range sensor is more complicated than that, then they should just write a longer manual!!

It's absolutely absurd to not document a device for general application use.  It was fun to play with, it did not work well in my application, and now I give up.  I have a lot of manual pages to read for all the other things I need to design with, I don't have time to mess around with a toy.

Mike

[dcode31]

Posted on March 25, 2018 at 01:22

Boo ST Support! 

:((

[ericcanfield9]

Posted on November 23, 2016 at 06:48

I totally agree, Mike.  The VL53L0X looked like the ideal solution for a high volume product that we have been retained to design for a client, but the API is a joke.  Your comment about the processors was right on (1800 page manuals, etc.).  I laughed when I read the ST response about ''an friendly API'' because when I read it quickly the first time, in my mind it came out ''unfriendly API'', which describes the API perfectly.  ST, if you're monitoring your own forums, you might want to rethink publishing the registers.

[Didier Longueville]

Posted on July 12, 2017 at 23:28

I am in full agreement with the previous messages: poor documentation, poor API code. Although I understand the business concerns from ST side, ST should understand the final user concerns: why and how could I promote this type of sensor for critical applications ? How shall I build a software validation strategy based on such a weak documentation ? The answer is no way. Ultimately, I feel like I lost my time investigating this promising chip. Too bad.

PS: I also full disagree with '

Registers description is not possible for this device due to complexity' . Smell fishy. Makes me feel like unresolved questions are still pending, which amplifies my concern for resigning from using the chip.

[mariankeller]

This is madness. How could the register map be possibly too complex to understand?

That API also is a bad joke. Planned on using this sensor in future projects, now I really have to reconsider if there are any alternatives with a better documentation, or reversre-engineer that "API".

[JCast.5]

This is nonsense and lack of respect with us!

[John E KVAM]

Far be it for me to defend ST - I just work here. :)

But here's the thinking.

You probably could write a driver from the register map.

And when you were finished, you would absolutely hate ST.

And as the guy who would have to support your effort, it would be **** ** both of us.

It took us a couple of years fine-tuning all those registers before it got to a point were we could release the driver.

if you don't like our driver, get the one from Pololu. Or from Sparkfun.

They have both reverse engineered the code and done a pretty fair job of it.

But you have enough work to do without digging deep into the chip's registers.

It's painful - believe me. There are many hundreds of registers and they are not easy to understand without a whole lot more documentation than we have.

• john

[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.

[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.

[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.