ping_timer call blocks if connection to Ping sensor non-existent or faulty

[Alex Youngs]

The call to ping_timer is usually very quick, except if your connection to a ping sensor is faulty or doesn’t exist. This is because the ping_timer function directly calls ping_trigger which can block for as long as MAX_DISTANCE allows for. This seems to occur every time if a ping sensor isn’t properly connected to the output pin. It’d be nice to prevent a loose cable from causing large delays to more critical pieces in the loop. And it could be nice to indicate a faulty ping sensor as well, so the control system can handle that accordingly. I’d consider anything that causes ping_trigger to fail to be a faulty ping sensor/connection.

I think a potentially easy solution is to use ping_timer to optionally fire off a one shot timer to start the ping process. As long as it’s optional, it shouldn’t affect those that expect the ping to start instantaneously instead. I’m happy to make a PR, I just wanted to get some feedback on if this approach already exists or has been considered.

[Tim Eckel]

The other things to consider is compiled size and execution speed. It seems a connection would always exist. However, if you are in an environment where a sensor connection may not be present, it seems this is a unique case, and in that case doing a pre-ping connection check may be more appropriate than including the logic in the library.