I’ve been using the ST VL53L1X devboard / bare sensor for a project running on a msp430fr2355. Pololu kindly ported the ST API to Arduino, and the sensor works perfectly there.
To get it working on my msp, I’ve been using TI’s energia, a open source project to be able to run Arduino code on msp. The sensor “works”, but the readings are terrible. More specifically, the first reading works perfectly, but all subsequent readings drift upwards, and seem to vary wildly compared to running the Arduino. There is an error code with the sensor readings, Signal Fail.
I’ve tested the heck out of it. and it is NOT a hardware issue. I’ve literally run the exact same code on the msp, had bad results, and then plugged the i2c into the Arduino, and it works perfectly.
The only thing to “fix” it is to do sensor.init(); before every reading, which is obviously not workable long term, but may give a clue as to the issue.
I’ve been battling this for weeks now, and have no idea where to proceed / what to look out / what could be causing this. It is the exact same code, same libraries, same everything, except with that energia layer in the middle (which I am guessing is the problem)
I have looked at the i2c lines and recorded the transactions, which I have attached below in a excel doc. I have attempted to highlight all differences.
If anyone has any advice / suggestions, I would love to hear them!
Yes, I am using that library. I will try the direct port, that is an excellent idea. I looked at it before but got scared, will try again.
I have tried it with the exact same sensor board, and with a bare chip on a pcb for the project I’m working on, both have the exact same issue.
The Arduino is a arduino uno, but it doesn’t really matter since its working perfectly.
The sensor is giving me these errors running on a msp430fr2355, on a devboard and on my project board. I have tried other devboards of the same chip with the same issue.
Thank you for your help! Is there a guide on using the direct port?
There are a lot of files in the API, but our port includes an Arduino sketch (vl53l1x-st-api.ino) that you should be able to open and use just like any other .ino file. The other files should be compiled into the program automatically.
Interesting, so I tried out the direct port, seems to work perfectly. Had to add && !defined(_STDINT_H) to the types.h file, but after that it started right up (worked perfectly on Arduino, but I guess msp does stuff differently)
As a bandaid fix, I’ll just use the direct port for now, but it would be cool to know why the simple port does not work on msp under energia. The direct port is also a ino file using the wire library, running under energia, so it’s especially weird that it seems to work perfectly.
Thank you for your help, if you investigate and find out why the simple port has such a weird error, I would love to know. If you need any files from me, just ask :>
Thank you again!
Edit: is there any way to not use the wire library? Seems like that’s the only reason it is an Arduino file, otherwise it could be just a .c
It’s good that the ST API seems to be working fine for you. That suggests there might be some kind of platform-specific bug in our simplified library (or maybe a weird interaction with Energia). I will try to look into your I2C logs some more when I can, and please let me know if you find anything too.
If you are asking about the official API, ST provides it in a form that calls a bunch of high-level I2C communication functions, which just leaves it up to the user to implement that high-level communication using I2C code specific to their platform. That is all our Arduino port of the API does (it implements the functions in platform.cpp by calling Wire library functions; all the rest of the files, other than the example .ino, come from ST and are unchanged).
If you can write some appropriate MSP430 code to do I2C instead, then yes, you should be able to use that instead of our Wire library platform layer + Energia. If you want to go that route, you might also consider using ST’s ULD API instead; that is an “ultra lite driver” that has a smaller footprint than the full API, but can similarly be ported by writing an appropriate platform layer.
