UART driver: read function

[Daniel Krüger]

Hello Sebastian,

Am 06.03.2015 um 11:20 schrieb 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()).

The code is intended to be platform independent, so I don't want to 
change it if not really necessary.

The interesting thing is, that newlib/libc/stdio/refill.c contains some 
"#ifndef __CYGWIN__" which seem to fix the problem under Cygwin.

Best regards,
   Daniel Krüger


> 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
>>
>

-- 
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund

Telefon : +49 (0) 3765 38600-0
Fax     : +49 (0) 3765 38600-4100
Email   : daniel.krueger at systec-electronic.com
Website : http://www.systec-electronic.com

Managing Director   : Dipl.-Phys. Siegmar Schmidt
Commercial registry : Amtsgericht Chemnitz, HRB 28082