Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm connecting to a USB-serial connection on /dev/ttyACM0. The code on the sender side is sending a \f character at regular intervals.

    print("----------------------------\n\r");
    print("-- LED CONTROLLER 00.01   --\n\r");
    print("-- (c) 2013 STACEY RIECK  --\n\r");
    print("----------------------------\n\r");
    print("\n\f");

However, when I run cat /dev/ttyACM0 from console, the output scrolls down my screen instead of refreshing at the top.

I've dug through the current stty settings (by typing stty -F /dev/ttyACM0 -a) which gives the following output:

speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

Reading the stty --help page gives the form feed delay (ff0), but doesn't indicate how to change anything else. I also found this page which indicates that I can set the FormFeed character like so FormFeed=014, but that syntax didn't work for my stty version (stty --version gives stty (GNU coreutils) 8.5).

Putty in Windows exhibits the correct behaviour, but I'm struggling to get this to work in Debian 6. Does anyone know how I can configure stty to interpret a form feed as a terminal clear?

share|improve this question

4 Answers 4

up vote 2 down vote accepted

You need to replace the form feed character (\f) with proper ANSI Escape codes.

You can do this with GNU sed:

sed 's/\f/\o33[2J\o33[0;0H/g' /dev/ttyACM0

In detail: \033[2J Clear screen, \033[0;0H: Go to pos 0,0

(If this does not work, try tail -f /dev/ttyACM0 | sed 's/\f/\o33[2J\o33[0;0H/g')

share|improve this answer
    
I believe the FPGA is not sending the two characters backslash and f, but the correct control byte 0x0C. –  eppesuig Apr 30 '13 at 16:47
    
@eppesuig Yes, but sed interprets escape codes in its arguments. So it really replaces 0x0C. –  jofel Apr 30 '13 at 16:49
    
How would this be used? Is the sed command going to return the result to the stdout, so I would use this in replacement of cat? –  Stacey Anne Apr 30 '13 at 17:00
    
@StaceyAnne Yes, sed writes to stdout. It behaves like cat: It either reads from the file in its arguments list or from stdin. –  jofel Apr 30 '13 at 17:12
    
@jofel it seems that sed does not interpret control character. The following command show it: echo "\f" | sed 's/\f/formfeed received/g'. In your example it should not match the line while it matches the line. –  eppesuig Apr 30 '13 at 17:26

When your FPGA execute the print("\n\f") it is really sending two bytes on its stdout, the first one is a linefeed and the second one is a formfeed. These bytes are 0x0A and 0x0C.

Then, the stdout is trasferred over the USB cable, and read via an emulated serial device. This serial device will just trasfer both bytes to the controlling terminal (because you are reading it via the cat command), and eventually to your gnome-terminal, xterm or any other program you are using. This terminal emulator have to understand both bytes and act accordingly.

So, you have to check the capabilities of your emulator. Which one are you using?

share|improve this answer
    
Ah. You make a good point. I'm using LXDE and so LXterminal is the one I use the most. Trying echo -e "\f" in the terminal doesn't clear the screen, which explains why it hasn't been working. I've tried xterm, LXterminal, and the terminal I get when I go CTL-ALT-F1 which identifies as "linux" accoring to $TERM, and all three of those don't work. –  Stacey Anne Apr 30 '13 at 16:53
1  
At least, the xterm manual page at xfree86.org/current/ctlseqs.html seems to clarify the while in VT100 emulation a formfeed is translated in a linefeed. –  eppesuig Apr 30 '13 at 17:08
    
I would really like to change the mode that the xterm runs in, but I'm not really sure how to generate the control characters in xterm using my keyboard. I tried ESC-[->-0, but I think I'm way off base with that. –  Stacey Anne May 1 '13 at 4:26

I found a lot of references online that say bash should interpret \f as a clear screen. And just as many saying it doesn't work.

You may be able to mess with your stty settings to get it to interpret \f properly (which in this context would be written as ^L for Ctrl+L). But I couldn't find anything obvious.

A workaround would be to change your code. But there is no easy, cross-platform way to clear the screen. However, there are many ways to choose from. If possible, you can link in a curses library and use that. Or stdlib.h and use system().

Personally, the way I've always done it, is to just send the ANSI Escape Code:

printf("\033[2J");

I'm pretty sure bash will interpret this just fine. And you just need to make sure to turn on ANSI/VT100 compatibility when using PuTTY or Hyperterminal.

share|improve this answer
    
unfortunately I can't do anything too elaborate from the sender side, because the sender device is an FPGA-based microcontroller that I'm trying to keep as small as possible. However, the ANSI escape code will definitely be a viable option if I can convince stty to turn on ANSI (or even better, if it's enabled by default). PS: fancy seeing you on this side of the SE world –  Stacey Anne Apr 30 '13 at 14:21
    
@StaceyAnne The *nix side shouldn't have trouble with the ANSI codes. It's usually the Windows side that requires extra configuration. Though it might be a good idea to do stty term=vt100. And I kind of assumed you'd be coming from an FPGA ;-) I figured you would be able to use a big library but included it to make a more complete answer. –  embedded.kyle Apr 30 '13 at 14:49
    
bash interprets Ctrl-L: If you type Ctrl-L and there is a bash running, then it clears the screen. But here, the Ctrl-L (\f) is not a keystroke, and it's not interpreted by a bash. –  Uwe Apr 30 '13 at 15:32
    
@Uwe I understand. But I can get the same behavior with echo -e "\f". Though I don't fully understand the mechanism by which is does so. Is that telling bash to interpret the escape code as a Ctrl keystroke? –  embedded.kyle Apr 30 '13 at 16:04
    
@embedded.kyle No, it seems that your terminal program receives the Ctrl-L and reacts by clearing the screen. Probably it's not a bash issue. I can't reproduce this behaviour with a bash running in either xterm or konsole. What terminal program are you using? –  Uwe Apr 30 '13 at 16:19

Since the problem is about the correct emulation of an ANSI terminal, I think the best option you have is to connect to the serial-to-USB converter with minicom. Just remember to open the serial device without initialising the modem, i.e., without sending hayes commands on startup.

share|improve this answer
    
I've tried minicom and it displayed nothing. My command was minicom -o -D /dev/ttyACM0 -b 115200. Is -o the correct way to bypass modem initialisation? –  Stacey Anne May 1 '13 at 2:46
    
These settings are the same as shown from your first stty command, so, yes, they seems right. Does minicom show the serial line status (connected or disconnected)? Does this status change when you disconnect the serial cable from the USB converter? –  eppesuig May 1 '13 at 6:49
    
I did setup with minicom -s and added the extra lines to the config to disable modem initialisation. if I run cat /dev/ttyACM0 it works. Then I run minicom which gives "Online" at the bottom, with correct settings, but no data. CTRL-A X exits minicom. then cat doesn't work anymore :(. Cable removal switches from Online to Offline as expected, but minicom doesn't recover from cable insertion right away. Had to exit minicom and re-try for it to detect port again. Found it on ~3rd retry. –  Stacey Anne May 1 '13 at 7:05
    
cat recovers with cable removal and re-insertion, which I would imagine flushes whatever buffer is getting confused. Very much running out of ideas at this point. –  Stacey Anne May 1 '13 at 7:08
    
Sadly, I have no other suggestions beside checking all serial settings. –  eppesuig May 1 '13 at 21:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.