4.10 Terminal Emulators
The most common way to communicate with an embedded system is to use a terminal emulation program on the host to communicate through an RS232 serial port with the target. Although there are a few terminal emulation programs available for Linux, not all are fit for all uses. There are known problems between minicom and U-Boot, for instance, during file transfers over the serial port. Hence, I recommend that you try more than one terminal application to communicate with your target. If nothing else, you are likely to discover one that best fits your personal preferences. Also, see your bootloader's documentation for any warnings regarding any terminal emulator.
Three main terminal emulators are available in Linux: minicom, cu, and kermit. The following sections cover the setup and configuration of these tools, but not their use. Refer to each package's documentation for the latter.
4.10.1 Accessing the Serial Port
Before you can use any terminal emulator, you must ensure that you have the appropriate access rights to use the serial port on your host. In particular, you need read and write access to the serial port device, which is /dev/ttyS0 in most cases, and read and write access to the /var/lock directory. Access to /dev/ttyS0 is required to be able to talk to the serial port. Access to /var/lock is required to be able to lock access to the serial port. If you do not have these rights, any terminal emulator you use will complain at startup.[16]
[16] The actual changes required for your distribution may differ from those discussed in this section. Refer to your distribution's documentation in case of doubt.
The default permission bits and group settings for /dev/ttyS0 vary between distributions, and sometimes between releases of the same distribution. On Red Hat 6.2, for example, it used to be accessible in read and write mode to the root user only:
$ ls -al /dev/ttyS0 crw------- 1 root tty 4, 64 May 5 1998 /dev/ttyS0
As with /dev/ttyS0, the permission bits and group settings for /var/lock largely depend on the distribution. For the same Red Hat 6.2, /var/lock was accessible to the root user and any member of the uucp group:
$ ls -ld /var/lock drwxrwxr-x 5 root uucp 1024 Oct 2 17:14 /var/lock
Though Red Hat 6.2 is outdated, and your distribution is likely to have different values, this setup is a perfect example to illustrate the modifications required to allow proper access to the serial port. In this case, to use a terminal emulator on the serial port as a normal user, you must be part of both the tty and uucp groups, and access rights to /dev/ttyS0 must be changed to allow read and write access to members of the owning group. In some distributions, the access rights to /dev/ttyS0 will be set properly, but /var/lock will belong to the root group. In that case, you may want to change the group setting, unless you want to allow normal users in the root group, which I do not recommend.
Going back to Red Hat 6.2, use chmod to change the rights on /dev/ttyS0:
$ su Password: # chmod 660 /dev/ttyS0 # ls -al /dev/ttyS0 crw-rw---- 1 root tty 4, 64 May 5 1998 /dev/ttyS0
Then, edit the /etc/group file using vigr[17] and add your username to the uucp and tty lines:
[17] This command is tailored for the editing of the /etc/group file. It sets the appropriate locks to ensure that only one user is accessing the file at any time. See the manpage for more information.
... tty:x:5:karim ... uucp:x:14:uucp,karim ...
Finally, log out from root user mode, log out from your own account, and log back in to your account:
# exit $ id uid=501(karim) gid=501(karim) groups=501(karim) $ exit Teotihuacan login: karim Password: $ id uid=501(karim) gid=501(karim) groups=501(karim),5(tty),14(uucp)
As you can see, you need to first log out and then log back in for the changes to take effect. Opening a new terminal window in your GUI may have similar effects, depending on the GUI your are using and the way it starts new terminal windows. Even if it works, however, only the new terminal window will be part of the appropriate groups, but any other window opened before the changes will still be excluded. For this reason, it is preferable to exit your GUI, completely log out, and then log back in.
For more information on the setup of the serial interface, have a look at the Serial HOWTO available from the LDP and Chapter 4 of the Linux Network Administrator's Guide (O'Reilly).
4.10.2 Minicom
Minicom is the most commonly used terminal emulator for Linux. Most documentation online or in print about embedded Linux assumes that you are using minicom. However, as I said above, there are known file transfer problems between minicom and at least one bootloader. Minicom is a GPL clone of the Telix DOS program and provides ANSI and VT102 terminals. Its project web site is currently located at http://www.netsonic.fi/~walker/minicom.html. Minicom is likely to have been installed by your distribution. You can verify this by using rpm -q minicom if you are using a Red Hat-based distribution.
Minicom is started by using the minicom command:
$ minicom
The utility starts in full-screen mode and displays the following on the top of the screen:
Welcome to minicom 1.83.0 OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n Compiled on Mar 7 2000, 06:12:31. Press CTRL-A Z for help on special keys
To enter commands to minicom, press Ctrl-A and then the letter of the desired function. As stated by minicom's welcome message, use Ctrl-A Z to get help from minicom. Refer to the package's manpage for more details about its use.
4.10.3 UUCP cu
Unix to Unix CoPy (UUCP) used to be one of the most popular ways to link Unix systems. Though UUCP is rarely used today, the cu command part of the UUCP package can be used to call up other systems. The connection used to communicate to the other system can take many forms. In our case, we are mostly interested in establishing a terminal connection over a serial line to our target.
To this end, we must add the appropriate entries to the configuration files used by UUCP. In particular, this means adding a port entry in /etc/uucp/port and a remote system definition to /etc/uucp/sys. As the UUCP info page states, "a port is a particular hardware connection on your computer," whereas a system definition describes the system to connect to and the port used to connect to it.
Though UUCP is available from the GNU FTP site under the terms of the GPL, it is usually already installed on your system. On a Red Hat-based system, use rpm -q uucp to verify that it is installed.
Here is an example /etc/uucp/port:
# /etc/uucp/port - UUCP ports # /dev/ttyS0 port ttyS0 # Port name type direct # Direct connection to other system device /dev/ttyS0 # Port device node hardflow false # No hardware flow control speed 115200 # Line speed
This entry states that there is a port called ttyS0 that uses direct 115200 bps connections without hardware flow control to connect to remote systems through /dev/ttyS0. The name of the port in this case, ttyS0, is used only to identify this port definition for the rest of UUCP utilities and configuration files. If you've used UUCP before to connect using a traditional modem, you will notice that this entry resembles modem definitions. Unlike modem definitions, however, there is no need to provide a carrier field to specify whether a carrier should be expected. Setting the connection type to direct makes carrier default to false.
Here is an example /etc/uucp/sys file that complements the /etc/uucp/port file listed earlier:
# /etc/uucp/sys - name UUCP neighbors # system: target system target # Remote system name port ttyS0 # Port name time any # Access is possible at any time
Basically, this definition states that the system called target can be called up at any time using port ttyS0.
We can now use cu to connect to the target:
$ cu target Connected.
Once in a cu session, you can issue instructions using the ~ character followed by another character specifying the actual command. For a complete list of commands, use ~?.
For more information on how to configure and customize UUCP for your system, have a look at Chapter 16 in the Linux Network Administrator's Guide (O'Reilly), the UUCP HOWTO available from the LDP, and the UUCP info page.
4.10.4 C-Kermit
C-Kermit is one of the packages maintained as part of Columbia University's Kermit project (http://www.columbia.edu/kermit/). C-Kermit provides a unified interface for network operations across a wide range of platforms. Although it features many capabilities, terminal emulation is the package's capability we are most interested in.
Though you are free to download C-Kermit for personal and internal use, C-Kermit is not open source software and its licensing makes it difficult for commercial distributions to include it.[18] C-Kermit is available for download from http://www.columbia.edu/kermit/ckermit.html. Follow the documentation in the ckuins.txt file included with the package to compile and install C-Kermit. In contrast with most other tools we discuss in this book, C-Kermit should be installed system wide, not locally to your project workspace. Once installed, C-Kermit is started using the kermit command.
[18] Although the license was changed lately to simplify inclusion in commercial distributions such as Red Hat, C-Kermit has yet to be included in most mainstream distributions.
In terms of usability, kermit compares quite favorably to both minicom and cu. Despite its lack of user menus, as provided by minicom, kermit's interactive command language provides a very intuitive and powerful way of interacting with the terminal emulator. When you initiate a file transfer from the target's bootloader, for example, the bootloader starts waiting for the file. You can then switch to kermit's interactive command line on the host using Ctrl-\ C and send the actual file using the send command. Among other things, the interactive command line provides Tab filename completion similar to that provided by most shells in Linux. Also, the interactive command line is capable of recognizing commands using the shortest unique character string part of a command name. The set receive command, for example, can be shortened to set rec.
To use the kermit command, you must have a .kermrc configuration file in your home directory. This file is run by kermit at startup. Here is an example .kermrc file that I use on my workstation:
; Line properties set modem type none ; Direct connection set line /dev/ttyS0 ; Device file set speed 115200 ; Line speed set carrier-watch off ; No carrier expected set handshake none ; No handshaking set flow-control none ; No flow control ; Communication properties robust ; Most robust transfer settings macro set receive packet-length 1000 ; Max pack len remote system should use set send packet-length 1000 ; Max pack len local system should use set window 10 ; Nbr of packets to send until ack ; File transfer properties set file type binary ; All files transferred are binary set file names literal ; Don't modify filenames during xfers
For more information about each of the settings above, try the help command provided by kermit's interactive command line. For more information regarding the robust macro, for example, use help robust. In this case, robust must be used before set receive, since robust sets the maximum packet length to be used by the remote system to 90 bytes, while we want it set to 1000 bytes.
Once the configuration file is created, you can start kermit:
$ kermit -c Connecting to /dev/ttyS0, speed 115200 Escape character: Ctrl-\ (ASCII 28, FS): enabled Type the escape character followed by C to get back, or followed by ? to see other options. ----------------------------------------------------
If you are looking for more information about the use of C-Kermit and intend to use it more extensively, think about purchasing the Using C-Kermit book by Frank Da Cruz and Christine Gianone (Digital Press). Apart from providing information regarding the use of C-Kermit, sales of the book help fund the project. Though the book covers Version 6.0, supplements for Versions 7.0 and 8.0 are freely available from the project's web site.
