VL53L1X tof driver based on the st's ULD API

Development
1

Hello everyone,

I need to use the vl53l1x sensor for my projects cause it has lots of powerful features. I started creating a module for him based on ULD API which is offered by st, therefore in order to avoid a huge refactoring i would like to present the approach and get some early feedback about the structure and if it is in agreement with RIOT.

This is case in my mind is more of a wrapper than an actual driver. I structure in a way in order to achieve two things:

be as separate as possible from the st API, so it would be easy to upgrade it, follow somehow RIOT’S driver structure.

Below is the structure:

Screenshot from 2021-09-16 19-12-02
Screenshot from 2021-09-16 19-12-02750×343 16.6 KB

So in st’s api, the platfrom files are were the implementation should take place. So the vl53l1x.h file contains wrapper functions for all functions of st’s API, but also the definitions for the i2c implementation functions which platform.h functions will call.

So while this in my mind seems a clean approach, i ask you if you think these 2 extra function call layer will add overhead. Also because platfrom callers are unaware of the multiple i2c channels that some mcu’s have, in the vl53l1x.c file it would require a global variable in order to pass the i2c device from the wrappers to the implementation functions with a global variable in order avoiding to pollute the st API. The latter seems to me a little hacky and weird so if you have some better approach in mind let me know.

Thanks in advance!

2

You might want to take a look at this PR. Maybe you can take it over?

3

First thank you for your quick response :grinning:

I didnt know about this topic https://github.com/RIOT-OS/RIOT/projects/29#card-45326523. My search for none existing drivers was on the official driver doc. Now i am feeling a bit silly :sweat_smile:

I have a semi working version almost ready but this seems pretty impressive because it includes the more complicated api’s too.

I would love to take it over, but to be clear i dont know exactly how to start doing it. Could you pls give me a little guidance on how.

4

@gschorcht’s code tends to be very good usually, so I think you don’t have to do much. It’s unfortunate that it didn’t receive a review earlier and these days he doesn’t have much time to spare for RIOT.

So to revive this you would have to

  • rebase the branch onto the current master, fix the merge conflicts (e.g. auto_init moved to drivers/saul/init_devs/init.c)
  • address @maribu’s review comments (ideally as separate commits, you can squash them later)

Then create a new PR with your branch, we’ll try to review it sooner this time :wink:

5

Thanks, will work on it!