Reading the Serial Port

Discussion in 'C++' started by Hal Vaughan, Mar 11, 2008.

  1. Hal Vaughan

    Hal Vaughan Guest

    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::eek: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
    Hal Vaughan, Mar 11, 2008
    #1
    1. Advertising

  2. Hal Vaughan

    Christopher Guest

    On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    > 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::eek: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.
    Christopher, Mar 11, 2008
    #2
    1. Advertising

  3. Hal Vaughan

    Hal Vaughan Guest

    Christopher wrote:

    > On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    >> 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::eek: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.



    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
    Hal Vaughan, Mar 11, 2008
    #3
  4. Hal Vaughan

    Lance Diduck Guest

    On Mar 11, 1:22 pm, Hal Vaughan <> wrote:
    > 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::eek: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
    Lance Diduck, Mar 11, 2008
    #4
  5. Hal Vaughan

    Paavo Helde Guest

    Hal Vaughan <> wrote in
    news:VvABj.5932$HA3.2326@trnddc02:

    > Christopher wrote:
    >
    >> On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    >>> I've done a fair amount of Googling for information on reading the
    >>> serial port in C++ (and in Linux).


    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?

    [..]
    >>> 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!

    Regards
    Paavo
    Paavo Helde, Mar 11, 2008
    #5
  6. Hal Vaughan

    Hal Vaughan Guest

    Paavo Helde wrote:

    > Hal Vaughan <> wrote in
    > news:VvABj.5932$HA3.2326@trnddc02:
    >
    >> Christopher wrote:
    >>
    >>> On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    >>>> I've done a fair amount of Googling for information on reading the
    >>>> serial port in C++ (and in Linux).

    >
    > 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, Mar 11, 2008
    #6
  7. Hal Vaughan

    Hal Vaughan Guest

    Lance Diduck wrote:

    > On Mar 11, 1:22 pm, Hal Vaughan <> wrote:
    >> 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::eek: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


    It helps a LOT!

    Thank you!

    Hal
    Hal Vaughan, Mar 11, 2008
    #7
  8. Hal Vaughan

    Christopher Guest

    On Mar 11, 1:50 pm, Hal Vaughan <> wrote:
    > Christopher wrote:
    > > On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    > >> 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::eek: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.

    >
    > 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.
    Christopher, Mar 11, 2008
    #8
  9. Hal Vaughan

    Paavo Helde Guest

    Hal Vaughan <> wrote in news:dzCBj.3956$z13.99@trnddc06:

    > Paavo Helde wrote:
    >
    >> Hal Vaughan <> wrote in
    >> news:VvABj.5932$HA3.2326@trnddc02:
    >>
    >>> Christopher wrote:
    >>>
    >>>> On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    >>>>> I've done a fair amount of Googling for information on reading the
    >>>>> serial port in C++ (and in Linux).

    >>
    >> 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.)


    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
    Paavo Helde, Mar 11, 2008
    #9
  10. Hal Vaughan

    Hal Vaughan Guest

    Christopher wrote:

    > On Mar 11, 1:50 pm, Hal Vaughan <> wrote:
    >> Christopher wrote:
    >> > On Mar 11, 12:22 pm, Hal Vaughan <> wrote:
    >> >> 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::eek: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.

    >>
    >> 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++.


    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
    Hal Vaughan, Mar 12, 2008
    #10
  11. Hal Vaughan wrote:

    > #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::eek: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
    Michael Oswald, Mar 12, 2008
    #11
  12. "Hal Vaughan" <> wrote in message
    news:9wIBj.4168$z13.1670@trnddc06...
    > Christopher wrote:
    >> 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.


    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.
    Christopher Pisz, Mar 12, 2008
    #12
  13. Hal Vaughan

    Hal Vaughan Guest

    Christopher Pisz wrote:

    >
    > "Hal Vaughan" <> wrote in message
    > news:9wIBj.4168$z13.1670@trnddc06...
    >> Christopher wrote:
    >>> 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.

    >
    > 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, Mar 12, 2008
    #13
  14. Hal Vaughan

    Hal Vaughan Guest

    Michael Oswald wrote:

    > Hal Vaughan wrote:
    >
    >> #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::eek: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).


    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
    Hal Vaughan, Mar 12, 2008
    #14
  15. Hal Vaughan

    Default User Guest

    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, Mar 12, 2008
    #15
  16. Hal Vaughan

    Default User Guest

    Christopher wrote:

    > On Mar 11, 1:50 pm, Hal Vaughan <> wrote:


    > > >> fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);


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


    > 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
    Default User, Mar 12, 2008
    #16
  17. Hal Vaughan

    Hal Vaughan Guest

    Default User wrote:

    > Christopher wrote:
    >
    >> On Mar 11, 1:50 pm, Hal Vaughan <> wrote:

    >
    >> > >> fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

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

    >
    >> 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.


    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
    Hal Vaughan, Mar 12, 2008
    #17
  18. Hal Vaughan

    Micah Cowan Guest

    Hal Vaughan <> writes:

    > Default User wrote:
    >
    >> Christopher wrote:
    >>
    >>> On Mar 11, 1:50 pm, Hal Vaughan <> wrote:

    >>
    >>> > >> fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

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

    >>
    >>> 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.

    >
    > 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.

    --
    Micah J. Cowan
    Programmer, musician, typesetting enthusiast, gamer...
    http://micah.cowan.name/
    Micah Cowan, Mar 12, 2008
    #18
  19. Hal Vaughan

    Christopher Guest

    > > "Hal Vaughan" <> wrote in message

    > 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.
    Christopher, Mar 12, 2008
    #19
  20. Hal Vaughan

    Hal Vaughan Guest

    Micah Cowan wrote:

    > Hal Vaughan <> writes:
    >
    >> Default User wrote:
    >>
    >>> Christopher wrote:
    >>>
    >>>> On Mar 11, 1:50 pm, Hal Vaughan <> wrote:
    >>>
    >>>> > >> fd1=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);
    >>>
    >>>> > >> ofstream myfile;
    >>>> > >> myfile.open("/dev/ttyS0", ios::eek:ut | ios::binary);
    >>>
    >>>> 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.

    >>
    >> 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.


    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
    Hal Vaughan, Mar 12, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Willie

    serial port reading

    Willie, Sep 7, 2005, in forum: Java
    Replies:
    4
    Views:
    13,529
    Willie
    Sep 8, 2005
  2. lec
    Replies:
    1
    Views:
    389
    Grant Edwards
    Jul 17, 2003
  3. Pom
    Replies:
    2
    Views:
    1,628
    Bas-i
    Jan 31, 2007
  4. Vivek Menon
    Replies:
    8
    Views:
    3,153
    bogdan
    Dec 6, 2006
  5. msalerno
    Replies:
    3
    Views:
    405
    Ilmari Karonen
    Jul 14, 2005
Loading...

Share This Page