Skip to content
This repository was archived by the owner on Apr 16, 2021. It is now read-only.

pulseIn and pulseInLong implemented #72

Closed
wants to merge 1 commit into from
Closed

Conversation

polldo
Copy link
Contributor

@polldo polldo commented May 7, 2020

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:

  • Timer 2
  • 1 GPIOTE event dynamically assigned to the pin
  • 6 PPI channels dynamically allocated
  • 3 PPI channel groups dynamically allocated

Notes:

  • The pin passed to this function is assumed to be already initialized as input pin, without interrupt attached to it.
  • Low timeout values, in the order of hundreds of microseconds, is probably not enough to capture even high frequency pulses. Tens of milliseconds are suggested as timeout precision.

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

@thebigredgeek
Copy link

thebigredgeek commented May 11, 2020

Can we get this merged and released?

@facchinm
Copy link
Member

@thebigredgeek we are still testing internally, as soon as we are done we can merge it

@thebigredgeek
Copy link

@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 :)

@facchinm
Copy link
Member

@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!

@thebigredgeek
Copy link

thebigredgeek commented May 14, 2020

@facchinm yep I have it! That said, not sure how to compile against a fork of Arduino. Any tips there?

@thebigredgeek
Copy link

@facchinm bump :)

@facchinm
Copy link
Member

@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.

@facchinm
Copy link
Member

Included in #81

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants