Hot answers tagged

28

I find screen the most useful program for serial communication since I use it for other things anyway. It's usually just screen /dev/ttyS0 <speed>, although the default settings may be different for your device. It also allows you to pipe anything into the session by entering command mode and doing exec !! <run some program that generates ...


23

Background The main reason why you need any program like minicom to communicate over a serial port is that the port needs to be set up prior to initiating a connection. If it weren't set up appropriately, the cat and echo commands would not do for you what you might have expected. Notice that once you run a program like minicom, the port is left with the ...


14

My personal flavor for Linux Kernel development is Debian. Now for your points: As you probably guessed Ubuntu doesn't bring nothing new to kernel ease kernel development afaik, apart from what's already available in Debian. For e.g. make_kpkg is a Debian feat. and not Ubuntu. Here are some links to get you started on common Linux Kernel development tasks ...


13

I found a way using a shell script here that put cat as a background process and a while loop that read the user input and echo it out to the port. I modified it to be more general and it fitted my purpose perfectly. #!/bin/sh # connect.sh # Usage: # $ connect.sh <device> <port speed> # Example: connect.sh /dev/ttyS0 9600 # Set up device ...


12

If UUCP is installed on the system, you may use the command cu, e.g. $ cu -l /dev/ttyS0 -s 9600


9

Serial connections don't have a standard way of setting terminal geometry. The assumed geometry is often 80x23 or 80x24 (terminals with zero to two status lines). Once you're logged in, you can set your preferred geometry via the shell, using something like stty rows 50 cols 132 This will last for the duration of your terminal session, but is not ...


7

Just for the record, here is the answer to this Problem (Usenet won): Console Applications running inside virtual terminal applications (xterm, rxvt and friends) will receive SIGWINCH after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler. Unfortunately when using a serial ...


7

have you tried minicom file transfer?


6

Most of the serial console programs (minicom, HyperTerm, VanDyke CRT...) you'll use on the other end of the connection will have Zmodem support, and most Linux boxes have the lrzsz package installed on them already. If not, lrzsz is small enough that you could bootstrap the process with one of the other recommended methods. You could ASCII-upload the ...


6

After reading more on the internets I found out that a newer version of systemd requires a kernel with configuration option CONFIG_FHANDLE=y - however, this option is not present on the kernel version included in the official banana-pi ArchLinux image (3.4.90). I recompiled the kernel with the option included and now the login prompt appears as expected -> ...


6

Wow, that has to be the first time this century that I've heard rx referred to as a "great little utility"! :-) Yet we can still dust the cobwebs off those old commands. XMODEM: rx for receiving, sx for sending. YMODEM: rb for receiving, sb for sending. ZMODEM: rz for reveiving, sz for sending.


6

Assuming you have a kernel with the debugger option compiled in you can use ControlAltEscape. From there you can call boot(0) or panic. Chapter 10 of the FreeBSD developers handbook explains this in a lot more detail. So much for more or less the same as SysReq via a keyboard. On the serial console, you need to send the break signal and have the options ...


4

If you're developing for an embedded platform that's not based on i386 hardware, you'll need to cross-compile. The Emdebian project provides toolchains to develop for many architectures (ARM, m68k, MIPS and more) on PCs (i386 or amd64). That means under Debian, you can simply add the repositories and apt-get install the toolchain for the target(s) of your ...


4

Don't know if this would work if all you had was a serial console, but if you have network access at all, then you could use nc(1) to copy files using TCP/IP. # WARNING: Depending on your setup, this could make your system unbootable root@destination-box.local # nc -l 8675 | dd of=/dev/sda1 root@source-box.local # dd if=/dev/sdb1 | nc destination-box.local ...


3

JTAG probes do exist, but these are fairly expensive (and the companies building them have exclusive contracts). The best way to debug kernel code is to start it in kvm or qemu with gdbserver inside the emulation.


3

BTW, the putty package (which does run on Linux) does include serial support.


3

You could open an additional session with ssh and issue the following command in it: tail -f /dev/ttyS0 it will print out everything that arrives at ttyS0. Of course, this solution is useful if you transmit printable characters only as otherwise your screen may be flooded with garbage.


3

iptables does not effect data sent over the serial port (unless you're running PPP or similar over the port, of course). But that command you gave is pretty broad, for example, you dropped packets that are entirely internal to the machine (go over lo). Depending on how your serial port is set up, maybe that was required. Dropping traffic over lo tends to ...


3

console is specified twice in that cmdline: console=ttyAMA0,115200 console=tty1 Perhaps the second one has overridden the first (it can't be both at the same time). If ttyAMA0 is what you want to use, remove console=tty1.


3

I'm with @Renan: it looks like this problem was fixed in newer kernels. (One such thread on LKML.) The key error is the invalid interface number one. It means the USB driver sees the device, but it's numbering its features (interfaces) in a way the driver doesn't expect, and it can't cope. Googling around, you can find several cases where people are fixing ...


3

Well after a lot of debugging (and head banging against the wall) in the init script that I was using to switch_root to the directory where debian is, I did not mount /dev, /proc and /sys... The correct tty was actually 1:2345:respawn:/sbin/getty ttyHSL0 115200


3

This is typically done using the tcsendbreak C library routine. You can get to this from the shell by using a Python or Perl one-liner: python -c 'import termios; termios.tcsendbreak(3, 0)' 3>/dev/yourdevicename perl -e 'use POSIX; tcsendbreak(3, 0)' 3>/dev/yourdevicename


3

RTS and DTR are output pins - which you can set. DCD and CTS are input pins and can only be read. The device is probably set for hardware handshaking by default. You can change this using tcsetattr (see CRTSCTS). Then you can use the TIOCMBIS ioctl to set RTS and DTR Good references are: Linux Serial HOWTO Linux Serial Programming HOWTO The above might ...


3

There might be simpler and more robust ways to transfer files, but this should work: base64 encode your file on the host system base64 file > file.64 Redirect the serial output to a file on the Pi: cat < /dev/ttyAMA0 > file.64 Use minicom's paste feature: Ctrl + A, Y, then select the file to be transferred. Press Ctrl + D on the Pi after the ...


2

As you say, you cannot read end-of-file from a serial port. (Ctrl-Z is a microsoft thing). So usually, you read until you have the wanted number of characters, or until you find a delimiter like newline that signals the end of the data. For example, I have a usb serial port with output connected back to input, so any writes to the device simply come ...


2

You could launch getty once you've booted to get a serial connection to your system. Note that this will not give you the default outputs typically seen with your console (Kernel Panics and other verbosities typically seen in console but not in normal terminals). But if you are just looking to get a login via serial after boot this should work. /sbin/agetty ...


2

Instead of launching minicom by typing: minicom type the following instead: TERM=linux minicom


2

When you start a virtual terminal connected to something like an X terminal emulator or an SSH session, the terminal size is configured for you (e.g. forwarded over SSH from your local terminal). As you've discovered, when connecting over a raw serial port, this does not happen. Option 1: just run resize This command will attempt to discover the size of ...


2

Use the screen quit command (normally ctrl-A ctrl-\).



Only top voted, non community-wiki answers of a minimum length are eligible