1 | Downloaded from http://www.lafn.org/~dave/linux/Serial-Programming-HOWTO.txt
|
---|
2 | Seems to be somewhat old, but contains useful bits for getty.c hacking
|
---|
3 | ============================================================================
|
---|
4 |
|
---|
5 | The Linux Serial Programming HOWTO, Part 1 of 2
|
---|
6 | By Vernon C. Hoxie
|
---|
7 | v2.0 10 September 1999
|
---|
8 |
|
---|
9 | This document describes how to program communications with devices
|
---|
10 | over a serial port on a Linux box.
|
---|
11 | ______________________________________________________________________
|
---|
12 |
|
---|
13 | Table of Contents
|
---|
14 |
|
---|
15 | 1. Copyright
|
---|
16 |
|
---|
17 | 2. Introduction
|
---|
18 |
|
---|
19 | 3. Opening
|
---|
20 |
|
---|
21 | 4. Commands
|
---|
22 |
|
---|
23 | 5. Changing Baud Rates
|
---|
24 |
|
---|
25 | 6. Additional Control Calls
|
---|
26 |
|
---|
27 | 6.1 Sending a "break".
|
---|
28 | 6.2 Hardware flow control.
|
---|
29 | 6.3 Flushing I/O buffers.
|
---|
30 |
|
---|
31 | 7. Modem control
|
---|
32 |
|
---|
33 | 8. Process Groups
|
---|
34 |
|
---|
35 | 8.1 Sessions
|
---|
36 | 8.2 Process Groups
|
---|
37 | 8.3 Controlling Terminal
|
---|
38 | 8.3.1 Get the foreground group process id.
|
---|
39 | 8.3.2 Set the foreground process group id of a terminal.
|
---|
40 | 8.3.3 Get process group id.
|
---|
41 |
|
---|
42 | 9. Lockfiles
|
---|
43 |
|
---|
44 | 10. Additional Information
|
---|
45 |
|
---|
46 | 11. Feedback
|
---|
47 |
|
---|
48 | ______________________________________________________________________
|
---|
49 |
|
---|
50 | 1. Copyright
|
---|
51 |
|
---|
52 | The Linux Serial-Programming-HOWTO is copyright (C) 1997 by Vernon
|
---|
53 | Hoxie. Linux HOWTO documents may be reproduced and distributed in
|
---|
54 | whole or in part, in any medium physical or electronic, as long as
|
---|
55 | this copyright notice is retained on all copies. Commercial
|
---|
56 | redistribution is allowed and encouraged; however, the author would
|
---|
57 | like to be notified of any such distributions.
|
---|
58 |
|
---|
59 | All translations, derivative works, or aggregate works incorporating
|
---|
60 | this Linux HOWTO document must be covered under this copyright notice.
|
---|
61 | That is, you may not produce a derivative work from this HOWTO and
|
---|
62 | impose additional restrictions on its distribution.
|
---|
63 |
|
---|
64 | This version is a complete rewrite of the previous Serial-Programming-
|
---|
65 | HOWTO by Peter H. Baumann, <mailto:Peter.Baumann@dlr.de>
|
---|
66 |
|
---|
67 | 2. Introduction
|
---|
68 |
|
---|
69 | This HOWTO will attempt to give hints about how to write a program
|
---|
70 | which needs to access a serial port. Its principal focus will be on
|
---|
71 | the Linux implementation and what the meaning of the various library
|
---|
72 | functions available.
|
---|
73 |
|
---|
74 | Someone asked about which of several sequences of operations was
|
---|
75 | right. There is no absolute right way to accomplish an outcome. The
|
---|
76 | options available are too numerous. If your sequences produces the
|
---|
77 | desired results, then that is the right way for you. Another
|
---|
78 | programmer may select another set of options and get the same results.
|
---|
79 | His method is right for him.
|
---|
80 |
|
---|
81 | Neither of these methods may operate properly with some other
|
---|
82 | implementation of UNIX. It is strange that many of the concepts which
|
---|
83 | were implemented in the SYSV version have been dumped. Because UNIX
|
---|
84 | was developed by AT&T and much code has been generated on those
|
---|
85 | concepts, the AT&T version should be the standard to which others
|
---|
86 | should emulate.
|
---|
87 |
|
---|
88 | Now the standard is POSIX.
|
---|
89 |
|
---|
90 | It was once stated that the popularity of UNIX and C was that they
|
---|
91 | were created by programmers for programmers. Not by scholars who
|
---|
92 | insist on purity of style in deference to results and simplicity of
|
---|
93 | use. Not by committees with people who have diverse personal or
|
---|
94 | proprietary agenda. Now ANSI and POSIX have strayed from those
|
---|
95 | original clear and simply concepts.
|
---|
96 |
|
---|
97 | 3. Opening
|
---|
98 |
|
---|
99 | The various serial devices are opened just as any other file.
|
---|
100 | Although, the fopen(3) command may be used, the plain open(2) is
|
---|
101 | preferred. This call returns the file descriptor which is required
|
---|
102 | for the various commands that configure the interface.
|
---|
103 |
|
---|
104 | Open(2) has the format:
|
---|
105 |
|
---|
106 | #include <fcntl.h>
|
---|
107 | int open(char *path, int flags, [int mode]);
|
---|
108 |
|
---|
109 | In addition to the obvious O_RDWR, O_WRONLY and O_RDONLY, two
|
---|
110 | additional flags are available. These are O_NONBLOCK and O_NOCTTY.
|
---|
111 | Other flags listed in the open(2) manual page are not applicable to
|
---|
112 | serial devices.
|
---|
113 |
|
---|
114 | Normally, a serial device opens in "blocking" mode. This means that
|
---|
115 | the open() will not return until the Carrier Detect line from the port
|
---|
116 | is active, e.g. modem, is active. When opened with the O_NONBLOCK
|
---|
117 | flag set, the open() will return immediately regardless of the status
|
---|
118 | of the DCD line. The "blocking" mode also affects the read() call.
|
---|
119 |
|
---|
120 | The fcntl(2) command can be used to change the O_NONBLOCK flag anytime
|
---|
121 | after the device has been opened.
|
---|
122 |
|
---|
123 | The device driver and the data passing through it are controlled
|
---|
124 | according to settings in the struct termios. This structure is
|
---|
125 | defined in "/usr/include/termios.h". In the Linux tree, further
|
---|
126 | reference is made to "/usr/include/asm/termbits.h".
|
---|
127 | In blocking mode, a read(2) will block until data is available or a
|
---|
128 | signal is received. It is still subject to state of the ICANON flag.
|
---|
129 |
|
---|
130 | When the termios.c_lflag ICANON bit is set, input data is collected
|
---|
131 | into strings until a NL, EOF or EOL character is received. You can
|
---|
132 | define these in the termios.c_cc[] array. Also, ERASE and KILL
|
---|
133 | characters will operate on the incoming data before it is delivered to
|
---|
134 | the user.
|
---|
135 |
|
---|
136 | In non-canonical mode, incoming data is quantified by use of the
|
---|
137 | c_cc[VMIN and c_cc[VTIME] values in termios.c_cc[].
|
---|
138 |
|
---|
139 | Some programmers use the select() call to detect the completion of a
|
---|
140 | read(). This is not the best way of checking for incoming data.
|
---|
141 | Select() is part of the SOCKETS scheme and too complex for most
|
---|
142 | applications.
|
---|
143 |
|
---|
144 | A full explanation of the fields of the termios structure is contained
|
---|
145 | in termios(7) of the Users Manual. A version is included in Part 2 of
|
---|
146 | this HOWTO document.
|
---|
147 |
|
---|
148 | 4. Commands
|
---|
149 |
|
---|
150 | Changes to the struct termios are made by retrieving the current
|
---|
151 | settings, making the desired changes and transmitting the modified
|
---|
152 | structure back to the kernel.
|
---|
153 |
|
---|
154 | The historic means of communicating with the kernel was by use of the
|
---|
155 | ioctl(fd, COMMAND, arg) system call. Then the purists in the
|
---|
156 | computer industry decided that this was not genetically consistent.
|
---|
157 | Their argument was that the argument changed its stripes. Sometimes
|
---|
158 | it was an int, sometimes it was a pointer to int and other times it
|
---|
159 | was a pointer to struct termios. Then there were those times it was
|
---|
160 | empty or NULL. These variations are dependent upon the COMMAND.
|
---|
161 |
|
---|
162 | As a alternative, the tc* series of functions were concocted.
|
---|
163 |
|
---|
164 | These are:
|
---|
165 |
|
---|
166 | int tcgetattr(int filedes, struct termios *termios_p);
|
---|
167 | int tcsetattr(int filedes, int optional_actions,
|
---|
168 | const struct termios *termios_p);
|
---|
169 |
|
---|
170 | instead of:
|
---|
171 |
|
---|
172 | int ioctl(int filedes, int command,
|
---|
173 | struct termios *termios_p);
|
---|
174 |
|
---|
175 | where command is TCGETS or one of TCSETS, TCSETSW or TCSETSF.
|
---|
176 |
|
---|
177 | The TCSETS command is comparable to the TCSANOW optional_action for
|
---|
178 | the tc* version. These direct the kernel to adopt the changes
|
---|
179 | immediately. Other pairs are:
|
---|
180 |
|
---|
181 | command optional_action Meaning
|
---|
182 | TCSETSW TCSADRAIN Change after all output has drained.
|
---|
183 | TCSETSF TCSAFLUSH Change after all output has drained
|
---|
184 | then discard any input characters
|
---|
185 | not read.
|
---|
186 |
|
---|
187 | Since the return code from either the ioctl(2) or the tcsetattr(2)
|
---|
188 | commands only indicate that the command was processed by the kernel.
|
---|
189 | These do not indicate whether or not the changes were actually
|
---|
190 | accomplished. Either of these commands should be followed by a call
|
---|
191 | to:
|
---|
192 |
|
---|
193 | ioctl(fd, TCGETS, &new_termios);
|
---|
194 |
|
---|
195 | or:
|
---|
196 |
|
---|
197 | tcgetattr(fd, &new_termios);
|
---|
198 |
|
---|
199 | A user function which makes changes to the termios structure should
|
---|
200 | define two struct termios variables. One of these variables should
|
---|
201 | contain the desired configuration. The other should contain a copy of
|
---|
202 | the kernels version. Then after the desired configuration has been
|
---|
203 | sent to the kernel, another call should be made to retrieve the
|
---|
204 | kernels version. Then the two compared.
|
---|
205 |
|
---|
206 | Here is an example of how to add RTS/CTS flow control:
|
---|
207 |
|
---|
208 | struct termios my_termios;
|
---|
209 | struct termios new_termios;
|
---|
210 |
|
---|
211 | tcgetattr(fd, &my_termios);
|
---|
212 | my_termios.c_flag |= CRTSCTS;
|
---|
213 | tcsetattr(fd, TCSANOW, &my_termios);
|
---|
214 | tcgetattr(fd, &new_termios);
|
---|
215 | if (memcmp(my_termios, new_termios,
|
---|
216 | sizeof(my_termios)) != 0) {
|
---|
217 | /* do some error handling */
|
---|
218 | }
|
---|
219 |
|
---|
220 | 5. Changing Baud Rates
|
---|
221 |
|
---|
222 | With Linux, the baud rate can be changed using a technique similar to
|
---|
223 | add/delete RTS/CTS.
|
---|
224 |
|
---|
225 | struct termios my_termios;
|
---|
226 | struct termios new_termios;
|
---|
227 |
|
---|
228 | tcgetattr(fd, &my_termios);
|
---|
229 | my_termios.c_flag &= ~CBAUD;
|
---|
230 | my_termios.c_flag |= B19200;
|
---|
231 | tcsetattr(fd, TCSANOW, &my_termios);
|
---|
232 | tcgetattr(fd, &new_termios);
|
---|
233 | if (memcmp(my_termios, new_termios,
|
---|
234 | sizeof(my_termios)) != 0) {
|
---|
235 | /* do some error handling */
|
---|
236 | }
|
---|
237 |
|
---|
238 | POSIX adds another method. They define:
|
---|
239 |
|
---|
240 | speed_t cfgetispeed(const struct termios *termios_p);
|
---|
241 | speed_t cfgetospeed(const struct termios *termios_p);
|
---|
242 |
|
---|
243 | library calls to extract the current input or output speed from the
|
---|
244 | struct termios pointed to with *termio_p. This is a variable defined
|
---|
245 | in the calling process. In practice, the data contained in this
|
---|
246 | termios, should be obtained by the tcgetattr() call or an ioctl() call
|
---|
247 | using the TCGETS command.
|
---|
248 |
|
---|
249 | The companion library calls are:
|
---|
250 |
|
---|
251 | int cfsetispeed(struct termios *termios_p, speed_t speed);
|
---|
252 | int cfsetospeed(struct termios *termios_p, speed_t speed);
|
---|
253 |
|
---|
254 | which are used to change the value of the baud rate in the locally
|
---|
255 | defined *termios_p. Following either of these calls, either a call to
|
---|
256 | tcsetattr() or ioctl() with one of TCSETS, TCSETSW or TCSETSF as the
|
---|
257 | command to transmit the change to the kernel.
|
---|
258 |
|
---|
259 | The cf* commands are preferred for portability. Some weird Unices use
|
---|
260 | a considerably different format of termios.
|
---|
261 |
|
---|
262 | Most implementations of Linux use only the input speed for both input
|
---|
263 | and output. These functions are defined in the application program by
|
---|
264 | reference to <termios.h>. In reality, they are in
|
---|
265 | /usr/include/asm/termbits.h.
|
---|
266 |
|
---|
267 | 6. Additional Control Calls
|
---|
268 |
|
---|
269 | 6.1. Sending a "break".
|
---|
270 |
|
---|
271 | int ioctl(fd, TCSBRK, int arg);
|
---|
272 | int tcsendbreak(fd, int arg);
|
---|
273 |
|
---|
274 | Send a break: Here the action differs between the conventional
|
---|
275 | ioctl() call and the POSIX call. For the conventional call, an arg of
|
---|
276 | '0' sets the break control line of the UART for 0.25 seconds. For the
|
---|
277 | POSIX command, the break line is set for arg times 0.1 seconds.
|
---|
278 |
|
---|
279 | 6.2. Hardware flow control.
|
---|
280 |
|
---|
281 | int ioctl(fd, TCXONC, int action);
|
---|
282 | int tcflow(fd, int action);
|
---|
283 |
|
---|
284 | The action flags are:
|
---|
285 |
|
---|
286 | o TCOOFF 0 suspend output
|
---|
287 |
|
---|
288 | o TCOON 1 restart output
|
---|
289 |
|
---|
290 | o TCIOFF 2 transmit STOP character to suspend input
|
---|
291 |
|
---|
292 | o TCION 3 transmit START character to restart input
|
---|
293 |
|
---|
294 | 6.3. Flushing I/O buffers.
|
---|
295 |
|
---|
296 | int ioctl(fd, TCFLSH, queue_selector);
|
---|
297 | int tcflush(fd, queue_selector);
|
---|
298 |
|
---|
299 | The queue_selector flags are:
|
---|
300 |
|
---|
301 | o TCIFLUSH 0 flush any data not yet read from the input buffer
|
---|
302 |
|
---|
303 | o TCOFLUSH 1 flush any data written to the output buffer but not
|
---|
304 | yet transmitted
|
---|
305 |
|
---|
306 | o TCIOFLUSH 2 flush both buffers
|
---|
307 |
|
---|
308 | 7. Modem control
|
---|
309 |
|
---|
310 | The hardware modem control lines can be monitored or modified by the
|
---|
311 | ioctl(2) system call. A set of comparable tc* calls apparently do not
|
---|
312 | exist. The form of this call is:
|
---|
313 |
|
---|
314 | int ioctl(fd, COMMAND, (int *)flags);
|
---|
315 |
|
---|
316 | The COMMANDS and their action are:
|
---|
317 |
|
---|
318 | o TIOCMBIS turn on control lines depending upon which bits are set
|
---|
319 | in flags.
|
---|
320 |
|
---|
321 | o TIOCMBIC turn off control lines depending upon which bits are
|
---|
322 | unset in flags.
|
---|
323 | o TIOCMGET the appropriate bits are set in flags according to the
|
---|
324 | current status
|
---|
325 |
|
---|
326 | o TIOCMSET the state of the UART is changed according to which bits
|
---|
327 | are set/unset in 'flags'
|
---|
328 |
|
---|
329 | The bit pattern of flags refer to the following control lines:
|
---|
330 |
|
---|
331 | o TIOCM_LE Line enable
|
---|
332 |
|
---|
333 | o TIOCM_DTR Data Terminal Ready
|
---|
334 |
|
---|
335 | o TIOCM_RTS Request to send
|
---|
336 |
|
---|
337 | o TIOCM_ST Secondary transmit
|
---|
338 |
|
---|
339 | o TIOCM_SR Secondary receive
|
---|
340 |
|
---|
341 | o TIOCM_CTS Clear to send
|
---|
342 |
|
---|
343 | o TIOCM_CAR Carrier detect
|
---|
344 |
|
---|
345 | o TIOCM_RNG Ring
|
---|
346 |
|
---|
347 | o TIOCM_DSR Data set ready
|
---|
348 |
|
---|
349 | It should be noted that some of these bits are controlled by the modem
|
---|
350 | and the UART cannot change them but their status can be sensed by
|
---|
351 | TIOCMGET. Also, most Personal Computers do not provide hardware for
|
---|
352 | secondary transmit and receive.
|
---|
353 |
|
---|
354 | There are also a pair of ioctl() to monitor these lines. They are
|
---|
355 | undocumented as far as I have learned. The commands are TIOCMIWAIT
|
---|
356 | and TCIOGICOUNT. They also differ between versions of the Linux
|
---|
357 | kernel.
|
---|
358 |
|
---|
359 | See the lines.c file in my "serial_suite" for an example of how these
|
---|
360 | can be used see <ftp://scicom.alphacd.com/pub/linux/serial_suite>
|
---|
361 |
|
---|
362 | 8. Process Groups
|
---|
363 |
|
---|
364 | 8.1. Sessions
|
---|
365 |
|
---|
366 | 8.2. Process Groups
|
---|
367 |
|
---|
368 | Any newly created process inherits the Process Group of its creator.
|
---|
369 | The Process Group leader has the same PID as PGID.
|
---|
370 |
|
---|
371 | 8.3. Controlling Terminal
|
---|
372 |
|
---|
373 | There are a series of ioctl(2) and tc*(2) calls which can be used to
|
---|
374 | monitor or to change the process group to which the device is
|
---|
375 | attached.
|
---|
376 |
|
---|
377 | 8.3.1. Get the foreground group process id.
|
---|
378 |
|
---|
379 | If there is no foreground group, a number not representing an existing
|
---|
380 | process group is returned. On error, a -1 is returned and errno is
|
---|
381 | set.
|
---|
382 |
|
---|
383 | int ioctl(fd, TIOCGPGRP, (pid_t *)pid);
|
---|
384 | int tcgetpgrp(fd, (pid_t *)pid);
|
---|
385 |
|
---|
386 | 8.3.2. Set the foreground process group id of a terminal.
|
---|
387 |
|
---|
388 | The fd must be the controlling terminal and be associated with the
|
---|
389 | session of the calling process.
|
---|
390 |
|
---|
391 | int ioctl(fd, TIOCSPGRP, (pid_t *)pid);
|
---|
392 | int tcsetpgrp(fd, (pid_t *)pid);
|
---|
393 |
|
---|
394 | 8.3.3. Get process group id.
|
---|
395 |
|
---|
396 | int ioctl(fd, TIOCGPGRP, &(pid_t)pid);
|
---|
397 | int tcgetpgrp(fd, &(pid_t)pid);
|
---|
398 |
|
---|
399 | 9. Lockfiles
|
---|
400 |
|
---|
401 | Any process which accesses a serial device should first check for the
|
---|
402 | existence of lock file for the desired device. If such a lock lock
|
---|
403 | file exists, this means that the device may be in use by another
|
---|
404 | process.
|
---|
405 |
|
---|
406 | Check my "libdevlocks-x.x.tgz" at
|
---|
407 | <ftp://scicom.alphacdc.com/pub/linux> for an example of how these lock
|
---|
408 | files should be utilized.
|
---|
409 |
|
---|
410 | 10. Additional Information
|
---|
411 |
|
---|
412 | Check out my "serial_suite.tgz" for more information about programming
|
---|
413 | the serial ports at <mailto:vern@zebra.alphacdc.com>. There some
|
---|
414 | examples and some blurbs about setting up modems and comments about
|
---|
415 | some general considerations.
|
---|
416 |
|
---|
417 | 11. Feedback
|
---|
418 |
|
---|
419 | Please send me any corrections, questions, comments, suggestions, or
|
---|
420 | additional material. I would like to improve this HOWTO! Tell me
|
---|
421 | exactly what you don't understand, or what could be clearer. You can
|
---|
422 | reach me at <mailto:vern@zebra.alphacdc.com> via email. Please
|
---|
423 | include the version number of the Serial-Programming-HOWTO when
|
---|
424 | writing.
|
---|