Fixed bug that caused the initialization to hang #2
Conversation
|
Thanks for the contribution! I've pushed the branch to gitlab for CI, as that's the project's main repo (github is just a mirror I've added for discoverability) - here's the pipeline: https://gitlab.com/mjbogusz/vl53l1x-linux/-/pipelines/1057760762 If that passes, I'm happy to merge - and then I have to remember to put a PR template into the repo redirecting future contributors to gitlab ;) |
…ady been started from a previous run. This is fixed by soft-restarting the chip.
mjbogusz
force-pushed
the
sb/reset_patch
branch
from
59fe037 to
4bd52c7
Compare
|
I've amended the comment to make uncrustify happy. Additionally I've found that this patch has been kinda-already-done, see here: https://gitlab.com/mjbogusz/vl53l1x-linux/-/commit/1530dbf9cbe81fe9673eee2fa60782094b6e21b9 but as I've mentioned above - this mirror was not kept up-to-date... and if I remember correctly that patch of mine did not resolve all my issues, that's why it wasn't merged into master/main. Could you please test my version? I don't have access to the sensors right now and this definitely requires testing with hardware. |
I have tested your version, including the original commit of 1530dbf9cbe81fe9673eee2fa60782094b6e21b9 as well as the master branch on gitlab with the .cpp file from the original commit copied over, and can confirm that it does not work. I have tested my commit and confirm that it mine still works. Edit: would like to include, it's very particular that your commit didn't work, as it appears your commit is doing something very similar to what mine is attempting. |
|
I finally got around to analyzing this a bit... but looking at the code, mine (branch I'm afraid that the issue is such a low-level one that it might require hooking a scope (or at least a logic analyzer) to the communication lines and dissecting the difference. As I've mentioned I don't have the hardware on hand, but I'll see if I can find an excuse to buy 2-3 of these sensors ;) In the meantime, if possible, could you test my code with sleeps a) disabled and b) extended to large values like 1s? |
|
Hello once again, I recently pulled and compiled directly from what main branch has on github, and manually added what was in the dev branch. IT SEEMS for some strange reason, with the newer up-to-date version of main, with the added changes that you had, allows it to work again. Maybe some change added somewhere else is allowing it to work, I don't know. But it seems your code with Edit: Wanted to also add, the newer main branch that was merged from gitlab, includes libsbc-linux-interfaces.so, which from my understanding is what handles all the actual i2c "touching", possibly features or patches in that handle better i2c communication that allow the resets to be perform without it choking. I am running the getDistance binary, both linked to the .so's that are compiled by make, as well as statically linking my .a archive and linked to the libsbc-linux-interfaces.so on my embedded system, in which it works for both of them. One thing to add, I did notice that when running with no thread sleeping, it hung ONCE and then never again. No clue if this is a coincidence on my end, or thread sleeping does take care of fringe cases of it hanging. Without the sleeps, it seems to "stumble" on the first few runs and with sleep it immediately takes off fine. |
Added static library compilation to CMake
If the chip had already been started from a previous run, then initialization hangs. Fixed by sending a RESET command as the first thing it does on initialize to the chip which soft-resets.