On 20/03/15 11:03, Daniel Krüger wrote:
Am 20.03.2015 um 10:02 schrieb Sebastian Huber:
On 20/03/15 09:42, Daniel Krüger wrote:
Am 06.03.2015 um 11:20 schrieb Sebastian Huber:
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.
will this work on non-POSIX targets at all?
Currently, we use this code under Linux.
This code switches stdin into non-blocking mode via the following
sequence:
tcgetattr(STDIN_FILENO, &oldt);
oldf = fcntl(STDIN_FILENO, F_GETFL, 0);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO);
newf = oldf | O_NONBLOCK;
tcsetattr(STDIN_FILENO, TCSANOW, &newt);
fcntl(STDIN_FILENO, F_SETFL, newf);
Then it tries to read from the input via getchar().
I must admit this code is a little bit tricky, because it uses
ungetc() for the implementation of a Windows kbhit() equivalent.
You already use the Termios functions, so I don't know why you cannot
use the POSIX read() directly.
The interesting thing is, that newlib/libc/stdio/refill.c contains
some "#ifndef __CYGWIN__" which seem to fix the problem under Cygwin.
This Cygwin approach seems to be quite a hack. The current FreeBSD
variant of refill.c uses the default. How does this work on Linux?
I didn't checked the glibc code, but non-blocking getchar() works as
expected.
To me this looks like a glibc vs. BSD libc compatibility issue. I don't
know if you are in the implementation defined area of the C/POSIX
standards here.
--
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
