That is also fine, but you describe exactly why it shouldn't send anything besides \n if you only type \n, most other devices only expect \n, they don't expect \r and \n, so it shouldn't send both unless specifically told to do so.

Then your solution is simply telling your serial client on your PC to expect only \n.

Hello Joey Ye,

what solution do you propose? To handle this at the sender side? I like that, if there's like "line discipline", to select what should go to the receiver side. By default, only LF (\n) is supplied, otherwise to each LF add CR (\r\n). What do you say?

Regards,
0xc0170

Hello, Martin,

What's I'm suggesting is 1. printf sends \n 2. whe _write function of retarget sees \n, call serial_putc twice to send \r and \n 3. no change serial sender 4. receiver get \r\n

By doing this, other devices still receive what ever they got before. The only place got impacted is printf like function, which we know that receiver is no other device, but a serial terminal who usually expect \r\n.

Thanks, Joey

I'm going to implement it, which is just 2 lines of change.

For those who want only \n, though I doubt anyone would need it, no good solution. For IAR and GCC, the mode parameter of _write isn't available, which could have been helpful to solve it.

Thanks, Joey

My vote is to leave the code as is. If you use a terminal program like screen that wants /r/n then use it in your printf() statements. If you have a more flexible terminal program (most of the other terminal programs) which can just accept /n then use it instead. I think an embedded framework should be light weight and having such a conversion down in _write() is overkill. I only use \n in my printf() statements since I switched away from screen on my second day of using the mbed.