UART driver: read function

[Sebastian Huber]

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.