[U-Boot-Users] non-canonical input mode for standalone app
In my standalone application, I'd like to implement a menu system based on single keystrokes. Exported function tstc() won't return any keystrokes until I hit the ENTER key. How can I turn off canonical input for a standalone application?
Ed Jubenville
In message GPECLCIGPLHEOMGPMCPAAELFDOAA.edjubenville@adelphia.net you wrote:
In my standalone application, I'd like to implement a menu system based on single keystrokes. Exported function tstc() won't return any keystrokes until I hit the ENTER key. How can I turn off canonical input for a standalone application?
Your message makes no sense.
tstc() *never* returns any keycodes. It returns 1 if there was any key pressed (without actually emptying the receive buffer).
What you probably might want is getc(), and this function returns each and every key code without any processing.
Best regards,
Wolfgang Denk
Wolfgang wrote:
Your message makes no sense.
tstc() *never* returns any keycodes. It returns 1 if there was any key pressed (without actually emptying the receive buffer). What you probably might want is getc(), and this function returns each and every key code without any processing.
Sorry for the confusion. I tried to be too concise. Let me clarify.
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 my application, which wants to perform background processing while waiting for single character operator input, as in a simple menuing system.
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. }
In past Linux applications that I've written, I've been able to implement code loops like this by first disabling canonical input on stdin (using tcgetattr/tcsetattr to modify flag ICANON), then turning off blocking and buffering on stdin. After those steps, getchar() will return -1 if no input is pending.
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.
Ed Jubenville
Dear Ed,
in message GPECLCIGPLHEOMGPMCPAGELIDOAA.edjubenville@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
Wolfgang,
You wrote:
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...
I found the problem, and it was on my end, not in u-boot.
The hello_world app and the initial boot countdown both worked on my board, but I could only press ENTER, not any other key. Based on your comment, I realized that I was fighting a connectivity issue, not a u-boot issue. Although I had originally tested with a direct serial connection, I later rigged up a serial-to-ethernet converter so that I could work remotely via telnet. As it turns out, I had telnet configured wrong.
My apologies. Sorry for the bother, but thanks for the help.
Ed Jubenville
participants (2)
-
Edward Jubenville -
Wolfgang Denk