Serial Programming Howto
Linux serial programming Chinese English Simplified Control Beta Edition
Translation: Carol Li
Original: garyfreking gary@frerking.orgpeter baumann
.
This document describes how to develop procedures for communicating through serial port on Linux devices
The Chinese Simplified Edition is based on the English version 1.01, and also refers to the serial programming of Traditional Chinese.
1. Introduction Introduction This is the Linux Serial Programming HOWTO All about how to program communications with other devices / computers over a serial line under Linux Different techniques are explained:.. Canonical I / O (only complete lines are transmitted / received), asyncronous I / O, and waiting for input from multiple sources. This is the first update to the initial release of the Linux Serial Programming HOWTO. The primary purpose of this update is to change the author information and convert the document to DocBook format. In terms of technical content, very little if anything has changed at this time. Sweeping changes to the technical content are not going to happen overnight, but I'll work on it as much as time allows. If you've been waiting in the wings for someone to take over this HOWTO, you've gotten your wish. Please send me any and all feedback you have, it'd be very much appreciated. All examples were tested using a i386 Linux Kernel 2.0.29. This article is for Linux HOWTO written in the serial program. On how to write a serial port with other computer devices in a Linux environment. The techniques discussed herein include: Standard I / O (only available for transfer / receiving lines), asynchronous I / O, and programs waiting for input from multi-signal source. This article is the first upgrade version of the initial Linux Serial Programming Howto. Mainly upgraded some author information, convert files to DocBook format. There is almost no big change in terms of technical content. The change in mass technical content is impossible to happen overnight. If time allows, I will try to do some work. If you are waiting for anyone who takes over this HOWTO, then your wish is reached. I will thank you for any feedback information. All examples are passed under I386 Linux Kernel 2.0.29.
1.1. Copyright Information Copyright Information This document is copyrighted (c) 1997 Peter Baumann, (c) 2001 Gary Frerking and is distributed under the terms of the Linux Documentation Project (LDP) license, stated below. Unless otherwise stated, Linux HOWTO documents are . copyrighted by their respective authors Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies Commercial redistribution is allowed and encouraged;. however, the author Would Like to Be Notified of Any Such Distributions. (C) 1997 is owned by Peter Baumann, (C) 2001 belongs to Gary Fract, and is released in LDP Lisnce (é). Unless otherwise stated, the copyright of the Linux HOWTO file is owned by the respective authors. The Linux Howto file can be copied or published in the form of a physical or electronic version, as long as the copyright is reserved in all copies. We encourage the release of business, but if you are published in this form, please let the author.
All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions;. please contact the Linux HOWTO coordinator at the address given below In short, we wish to promote dissemination of this information through as many channels as possible However, we do wish to retain copyright on the HOWTO documents, and would like. To be notified by any plan to redistribute the howto. If you have any questions, please contact
1.2. Disclaimer stated No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author (s) do not take any responsibility for that. All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements. You are strongly recommended to take a backup of your system before major installation and backups at regular intervals The risk of using this article, examples and other content is borne by you, and we are not responsible for the consequences of this. Since this is a new document, there may be errors or errors, and it is possible to cause damage to your system. Please be careful, although this is almost impossible, the author does not assume any responsibility. All copyrights are owned by their respective authors unless special labels. Use this document that cannot be marked with any trademark or service tag. Names of specific products or brands cannot be understood to be recognized. (Halo, this paragraph should ask a lawyer to turn).
It is highly recommended that you back up your system before you have a regular installation. 1.3. New Versions Release Update As Previously Mentioned, Not Much IS New In Terms of Technical Content Yet. As mentioned earlier, this version does not have a big update in the technical content. 1.4. Credits to thank The original author thanked Mr. Strudthoff, Michael Carter, Peter Waltenberg, Antonino Ianella, Greg Hankins, Dave Pfaltzgraff, Sean Lincolne, Michael Wiedmann, and Adrey Bonar. Author thanks Strudthoff, Michael Carter, Peter Waltenberg, Antonino Ianella Mr. Greg Hankins, Dave Pfaltzgraff, Sean Lincolne, MICHAEL WIEDMANN, Mr. And Adrey Bonar. . 1.5 Feedback Feedback Feedback is most certainly welcome for this document Without your submissions and input, this document would not exist Please send your additions, comments and criticisms to the following email address:..
There is any additional, comment, critic, please send a message to: gary@frerking.org 2. getting start 3.1. Debugging debugging the best way to debug your code is to set up another linux box, and connect the Two Computers via a null- modem cable. Use miniterm (available from the LDP programmers guide (ftp://sunsite.unc.edu/pub/Linux/docs/LDP/programmers-guide/lpg-0.4.tar.gz in the examples directory) to transmit characters to your Linux box. Miniterm can be compiled very easily and will transmit all keyboard input raw over the serial port. Only the define statement #define MODEMDEVICE "/ dev / ttyS0" has to be checked. Set it to ttyS0 for COM1, ttyS1 for COM2, etc .. It is essential for testing, that all characters are transmitted raw (without output processing) over the line. To test your connection, start miniterm on both computers and just type away. The characters input on one computer should appear on The Other Computer And Vice Versa. The Input Will NOT BE Echoed To The Attached Screen. Debug code is the best way to establish a Linux host (Linux box), non-modem The serial line (NULL-MODEM) connects two machines. You can also use Minicom (you can get from the LDP program guide: ftp://sunsite.edu/pub/linux/docs/ldp/programmers-guide/lpg-0.4.tar.gz "Examples directory) to transfer characters Go to your Linux host. Miniterm is easy to compile and direct the input of the keyboard to the serial port directly (RAW mode). Just try to declare the definition #define modemdody "/ dev / ttys0" to change. COM1 is set to TTYS0, and COM2 is TTYS1, which push ... Test is required, all characters are transferred directly through cable transfer, and no output processing is performed. In order to test your connection, open Minicom on your two machines and enter some characters free. The characters entered from a computer should be displayed on another device and vice versa. The input character does not echode (echo) on the local screen. To make a null-mod (transmit) and rxd (receive) Lines. For a description of a Cable See SECT. 7 of The Serial-HowTo.
When a NULL-MODEM CABLE is self-made, you need to connect one end transfer end (TXD) to the receiving end (RXD) of the other end, connecting the transmitting end of the other end with the other end, see Serial-HowTo Seventh section.
It is also possible to perform this testing with only one computer, if you have two unused serial ports. You can then run two miniterms off two virtual consoles. If you free a serial port by disconnecting the mouse, remember to redirect / dev / mouse if it exists. If you use a multiport serial card, be sure to configure it correctly. I had mine configured wrong and everything worked fine as long as I was testing only on my computer. When I connected to another computer, the port started loosing CHARACTERS. EXECUTING TWO Programs on One Computer Just Isn't Fully Asynchronous. If your computer has two idle serial port ports, you can do these tests as long as you use a machine, you can do it on both virtual consoles. Each runs a Miniterm, used to send and receive results, respectively. If you use a serial mouse, remember to redirect the / dev / mouse before the test. If you use multiport serial cards, you must make sure that this device is configured correctly, my computer has this problem because of the configuration error: When I test it on my own machine, everything is normal, When connecting to other computers, the port begins to lose data. Note that running two serial applications on a machine is not fully asynchronous. 2.2. Port Settings Port Settings The devices / dev / ttyS * are intended to hook up terminals to your Linux box, and are configured for this use after startup. This has to be kept in mind when programming communication with a raw device. Eg the Ports are configured to echo characters Sent from the Device Back to it, Which Normal Has To Be Changd for Data Transmission. Device / dev / ttys * will be treated as terminal devices connected to your Linux machine, and after the system is started It has been configured. This is necessary to keep in mind when you write the serial communication program of the RAW device. For example, this serial port is set to return (Echo) all the characters sent from this device, usually, when doing data transmission, you need to change this Operating mode. All Parameters Can Be Easily Configured from Withnin A Structure Struct Termios, Which is defined in
Struct termios {
Tcflag_t c_iflag; / * Input mode flags * /
Tcflag_t c_oflag; / * Output Mode Flags * / Tcflag_t c_cflag; / * control mode flags * /
TCFLAG_T C_LFLAG; / * local mode flags * /
CC_T C_LINE; / * LINE Discipline * /
CC_T C_CC [NCCS]; / * Control Characters * /
} All parameters can be easily configured in the program. Configuration Save in Structural Struct Termios, this structure is defined in
#define nccs 19
Struct termios {
Tcflag_t c_iflag; / * Input mode flag * /
Tcflag_t c_oflag; / * Output mode logo * /
Tcflag_t c_cflag; / * Control Mode Sign * /
Tcflag_t c_lflag; / * Local mode logo * /
CC_T C_LINE; / * Row Control LINE Discipline * /
CC_T C_CC [NCCS]; / * Control Character Control Characters * /
} This file also includes all flag definitions. The input mode flags in c_iflag handle all input processing, which means that the characters sent from the device can be processed before they are read with read. Similarly c_oflag handles the output processing. C_cflag contains the settings for the port, as the baudrate, bits per character, stop bits, etc .. The local mode flags stored in c_lflag determine if characters are echoed, signals are sent to your program, etc .. Finally the array c_cc defines the control characters for end of file, stop, etc .. Default values for the control characters are defined in
2.3.1. Canonical Input Processing standard input mode This is the normal processing mode for terminals, but can also be useful for communicating with other dl input is processed in units of lines, which means that a read will only return a full line of input A line is by default terminated by a nl (ASCII LF), An end, or an end of line character. A cr (the dos / windows default end-limited) WILL NOT TERMINATE A LINE with the default settings Canonical Input Processing Can Also Handle The Erase, Delete Word, And Reprint Characters, Translate Cr To NL, etc .. This is the standard processing mode of the terminal device, which is also useful in communication with other DL. In this way, the READ will return to a complete integrity input. The end of the line, the default is NL (ASCII value LF), the file end value, or a row end character. In the default setting, Cr (the default line end in DOS / Windows is not the end flag. Standard input processing can also handle clear, delete words, redraw characters, conversion CRs NL, and the like.
Non-Canonical Input Processing will handle a fixed amount of characters per read, and allows for a character timer. This mode should be used if your application will always read a fixed number of characters, or if the connected device sends bursts of characters.
Non-standard input processing can be used to need a timer that allows the character reception time to be used each time you read a fixed quantity character. This mode can be used in a program that reads a fixed length string, or the connected device suddenly sends a large number of characters.
2.3.3. Asynchronous Input asynchronous input mode
The two modes described above can be used in synchronous and asynchronous mode. Synchronous is the default, where a read statement will block, until the read is satisfied. In asynchronous mode the read statement will return immediatly and send a signal to the calling program upon This Signal Can Be Received by A Signal Handler.
The two modes described above can be used in synchronous and asynchronous transmission modes. The default is to work in synchronous mode, that is, the status of the READ will be blocked (Block) before the data is not read. In the asynchronous mode, the status of the READ will return and send a signal to the call to the call until the work. This signal can be received by the signal processing CPCler.
2.3.4. Waiting for Input from Multiple Sources Waiting for the input from multiple signal sources
This is not a different input mode, but might be useful, if you are handling multiple devices. In my application I was handling input over a TCP / IP socket and input over a serial connection from another computer quasi-simultaneously. The program example given below will wait for input from two different input sources. If input from one source becomes available, it will be processed, and the program will then wait for new input.The approach presented below seems rather complex, but it is important to keep in mind that Linux is a multi-processing operating system. The select system call will not load the CPU while waiting for input, whereas looping until input becomes available would slow down other processes executing at the same time.
This section is not another input mode, but if you want to handle data from multiple devices, it may be useful. In my application, I need to handle input from other computers through a TCP / IP socket and a serial port. The sample program given below will wait for input from two different input sources. If one of the signals appear, the program will process it, while the program will continue to wait for new inputs.
The method raised later seems quite mix, but remember that Linux is a multi-process operating system. The system calling SELECT does not increase the burden of the CPU when waiting for the input signal, and if the polling method is used to wait for the input signal, the process will be slowed down slowly.
2.3.2. Non-Canonical Input Processing Non-standard Input Mode
