In a MAC OS X (10.10) program, I have a hard time setting up termios correctly for RS-485 serial communication (I use a starcom USB → RS-485 featuring the FTDI chip)
I need to set up the following:
1 Start bit (0 bit)
8 Databits
1 Odd parity bit
1 Stop bit (1 bit)
19200 baud
Communication is binary, so there is no stop character.
Currently, I have found how to set most of the settings (see code below), but I didn't found where to tell termios I want a start bit.
#property(readwrite) int fileDescriptor;
_fileDescriptor = open(bsdPath, O_RDWR | O_NOCTTY | O_NONBLOCK);
ioctl(_fileDescriptor, TIOCEXCL)
fcntl(_fileDescriptor, F_SETFL, 0)
tcgetattr(_fileDescriptor, &gOriginalTTYAttrs)
struct termios options = gOriginalTTYAttrs;
cfmakeraw(&options);
struct termios* rawOptions = &options;
// Timeout 100 ms
rawOptions->c_cc[VTIME] = 1;
rawOptions->c_cc[VMIN] = 0;
// 8 bits
rawOptions->c_cflag |= CS8;
// Parity ODD
rawOptions->c_cflag |= PARENB;
rawOptions->c_cflag |= PARODD;
// Stop bit (I hope it means one stop bit)
rawOptions->c_cflag = rawOptions->c_cflag & ~CSTOPB;
// Flow control none
rawOptions->c_cflag = rawOptions->c_cflag & ~CRTSCTS;
rawOptions->c_cflag = rawOptions->c_cflag & ~(CDTR_IFLOW | CDSR_OFLOW);
rawOptions->c_cflag = rawOptions->c_cflag & ~CCAR_OFLOW;
// Turn on hangup on close (NO IDEA WHAT IT DOES)
rawOptions->c_cflag |= HUPCL;
// Set local mode on (NO IDEA WHAT IT DOES)
rawOptions->c_cflag |= CLOCAL;
// Enable receiver (USEFUL, I GUESS)
rawOptions->c_cflag |= CREAD;
// Turn off canonical mode and signals (NO IDEA WHAT IT DOES)
rawOptions->c_lflag &= ~(ICANON /*| ECHO*/ | ISIG);
// Raw (binary output)
rawOptions->c_oflag &= ~OPOST;
// 19200 baud
cfsetspeed(rawOptions, 19200);
// Applying settings
tcsetattr(_fileDescriptor, TCSANOW, rawOptions);
Related
I'm sending packets from an Ubuntu machine to an STM32 autopilot through a USB cable using write() and tcdrain():
int Serial_port::_write_port(char* buff, unsigned int len) {
const std::lock_guard<std::mutex> lock(_mutex_write_on_port);
const int bytes_written = static_cast<int>(write(_fd,buff, len));
if(bytes_written<0) {
printf("write to port failed with errno: %s\n", std::strerror(errno));
}
//wait until all data has been written to the port
tcdrain(_fd);
return bytes_written;
}
After a few thousands packets successfully sent, tcdrain() randomly blocks. I'm trying to understand why.
Any recommendations on how to debug this?
I've done some research but couldn't come across a good debug methodology.
Note: I've noticed if I run a simple python command in another terminal ser = serial.Serial('/dev/ttySAC0') this "unfreezes" my code about 75% of the time but I'm kind of at a loss to understand why.
If that helps, here is how I configure the port:
int Serial_port::_config_port() {
//Config based on following sources:
//https://github.com/mavlink/c_uart_interface_example
//https://blog.mbedded.ninja/programming/operating-systems/linux/linux-serial-ports-using-c-cpp/
struct termios config;
if(tcgetattr(_fd, &config) < 0) {
return -1;
}
// Input flags - Turn off input processing
// convert break to null byte, no CR to NL translation,
// no NL to CR translation, don't mark parity errors or breaks
// no input parity check, don't strip high bit off,
// no XON/XOFF software flow control
config.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | INPCK | ISTRIP | IXON);
// Output flags - Turn off output processing
// no CR to NL translation, no NL to CR-NL translation,
// no NL to CR translation, no column 0 CR suppression,
// no Ctrl-D suppression, no fill characters, no case mapping,
// no local output processing
config.c_oflag &= ~(OCRNL | ONLCR | ONLRET | ONOCR | OFILL | OPOST);
// No line processing:
// echo off, echo newline off, canonical mode off,
// extended input processing off, signal chars off
config.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
// Turn off character processing
// clear current char size mask, no parity checking,
// no output processing, force 8 bit input
config.c_cflag &= ~(CSIZE | PARENB | CSTOPB); //~CSTOPB to set only 1 stop bit for multiflex
config.c_cflag |= CS8;
// One input byte is enough to return from read()
// Inter-character timer off
config.c_cc[VMIN] = 0; //DEBUG: this is different from mavlink recommended setup. Confirm this is ok
config.c_cc[VTIME] = 10;
//baudrate
if(cfsetispeed(&config,_baudrate)<0) return -1; //input baudrate
if(cfsetospeed(&config,_baudrate)<0) return -1; //output baudrate
//write config to port
if(tcsetattr(_fd,TCSAFLUSH,&config) < 0) {
return -1;
}
std::cout<<"port "<<_uart_name<< " configured successfully"<<std::endl;
return 0;
}
I have been trying to perform serial communication on linux via the /dev/ttyS devices but when I try to read from them after writing I read no data.
I have the following code
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <unistd.h>
int main() {
printf("hello world\n");
int n;
int fd;
char c;
int bytes;
char buffer[10];
char *bufptr;
int nbytes;
int tries;
int x;
struct termios options;
fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
if(fd == -1) {
perror("open_port: Unable to open:");
} else
tcgetattr(fd, &options);
// Set the baudrate, same speed for both I/O
cfsetispeed(&options, B150);
cfsetospeed(&options, B150);
// Enable reading
options.c_cflag |= (CLOCAL | CREAD);
// Set 'RAW' mode
cfmakeraw(&options);
// Set byte size
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
// Set parity
// options.c_cflag &= ~PARENB;
options.c_cflag |= PARENB;
options.c_cflag |= PARODD;
options.c_cflag &= ~CSTOPB;
// Set StopBits, #Linux no OneHalf is supproted, so OneHalf and Two are the same
options.c_cflag &= ~CSTOPB;
// Set Handshake options
// options.c_iflag |= CRTSCTS;
// options.c_iflag &= ~CRTSCTS;
// options.c_cflag &= ~( IXON | IXOFF | IXANY );
options.c_cflag |= IXON | IXOFF | IXANY;
// Set Timeouts
options.c_cc[VMIN] = 0; // read() will return after receiving character
options.c_cc[VTIME] = 10; // == 0 - infinite timeout, != 0 - sets timeout in deciseconds
tcsetattr(fd, TCSANOW, &options);
tcflush(fd, TCIOFLUSH);
bytes = write(fd, "ATZ\r",4);
printf(" wrote %d bytes\n", bytes);
bufptr = buffer;
bytes = read(fd, bufptr, sizeof(buffer));
printf("number of bytes read is %d\n", bytes);
perror ("read error:");
for (x = 0; x < 10 ; x++) {
c = buffer[x];
printf("%d ",c);
}
tcflush(fd, TCIOFLUSH);
close(fd);
printf("\n");
return (0);
}
The program output is as follows
hello world
wrote 4 bytes
number of bytes read is 0
read error:: Success
0 0 0 0 0 0 0 0 0 0
Although I expected it to read the 4 characters I just wrote it seems that read reads 0 bytes. In case i put VTIME to 0 then read blocks forever. I have tried to do echo /dev/ttyS0 but no output comes out. Any idea what might cause this and how can it be fixed?
Your code apparently is ok, except for the following facts:
You call perror("read error"); after calling printf(3), and not right after read(2) so the possible error (if happened) is masked to the call to read(2) by the call to printf(3). If you want to print the number of read characters, save the value of errno and the returned value from read(2) before calling printf(3), and then, if the returned error is neg, then call perror(3).
Anyway. The c_cc[VTIME] = 10 imposes a one second timeout, and this is too sort for resetting a modem. Your line settings are:
CS8, Parity ODD, one STOP bit, and 150 baudrate
Normally, modems answer to ATZ\r command after resetting, which takes some time (frequently more than a second) and in the default modem speed (because you have reset it) and not at the speed at which you have send the AT command.
Resetting a modem is, for this reason, done blindly normally, and then you send a simple AT\r command, in order to ask for an \r\nOK\r\n response. The answer to AT\r command is normally immediate, not as the response to a reset command, and lets the modem adjust its communication settings according to the received chars.
Modems always adapt their speed when the A and T sequence is received, by sampling the square pulses received at a high sampling frequency, then they switch speed to the detected and normally do speed conversion (making it possible to talk to the modem at a different speed than the negotiated remotely)
I'm attempting to read from a serial port (/dev/ttyS4) on a BeagleBone Black, but I think(?) this should apply to all Linux devices in general.
Currently, I can set up minicom with a baud rate of 9600 and 8N1 data to read from the serial port correctly. However, if I attempt to directly cat /dev/ttyS4, nothing shows up in my terminal. My code also does this, and returns a Resource temporarily unavailable error, which I suspect is what is happening with the cat command.
If I run stty -F /dev/ttyS4, I get the following output (which, as far as I can tell, is consistent with my minicom settings):
speed 9600 baud; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>;
-brkint -imaxbel
-opost -onclr
-isig -iexten -echo -echoe -echok -echoctl -echoke
An interesting note is that when I have minicom open, if I start my program, minicom will stop printing anything, and stay that way even if I stop my program. I need to open the serial settings again (Ctrl-A, P) and close it for minicom to resume working (it appears that nothing was changed).
My code is as follows:
int main() {
std::cout << "Starting..." << std::endl;
std::cout << "Connecting..." << std::endl;
int tty4 = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
if (tty4 < 0) {
std::cout << "Error opening serial terminal." << std::endl;
}
std::cout << "Configuring..." << std::endl;
struct termios oldtio, newtio;
tcgetattr(tty4, &oldtio); // save current serial port settings
bzero(&newtio, sizeof(newtio)); // clear struct for new settings
newtio.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
newtio.c_iflag = IGNPAR | ICRNL;
newtio.c_oflag = 0;
newtio.c_lflag = ICANON;
tcflush(tty4, TCIFLUSH);
tcsetattr(tty4, TCSANOW, &newtio);
std::cout << "Reading..." << std::endl;
while (true) {
uint8_t byte;
int status = read(tty4, &byte, 1);
if (status > 0) {
std::cout << (char)byte;
} else if (status == -1) {
std::cout << "\tERROR: " << strerror(errno) << std::endl;
}
}
tcsetattr(tty4, TCSANOW, &oldtio);
close(tty4);
}
Edit: I've gotten the serial port to work correctly (in python) by following Adafruit's tutorial for using python with the BeagleBone. At this point I'm certain that I'm doing something wrong; the question is what. I would much prefer using C++ over python, so it'd be great to get that working.
Your program opens the serial terminal in nonblocking mode.
int tty4 = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
Nonblocking I/O, especially read operations, requires additional, special handling in a program.
Since you neglect to mention this mode, and your program has no capability to properly process this mode, this could be considered a bug.
Either remove O_NDELAY option from the open() call, or insert a fcntl(tty4, F_SETFL, 0) statement to revert back to blocking mode.
My code also does this, and returns a Resource temporarily unavailable error,
That's an EAGAIN error, which is consistent with a nonblocking read().
The man page describes this error will occur when "the file descriptor ... has been marked nonblocking (O_NONBLOCK), and the read would block".
The read() syscall "would block" because there is no data to satisfy the read request.
If you insist on using nonblocking mode, then your program must be able to cope with this condition, which is not an error but a temporary/transient status.
But blocking mode is the simpler and preferred mode of operation for typical programs in a multitasking system.
Your program should be modified as previously mentioned.
There are numerous issues with the initialization of the serial terminal.
tcgetattr(tty4, &oldtio); // save current serial port settings
The return values from the tcgetattr() and tcsetattr() syscalls are never checked for errors.
bzero(&newtio, sizeof(newtio)); // clear struct for new settings
Starting with an empty termios structure is almost always a bad idea. It may appear to work on some systems, but it is not portable code.
The proper method for initializing a termios structure is to use values from tcgetattr().
See Setting Terminal Modes Properly.
Since it is already called, all you need is newtio = oldtio to copy the structure.
newtio.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
newtio.c_iflag = IGNPAR | ICRNL;
newtio.c_oflag = 0;
newtio.c_lflag = ICANON;
Rather than assignment of constants, the proper method of changing these flags is to enable or disable the individual attributes.
The following should suffice for canonical mode:
newtio.c_cflag |= CLOCAL | CREAD;
newtio.c_cflag &= ~CSIZE;
newtio.c_cflag |= CS8; /* 8-bit characters */
newtio.c_cflag &= ~PARENB; /* no parity bit */
newtio.c_cflag &= ~CSTOPB; /* only need 1 stop bit */
newtio.c_cflag &= ~CRTSCTS; /* no hardware flowcontrol */
newtio.c_lflag |= ICANON | ISIG; /* canonical input */
newtio.c_lflag &= ~(ECHO | ECHOE | ECHONL | IEXTEN);
newtio.c_iflag &= ~INPCK;
newtio.c_iflag |= ICRNL;
newtio.c_iflag &= ~(INLCR | IGNCR | IUCLC | IMAXBEL);
newtio.c_iflag &= ~(IXON | IXOFF | IXANY); /* no SW flowcontrol */
newtio.c_oflag &= ~OPOST;
The following is the preferred method for setting the baudrate:
cfsetospeed(&newtio, B9600);
cfsetispeed(&newtio, B9600);
If any salient attributes are left unspecified, the existing settings are used.
This can lead to erratic program behavior, e.g. sometimes it works, sometimes it doesn't.
An interesting note is that when I have minicom open, if I start my program, minicom will stop printing anything, and stay that way even if I stop my program. I need to open the serial settings again (Ctrl-A, P) and close it for minicom to resume working (it appears that nothing was changed).
The serial terminal is not intended for sharing among more than one process.
Some of the termios attributes have to be implemented in the serial device driver, which has no concept of sharing the port. The most recent termios attributes are in effect for the device.
When you execute your program after minicom has started, you are clobbering the termios attributes that minicom expects to execute with.
You are restoring the termios attributes to minicom's requirements by using its menu.
We are migrating from an older OS (OpenSuse 10.2) to Ubuntu 16.04, and one of our applications communicates via a serial port. Communication stopped working on Ubunutu, but with a small hack(?) it does start working. That hack is to send a tcsendbreak() right after the call to open, like so:
fd = open(pname, O_RDWR | O_NOCTTY); //pname becomes /dev/ttyS6
if (fd < 0)
{
printf("Couldnt open comms port \"%s\".\n", pname);
return SYSERR;
}
if (tcsendbreak(fd, 0) < 0)
{
printf("tcsendbreak error\n");
}
After doing this everything runs normally. I've tried doing a tcflush at various points (without the tcsendbreak), that didn't make a difference.
What are some reasons why the tcsendbreak would allow communication to be established? Any ideas of what to try without using the tcsendbreak? Trying to understand why its needed, and if there is an underlying issue that this break skips past.
We set the modes the following way:
int r = 0;
struct termios port_opt, *popt;
r |= tcgetattr(fd, &original_port_options);
port_opt = original_port_options;
popt = &port_opt;
cfmakeraw(&port_opt);
/* parity/framing errors come in as nulls. */
popt->c_iflag |= (IGNBRK);
popt->c_cflag |= (CLOCAL);
popt->c_cc[VMIN] = 0; /* ignored by line discipline. */
popt->c_cc[VTIME] = 1; /* ignored by line discipline. */
popt->c_cflag |= CREAD; //enable receiver
r |= cfsetispeed(popt, B19200);
popt->c_cflag &= ~(PARENB);/* turn off parity. */
popt->c_cflag = (popt->c_cflag & ~CSIZE) | CS8; /* 8 bits. */
popt->c_cflag &= ~CSTOPB; /* only 1 stop bit. */
r |= cfsetospeed(popt, B19200);
r |= tcsetattr(fd, TCSANOW, popt);
if (r != 0)
gos_panic("Cant set comms driver parameters");
Additionally, we also set a line discipline:
r = ioctl(fd, TIOCGETD, &old_line_discipline);
if (r != 0)
old_line_discipline = -1;
r = map_line_discipline("LINE_DISC", 27);
r = ioctl(fd, TIOCSETD, &r);
Note that communication works when sending the tcsendbreak before setting all these modes.
I am working on a "high level" C++ interface for the standard PC serial port. When I open the port, I would like to clear the input and output buffers in order not to receive or send data from previous usage of the port. To do that, I use the tcflush function. However, it does not work. How can that be? My "port opening" code can be seen below. Yes I use C++ exceptions but none are getting thrown. That indicates that tcflush returns 0 but it does not clear the buffer.
The only way I can clear the input buffer is to read bytes from it until there is none left. This usually takes a couple of seconds and I do not think of it as a solution.
Thanks in advance :-)
fd = ::open(port.c_str(), O_RDWR | O_NOCTTY);
if (fd < 0)
{
throw OpenPortException(port);
return;
}
// Get options
tcgetattr(fd, &options);
// Set default baud rate 9600, 1 stop bit, 8 bit data length, no parity
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
// Default timeout (1000 ms)
options.c_cc[VMIN] = 0;
options.c_cc[VTIME] = 10;
// Additional options
options.c_cflag |= (CLOCAL | CREAD);
this->port = port;
// Apply the settings now
if (tcsetattr(fd, TCSANOW, &options) != 0)
{
throw PortSettingsException();
}
// Flush the port
if (tcflush(fd, TCIOFLUSH) != 0)
{
throw IOException();
}
This is the correct way (as below):
usleep(1000);
ioctl(fd, TCFLSH, 0); // flush receive
ioctl(fd, TCFLSH, 1); // flush transmit
ioctl(fd, TCFLSH, 2); // flush both
User can choose both of the first 2 lines OR last line alone based on requirement. Please check if sleep may be required.
Try
ioctl(fd, TCFLUSH, dir)
with dir equal to 0 for receive, 1 for transmit, 2 for both.