Arduino Serial Control - Strings?

Using Arduino Programming Questions
21

Arrch:
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.

22

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 .
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

23

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 :wink:
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.

24

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.