This repository was archived by the owner on Apr 16, 2021. It is now read-only.
pulseIn and pulseInLong implemented #72
Closed
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.
pulseIn ref: https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/
"Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go from LOW to HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds or gives up and returns 0 if no complete pulse was received within the timeout."
The implementation exploits the following peripherals:
Notes:
Brief explanation of the implemented strategy:
Firstly, a GPIOTE event is configured to notify every time the pin is toggled.
Three PPI hw channels have been employed in order to accurately react to the toggles of the pin.
Initially only the first channel is enabled, when it is activated it disables itself and enables the second one. The second follows this same scheme.
The first channel starts a timer. The second channel captures the first pulse. The third channel captures the second pulse.
In order to select the pulse that the caller asked for, the function should be able to understand the state of the pin at the moment of the first channel activation. Such a synchronization between hardware and software is not accurate, so if the activation is performed too close to a pin edge the software can't be sure whether the first PPI channel detected it or not. In such cases, the the channels are disabled and then enabled again, to wait the next pin edge.
#47