next topic »

[on:]

Guys, in short, I'm facing a question about the speed of serial communication,
I just start to try it and made the code at the bottom to test.

the action I want to test is
when I input " 50 0 170 0 255 0 " for example,
the led should " glow-> off -> glow brighter -> off -> glow full -> off "

the problem I am facing is that
the first 5 action go smooth with the delay I expected,
but the last action, the off here, no matter how many numbers I have input,
the last one always have a additional delay of hundreds millis seconds.

can anyone tell me why?

Code:

void setup(){
  Serial.begin(9600);
  pinMode(13,OUTPUT);
  digitalWrite(13,LOW);
}

int byteRead = 0;

void loop(){
  if(Serial.available()){
    byteRead = Serial.parseInt();
    if(byteRead>255)digitalWrite(13,HIGH);
    else analogWrite(13,byteRead);
    delay(500);
  }
}

[Reply #1 on:]

Please don't cross-post.

[Reply #2 on:]

because I don't know where it exactly belongs to ...

How about the question?
is it something about Serial.available() that I don't fully understand?

my point is, if I need to keep sending one integer separately but rapidly,
how can that unexpected delay be exist?

[Reply #3 on:]

Which board are you using ?

Read the reference of every function you use.
If you read this : http://arduino.cc/en/Reference/analogWrite
And take a good look at your board, you notice that PWM is not possible with pin 13 on a Arduino Uno.

[Reply #4 on:]

Which board are you using ?

Read the reference of every function you use.
If you read this : http://arduino.cc/en/Reference/analogWrite
And take a good look at your board, you notice that PWM is not possible with pin 13 on a Arduino Uno.

mega 2560
there is no problem of PWM
and if this is a PWM problem it shouldn't be a delay

my problem is the delay when there is just one integer sent into the board,
or when there is only one unread integer left in the buffer.

[Reply #5 on:]

my problem is the delay when there is just one integer sent into the board,
or when there is only one unread integer left in the buffer.

How does "parseInt" know when it has reached the end of the data?

Code:

#define PARSE_TIMEOUT 1000  // default number of milli-seconds to wait

(From "Stream.cpp")

the last one always have a additional delay of hundreds millis seconds.

Ten hundred, to be precise.

Send an extra comma, or a line feed, carriage return - anything but a decimal digit.

[Reply #6 on:]

a, or a line feed, carriage return - anything but a decimal digit.

I got it!! THANKS!!!!!

[Reply #7 on:]

when there is a serial character available,  you got no idea how many.   You cannot necessarily
assume that the whole three character number is there.

[Reply #8 on:]

when there is a serial character available,  you got no idea how many.   You cannot necessarily
assume that the whole three character number is there.

I don't get it. Not understanding............

and now I know I need to tell arduino it's the end?
but how?
what is a carriage return?
I tried :
/r
'/r'
but still a delay there and at the end turn off the LED,
just like what I add is a digit zero at the end.

[Reply #9 on:]

"Close, but no cigar"
Try '\r' for carriage return or '\l' for linefeed.

[Reply #10 on:]

when there is a serial character available,  you got no idea how many.   You cannot necessarily
assume that the whole three character number is there.

But "parseInt" takes care of that by waiting for input, or timing-out after (by default) one second. ("ten hundred milliseconds").

If anything, the "available" may not be necessary, depending on how frequently updates are sent.

'\l' for linefeed.

Close, but no cigar   

[Reply #11 on:]

"Close, but no cigar"
Try '\r' for carriage return or '\l' for linefeed.

When I input :
50 \r
or
50 '\r'
I still got the same effect as I input :
50 0

Still don't get it.......

[Reply #12 on:]

Still don't get it..

It doesn't matter what you send, so long as it isn't a decimal digit.

[Reply #13 on:]

Still don't get it..

It doesn't matter what you send, so long as it isn't a decimal digit.

So now the case is that I need to send a decimal digit
then send a decimal digit again within 1000 ms
but the first "command" still do not have effect due to the " last input delay ( what I call it ) "
and the second "command" seems to "merge" to the first and result as some unwanted brightness.

for example if I type 2 then press enter, then type 55 then press enter,
I result as if I type 255 and press enter......

And i suppose if the first command response immediately,
the second one will also response immediately just after I press 'enter'

Now what i need to do to solve this is..............?

[Reply #14 on:]

last input delay ( what I call it ) "

Call it a timeout, because that's what it is.

I'm struggling to see what the problem is.