Why does VL53L1X full API take up SO much memory?

[MRasm.1329]

So I am working with a VL53L1X sensor on a LPC804 from NXP. I am using the full API (STSW_img007). I made a simple test to see if I could get the I2C functions running allright, so I tried to read out the model ID. When I was successful, I wanted to move on to see if I could make some measurements and get the data out. So I plugged in some code I found in an example to get started, but suddenly I did not have enough memory from my code. I can see that the code jumpes from around 12KB to a whooping 38KB just by implementing these test functions.

So now I cant go further, because the code is too large. It says on ST.com that the full API would take up around 9KB, so I have no idea why this is happening.

Does anyone know why it takes up so much memory and what I can do about it? The two pictures show my test code for I2C and my code for range measurement.

Bonus question: I tried to look at the .map file that is generated when I build the code in order to determin what was taking up so much space. My .map file was hard to get any useful data out of, because there were so many debug.o files. Is there an easy way to turn off the logging function in the VL53L1X full API? I am asking as I suspect that the debug.o files are from the logging function.

Thanks

[S.Ma]

Search for en.STSW-IMG009.zip instead.

and let me know.

[John E KVAM]

​The ST UltraLite Driver (STSW-IMG009) is exactly what you need. 2K of ROM and some 38 bytes of RAM.

Granted the ULD is not as complete as the full driver, but it should cover some 90% of the needs.

And if you need a function from the full driver that is not in the ULD, it's easier to extract that function from the full driver and move it across than to remove functions from the full driver.

We made the ULD specifically for customer's such as yourselves that were short on memory size.

It works a little differently in some cases - such as setting ROI's - but that's because we refused to use code to make it identical. The ULD works the way the hardware does - even if it's less easy to understand.

One note: In the ULD the 'dev' first argument is not a structure - as you would expect from a Linux driver. It's an 'int' - and it's the I2C address of the chip.

As I said,  it's a small implementation. 

-john