Go Down

Topic: My Arduino is delaying functions (Read 938 times) previous topic - next topic

dindibo4

Hello, I uploaded to my Arduino mega 2560 a program that connects to ultra sonic HC-SR04 rangefinder
sensor and debugs on the serial monitor the range it detects.
I have run this on a dry run without the sensor yet but in either case my arduino reads 0 as it should be but the delay between each read is way more than it should be, it suppose to delay it by roughly 50 ms but in practice, it delays it like 1 second.
There is the code I used:
Code: [Select]

void op1(){
 
   pinMode(trig, OUTPUT);
   digitalWrite(trig, LOW);
   delayMicroseconds(2);
   digitalWrite(trig, HIGH);
   delayMicroseconds(10);
   digitalWrite(trig, LOW);
   pinMode(echo, INPUT);
   dist = pulseIn(echo, HIGH);
   Serial.println(distance(dist));
   delay(50);
}


Does somebody know why is that?
is something wrong with my arduino?

Juraj

it spends time in function called by the function op1()

sterretje

#2
Aug 27, 2017, 05:47 pm Last Edit: Aug 27, 2017, 05:47 pm by sterretje
And your full code is ??

Also be aware that if you print a lot, the software output buffer used by e.g. Serial.print will fill up and block your code once it's full.

FYI: At 9600 baud, transmission of one character takes roughly 1 ms.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

dindibo4

it spends time in function called by the function op1()
And your full code is ??

Also be aware that if you print a lot, the software output buffer used by e.g. Serial.print will fill up and block your code once it's full.

FYI: At 9600 baud, transmission of one character takes roughly 1 ms.
The rest of the code isn't the problem, I tried to delete the op1(); lines and it turned out to work fine.
Is there anything that I can do in order to make the calculations faster or make it work faster?

AWOL

What is the timeout period of pulseIn?

sterretje

#5
Aug 28, 2017, 06:30 am Last Edit: Aug 28, 2017, 06:33 am by sterretje
The rest of the code isn't the problem, I tried to delete the op1(); lines and it turned out to work fine.
You have an unknown function distance() in there; for all I know you can have a delay in there. I know it's not likely but we can't be sure.

We also don't know how often you call your op1() and you might be filling the serial buffer (as indicated).

Is there anything that I can do in order to make the calculations faster or make it work faster?
Maybe use of the newping library? No experience with it but as far as I know it can be used non-blocking.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

dindibo4

You have an unknown function distance() in there; for all I know you can have a delay in there. I know it's not likely but we can't be sure.

We also don't know how often you call your op1() and you might be filling the serial buffer (as indicated).
Maybe use of the newping library? No experience with it but as far as I know it can be used non-blocking.
Alright so there is the only time I call op1() and distance:

void initialization(){

 for(int i = 0;i<=180;i++){
   pos.write(i);
//   op1();
   range = dist;
   delay(initTime);
 }
   for(int i = 180;i>=0;i--){
   pos.write(i);
//    op1();
   range = avg(range, dist);
   delay(initTime);
 }
 
 
}

void op1(){
 
  pinMode(trig, OUTPUT);
  digitalWrite(trig, LOW);
  delayMicroseconds(2);
  digitalWrite(trig, HIGH);
  delayMicroseconds(10);
  digitalWrite(trig, LOW);
  pinMode(echo, INPUT);
  dist = pulseIn(echo, HIGH);
  Serial.println(distance(dist));
  delay(50);
}

double distance (double time){
 double v = 0.034029;
 return (v*time)/2;
}

Parameters:
int initTime = 28;
int echo = 12;
int trig = 11;
double dist = 0;
bool initializationCom = false;
const double s = 1000;
double range[180];

AWOL

...and that's why we ask you to use code tags.

DrAzzy

It's not the serial buffer - the delay(50) gives plenty of time for the output to print.

It's gotta be that pulseIn() is sometimes timing out (ie, not seeing a pulse).
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

sterretje

It's not the serial buffer - the delay(50) gives plenty of time for the output to print.
That depends on what is printed at which speed; and I know that you know that ;)
Code: [Select]
This is a flipping long text that can't be send in 50 ms at 9600 baud without delaying the code


It's gotta be that pulseIn() is sometimes timing out (ie, not seeing a pulse).
Hence the suggestion that the newping library might be a solution.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

DrAzzy

That depends on what is printed at which speed; and I know that you know that ;)
Of course, if we didn't know what was being printed, we couldn't make an assertion like that. But we do know what's being printed - a single floating point value followed by a CRLF sequence, each pass through that function.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

sterretje

Ah, I  didn't look at the latest code.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

slipstick

In the initial post didn't the OP say the sensor wasn't connected yet?

No sensor presumably means no pulse. So isn't pulsein() going to time out every time? And by a strange coincidence the default timeout is exactly the time he's complaining about (which is what I thought AWOL was trying to tell him before things went off in all sorts of other directions).

Steve

Go Up