Binary data over serial terminal

Question

My only way of communication with my embedded device is a serial port. By default, embedded Linux uses this port as a terminal. How do I disable this terminal and use the serial link to transfer binary data? I heard of commands like rx and tx but i cannot find them.

I think I can just read() from and write() stuff to /dev/tty but I want to make sure no error messages or whatever mess with my data stream.

Answer 1

Can't you just set the terminal to raw?

Have a look at this tutorial.

Answer 2

You can run on the terminal a command that will transfer the data through an application-level protocol. The rx and tx commands you refer to implement the XMODEM file transfer protocol. It could be a solution, if the binary data you want to transfer consists of files, the throughput demands are low, and you don't mind the administrative overhead of running the commands. Alternatively, you may want to multiplex the serial port for handling both data transfer and the terminal. Disable the serial terminal driver command (getty), and run the PPP protocoll over the serial line to establish an IP connection to your device. You can then login to the device through ssh or telnet and transfer your data through an IP socket.

Answer 3

Yes, all of your serial ports are in /dev/ttyxx. Note that /dev/tty is a shortcut that stands for your current terminal, not a specific serial port. Often, these are owned by root, and require you to either have privileges or be in the adm group to access the device directly from your application.

You may want to chown the device so you can access it. I'm not sure what the consequence of changing device ownership are; IIRC, it's easy to do and works nicely. The alternative is to use setuid to elevate your program to a privileged state.

There's a program named getty that lets users login from a serial port. Your inittab will start getty on serial ports so people can login.

You want to disable getty. In some cases, there's a port manager that helps do this.

In some cases, you can change your inittab to use mgetty, which is a smarter and easier to control version of getty.

Answer 4

To disable the Linux console you have to change the Linux command line create by the bootloader from : console=/dev/ttyS? to : console=null

Answer 5

You can use an application like xmodem to transfer file over any terminal. Is the serial port you speak off a terminal, or is it also the kernel console.

If you're kernel is not noisy, then you can use your current connection to make xmodem like transfer. On the host side, you can use kermit, which is nice AND scriptable.

If you want to make your serial port raw, and you have file descriptor ttyfd opened, here is one way to do it :

struct termios tty, orig_tty;

...

if(tcgetattr(ttyfd, &tty) < 0)
{
    // error checking
}
// backup tty, make it raw and apply changes
orig_tty = tty;
cfmakeraw(&tty);
if(tcsetattr(ttyfd, TCSAFLUSH, &tty) < 0)
{
    // error checking
}

...
//end of program or error path :
tcsetattr(ttyfd, TCSAFLUSH, &orig_tty)

Don't forget to restore the setting at the end of your program if you still want a good behaved terminal.

Answer 6

As the other notes have implied, there are several things to check, collected here:

1. Make sure the linux kernel isn't using the serial port. Make sure there is either no console= option on the bootload command in your grub file. It usually isn't there by default.
2. Make sure there is no getty running on the serial port. Look in /etc/inittab for an entry for /dev/ttyS0 (serial port A) and comment it out if it is there.
3. Make sure the /dev/ttyS0 is readable and writable by your process. You might create a specific user under which the control program is run, and which owns the /dev/ttyS0, then chmod 700 /dev/ttyS0. This will help make sure some other user/program doesn't also try using the serial port.
4. Use open() on ttyS0 to get an fd, then use the tcsetattr family of routines to set the line speed and discipline.

Terminal programs probably won't be useful to you unless you can run the same program on the embedded device to manage the other end of the connection.