ansaurus

Question

Correct initialization sequence for Linux serial port

Answer 1

+1 A:

I am not sure what is wrong with your snippet of code there but this might come in handy, if you haven't already seen it: Serial Programming Guide for POSIX Operating Systems

I had to do some serial port interfacing quite recently and this library worked fine, that might serve as another example.

Hamza 2010-06-05 23:43:42

I just copied most of the above code from that guide. It is just _not that good_, or am I missing something?..I'll check that library, but it is GPL'd, and my app uses Expat (aka MIT); and also it's interface is not good at all. E.g. I'd like to specify ttyUSB as a string: it might get different names with different udev config or sometimes.

whitequark 2010-06-05 23:47:18

Yeah, I must admit there were a few confusing bits in that guide but still that was the most comprehensive resource I could find. Regarding the library: Perhaps you can use it as a 'sanity check', just to see if that will break your system too?

Hamza 2010-06-05 23:51:30

Yeah, I checked and can confirm that the initialization code is same in that library and in my code, except for `O_NDELAY` (=`O_NONBLOCK`). I had that option set in the past, and results were even more weird: complete nonsense was sent to and received from the device, errors were returned by `read()`, and even more `WARNING`'s in syslog.

whitequark 2010-06-05 23:52:54

Not sure if this is relevant to your problem, but I seem to remember I had a hell of a time trying to get a PL-2303 chipset based device working a couple of months back and it used to cause all sorts of random behaviour in the system. All the other devices (including the one I used the mentioned library with) were all FT232 based devices.

Hamza 2010-06-06 00:03:02

My device **is** FT232RL-based.

whitequark 2010-06-06 13:00:59

Answer 2

+1 A:

Hitting a WARN_ON line might mean that you've hit a kernel bug. I know that there has been much work on improving the USB-serial driver lately; I suggest trying a newer kernel, and/or asking on the [email protected] mailing list.

caf 2010-06-06 01:31:59

This problem is hit quite often by people using Beagle Boards, where almost everything connected is connected via USB. I'm also quite sure he's hitting one of several possible bugs in that subsystem.

Tim Post 2010-06-06 02:57:05

History for the stable kernel suggests that no changes were made after ca. 2009-10. Also, when I use `minicom` or similar tools, the "bug" doesn't arise.

whitequark 2010-06-06 13:00:19

Answer 3

A:

Just as a side note really, your error check on open isn't quite right - error conditions are signalled by a return value of -1. (0 is a perfectly valid fd, usually connected to stdin.)

crazyscot 2010-06-06 08:58:43

Thanks, fixed that.

whitequark 2010-06-06 13:01:18

Answer 4

A:

You might want to try:

  vuxboot(string filename, unsigned baud = B115200) : _debug(false) {
    _fd = open(filename.c_str(), O_RDWR | O_NOCTTY);
    if(_fd < 0) throw new io_error("cannot open port");

    // Serial initialization was written with FTDI USB-to-serial converters
    // in mind. Anyway, who wants to use non-8n1 protocol?

    tcgetattr(_fd, &_termios);

-   termios tio;
+   termios tio;
+   memcpy(&tio, &_termios, sizeof(struct termios)); 

    tio.c_iflag = IGNPAR;
    tio.c_oflag = 0;
    tio.c_cflag = baud | CLOCAL | CREAD | CS8;
    tio.c_lflag = 0;

    tcflush(_fd, TCIFLUSH);
    tcsetattr(_fd, TCSANOW, &tio);
}

This makes it so that any unexpected fields of termios on your system get somewhat reasonable values.

nategoose 2010-06-06 18:42:22

ansaurus

tags:

views:

answers:

Correct initialization sequence for Linux serial port

related questions