Draft
Conversation
- change MAX_TIMEOUT_MICRO_SEC back to old value - switch sensors - make logging less noisy
Member
|
Hi Mark, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Heya fellas!
This is a bit bigger.
The intention of this PR is to seperate the sensor code into two parts.
One part is very low level and only deals with microseconds, pins, and interrupts. It also knows how to sequence, interleave, or parallelize the sensors. This is now
tofmanager.h/.cpp.The second part is now
DistanceSensor. This part of the code know how to convert microseconds into the final result values, including computing the distance from the time of flight and including applying any offsets (handlebar).The two parts communicate via a FreeRTOS Queue. The low-level part runs in a dedicated FreeRTOS task on core0. The idea behind this is, to create some freedom to tinker with new and interesting ways to work the existing sensors. One idea is to introduce some calibration routines, another idea is to try to accelerate the data gatherin by making it dynamic. One possible use case could be dooring zone detection. Despite all grand new ideas, I think the new code is an improvement and easier to understand.
This is not finished and it probably needs two more weeks of work. Right now the UI is "airworthy" and can be used by normal people. I ran the sensor for 2h today and had no OOM conditions. I also didn't see any crashes during these two hours.
The following things are missing right now: The raw data / CSV is not verified and I think it could be badly broken. Some things (like missing interrupt detection) are missing, I will review these things in the coming weeks. Bluetooth has been disabled (I didn't want to share core0). The low level code uses 64bit atomic unsigned integers for time measurement, and I think the high level part does not properly reflect that.
I think there are also more things missing. I will review the CSV output this week and fix any oversights. In the following two or three weeks I want to wrap up work on this one.
Please don't be angry at me, because I took a lot of liberty in renaming things. I especially felt, that the name of a variable or parameter should reflect the physical unit and the purpose (e.g. distance or distance with offsets applied) should be obvious from a comment.
Additionally I upgraded the project to be C++20 compliant.
Fellas, I think this is a marvelous project and a really fun thing to hack on. Have a good evening.
Cheers, Mark