Hi,

...

is there a particular reason why xpcc::endl appends only `\n`, and not `\n\r` ? When using a serial device from the command line (using screen, picocom, etc) this gets annoying _really_ quickly, as there are no options to treat a newline as a newline with a carriage return.

Yes, there are. At least for picocom, I don't know about screen. Use "picocom --imap lfcrlf /dev/…"

Yes! That works. If you install picocom v1.7 from source, because in 12.04 only v1.4 is available and it does not have that feature yet ;-)

...

Are there any concerns over just changing xpcc::endl to append `\n\r` ?

I don't like '\r' :-) But for terminals it might be a useful solution. Perhaps it would be nice to make that changeable via a xpcc define.

Actually I think the current solution is the “correct" one. In C/C++ this is the standard behaviour: "When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.” [1] Since we do not know what the native newline sequence of the OS that reads the output is, we cannot “solve” this problem. Of course it does not change the fact, that `screen` (arguably the most simple and available terminal there is) cannot remap this. So yes, we should allow customization via define. Cheers, Niklas [1]: http://en.wikipedia.org/wiki/Newline