Extend API - Async and Continuous

[KurtE]

@ladyada - I am not sure if this is something you would be interested in having integrated as I go, or if you wish to wait until I stop doing stuff. Thought since I had been playing around with some of your VL6... and Someone on PJRC forum had some of the VL5... I would see about updating the capabilities of this library to be similar to stuff earlier in VL6.

This library is very different than your VL6... library in that you have included the ST library and use it. I was also looking at the Pololu library which is in some ways closer to your VL6 in that they extracted those pieces of the ST library and used the stuff directly instead of going through their layers.

There are questions on how best to do the APIs. Your previous one function to do a range, returned the data in the ST library data format. Where some of these new ones allow you to simply say give me the range. Give me the range status... May want give more access to some of the other data.

So decided to start this PR, so that you can take a look and see if you have suggestions on maybe how these two worlds of APIs and layers, should be melded together.

Thanks - Kurt

Comments From the commit

I am trying to make use of the underlying ST library that is included with this library.

Some of the additions include:

The ability to startup a range measurement and not have to wait for it to complete.

The ability to start up a continue ranging operation

I included an example sketch that shows some different modes of operation, it is setup with a table of sensors, like which SPI buss it is on, which GPIO pins are for shutdown and GPIO... Currently it is doing 4 sensors 2 on SPI and other 2 on SPI1. Can update to make more compatible with systems that don't have SPI1.

Some of the modes: a) Use the currently released api to read each of these b) Use new one that starts up range on all 4 devices and waits for them to complete by doing query to see if complete. c) Like b) but instead checks GPIO pin for completion. d) Continuous updates - allows you to type in cycle time.

Again there is lots more testing and extensions that can and should be done.

Note: I ran clan-format -i on the three files.

Also don't be worried if the request is closed or not integrated--sometimes the priorities of Adafruit's GitHub code (education, ease of use) might not match the priorities of the pull request. Don't fret, the open source community thrives on forks and GitHub makes it easy to keep your changes in a forked repo.

[KurtE]

@ladyada I fixed up the example I mentioned in the first message as sure enough the verification stuff runs against things like Arduino UNO, which does not have enough memory nor SPI1. So now the examples if built with Arduino AVR... Only does 2 sensors.

Also marked all of the Serial.prints to use F("text") to force the strings to flash instead of regular memory.

Note; The expanded size of the main object makes memory tight on UNO. I may need to remove the results object out of the main object and maybe only cache the information we really are interested in.

[ladyada]

looks great! woudl you mind verifying the existing older examples still work with an UNO and we could merge?

[KurtE]

Will try to find my UNO. and run it to see if they work. They do have low memory available. Will be interesting to compile back the main one to see how much I have grown it. Should not be much.

Right now I am pulling some of the code out of my example sketch which is extracted from the ST library release examples to make it easy to configure a sensor for Long Range or...

  typedef enum {
    VL53LOX_SENSE_DEFAULT = 0,
    VL53LOX_SENSE_LONG_RANGE,
    VL53LOX_SENSE_HIGH_SPEED,
    VL53LOX_SENSE_HIGH_ACCURACY
  } VL53LOX_Sense_config_t;

  boolean configSensor(VL53LOX_Sense_config_t vl_config);

[KurtE]

@ladyada - I did another pass through, you want take another look.

I took another pass through and added some of the configuration stuff from the ST library example sketches for different configurations of sensors.

Some testing with some of the none default but not sure about some high accuracy ones. But probably good enough for now as before you could not do any setting of any of these settings.

Added a keywords.txt file to the project to pickup the methods and a few literals.

I ran it again on T4 with 4 sensors.

Ran 3 of the examples on an older UNO, did not try the oled sketch. But the other three appear to build and run on UNO. The multi one was configured for 2 sensors on AVR boards.

I did another clang-format -i but will be interesting to see if the checks pass again.

[ladyada]

done :)