cu and auto carriage return

J

jbo@

Developer
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.
 
Hmm, not sure if I'm getting this right. Here's what I did:
  1. Leave the current cu(1) session essentially returning to shell (in my case shells/fish)
  2. Run stty onlcr
  3. 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.
 
Code: 
[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
 
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
 
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:

Code: 
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).
 
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>
 
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)?
 
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
 
You must log in or register to reply here.
Back
Top