On Monday 23 April 2012 16:57:16 Mike Frysinger wrote:
On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote:
Mike Frysinger wrote:
You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF.
because that isn't how u-boot on the hardware works. u-boot itself calls tstc() to see if there's any data and does so in a continuous loop. when there is data, it calls getc(). tstc() should not block, and getc() isn't call unless u-boot knows there's data.
That's why I suggested to use select() or poll() to poll for available characters, just like the hardware does. Only we do NOT want to tun this in a tight loop. We will most likely want to add a sufficiently large delay to keep CPU load in reasonable bounds.
where exactly do you propose adding this delay ? tstc() is called in many places (not just the main console loop), many of which are done simply to handle the unlikely CTRL+C interrupt. thus we don't want tstc() delaying at all or it'll slow down random CPU-bound operations.
also, what you're proposing is changing the behavior of u-boot when it's in the sandbox so that it acts less like the hardware. when you run u-boot on the hardware and it's sitting at the prompt, u-boot is running the cpu at 100%.
hmm, maybe the hush shell works differently and calls getc() directly rather than itself calling tstc(). so in the hardware, it eats the cpu because the hardware has no way of sleeping for the data, but in an OS we can wait for input. should be easy to post a patch for this code path. -mike