So I have completed and posted my Guide to Serial Communications. I started a blog to give me someplace to put it (I was unable to figure out how to put stuff on the Playground, the links for requesting access appear to be broken).
Link to the guide: JHaskell's Blog: Serial Comm Fundamentals on Arduino
It's an attempt to explain not just how to handle serial communications, but why it has to be handled the way it does in the hopes that. Not sure how successful it will be at doing that.
Comments? Criticisms? Flames?
char c = '/r'; //Use the forward slash 'escape character' followed by the 'control' character for Carriage Return
The escape character is the backslash, not the forward slash.
This is a very nice start. One glaring (I know you didn't want to hear that) omission, though, is that while you do a great job of building the character array, you never actually NULL terminate it. So, parsing and using that array is going to be tricky. Adding a NULL after each addition guarantees that the character array is a string at all times, compatible with atoi(), strrok(), strcmp(), etc. - all the string processing functions. Note that I am careful to distinguish between a string and a String object.
The reasons for NOT using a String object should be explained on your page, too.
Thanks for the feedback PaulS.
Good catch on the escape character. I did catch that when I tested my code, but apparently never updated the guide.
I also added a note on C strings vs the String class, and the potentially nasty pitfall of the String class.
Working on resolving the NULL terminator issue. I've also been working on another followup guide on parsing the strings using the C library functions, but that's still probably a few days away or so.
It's a good effort. I have a few nit-picks.
First, you're kind of mixing hardware issues like baud rate with protocol issues. You didn't clearly distinguish between the two concepts. When you talk of "delimiters" you are talking about an atificial organization that is enforced on the data being sent over the hardware. That concept really is not wedded to serial communications. And, serial communications is not wedded to text data. You can send binary data over serial as well. Its true that NMEA uses a $ to begin a new bit of data and \r\n to end it, but that is specific to that protocol. You can use that protocol over any communications channel.
Serial.available(): This method returns the number of characters that are available in the Serial buffer at the moment it is called. This value can be anywhere from 0 to 128, as the Serial buffer can hold up to 128 bytes.
Actually, the default size of the buffer depends upon the amount of memory on the target processor. A look through HardwareSerial.cpp confirms that it checks the amount of RAM and sizes the buffer accordingly.
if(Serial.available()>0){
char incomingbyte = Serial.read();
buffer[index++] = incomingbyte;
}
I see this method used frequently in examples. How about this:
int incomingByte = Serial.read();
if(incomingByte > -1)
{
buffer[index] = incomingbyte;
index++;
}
This code does one less comparison. Notice I also seperated the post increment out. If beginners are reading this, they may not unserstand how side effects work.
char startChar = '
So this code will fail if the loop executes faster than data is received.
; // or '!', or whatever your start character is
boolean storeString = false; //This will be our flag to put the data in our buffer
while(Serial.available()>0)
{
char incomingbyte = Serial.read();
if(incomingbyte==startChar)
{
index = 0; //Initialize our index variable
storeString = true;
}
if(storeString){
buffer[index++] = incomingbyte;
}
}
So this code will fail if the loop executes faster than data is received.
First, you're kind of mixing hardware issues like baud rate with protocol issues. You didn't clearly distinguish between the two concepts.
I'm attempting to provide a protocol that addresses the most significant issues beginners typically have, but you are correct. I do not clearly distinguish between the two. I'll look into making the distinctions more clear. I also think binary comms are well beyond a beginner and intentionally left any discussion of it out of the guide.
Actually, the default size of the buffer depends upon the amount of memory on the target processor.
Another good point. I was thinking pretty much just about the Uno when writing the guide, but I don't make that clear either, and I'm now thinking I really shouldn't do that anyways.
So this code will fail if the loop executes faster than data is received.
That code was an iterative step in building a complete and functional serial read routine, and never intended to work completely all on it's own, as was all the sample code provided throughout the guide except the final routine. Again though, that's something I should make more clear.
Thanks for your input as well skyjumper.