0

Before adding O_NOCTTY option, my process was killed once by unknown per every booting. I don't know why the process was killed :( and I thought the initializing has some problems. so that I added O_NOCTTY option, and the process was not killed. But it cannot read any data from the buffer until restarted by other process. Please help me :( The following is code about initializing and reading.

void Init() {
    mFd = open("/dev/ttyS2", O_RDWR | O_NOCTTY);

    if (mFd > 0)
    {
        (void)tcgetattr(mFd, &mTermios_p);
        speed = B115200;
        mTermios_p.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
        mTermios_p.c_oflag &= ~OPOST;
        mTermios_p.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
        mTermios_p.c_cflag &= ~(CSIZE | PARENB);
        mTermios_p.c_cflag |= CS8;
        mTermios_p.c_cc[VMIN] = 0U;
        mTermios_p.c_cc[VTIME] = 0U;
        (void)cfsetispeed(&mTermios_p, speed);
        (void)cfsetospeed(&mTermios_p, speed);
        (void)tcflush(mFd, TCIOFLUSH);
        (void)tcsetattr(mFd, TCSANOW, &mTermios_p);
    }
    else
    {
        LOGE("uart open failed %s", strerror(errno));
    }
}
int32_t Read() {
    int32_t bytes = -1;
    if (mFd > 0)
    {
        (void)pthread_mutex_lock(&mMutexLock);
        bytes = static_cast<int32_t>(read(mFd, buf, nMaxRead));
        (void)pthread_mutex_unlock(&mMutexLock);
    }

    if (bytes < 0)
    {
        LOGE("read failed");
    }

    return bytes;
}
John
  • 15
  • 5

1 Answers1

1

Your serial terminal initialization is essentially the near-equivalent of cfmakeraw() plus setting the baudrate.
However that is insufficient to fully initialize a serial terminal.

At the very least the receiver also has to be enabled:

mTermios_p.c_cflag |= CREAD;

To eliminate any modem handshake issues (especially when there is no modem):

mTermios_p.c_cflag |= CLOCAL;

To eliminate any hardware handshake issues:

mTermios_p.c_cflag &= ~CRTSCTS;

BTW

    mTermios_p.c_cc[VMIN] = 0U;
    mTermios_p.c_cc[VTIME] = 0U;

Setting both VMIN and VTIME to zero is an ill-advised configuration.
This guide describes this configuration as one that should be used only if "you really, really know what you're doing."
The code that you posted for reading is not capable of (efficiently) handling the consequences of setting both VMIN and VTIME to zero. Unless your program is synchronized with the transmitting program, your read code is likely to "successfully" read zero bytes, i.e. no data.

sawdust
  • 16,103
  • 3
  • 40
  • 50
  • I'm wondering between following 2 settings, which difference exists. 1. `mFd = open(..., ... | O_NONBLOCK)...mTermios_p.c_cc[VMIN] = 1U ` 2.`mFd = open(..., ...)...mTermios_p.c_cc[VMIN] = 0U` Are both 2 settings operating non-blocking mode?? – John Apr 24 '20 at 05:28
  • @John -- Essentially similar, but **read()** could return different codes, e.g. -1 with errno=EAGAIN versus zero. See https://stackoverflow.com/questions/25996171/linux-blocking-vs-non-blocking-serial-read/26006680#26006680 – sawdust Apr 24 '20 at 06:23
  • Thanks for your answer. By the way,as I mentioned in the original question, after adding `O_NOCTTY` flag, the process cannot read anything via uart and it operates well after killed once by other process. I'm confused where should I debug first. – John Apr 24 '20 at 07:11
  • @John -- You have provided zero details about the involved processes. Processes normally do not interact nor interfere with each other. Somehow you have created dependencies between processes. You have not posted a minimal reproducible example as expected for this site. Apparently your code makes extensive use of global variables, and unexplained use of a mutex. I'm not going to guess how to debug such unknowns. You have posted your termios initialization, and I have pointed out that it is incomplete. You have posted some read code, and I have pointed out its limitations. – sawdust Apr 24 '20 at 22:50
  • IOW I have provided a solution to the termios side of your reading problem. The inter-processing conflict(s) is IMO a separate issue. – sawdust Apr 24 '20 at 22:56