VL53L0X or VL6180X

[PrinceNai]

Hello all,

I wonder if anybody here ported the code for VL53L0X or VL6180X from ST's API on PIC?

Best regards

[Ttelmah]

You only need to provide the I2C functions from CCS.
The rest of the library will basically compile pretty much 'as is'.
However you need a largish PIC. The code won't fit on a PIC16. Needs a large PIC18 (and on this some tweaks because the sizes won't be what is assumed), or easier on a PIC24/30/33. There is some fairly bulky maths in the calibration stuff in particular.

[PrinceNai]

Ttelmah,

Thank you for your answer. To do it from ST's API is a task way above my level of knowledge. However, I did find an example on Mikroelektronika's site, where I translated their functions to CCS and it finally compiles OK. I'll put the board together tomorrow and check if it actually also does anything :-) .
Regards

[PrinceNai]

No luck. I guess the solution is to buy an Arduino board for $3, learn their dialect, use their proven working libraries, dirt cheap shields and spend my time with actually developing instead of wasting it with just trying to port code for a 4 pin thingie. All for the sake that CCS code be debugged in Mplab (and don't hang me, even simulated in Proteus). This time it just wasn't worth it. I do not know the unit for frustration, but mine is sure in mega range.

Thanks again, Samo

[temtronic]

well does the hardware work ?
It's just a simple 3 volt I2C peripheral.
so q1. did you use a 3 volt PIC? If not, did you use some form of logic level conversion ??
q2. did you compile and run PCM P's "I2C scanner" program? if yes, what ADDRESS came back for the device ? Some still use the I2C 7 bit address while others(most) use 8 bit to communicate with I2C devices( CCS does, as do I). you can't port 7bit I2C code to CCS without making some simple changes though !!
Until you prove the basic hardware is working NO software will work, well correctly at any rate.

There hasn't been any peripheral in the past 25 years of 'playing with PICs' that I haven't been able to use with a PIC and CCS C and that's from the 'stone age' years of quartz windowed 16C71s and 15 minute erase times. Some were easy, some weren't. It takes a LOT of reading and bench testing to get stuff to work though these days it's child's play...premade modules, code all over the net...LOTS of access to help like this forum.

I'll lay odds the amount of time you wasted on Proteus alone, I could have had the TOF 'up and running'.

Jay

[PrinceNai]

Dear temtronic,

The hardware works just fine. I did use I2C scanner and it returns the correct address (0x52). It has level shifters, so it works on 5V. As far as I remember, I never said CCS can't do it. I'm sure it can. What I said is that I'm not able to do it in CCS, because it's way too complicated for me to port the code to it. Have you checked the API? 21 .c and .h files to get a "simple" peripheral running. I'd understand if it was a complete nuclear power plant. But it's a range finder, for Christ's sake. That is the reason I believe it's easier to go either for a different chip that has libraries for this particular sensor or even better, for a different sensor.
Regarding Proteus, you'd lose even on 50:50 odds. I use it to draw my circuit and 95% of my time with it to draw PCB's. I just find it easier to work with than let's say Eagle. Since all my projects are simple, hobby type, I always take the extra step to wire them and test them in let's say real environment, as far as 50 wires on a proto board can be called real. I like to see the LED's blinking and check if one second is at least close to that :-).

[temtronic]

The problem is that for $3 it's not a 'simple' peripheral. There's a lot going on in the epoxy and every aspect of it needs to be 'setup'. Gone are the 'good old days' of soldering a couple phototransistors and LEDs and making you own distance sensors. No need to spend days and nights figuring out math and mechanics, then trying to stuff 8K of code into less than 1K of code space.
The main problem with Proteus is it is a LOUSY 'simulator'. I've never tried it as a PCD designer, heck I've still got boxes of donuts and tape here though for field prototypes I use the 'solder stitch' method, pad per hole perfboard and use stripped wirewrap wire to connect. I have used Eagle to layout the boards though. I've also got 20K worth of 4000 and 7400 series chips here destined for the landfill as a 25 cent PIC replaces 99% of them, sigh.
Jay

[PrinceNai]

I know it isn't simple, the technology behind it must be mind blowing. But in my honest opinion it should be easier to interface with. There is some heavy processing done in that little bastard, so I believe that they shouldn't make everyone go thru the steps and that on their terms. I mean, after reset. Why issue 8 different commands, always the same. Just put yourself to some measurement mode (it is a simple measurement tool, not a replacement heart) and let me take care if I want to change it. The only commands I should issue to it are: calibrate, cross talk and continuous or single. Other than that, it should work. Why 30k of code? command: measure continuous. command:calibrate. command: set spades or whatever. Regarding i2c commands: how many are there? A simple set of defines should take care of language differences. define_i2c_st_api_secret_read i2c_read

I'm sorry for my attack, but out of frustration I just lost it there.

Samo

[temtronic]

Welcome to my World... I will NOT defend what 'engineers' design and have maintained they all should work/fix whatever they 'design' using normal tools.That being said, there's a lot of neat 'chips' out there,already mounted on PCBs so old guys like me, can both see and use them.Hard to believe the 'bloatware' needed for the thing, it makes me think it's so poorly designed that it NEEDS to be 'setup' every time so there can't be 'factory defaults' that'll make it work right out of the box. As for rants..ToF, aka 'Time of Flight' What has that got to do with a distance measuring sensor!? I was thinking ,neat ..ToF, some onboard 'black box' for a drone,recording GPS, alt,temp,G, etc.
Silly me....think I'll go back to 16C71 PICs.....though I do like 2 HW UARTS in the 18F46K22.
Jay

[PrinceNai]

I thought it was a part for a drone too :-). Out of curiosity: can someone recommend a sensor that relatively accurately (+/- 1,5mm) measures distances from 3 to 25cm? Digital output would be nice. Objects are not of the same color. I know of GP2Y0A41SK0F from Sharp, but is there a better solution?

Regards

[diode_blade]

https://github.com/LILCMU/vl53l0x-ccs

I came across this code, wether it might help or not, I am thinking about using 2 of these for a future project to keep a balance beam level, one at front and one at the rear, I have not tried the code but came across this thread and thought the link might be able to help you.

Regards
Dave

[PrinceNai]

Dear Sirs,

I still can't believe what just happened. The code on diode_blade's link works on 18f252 :-). It had some minor errors in it, nothing that couldn't be fixed in 5 minutes. The results are about 10mm off and they jump for a mm up and down on a fixed target. I'll rig something with a precise distance and test it there. So my next question is: how do I put the code here?

Thank you all very, very much

[diode_blade]

High Prince,
Glad it worked for you that is good news, as for putting the code on the forum, place it in the CODE LIBRARY section, but I suggest testing it thoroughly first. The other more experienced users on this forum will be able to advise you.

Regards
Dave

[Ttelmah]

As diode_blade says, post your modified version, together with an acknowledgement back to the github version in the code library.
Great start for anyone.

Also worth thanking the Github poster directly.

[PrinceNai]

Posted. Any comment and improvement would be greatly appreciated. Next step is to interface 12 of them and to calculate the number of 2,5mm plastic chips in each of 12 stacks.