Pingdar has been slow going, because I've been pretty unhappy with the results of mixing a Servo with PulseIn. PulseIn is a Arduino function which waits for the state of a line to change.  This is done to find the range of some obstacle from a ultrasonic sensor like the sr04.  The problem is that the delay of waiting for the line makes the servo move very Sloooooooow.  (At least I "think" that's the problem)  But, it's difficult to tell. In order to be sure and get more "eyes" on the problem, I've created a new tool.  

I've created "Load Timings"  ..  Tadaaaa ! This measures and sends back the time it takes for MRLComm.ino to process one control "loop".  It seems to be WORKY !  Yay !  Yes that's micro-seconds .. not milliseconds !

So in playing around with it and the oscope I've discovered digital reads are the arduino are wicked quick - in fact no real precievable difference when you read digital pins ... but analog pins Whoa ! - each one adds about 1000 us to the loop !

This will definately be a useful tool to squeeze all the performance I can out of the Arduino 

Coming Soon : average load times, pulseIn timings & confirmation on my guess on how it interferes with servos,  Timings of other activities ... like moving servos & serial feedback

Wow  .. look how fast it does nothing !  120 us !
(Ok it's "nothing" - still checks for serial commands and spins through a couple loops checking if it "should" do something)

Now monitoring 6 analog lines .. 

 

Performance of a Mega is not as good as a Uno
Below is a Mega

Digital reads are still wicked quick ... 8 lines and "just" over 200 us

And here we go ... NewPing / PulseIn + Servo
AS HIGH AS 18K us !!!!  YIKES !!

 

I'm think this will work...

PulseIn is good because it's "easy" .. you ask for a pulseIn and you get the value back .. very nice...  but it means you have to "wait" for the pulse..  

WE DON'T LIKE TO WAIT !!!

PulseIn & NewPing (newer Arduino library) make you wait around for the results.. instead what we will do is check our watch and keep racing on..

The ping sensors have to send out pings and they have to be of a certain width - with delays in between.
So we write the pin low and RACE ON TO DO OTHER THINGS
then we come back and check our watch to see if enough time has gone by .. if not WE RACE ON
if so we bring the pin into a HIGH state and RACE ON
then we come back and check our watch to see if enough time has gone by .. if not WE RACE ON
if so we write down the  time the ping has gone out ...
then we check the echo pin .. has it changed states? no? ... WE RACE ON
keep checking when we fly back from doing other things to see if the echo pin has changed states..
When it finally has changed states .. REPORT THE PING !

So as you can see potentially there could be A LOT of waiting going on, but we just write down the time and keep going.. NO WAITING...  this is a much better way to go .. but there is one possible bad thing from this design..

If some other thing takes too long ... e.g. reading Analog Lines .. then our Ping values will become inaccurate

 

That's what taking an average of multiple samples is for.  :)  Or maybe the rest of the program has to be smart enough not to read any Analog while it's waiting on a ping.  Digital is quick so it's ok to do since it should only introduce a small inaccuracy in the ping.

Alessandruino

10 years 5 months ago

So with the "old" pulseIn you have to wait in arduino too ( I mean without mrl)... This mean you should use an arduino only for the ping sensor ? That s crazy!