# cu and auto carriage return



## jbo (May 10, 2022)

I have an embedded device which provides some debug output over good old serial. I use cu(1) to look at the serial output on my FreeBSD host.
The problem I'm experiencing is that the embedded device only sends newline `\n` which makes the content shown in cu(1) appear shifting to the right due to the missing carriage return.

Is there a way to instruct cu(1) to automatically insert a carriage return `\r` after each `\n` occured?

I've also looked at comms/minicom for such a feature but didn't find any. It's likely that I'm looking for the wrong terms.


----------



## covacat (May 10, 2022)

escape to shell 
and type
stty onlcr


----------



## jbo (May 10, 2022)

Hmm, not sure if I'm getting this right. Here's what I did:

Leave the current cu(1) session essentially returning to shell (in my case shells/fish)
Run `stty onlcr`
Start cu(1) session again (from the same shell).
I could not observe a change in behavior tho. Did I misunderstand your instructions?

Just to be clear here: The embedded device that talks to my FreeBSD host over serial is NOT running FreeBSD. It's a traditional embedded device with a small microcontroller. Nothing fancy.


----------



## covacat (May 10, 2022)

~!      Escape to a shell (exiting the shell will return to cu).
then stty


----------



## covacat (May 10, 2022)

```
[18:19:59] [ns!user]~$stty -onlcr && jot 4
1
 2
  3
   4
    [18:20:16] [ns!user]~$stty onlcr && jot 4
1
2
3
4
```


----------



## jbo (May 10, 2022)

Hmm... still missing the `CR` after following those instructions. Not sure what I'm doing wrong.
I start cu(1) from shells/fish within x11/kitty (within an X session). That shouldn't matter, right?


----------



## covacat (May 10, 2022)

it should not
somehow the tty / term data gets altered, it might be a control code sent by the device
normal programs like cat, ls never output CRs (\r) , the tty / term does the stuff
so the session transcript does not have to contain CRs for a proper output


----------



## covacat (May 10, 2022)

you can also can try to connect with screen


----------



## jbo (May 10, 2022)

Don't seem to be able to get this working...

In the meantime, I tried comms/picocom which provides the `--imap` option which can be used to map incoming `\n` to `\r\n` like this:


```
picocom /dev/cuaU0 --baud 115200 --imap=lfcrlf
```

This way I get automatically inserted CRs as expected. However, I'd really prefer a solution using FreeBSD built-in infrastructure such as cu(1).


----------



## covacat (May 10, 2022)

thats for input mapping, it seems the device expects \r\n when you press enter
normal tty behaviour is to send only \n
you can't do that easily
for a try you can stty -icrnl and then use ^M^J instead or <Enter>


----------



## jbo (May 10, 2022)

The serial line between my FreeBSD host and the device is TX (from the device's perspective) only. There is physically no connection to send data from the host to the device.
Picocom's `--imap` mapping feature considers input to be from device to host - which is why it works in my case. There is also `--omap` for the same feature but the other directory (from host to device) - not relevant in my case.

What I mean to say: My problem is that the data from the device to the host is only containing \n but no \r which makes the device's output "shift across the screen" on my FreeBSD host's serial terminal (eg. via cu(1)).
Is it possible that there was some misunderstanding here and your information regarding `stty onlcr/cmd] is only working for the direction from host to the device whereas I'm looking for the opposite (insert CR at LF when data flows from the device to the host)?`


----------



## covacat (May 10, 2022)

the tty driver should do that automatically with onlcr (start a new line at every line feed)
programs like ls dont output "\r" and still the stairway effect is not present 
unless cu does some funny stuff. the device should not be required to send carriage returns at all

what if you just cat /dev/cuaU0
set speed,parity,stop with stty on /dev/cuaU0.init and the cat it
or hexdump it

 stty -parenb cs8 -cstopb speed 19200 < /dev/cuaU0.init (19200,8,N,1)
cat /dev/cuaU0


----------

