Go Down

Topic: Getting reliable Serial.read()'s without a stop character (Read 5817 times) previous topic - next topic

PaulS

Quote
Why not encoding something like that according to your example values:
0x00, 0x01, 0x02, ..., 0xfd, 0xfe, 0xff, 0x00, 0x00 ?
So your frame length = nBytes+2, and your delimiter is a 0x00 pair?

Because that wasn't what you asked.
The art of getting good answers lies in asking good questions.

graynomad

Ummm, did I miss something. Aren't we talking about a human typing into a terminal program? If so the only "protocol" needed is

PC
Send every character to the Arduino.

Arduino
Read characters until you get \n
Parse command.

Quote
that's just one more thing for the user to type, every single time.

What is? The return? It's the most natural thing in the world to hit ENTER after typing a command.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

jraskell

Quote
A stop character seems more like a crutch to me


If that were the case, then the vast majority of communication protocols (if not all of them) out there rely on some form of this crutch to transmit data reliably.  Ethernet TCP and UDP.  HTML.  XML.  RSS.  RS-232.  RS-485.  I2C.  Canbus.  Devicenet. Email.  Text messaging. etc. etc.  The list just goes on and on and on.  Basically, virtually every form of electronic communications involves some form of start of data and stop of data, whether it's a uniquely identifiable bit or signal pattern, or just a known arbitrary signal state.  Some have fairly complicated protocols, others extremely simple.  Many stack multiple layers of communications protocols on top of each other, all utilizing their own particular protocol to determine the start and end of a discrete packet of data.  So, you may want to rethink your view of the ubiquitous stop character.  In fact, the very RS-232 serial protocol you're using to communicate with your Arduino utilizes a start and stop bit in it's own protocol.

That being said, your stop character could quite simply be a carriage return.  Since it's fairly standard to have to hit the enter key to execute the command you just typed in, it's hardly an imposition on the user.

antiquekid3

Paul, you seem to have jumped to the conclusion that I have already studied C in school. In fact, I'm taking my second semester of Java, and not once have we talked about how strings are terminated. Only EEs take C; ECPEs like myself study Java. Unfortunately for me, the Java classes offered here use Java as a high-level, OO language, as it was intended, and not to teach basic low-level characteristics of strings, such as how they are terminated.

Rob, I didn't realize the new line character was also sent. I just assumed pressing enter in the serial monitor was equivalent to hitting "send." Thank you for the help!

By no means do I think the stop character is a crutch in the protocols you listed. I only think it would be a crutch if I had to send, say, a semicolon after every command. Now that I know the terminal program also sends the carriage return, I'd say the problem is solved.

zoomkat

Quote
I just assumed pressing enter in the serial monitor was equivalent to hitting "send."


It is an option in the latest arduino IDE to append or not the cr/lf to the characters sent.
Google forum search: Use Google Search box in upper right side of this page.
Why I like my 2005 Rio Yellow Honda S2000  https://www.youtube.com/watch?v=pWjMvrkUqX0

PaulS

Quote
Paul, you seem to have jumped to the conclusion that I have already studied C in school.

Well, yes, I did. I saw nothing in your posts to indicate anything to the contrary. Having jumped to an erroneous (though innocently so) conclusion, I'll apologize for any grief I gave you.

End-of-packet markers ARE required, though, for robust serial data processing (quit rolling your eyes, zoomkat).
The art of getting good answers lies in asking good questions.

nickgammon


Rob, I didn't realize the new line character was also sent. I just assumed pressing enter in the serial monitor was equivalent to hitting "send." Thank you for the help!


In the olden days ... ah those were the days! ... you had "dumb" terminals. They simply sent what you typed, and the Enter or Return key would just send another character (actually I think carriage-return (0x0D) hence the name "return"). And *that* was from the days of manual typewriters where you hit a big lever (the "carriage return" lever) which literally "returned the carriage" which held the paper back to the start of the line, and a cog advanced it one line). So really on a manual typewriter the "carriage return" lever also did a "new line" (advanced the line down) - I think you could adjust that part, from memory.

So to be consistent with what typists were used to, the "new" terminals used the "return" key to "finish the line". Well actually the receiving end interpreted return (0x0D) as "the line was finished, now interpret it".

Indeed in modern GUI programs hitting "return" may not actually send a "return" anywhere, it may just close a dialog box. But the concept is generally the same.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

AWOL

Ah yes, the glory days of teletypes, and having to remember to send padding characters after a carriage return, so that the carriage actually had time to return to the start of the line, before printing the contents of the next line.

Go Up