[U-Boot-Users] non-canonical input mode for standalone app

[Wolfgang Denk]

Dear Ed,

in message <GPECLCIGPLHEOMGPMCPAGELIDOAA.edjubenville at adelphia.net> you wrote:
> 
> I'm using a customized MPC5200 IceCube configuration, and my testing shows
> that getc() blocks unless there is input pending, and tstc() will not return
> 1 until after an ENTER key has been hit.  This doesn't fit too nicely into

Maybe your customization broke someting?

> my application, which wants to perform background processing while waiting
> for single character operator input, as in a simple menuing system.

Yes, understood.

> A simplified version of my application looks something like this...
> 
> done = 0;
> while(!done) {
>     // perform a single pass of hardware testing here, then...
>     // check for user input to quit or alter the test mode
>     while (tstc()) {
>         c = getc();
>         // handle input (e.g. 'Q' = quit, '?' to display help, etc.)
>         if (c == 'Q')
>             done = 1;
>         else if (c == '?')
> 		... display the help screen...
>         else if (c == ANOTHER_OPTION_HERE)
>             ... etc.
> }

Looks perfectly legal to me.  See for example the hello_world example
code.

> How can I make tstc() return 1 as soon as any key is hit?  If such a
> capability existed, u-boot commands "loop", "iloop", and "loopw" could
> benefit, giving the operator an exit path without a reset.

It exists, and is used in many places. If it didn't work,  you  would
not  be  able  to  stop the initial count down. Or the hello_world app
would not terminate. Or...

But they do work. At least on the systems I have access to...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober!
                                     - Terry Pratchett, _Men at Arms_