Reading the Serial Port

[Hal Vaughan]

I've done a fair amount of Googling for information on reading the serial
port in C++ (and in Linux). Unfortunately, out of every 4 hits, 1 seems to
be an unanswered question, 1 is someone saying, "That's easy, there's a lot
out there, Google it,", 1 is a discussion on it without examples and the
other is who knows what.

I did find some info on it and have been experimenting. The one example
that I liked the best in terms of explanations and readability for a new
C++ programmer (coming over from Java and Perl) used this to open the
serial port (yes, with the .h on each include, I know it's older):

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
int fd1;
fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

I understand the serial port will be binary and may be different from other
files, but I don't understand why this won't work just as well:

#include <iostream>
#include <fstream>

ofstream myfile;
myfile.open("/dev/ttyS0", ios:ut | ios::binary);

Would that work as well or is there a reason for handling it the first way?
Basically, after I catch up on everything, one program will be reading the
serial port and reporting the output and another will be sending data to
the port. (It's possible, if I can ever find a good thread tutorial for
C++ that instead of different programs, they'll be different threads.)

Thanks for any help on the significance and differences of these two
methods!

Hal

 

[Christopher]

I've done a fair amount of Googling for information on reading the serial
port in C++ (and in Linux). Unfortunately, out of every 4 hits, 1 seems to
be an unanswered question, 1 is someone saying, "That's easy, there's a lot
out there, Google it,", 1 is a discussion on it without examples and the
other is who knows what.

I did find some info on it and have been experimenting. The one example
that I liked the best in terms of explanations and readability for a new
C++ programmer (coming over from Java and Perl) used this to open the
serial port (yes, with the .h on each include, I know it's older):

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
int fd1;
fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

I understand the serial port will be binary and may be different from other
files, but I don't understand why this won't work just as well:

#include <iostream>
#include <fstream>

ofstream myfile;
myfile.open("/dev/ttyS0", ios:ut | ios::binary);

Would that work as well or is there a reason for handling it the first way?
Basically, after I catch up on everything, one program will be reading the
serial port and reporting the output and another will be sending data to
the port. (It's possible, if I can ever find a good thread tutorial for
C++ that instead of different programs, they'll be different threads.)

Thanks for any help on the significance and differences of these two
methods!

Hal

The C++ language has no concept of what a serial port is, therefor it
is off topic here. However, a newsgroup specific to your operating
system may very well hold answers for you.

 

[Hal Vaughan]

The C++ language has no concept of what a serial port is, therefor it
is off topic here. However, a newsgroup specific to your operating
system may very well hold answers for you.

So nobody here would have insight or help on reading from a device overall?
Or what the difference between the two methods are even if it's not just
Linux?

I'm sure an experienced C++ programmer could still give me some good info
about the two different ways to open a file/device that would help with an
overall understanding of the situation. I'm sure, for instance, that the
first method is not Linux specific and I know the 2nd one is not.

Hal

 

[Lance Diduck]

I've done a fair amount of Googling for information on reading the serial
port in C++ (and in Linux).  Unfortunately, out of every 4 hits, 1 seems to
be an unanswered question, 1 is someone saying, "That's easy, there's a lot
out there, Google it,", 1 is a discussion on it without examples and the
other is who knows what.

I did find some info on it and have been experimenting.  The one example
that I liked the best in terms of explanations and readability for a new
C++ programmer (coming over from Java and Perl) used this to open the
serial port (yes, with the .h on each include, I know it's older):

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
int fd1;
fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

I understand the serial port will be binary and may be different from other
files, but I don't understand why this won't work just as well:

#include <iostream>
#include <fstream>

ofstream myfile;
myfile.open("/dev/ttyS0", ios:ut | ios::binary);

Would that work as well or is there a reason for handling it the first way?
Basically, after I catch up on everything, one program will be reading the
serial port and reporting the output and another will be sending data to
the port.  (It's possible, if I can ever find a good thread tutorial for
C++ that instead of different programs, they'll be different threads.)

Thanks for any help on the significance and differences of these two
methods!

Hal

There is no reason that the ofstream cant be used. There are tons of
differences in how errors are handled, how formatted IO is handled,
and so forth. (the "ios::binary" will turn off some of the character
translations that go on between different encodings -- something you
dont need in serial ports)
The other differences is that once myfile goes out of scope, all
system resources will be released. And of course ofstream will format
your data into character based streams. If you really want to send raw
bytes through your serial port, avoid doing this
myfile<<data;
and do this instead:
myfile.write(&data,sizeof(data));

Hope that helps
Lance

 

[Paavo Helde]

Maybe the reason of your failure is that serial port is becoming
obsolete. Most peripheral devices are using USB nowadays. From your post
I gather that you are planning to make two threads in the same process
communicate over the serial port - why on the earth you would want to do
that?

[..]

[...]

So nobody here would have insight or help on reading from a device
overall?

For interprocess or interthread communication you don't need any device!

Regards
Paavo

 

[Hal Vaughan]

Maybe the reason of your failure is that serial port is becoming
obsolete. Most peripheral devices are using USB nowadays. From your post
I gather that you are planning to make two threads in the same process
communicate over the serial port - why on the earth you would want to do
that?

It's not failing, what I'm trying to understand is what is the difference in
the two methods? Are there things that won't show up in a simple test?
Are there implications in one method that aren't there in the other that
someone new to C++ won't think of without help?

Because that's where the device is I need to communicate with.

If I use a USB/Serial adaptor on a USB port, will reading and writing to the
USB port be just the same as to/from the serial port? (I would think so,
but I don't know if the USB/serial adaptor makes things different.)

[..]

Basically, after I catch up on everything, one program
will be reading the serial port and reporting the output and another
will be sending data to
the port. (It's possible, if I can ever find a good thread tutorial
for C++ that instead of different programs, they'll be different
threads.)

[...]

So nobody here would have insight or help on reading from a device
overall?

For interprocess or interthread communication you don't need any device!

Sorry, it's a separate issue and I was thinking of the whole thing together
and I shouldn't have combined the two in one post.

Hal

 

[Hal Vaughan]

There is no reason that the ofstream cant be used. There are tons of
differences in how errors are handled, how formatted IO is handled,
and so forth. (the "ios::binary" will turn off some of the character
translations that go on between different encodings -- something you
dont need in serial ports)
The other differences is that once myfile goes out of scope, all
system resources will be released. And of course ofstream will format
your data into character based streams. If you really want to send raw
bytes through your serial port, avoid doing this
myfile<<data;
and do this instead:
myfile.write(&data,sizeof(data));

Hope that helps
Lance

It helps a LOT!

Thank you!

Hal

 

[Christopher]

So nobody here would have insight or help on reading from a device overall?
Or what the difference between the two methods are even if it's not just
Linux?

I'm sure an experienced C++ programmer could still give me some good info
about the two different ways to open a file/device that would help with an
overall understanding of the situation. I'm sure, for instance, that the
first method is not Linux specific and I know the 2nd one is not.

Hal

Sure, the first is C and the second is C++.
If that is all wanted to know, you could leave mention of serial ports
and everything else out of your post and could have entitled it
"opening a file", otherwise you are looking for information specific
to serial port IO, which is not part of the C++ language.

 

[Paavo Helde]

It's not failing, what I'm trying to understand is what is the
difference in the two methods? Are there things that won't show up in
a simple test? Are there implications in one method that aren't there
in the other that someone new to C++ won't think of without help?

Because that's where the device is I need to communicate with.

If I use a USB/Serial adaptor on a USB port, will reading and writing
to the USB port be just the same as to/from the serial port? (I would
think so, but I don't know if the USB/serial adaptor makes things
different.)

Sorry, I misunderstood your problem! I don't know answers to your
questions. Alas, the serial ports are outside of C++ and off-topic in
this ng, please try some linux newsgroup!

(I myself would go for POSIX open() route just to avoid any chances that
the C++ layer fails to provide some seemingly needed flags like O_NOCTTY
or O_NDELAY. But this would be non-portable of course.)

Regards
Paavo

 

[Hal Vaughan]

Sure, the first is C and the second is C++.

Any reason why you didn't want to say that at the start? It would have been
quite helpful to a new C++ programmer.

If that is all wanted to know, you could leave mention of serial ports
and everything else out of your post and could have entitled it
"opening a file", otherwise you are looking for information specific
to serial port IO, which is not part of the C++ language.

Because I didn't know all that until I asked and some people were quite
helpful in explaining what they knew. Some people gave me whatever info
they could along with pointing out the serial port was OS specific.

And some people decided that rather than try to provide helpful information
from the start and addressing the parts of my post they could, that they'd
rather just play Internet Policeman.

I'll remember in the future that if there is something I truly don't
understand and don't know that much about that instead of just asking the
question in what seems, at the time, to be the appropriate forum, to just
not ask because Christopher would rather make sure people post in exactly
the right place than that they get what help could be offered within the
context of that situation.

Hal

 

[Michael Oswald]

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
int fd1;
fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

I understand the serial port will be binary and may be different from
other files, but I don't understand why this won't work just as well:

#include <iostream>
#include <fstream>

ofstream myfile;
myfile.open("/dev/ttyS0", ios:ut | ios::binary);

Would that work as well or is there a reason for handling it the first
way? Basically, after I catch up on everything, one program will be
reading the serial port and reporting the output and another will be
sending data to
the port.

As others already said, it's mostly off-topic here.

But a few hints:
When using the iostreams (you can do that), you are not able to set
properties of the connection (number of bits, parity, handshake etc.). If
you want to get it up quick, use the first method.
On the other side, you may develop an own streambuf class which is able to
handle the properties of the connection (with use of the OS specific
functions) and use that streambuf with the iostream classes (I did this for
an application some years ago).


lg,
Michael

 

[Christopher Pisz]

Because I didn't know all that until I asked and some people were quite
helpful in explaining what they knew. Some people gave me whatever info
they could along with pointing out the serial port was OS specific.

And some people decided that rather than try to provide helpful
information
from the start and addressing the parts of my post they could, that they'd
rather just play Internet Policeman.

I'll remember in the future that if there is something I truly don't
understand and don't know that much about that instead of just asking the
question in what seems, at the time, to be the appropriate forum, to just
not ask because Christopher would rather make sure people post in exactly
the right place than that they get what help could be offered within the
context of that situation.

And some people realize that everytime an off topic question gets answered,
the poster just comes back thinking this is
comp.lang.askanythingunderthesunthatyoucomacrosswhileprogramming creating
screenfulls of noise to sort through before anything can be asked or
answered. Others promote the noise by answering the poster when they are
obviously off topic and then wonder why people coninually ask questions
about why xyz compiler gives abc error when using qrs IDE on opertating
system 123 when linking with the hoobajah library, instead of looking at the
hoobajag documentation or asking on a nwqsgroup or forum dedicated to
hoobajah. And frankly, some people are sick of all the noise.

 

[Hal Vaughan]

And some people realize that everytime an off topic question gets
answered, the poster just comes back thinking this is
comp.lang.askanythingunderthesunthatyoucomacrosswhileprogramming creating
screenfulls of noise to sort through before anything can be asked or
answered. Others promote the noise by answering the poster when they are
obviously off topic and then wonder why people coninually ask questions
about why xyz compiler gives abc error when using qrs IDE on opertating
system 123 when linking with the hoobajah library, instead of looking at
the hoobajag documentation or asking on a nwqsgroup or forum dedicated to
hoobajah. And frankly, some people are sick of all the noise.

Ah, so there's an excuse for not only being rude, but for making sure you
couldn't help at all. If you were THAT worried about OT noise, you
wouldn't have responded, then, would you? A polite answer to the parts of
the question you could have answered wouldn't have hurt and would have
helped, wouldn't it?

And I didn't know until I asked, did I?

I have questions on threads. Do I dare ask them here now, or will you come
along and tell me, "That's POSIX stuff, go away?" It's hard to find good
info on threads on the Internet, so how will I know how much of it is a C++
thing and how much is POSIX until I ask? But then I shouldn't ask because
if I'm wrong, Christopher will get ticked off.

Sometimes until you ask, you don't know -- and when you ask, sometimes some
people go out of their way to help you and others just find a need to push
people around. Every action and choice we make tells the world who we are.
You had a chance to be of some help, but instead made the choice and did
the action that would be the least helpful but would put you in a position
of authority. I wonder what that says about the kind of person you are?

To others: Sorry for going so OT, but after ten years of teaching, I've
learned that those who are more active in discouraging questions than in
answering or helping people are the ones that make it harder for everyone
to learn because they're more interested in displaying a show of their
self-appointed authority than in making sure people get the help they need.

Hal

 

[Hal Vaughan]

As others already said, it's mostly off-topic here.

But a few hints:
When using the iostreams (you can do that), you are not able to set
properties of the connection (number of bits, parity, handshake etc.). If
you want to get it up quick, use the first method.
On the other side, you may develop an own streambuf class which is able to
handle the properties of the connection (with use of the OS specific
functions) and use that streambuf with the iostream classes (I did this
for an application some years ago).

Thank you. I don't mind asking about what's appropriate in another group,
but there are also issues, as you point out, that are directly connected to
the language and you've given me a lot of help in pointing out what the
differences are.

I've tried the 2nd method, since it was so easy to read one character at a
time from the stream (I guess it might be in the 1st method as well) and it
seems to be working. I would have left it at that, but your point about
the baud and so on is something I wasn't at all aware of, so I'll have to
look into using that.

I'd like to create my own class for it, but I'm still quite new and I'll
probably have this part of the program working before I get to the point
where I'm learning how to do classes in C++ (already know Java, so I know
classes, just not the implementation in C++).

Thanks for the help!

Hal

 

[Default User]

Hal Vaughan wrote:

And some people decided that rather than try to provide helpful
information from the start and addressing the parts of my post they
could, that they'd rather just play Internet Policeman.

*plonk*



Brian

 

[Default User]

Sure, the first is C and the second is C++.

Not even that. The first is POSIX, which happens to have a C API. It's
no more a C function that it is a C++ one.




Brian

 

[Hal Vaughan]

Not even that. The first is POSIX, which happens to have a C API. It's
no more a C function that it is a C++ one.

So if it's POSIX, is it part of a special class or something? How is it I'm
finding it in a C++ program? Is it because of an OS specific include?

Hal

 

[Micah Cowan]

So if it's POSIX, is it part of a special class or something? How is it I'm
finding it in a C++ program? Is it because of an OS specific include?

Yes. Probably <fcntl.h>. On some POSIX systems, <sys/stat.h> may also
be required.

Other differences between the two examples include:
- fd1 is opened for reading and writing, whereas myfile is opened
for writing only.
- myfile buffers its output, whereas fd1 doesn't use any buffering
(within the program itself; the OS kernel may use a buffer).
- the fd1 example includes something POSIX-specific that prevents
/dev/ttyS0 from having special meaning to the currently-running
process in some circumstances.
- writes through myfile may cause the program to wait until ttyS0 is
ready to receive data, whereas this will not happen to fd1.

 

[Christopher]

Ah, so there's an excuse for not only being rude, but for making sure you
couldn't help at all. If you were THAT worried about OT noise, you
wouldn't have responded, then, would you? A polite answer to the parts of
the question you could have answered wouldn't have hurt and would have
helped, wouldn't it?

I don't know where I was rude in my first response. I told you it was
OT. you continued the thread anyway ignoring that fact. That is when I
get rude. When you think you wishes and desires are more important
than any kind of order.

And I didn't know until I asked, did I?

A) You could read the FAQ!
B) You could search for related posts that received the same response.
C) You _did_ know as soon as you got my response, you continued the
thread anyway.

I have questions on threads. Do I dare ask them here now, or will you come
along and tell me, "That's POSIX stuff, go away?" It's hard to find good
info on threads on the Internet, so how will I know how much of it is a C++
thing and how much is POSIX until I ask? But then I shouldn't ask because
if I'm wrong, Christopher will get ticked off.

You can ask about threads. Use Google on this group's recent posts, if
you know how.

Sometimes until you ask, you don't know -- and when you ask, sometimes some
people go out of their way to help you and others just find a need to push
people around. Every action and choice we make tells the world who we are.
You had a chance to be of some help, but instead made the choice and did
the action that would be the least helpful but would put you in a position
of authority. I wonder what that says about the kind of person you are?

Get over it. I want to buy a Trans Am at the Toyota dealership, but
the dealer doesn't seem to believe he should have all cars in stock
just because he is a car dealer.

To others: Sorry for going so OT, but after ten years of teaching

....
Oh good grief. Ten years of teaching and you don't know how to perform
your research?

, I've learned that those who are more active in discouraging questions than in
answering or helping people are the ones that make it harder for everyone
to learn

Bullshit. It is just the opposite. If people asked their questions in
the proper places, learning would be _easier_

A) Expertise would be more available in one location
B) Others interested in the same topic could give input
C) The asker would likely find related information
D) Good newsgroups would not die off from lack of traffic that has
been rerouted to groups such as this one.

because they're more interested in displaying a show of their self-appointed authority than in making sure people get the help they
need.

Are you a psychiatrist too? I'd be happy to answer questions when they
are asked int the proper places. I answer MS questions in the MS
newsgroups, I answer DirectX questions in the DX newsgroups, I answer
networking questions in the networking newsgroups, I answer _C++_
questions here.

 

[Hal Vaughan]

Yes. Probably <fcntl.h>. On some POSIX systems, <sys/stat.h> may also
be required.

Gotcha. That helps!

Other differences between the two examples include:
- fd1 is opened for reading and writing, whereas myfile is opened
for writing only.

Okay, easily changed, but something I missed.

- myfile buffers its output, whereas fd1 doesn't use any buffering
(within the program itself; the OS kernel may use a buffer).

Important difference. If I can stick with it, then the buffer could be a
BIG help.

- the fd1 example includes something POSIX-specific that prevents
/dev/ttyS0 from having special meaning to the currently-running
process in some circumstances.
- writes through myfile may cause the program to wait until ttyS0 is
ready to receive data, whereas this will not happen to fd1.

In this case I'm only reading, but on the flip side, I will be writing to
the port eventually, so that could be a major difference that would have
taken me a long time to detect without knowing that.

Thanks!

Hal