Closed polldo closed 4 years ago
Can we get this merged and released?
@thebigredgeek we are still testing internally, as soon as we are done we can merge it
@facchinm is there anything I can do to help? I haven't yet contributed to Arduino but I'm fairly involved in other FOSS communities. Happy to help out if it helps reduce time to release :)
@thebigredgeek sure! If you have an ultrasonic sensor running this sketch https://create.arduino.cc/projecthub/Isaac100/getting-started-with-the-hc-sr04-ultrasonic-sensor-036380 and checking if the results are correct would be great!
@facchinm yep I have it! That said, not sure how to compile against a fork of Arduino. Any tips there?
@facchinm bump :)
@thebigredgeek sorry, I missed the edit... Since the commit is a single file, you can grab it from here and add it to any sketch as a secondary tab. This will allow proper linking and testing.
Included in #81
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.
https://github.com/arduino/ArduinoCore-nRF528x-mbedos/issues/47