After le_tty_Open(), read() fails "Resource temporarily unavailable"

Legato Application Framework
1

Jul 9 09:24:23 | msglegato[3586]/framework T=main | LE_FILENAME le_tty_Open() 247 | Serial device ‘/dev/ttyHS0’ acquired by pid 3586.
Jul 9 09:24:23 | msglegato[3586] | | read: Resource temporarily unavailable

/dev/ttyHS0 is configured for Linux applications and cat /dev/ttyHS0 works.

#include “legato.h”
#include “interfaces.h”
#define UARTDEV “/dev/ttyHS0”
#define MSGLEN 25
COMPONENT_INIT
{
LE_INFO(“Hello, legato.”);
char buffer[MSGLEN];
le_result_t rc;
// legato style
int fd;
fd = le_tty_Open(UARTDEV, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd < 0)
{
perror(“Open_uart”);
}
else {
rc = le_tty_SetBaudRate(fd, LE_TTY_SPEED_9600);
if (rc != LE_OK)
{
perror(“le_tty_SetBaudRate”);
}
rc = le_tty_SetRaw(fd, MSGLEN, 0);
if (rc != LE_OK)
{
perror(“le_tty_SetRaw”);
}
}
int len = read(fd, buffer, MSGLEN);
if (len < 0)
{
perror(“read”);
}
else
{
buffer[len] = ‘\0’;
LE_INFO(“buffer=%s, len=%d”, buffer, len);
}
}

2

Is your app unsandboxed?

Does it work to use standard linux api open() ?
E.g.

3

It’s not unsandboxed. I am able to read after using open(), also unsandboxed. However this always gives me garbled data on the first read. I thought I would try using le_tty_open() to see if this fixes the problem, however it doesn’t work at all.

I am including [rw] /dev/ttyHS0 /dev/ttyHS0 in the .cdef file, both configurations.

4

Maybe the garbled data come from noise on your board.

5

Hi @piinst,

I note your example shows that you never setup the framing on the serial port.

Maybe try setting it up with le_tty_SetFraming() after you set the baud rate and see how that goes.

Raf

6

Calling le_tty_SetFraming(fd, ‘N’, 8, 1) after le_tty_SetBaudRate() makes no difference.

As for garbled data, it only happens on the first read after inactivity. Never during a sequence of reads. Also, if I take the rate down to 2400 bps, I find the first character drops rather than the data being garbled. I think it’s likely to be a sleep/wakeup issue. I am investigating this and if I can fix it I will just stick to the Posix calls.

7

See if this helps by keeping the uart awake.

1 Like
8

Thanks for the tip, periodic calls to tcflow(fd1,TCION ) are effective in preventing lost data on UART using open()/read().

As for the le_tty_open()/read() issue, perhaps it has something to do with the event processing framework, but I don’t need to deal with it at this time.