Serial Port over USB ttyUSB0 not initializing properly?

I have a USB FTDI serial device that connects to the BBB and it shows up under /dev/ttyUSB0.

After bootup If I try connecting to the device via a c program I get an error “11 - Resource temporarily unavailable”.

However, if I first connect to the device using something like “screen” or “minicom” then kill the process, I am able to use my c program to access the serial device without any problems.

Is there some sort of initialization script I need to run in order to access the USB serial device?

If I use stty -F /dev/ttyUSB0 -a I get

speed 230400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Hi Mike,

I have a USB FTDI serial device that connects to the BBB and it shows up under /dev/ttyUSB0.

After bootup If I try connecting to the device via a c program I get an error “11 - Resource temporarily unavailable”.

However, if I first connect to the device using something like “screen” or “minicom” then kill the process, I am able to use my c program to access the serial device without any problems.

Is there some sort of initialization script I need to run in order to access the USB serial device?

If I use stty -F /dev/ttyUSB0 -a I get

speed 230400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

I seem to recall that modemmanager and/or brltty (on your host computer) may cause access problems.
So one of the first things I do is to uninstall those 2 packages (this may not be what you’re running into, but I’ve been burned by it several times, so I figured I’d mention it).

It looks like CLOCAL is turned off, which means that it expects modem control lines to take effect (including carrier detect).

I’ve written a small sample program I call sertest which you can find here:

https://github.com/dhylands/projects/blob/master/host/sertest/sertest.c

It opens a serial port and takes any characters you type and sends them to the serial port, and prints any received characters to stdout.

If you short RxD and TxD on your USB serial dongle, then you should be able to see what you type.

Opening the serial port using O_NONBLOCK is desirable (otherwise you may hang if the carrier detect isn’t asserted), but it will cause the error that you’re seeing when you try to read data from the serial port.

You’ll see here: https://github.com/dhylands/projects/blob/master/host/sertest/sertest.c#L225

that I turn off the non-blocking behaviour after opening the serial port, which means that the read will block instead of returning EAGAIN.

If you’re still having issues, it would be useful if you could post the code that you’re using. You didn’t mention which exact call was returning the EAGAIN error.

Side note: Nifty program Dave. I can use your sertest program to serial into my beaglebone and do stuff similar to minicom, but I can also use tee to pipe everything I do into a logfile. nice.

Thanks for sharing.

Hi Michael,

Im using a TTYL encoder/decoder counter device that translates the encoder pulses to a USB serial port.

the call being used is
int qsb = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK);

ioResult = read(qsb, response, responseSize); //EAGAIN error in here

Hi Mike,

Im using a TTYL encoder/decoder counter device that translates the encoder pulses to a USB serial port.

the call being used is
int qsb = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK);

ioResult = read(qsb, response, responseSize); //EAGAIN error in here

Exactly. This happens because the serial port was opened using O_NONBLOCK.

Opening with O_NONBLOCK is desirable, so you need to add

fcntl(gsb, F_SETFL, fcntl(gsb, F_GETFL ) & ~O_NONBLOCK);

to turn off non-blocking mode once you’ve done the open.

Then the read command will block and wait for the data, rather than returning EAGAIN if the data isn’t ready yet.

Also - In general I highly recommend that you put the port in raw mode. Otherwise if you’re sending binary data you’ll get a bunch of weird translations happening and your data will get corrupted. In canonical mode, it interprets things like backspaces, and may massage your CRs

I use VMIN = 1 and VTIME = 0 which means that read will return as soon as a single byte is available, but it will return more if its available.
So you may get less data that you asked for, but on the other hand if you ask for 6 bytes, it won’t actually wait for 6 bytes to arrive.

It kind of boils down to the type of error handling that you want to do. Here’s a site that explains the VMIN/VTIME configuration:
http://www.unixwiz.net/techtips/termios-vmin-vtime.html

Dave I appreciate the info.

Unfortunately still no joy. I used

int qsb = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK);
fcntl(qsb, F_SETFL, fcntl(qsb, F_GETFL ) & ~O_NONBLOCK);

fcntl after my open() but the only result is that the process hangs indefinately and there is no output. If I run then kill “screen” before executing the code change works albeit much slower.

Did I put the call in the wrong location?

Hi Mike,

Dave I appreciate the info.

Unfortunately still no joy. I used

int qsb = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK);
fcntl(qsb, F_SETFL, fcntl(qsb, F_GETFL ) & ~O_NONBLOCK);

fcntl after my open() but the only result is that the process hangs indefinately and there is no output. If I run then kill “screen” before executing the code change works albeit much slower.

Did I put the call in the wrong location?

That looks right. I suspect that there is something wrong in other parts of your program.

If you ask to read and there is no data available, then the read will hang until data is available.

Can you post your complete source code?

What type of device are you trying to connect to on the serial port?

There are really only 4 ways to read data from the serial port:

1 - Using non-blocking (which means that read will return errno == EAGAIN when no data is available

2 - Use multiple threads (and noon-blocking reads). The tthread that reads from the serial port will hang, but the other threads will run.

3 - Use select to determine when data is available and then read

4 - Use a single thread and blocking reads - which will cause your program to hang.

Hello Dave,
I encountered the same situation as Mikester. I have to open minicom first of all. Then run my own program on Beaglebone. Or the system will show “: Resource temporarily unavailable”. It seems like I have to set ttyO0 free then I can use the read function.
My program can write “HelloBeaglebone!” to my laptop perfectly but it just cannot read.
I am looking to your kind reply.

Jian

#include<stdio.h>
#include<fcntl.h>
#include<unistd.h>
#include<termios.h> // using the termios.h library

int main(){
int file, count;

if ((file = open("/dev/ttyO0", O_NDELAY | O_RDWR | O_NOCTTY ))<0){ //| O_NONBLOCK
perror(“UART: Failed to open the file.\n”);
return -1;
}
// fcntl(file, F_SETFL, fcntl(file, F_GETFL ) & ~O_NONBLOCK);
struct termios options; //The termios structure is vital
tcgetattr(file, &options); //Sets the parameters associated with file
options.c_cflag = B9600 | CREAD | CS8 | CLOCAL;//
// Set up the communications options:
// 9600 baud, 8-bit, enable receiver, no modem control lines

options.c_iflag = IGNPAR | ICRNL; //ignore partity errors, CR → newline
tcflush(file, TCIFLUSH); //discard file information not transmitted
tcsetattr(file, TCSANOW, &options); //changes occur immmediately

unsigned char transmit[18] = “Hello BeagleBone!”; //the string to send

if ((count = write(file, &transmit,18))<0){ //send the string
perror(“Failed to write to the output\n”);
return -1;
}

usleep(100000); //give the Arduino a chance to respond

char receive[4]; //declare a buffer for receiving data
for (int i=0; i<2; i++){
if ((count = read(file, (void*)receive, 4))<0){ //receive the data
perror(“Failed to read from the input\n”);
return -1;
}
if (count==0) printf(“There was no data available to read!\n”);
else {
printf(“The following was read in [%d]: %s\n”,count,receive);
}
}
close(file);
return 0;
}

在 2013年11月29日星期五 UTC-3:30下午7:57:44,Dave Hylands写道: