next topic »

[Reply #15 on:]

Add a small delay at the end of your if block and then read and discard the rest of the buffer.

No, no, no. Please do NOT do this.

First,

Code:

if (Serial.available() == 4) {

is wrong. The == should be >=. Then, if there should be 5 or 8 characters in the buffer, they are not permanently stuck there.

Second, you MUST send start and end of packet markers, so that <AAAA> and <AAAAA> are separate packets. Then, you can use code like this:
 

Code:

#define SOP '<'
#define EOP '>'

bool started = false;
bool ended = false;

char inData[80];
byte index;

void setup()
{
   Serial.begin(57600);
   // Other stuff...
}

void loop()
{
  // Read all serial data available, as fast as possible
  while(Serial.available() > 0)
  {
    char inChar = Serial.read();
    if(inChar == SOP)
    {
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {
       ended = true;
       break;
    }
    else
    {
      if(index < 79)
      {
        inData[index] = inChar;
        index++;
        inData[index] = '\0';
      }
    }
  }

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  {
    // The end of packet marker arrived. Process the packet

    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    inData[index] = '\0';
  }
}

To read the whole packet, and nothing but the packet. Where it says "Parse the packet" is where if if(strcmp()) tests go.

[Reply #16 on:]

Add a small delay at the end of your if block and then read and discard the rest of the buffer.

No, no, no. Please do NOT do this.

I know the hip thing to do here is oppose any usage of delay, and discarding data, more often than not, is not a good idea, but do you have any other reason for why this would work in simple applications?

[Reply #17 on:]

but do you have any other reason for why this would work in simple applications?

Delay() is a bandaid that often masks an underlying problem. I'd really prefer to fix the underlying problem than mask it.

Dumping random amounts of unread data is also generally not a smart thing to do. Getting a real handle on the exchange of data is a better idea.

Just my opinion, of course, and no more right, or wrong, than yours.

[Reply #18 on:]

See? that is why i thought had to do with the lack of handshake/flow control and cts/rts. You end up with things like this to sort and debug. But if you keep it simple should be easy in this case. That tutorial on Nick's site explains several ways of getting around that !!
Though in this case is to do with reading the buffer properly, right ?!

[Reply #19 on:]

Its actually good and im also learning a lot with this case, as i never needed to come down so detailed like this to send data, programming wise...So, deffo a good lesson for me !!!

[Reply #20 on:]

I know the hip thing to do here is oppose any usage of delay, and discarding data, more often than not, is not a good idea, but do you have any other reason for why this would work in simple applications?

It's not so much hip, as trying to get things to work properly. If you band-aid your way around things, you'll be back in a week saying "sometimes my program loses data".

Let's deal with delay first. Say your mail is normally delivered at 9 am. Would you just sit around at 8 am for an hour, and then go get the mail? Well, no, because:

• You aren't doing anything useful
• The mail may come at 8:50 or 9:10

So you check if the mail is "available". Then you know it's there. Whenever that is.

... and discarding data ...

That's like going and getting the mail, expecting two letters, getting three, and throwing the third one into the bin. Maybe the third one was important. That's why you don't discard data.

[Reply #21 on:]

Hi everyone!

I'm trying to edit PaulS code to put it working for my situation, but I don't know exactelly where I should put the code to compare strings: where is it exactelly?

Also, I've got a doubt. It's kind of a little thing but I tought about it a few moments ago and I wanna solve it as soon as possible: let's imagine that everything is working, and I'm using caracters to start and end the packed, wich are < and >. So, the arduino is plugged into my router and I'm not sending any code to the arduino. However, in the "garbage" that the router sends to arduino appears a < caracter. And, a few moments later I try to send an action to the arduino, like this <AAAA>.
So, my doubt it: Arduino already received a < from the router. Will it accept my order, or it will be waiting for a > to end the packet and only then it will accept and process my order?

Anyway, thank you all very much!

Tiago Ferreira

[Reply #22 on:]

Will it accept my order, or it will be waiting for a > to end the packet and only then it will accept and process my order?

Well, that's up to you
Easiest is: every '<' resets all internal indexes and stuff, every '>' examines what has come so far and acts.
After startup, you discard everything until a '<' arrives. Then '<' resets, and after that you store everything that comes until the '>' arrives (or it's obviously garbage (don't go beyond the provided buffer size)

BTW: I'd prefer to use a newline as both end like '>' and start of a new command  like '<' in the discussion up to now.
It's up to you if newline is defined as 0x0D (CR) or 0x0A (LF) or both.
Easy to test using Serial Monitor and the Enter key.

Keep special characters like < > : = etc. as delimiters within a command.

[Reply #23 on:]

Well, that's up to you

True, but the way I wrote the code, the < resets everything because it signifies the start of a packet.

One thing to keep in mind is that serial data is not guaranteed to be delivered correctly. Noise, timing issues, and other factors can cause a bit to not be received correctly, The byte, then, is discarded. If that byte was a >, the packet that it ended will be discarded, too (with the code I posted).

If the character that is corrupted is a <, then the packet is starts will be discarded, because the next character(s) do(es) not follow a <. The next < gets things back in sync.

If the character that is corrupted is between the start and end of packet markers, then it is up to you to determine what to do. If the packet is AAA, instead of AAAA, then it won't match any command, so no harm, no foul, and the packet is discarded.

In most cases, though, you need to do something more to ensure that only good data is used. If the packet represents a PWM value, and the value sent was 103, and the 0 was corrupted, the packet value will be 13, instead of 103. You need to decide whether the actual value received is reasonable, or not.

For instance, if you have been receiving values like 101, 101, 102, 103, 104, 107, 105, and 103 arrives, that is most likely a good value. If the value that arrives is 13, it may not be good.