2

I'm working on Android Things on an rpi3 dev kit, with the IMHO excellent Picon Zero hat. I'm trying to trigger and read the reply from a HC-SR04, which requires a ~10 μS trigger pulse, then quickly swap the GPIO to be an input, and listen for the length of the reply pulse.

But things in Java are sloooooww compared to Arduino. (I know, real-time system vs RPi3, apples and oranges). I tried a variety of "wait for a small enough amount of time to have it be just 10 μS" and everything was way too big.

With a target of 10,000 nS:

  1. Vanilla Android Spin-wait reading System.nanoTime() = 125% (best!)
  2. Kotlin's coroutine "delay" = 2000%
  3. Thread.sleep = 13000%

And the only thing that could consistently get a time-slice that small was two sequential System.nanoTime() calls - which had ~ 14 μS between them. And that was before stuffing back in the calls to change the GPIO pin from write to read.

Is this expected? It seems slow. 900 MHz (each core) is 9000 cycles in that 10 μS window I'm shooting for. Having literally the one instruction of "get nano time" eat the entire 9000 cycles seems... odd.

  • 1
    10µs is the minimum trigger pulse length, it can be much longer. – joan Jun 6 '17 at 21:55
  • I'm more worried about the amount of steps needed to turn a "trigger" pin into an "echo" pin because my sensor is a 3-pin model. According to hackernoon.com/… it may not be enough time. – Benjamin H Jun 16 '17 at 17:37
  • If you want reliable results you will have to dump one or more of Java and the sensor. Those with separate trigger and output lines are much easier to interface. – joan Jun 16 '17 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.