AW: AW: [En-Nut-Discussion] getch/kbhit

[Oliver Schulz]

Hi all,

> Another idea is to use dev->dev_size() to return the
> number of bytes in the input buffer. The application
> or better kbhit() may then call _filelength().
> But this is a similar hack as using _read(0) to flush
> the input buffer.
I think this is an good idea. Never mind, that it looks like an additional hack. Currently there are no dev_size functions for UART and USART, so it would not disturb anybody, to have this new function. 
If you don't need it, don't use it.

> 
> I'm undecided. Any other proposals? How did other OSes
> handle it? Linux/BSD seem to offer very complicated
> mechanisms.
I can just talk about DOS and Win. Old DOS kbhit() uses a call to the DOS interrupt 0x21, it returns the number of chars in keyboard input buffer. This is not tied to any input stream.
In Win we have special functions to ask for the current state of a console window. Again, this has nothing to do with a input stream like stdin.
So these implementations are not suitable for us.

As a first approach, yesterday I wrote the dev_size functions for UART and USART devices. These function return the number of unread characters in input buffer. As suggested, the new kbhit() function calls _filelength on stdin.

Commited all changed files to CVS HEAD branch.

Happy testing. :-)

Cheers,
Oliver.