Serial programming problems (POSIX)

Serial programming problems (POSIX)

Post by Mart » Tue, 17 Nov 1998 04:00:00



Hi.  I am trying to develop a primitive 'cu' command on Linux, much
like the one that is available on SVR4 systems, and I've had partial
success. My aim is to remain fully POSIX in my programming and I would
like to (if possible) try to stay away from any non-POSIX way of
accessing the serial ports.

What I did in my program which I do not have at hand was like this
(pseudo code):

portfd=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NONBLOCK);
[checks here for success...]
tcgetattr(portfd);
cfsetispeed/cfsetospeed(portfd);
cfmakeraw(portfd);
tcsetattr(portfd);

then (here's where my trouble begins):

while (1)
{
        char ch, buf[1024];
        cnt = read(portfd, buf, 1024);
        [if cnt != 0, then I echo the characters to the terminal,
meaning that there was something coming back from the serial port,
i.e. an OK from the modem]]
        cnt = read(STDIN_FILENO, &ch, 1); // get kbd input
        [checks here for success...]
        write(portfd, &ch, 1);                  // send it right away on a
char by char basis to the port
        [checks here for success...]

Quote:}

Now, when I did something like this, don't remember the EXACT code, I
managed to be able to issue commands to the port, however, everything
I typed was echoed back a character later. I.E. if I wanted to issue
an AT\r, I'd hit A, then nothing would be echoed back (and it
supposedly should be echoed back at the beginning of the loop on the
next iteration), and then when I'd hit the T, the A would be echoed
back to me, then I'd hit <Enter>, then the T would be echoed back, and
then I'd finally hit <enter> or some other key, and the OK result
would be echoed back to me.

What am I doing wrong here?  Do I need to have separate processes that
will handle keyboard input and serial port output or no? I was looking
at some MINICOM code and it looks like he's managing to do all this in
a single while (1) loop, using select() and not having to fork
separate processes for keyboard handling or for ser. output handling.

Can someone experienced more than I tell me what is the _correct_, by
the book way, of doing this sort of thing, that is, handling serial
input and output mixed with keyboard input?  Do I need separate
processes ? I booted 'cu' on an SVR4 machine, it looked like it was
forking twice, which makes me think the correct way of doing this now
is to use 2 processes, one for kbd input, one for ser. output
handling? I have no experience in this area so any books recommended
would help, or at least some unix lovers' :-) advice would help.

Please help.
thank you.
Martin
p.s. what I really want to eventually do is write up an API for my
Kodak DC210 camera, which what I'll do once I learn proper RS232
handling techniques and give the API source away for free to support
Linux and POSIX at the same time. I just need a little boost on rs232
techniques :-).

Thanks.

 
 
 

Serial programming problems (POSIX)

Post by Andrew Giert » Tue, 17 Nov 1998 04:00:00


 Martin> Hi.  I am trying to develop a primitive 'cu' command on
 Martin> Linux, much like the one that is available on SVR4 systems,
 Martin> and I've had partial success. My aim is to remain fully POSIX
 Martin> in my programming and I would like to (if possible) try to
 Martin> stay away from any non-POSIX way of accessing the serial
 Martin> ports.

Drop the use of cfmakeraw(), then; it's an extension.

 Martin> What am I doing wrong here?  Do I need to have separate
 Martin> processes that will handle keyboard input and serial port
 Martin> output or no?

No, but you do need to use select() to do it in one process.

(select() is not defined by Posix. Tough cookies. I suggest you use
it anyway.)

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

Serial programming problems (POSIX)

Post by Frank da Cr » Tue, 17 Nov 1998 04:00:00



: Hi.  I am trying to develop a primitive 'cu' command on Linux, much
: like the one that is available on SVR4 systems, and I've had partial
: success. My aim is to remain fully POSIX in my programming and I would
: like to (if possible) try to stay away from any non-POSIX way of
: accessing the serial ports.
:  ...
: p.s. what I really want to eventually do is write up an API for my
: Kodak DC210 camera, which what I'll do once I learn proper RS232
: handling techniques and give the API source away for free to support
: Linux and POSIX at the same time. I just need a little boost on rs232
: techniques :-).
:
Why don't you write your program in Kermit script language rather than C?
This hides all the bit-twiddling ioctl(), etc, details from you, keeps your
program portable to every variety of UNIX (and beyond), plus it's way easier.
See, as an example, the Kermit script for sending alphanumeric pages, which
implements a finite-state machine to exchange error-checked messages
with a paging service via Telocator Alphanumeric Protocol.  It requires
less than a page of code, compared to doing it in C and making it work on
lots of different platforms, which would be a neverending task.  More about
Kermit at:

  http://www.columbia.edu/kermit/

and C-Kermit (for UNIX, etc) at:

  http://www.columbia.edu/kermit/ckermit.html

- Frank

 
 
 

Serial programming problems (POSIX)

Post by Victor Wagn » Fri, 20 Nov 1998 04:00:00


: Hi.  I am trying to develop a primitive 'cu' command on Linux, much
: like the one that is available on SVR4 systems, and I've had partial
: success. My aim is to remain fully POSIX in my programming and I would
: like to (if possible) try to stay away from any non-POSIX way of
: accessing the serial ports.

Why not get sources of real cu command (or minicom, if it is more
readable for you) and see how the matter is handled. I believe that
sources of Jan Tailor worth reading. (Minicom is bit worse, but
precisely that may make it more readable for person with somewhat
strange ideas)
--
--------------------------------------------------------
I have tin news and pine mail...

 
 
 

1. POSIX Serial programming problem

Experts,

  I'm having a strange problem with POSIX Serial programming.  I'm
trying to control a modem which is being used to connect to paging
terminals.

  On some paging terminals, the data that I get from the remote
terminal is messed up.  Even though I set object to connect at, say,
2400 7E1, what I get back from the terminal is what would be the
correct data, but with the parity bit included as the high bit of the
data.  So, instead of getting 'ID=' ('0x49 0x44 0x3D') I get '0xC9
0x44 0xBD'.  Notice that the 'D' stays the same because it's even
parity naturally, but the other two characters would have an odd
parity if their high bits weren't set.  So, it seems like the parity
isn't being handled properly.  Note that this happens regardless of
whether the settings are 8N1 or 7E1 (or anything else, actually).

  Whatever the problem is, it's not limited to my program.
Minicom has the same problem, but Kermit doesn't. There's also a tiny
program called 'miniterm' that comes with the LDP programming examples
on which I can reproduce the problem.  I have not succeeded in
modifying any program to no longer have the problem, nor can I
reproduce the problem in Kermit. Also, I've tried two different modems
on two different machines (one modem was PCI, the other USB), and the
problem happens on all combinations.

  Has anybody had similar problems?  Anybody know of a fix?

  Thanks in advance,

  S. Dawson

2. notebook cooling pad

3. Serial Programming in POSIX

4. can npasswd support to deny change password twice in one day.

5. POSIX Serial Programming

6. UNIX lovers...preach me your knowledge

7. Serial Programming in POSIX

8. X11 & Vlb Et4000 W32

9. How to set up serial port when programming serial communication

10. Parallel Port programming question, was "Serial Port Programming"

11. serial port access on POSIX

12. POSIX.1 method of setting serial communications speed above 38400 Baud