Suppressing CR on LF in C++ in Windows

[Doug Broadwell]

I'm using a serial port to talk between processes running on a Windows computer (running QT4 - MinGW, using QextSerialPort) to a stand-alone process running on an imbedded computer.

It appears that when I end a line with a \n ("nl"), the serial driver under the hood is appending a \r ("cr") to it. The QextSerialPort isn't doing it and I'm assuming (??) that the C++ compiler isn't doing it, and I don't see anything in the win32 serial port API that would disable it.

Is there a way to suppress this behavior?

Thanks

[wysota]

Don't use "\n" :) You can use \x0A (10 dec) instead. Alternatively strip out all 0Dh (13dec) during transmission.

[Doug Broadwell]

I'm afraid that doesn't work, using \x0A instead of \n operates the same. And I can't just strip out \r's following \n's as I'm transmitting binary data and that messes things up.

[wysota]

So prepare the other end of transmission to receive \r\n instead of \n.

[Doug Broadwell]

That's the only way I can deal with it at the moment, it means that I cannot have a "command" number 13 as the first character in a message so I can strip it out if it is following a NL. It works, it's just less elegant and makes my command number enumeration more fragile.

Thanks.

[wysota]

You have an alternative - don't use newlines at all. If you transmit binary data, what do you need the newlines for?

[Doug Broadwell]

It's a convienience to work in a line oriented mode as the embedded cpu has a monitor program that can be accessed via a terminal in line input mode - so the serial receiving program can be the same for both - it buffers characters until a \n then sends a message to either the command processor or monitor program depending upon the mode it's in.

[wysota]

it means that I cannot have a "command" number 13 as the first character in a message

This suggests you are sending bare command numbers. In such a situation you'll be having unprintable characters in your transmission, so you'll end up with trash in your monitor anyway. Maybe it's better to implement the monitor in a way that it "translates" binary data to human readable format and get rid of all textual transmission?

[Doug Broadwell]

Thanks. Actually, I realized in the wee hours of the morning what a ninny I am, there is no way that there could be a "line oriented" binary protocol !!

What I must do is move the logic of the parsing of messages down into the routine that is reading in the characters to switch between the binary message format and the line oriented format (and then, the CR stripping will be trivial for the line oriented case but still a big problem if some driver I have no control over is insisting on inserting a #13 character every time it sees a #10 character).

Sorry for being so dense.

[wysota]

You can use XML (using QDomDocument of course) to have a nice textual representation of your protocol, which is very easy to parse and interpret - this way you can make a nice monitoring application and at the same time have both human readable representation and easy syntax checking on both ends.