Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux UART does not time out while receiving (Raspberry PI) #288

Open
StWandl opened this issue Mar 23, 2022 · 3 comments
Open

Linux UART does not time out while receiving (Raspberry PI) #288

StWandl opened this issue Mar 23, 2022 · 3 comments
Labels

Comments

@StWandl
Copy link

StWandl commented Mar 23, 2022

Hello everybody,

I successfully built and used the library on my Raspberry PI.
But one thing I noticed is that read() in hal_uart_receive() (hal_linux_uart_userspace.c) did not time out when nothing is received. So it just blocked my application.

In hal_uart_open_file() the read timeout is set to 500ms.
// hal_linux_uart_userspace.c line 146
tty.c_cc[VTIME] = 5;

But read() still does not time out, so I did some digging and found a solution by setting VMIN in the termios struct to zero.
tty.c_cc[VMIN] = 0;

Some infos for VTIME and VMIN in the termios struct:
http://unixwiz.net/techtips/termios-vmin-vtime.html

VMIN represents the minimum number of received bytes.
So if VMIN > 0 --> read() never times out because nothing is received.

With VMIN set to 0 the read() call timed out after 500ms.

So I think setting VMIN to 0 should be added to hal_uart_open_file().
Or did I miss something that would be negatively affected by this change?

@bryan-hunt
Copy link
Contributor

It would have to be tested - there are a couple of usecases for the uart usage. Kit protocol (which is basic ascii frames) and SWI which is more complicated (oversampling). In the later case the rx & tx lines are tied together.

Were you using kit protocol to communicate with a development board (i.e. with the kit_host from the app folder on the other side) or were you trying to work with a SWI device?

@StWandl
Copy link
Author

StWandl commented Mar 25, 2022

Sorry, I forgot to mention. I was communicating with a SWI device (ATSHA204A) and had RX & TX tied together.
The communication worked fine, but one time I forgot to power the device and I noticed that the program got stuck due to the blocking read() call.

@bryan-hunt bryan-hunt added the bug label Mar 25, 2022
@bryan-hunt
Copy link
Contributor

Thanks for the additional details. This does make sense to modify given the SWI usecase generally revolves around removable components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants