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

Harald Kipp harald.kipp at
Fri May 21 11:15:35 CEST 2004

Hi Oliver,
Hi Brett,
Hi all,

Let me apologize first for taking part here quite rarely.
I'm busy integrating Tyou's ARM7 port into the existing
local stuff here.

On the topic: I assume that it will fail to implement
something general, as devices are very different.
IMHO, kbhit() should check the device type first and
decide what to call.

I doubt, that the current device type classification
(IFTYP_) would be sufficient to solve this.

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'm undecided. Any other proposals? How did other OSes
handle it? Linux/BSD seem to offer very complicated


At 10:18 21.05.2004 +0200, you wrote:
>Hi Brett,
>yes, it would run for nut/os 3.4, but it is tied to one specific device, in
>this case an UART. Thus it is not suitable for a "simple" function.
>A more general function is not possible, unless we define a 'global' ioctl
>function code (ex: IOCTL_GETSTATUS), which delivers some globaly defined
>status bits.
>After that, it would be possible to write a 'kbhit()' function, that uses
>the stdin file, regardless, which device/file is connected to stdin.
>Harald, what do you think?
>-----Ursprungliche Nachricht-----
>Von: en-nut-discussion-bounces at
>[mailto:en-nut-discussion-bounces at]Im Auftrag von Brett Abbott
>Gesendet: Donnerstag, 20. Mai 2004 01:31
>An: en-nut-discussion at
>Betreff: [En-Nut-Discussion] getch/kbhit
>Originally posted May 2003.  Support to test for incoming characters waiting
>is kind of there.  This may help you out
>Oliver - Could the test part of this be usefully added to nutos as kbhit? -
>Looks ugly but is pretty straightforward to use.
>The following snippet of code can be used to check for the existance of
>incoming characters without having to actually receive them.  Useful for
>"Press the Return key or wait 10 seconds to reload last known configuration"
>type messages.  Improved versions of version portable code welcomed.
>It uses the uart library.  Is there a more generic stream or file function
>call I could use?  I chose this approach rather than write a custom function
>to hopefully support future and past nutos releases.
>Hopefully this will save someone some effort.
>// Globals
>FILE *uart;
>u_long UartStatus;
>u_long *UartStatus_ptr;
>// Sample Code to check for key press, Assumes uart file already open. Does
>not block if no characters were received.
>   // Were any keys pressed?
>   result=UartAvrIOCtl(((NUTFILE *) (_fileno(uart)))->nf_dev, UART_GETSTATUS,
>   if((UartStatus & UART_RXBUFFEREMPTY)==0) // One or more keys were pressed
>        // Now go get it
>        if((rlen = _read(_fileno(uart), rxbuff_ptr, RXBUFF_LEN)) > 0) // Get
>the characters
>           if(strchr(rxbuff_ptr, '\r') || strchr(rxbuff_ptr, '\n'))    // Did
>the user hit <CR> or <LF> ?
>               UserEnterNewConfig();  // Yes? go to Configure mode
>Brett Abbott, Managing Director, Digital Telemetry Limited
>Email: Brett.Abbott at
>PO Box 24 036 Manners Street, Wellington, New Zealand
>Phone +64 (4) 5666-860  Mobile +64 (21) 656-144
>------------------- Commercial in confidence --------------------
>En-Nut-Discussion mailing list
>En-Nut-Discussion at

More information about the En-Nut-Discussion mailing list