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

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

[dcode31]

Posted on March 25, 2018 at 01:22

Boo ST Support! 

:((

[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