0

So I have a development board which has some UART peripherals muxed to some tty*-like files.

I have connected some other device on one port (RX pin), and I expect to be able to read the data that it was sent to me.

The devices sends me data in 11-bytes chunks.

This is the code I have been used:

if(-1 == (fd_read = open(port.c_str(), O_RDONLY))) {
            throw std::ios_base::failure("Unable to open UART descriptor.");
    }

    tcgetattr(fd_read, &settings);

    /*!
     * Set some default settings.
     */
    cfsetospeed(&settings, baud);       /* baud rate        */
    settings.c_cflag &= ~PARENB;        /* no parity        */
    settings.c_cflag &= ~CSTOPB;        /* 1 stop bit       */
    settings.c_cflag &= ~CSIZE;
    settings.c_cflag |= CS8 | CLOCAL;   /* 8 bits           */
    settings.c_lflag = ICANON;          /* canonical mode   */
    settings.c_oflag &= ~OPOST;         /* raw output       */

    settings.c_cc[VMIN] = 0;
    settings.c_cc[VTIME] = 0;

    /*!
     * Apply the settings for both: the writing and reading file descriptors.
     */

    tcsetattr(fd_read, TCSANOW, &settings);
    tcflush(fd_read, TCOFLUSH);

The problem is that the other devices sends me a data chunk (I can see it on scope), but the read() function doesn't return.

This is the read function call:

auto bytesReceived = ::read(fd_read, UARTDataBuffer, max_incoming_uart_data_length); // "max_incoming_uart_data_length" is 2048.

The strange thing is that when I use another TX pin from my board, and send the exact the same data (as I suppose to receive from the another device), everything works as expected, the read() function returns with the correct data.

Why is this happening?

L.E. More details about the problem:

Both, the development board (BeagleBone Black) and the other sensor are using 3.3V for UART signals.

After configuring the communication with the code shown above, I also applied the following command on the associated tty*-like file:

stty -F /dev/ttyO2 921600

Where /dev/ttyO2 is my UART-associated port, and 921600 is the baud rate value. I use this because termios structure don't provide such higher baud values.

I'm expecting that stty won't change the other settings (like parity, start/stop bits, etc), it will only set the baud rate.

Update2: When I open the same port (where I'm expecting data) using minicom, everything works as expected, I'm able to receive data in my application. (and the minicom also captures the data).

mariusmmg2
  • 713
  • 18
  • 37
  • 1
    What does `tcsetattr()` return? You're ignoring the return value. – Andrew Henle Jun 14 '16 at 10:25
  • @AndrewHenle It's returning 0 in all the cases, so this isn't the source of problems. – mariusmmg2 Jun 14 '16 at 10:37
  • If you know `tcsetattr()` is returning zero in all cases, the code you posted isn't the code that isn't working. – Andrew Henle Jun 14 '16 at 10:48
  • @AndrewHenle You're right, there was something that I omitted, please see the update. – mariusmmg2 Jun 14 '16 at 10:56
  • Can you try running `minicom` under [`strace`](http://man7.org/linux/man-pages/man1/strace.1.html)? That way, you can capture how `minicom` is setting properties. – Andrew Henle Jun 14 '16 at 15:38
  • 1
    You configure for canonical mode, so your expected 11 bytes had better end with a line terminator. Otherwise the read will block until a line terminator is received. (I'm pretty sure minicom uses non-canonical mode, so that's why that seems to work.) Also VMIN=0 and VTIME=0 are dangerous assignments, although they are irrelevant in canonical mode. *"The strange thing is that when I use another TX..."* -- That's a loopback, and that will work for almost any port setting. It can indicate that the real connection has a mismatch in baud rate or framing. – sawdust Jun 16 '16 at 07:24

0 Answers0