Hello Daniel,
I would not use the C stdio for this and instead directly use the POSIX
read/write. You have to set up the right Termios settings. In case you
use RTEMS 4.11 I would use the new Termios device interface (see
rtems_termios_device_install()).
On 06/03/15 10:52, Daniel Krüger wrote:
Hello,
what is the right implementation for the UART driver read function
(console_fns .deviceRead)? It seems to be implemented differently from
target to target. Some implementations return -1 if the receive FIFO
is empty and some implementations do a busy waiting for new characters.
I would like to use some Posix application code, which switches stdin
into non-blocking mode and uses getchar() to read from UART. getchar()
shall return EOF if no character is available.
This code requires that the UART driver read function does not block,
otherwise getchar() will block. But a non-blocking UART driver is not
sufficient. The function __srefill_r() in newlib/libc/stdio/refill.c
sets the flag __SEOF whenever the driver's read function returns no
characters. So on subsequent calls of getchar() and hence
__srefill_r() the UART driver's read function is not called anymore,
because __SEOF flag is set (see if statement at beginning of
__srefill_r()).
My current work-around is to call clearerr(stdin) before calling
getchar(). clearerr() resets the flag __SEOF, so getchar() will get
the current character from the UART driver.
There are many other functions and modules (e.g. console*.c,
rtems_termios*, ...) involved between getchar() and the UART driver's
read function. So it's a little bit hard to dig into that issue and to
find a good solution.
Best regards,
Daniel Krüger
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
