Clemens Koller wrote:
> Jerry Van Baren schrieb:
>> Michael Schwingen wrote:
>>> Wolfgang Denk wrote:
>>>> Please let's stay terse. Printing a dot is a single character on the
>>>> console. I dislike funny stuff which requires output of non-printing
>>>> characters or (weven worse!) terminal specific escape sequences.
>>>>
>>> Backspace or CR without LF should work on all terminals, no?
>>>
>>> No matter how it is implemented, I am strongly in favor of *some*
>>> kind of progress output.
>>>
>>> If it is possible to estimate how long the operation will take, this
>>> would be a big plus IMHO (which precludes the simple dots).
>
>> Hi Michael, Stefan, Wolfgang,
>>
>> I understand where you are coming from and like countdowns a lot when
>> driving the system from a terminal.
>>
>> The dark side of countdowns with \r characters is if you capture it in
>> a log file. It isn't impossibly bad, but you end up with a lot of
>> crap in your log file.
>>
>> The dark side of dots, as you point out, is that you don't know how
>> many dots are suppose to print, at least the first couple of times you
>> do it.
>>
>> Here is a thought, what about printing a bar and then print the dots.
>> How sophisticated is our printf() formatting capabilities? Hmmm. How
>> about something like this (I think the?
>>
>
> ACK from my side to Jerry's version. Maybe a quite long fixed length
> (~40 characters)
> bar would also be reasonable and the dot-time scaled to fit the progress.
>
> A progress bar needs IMO two informations:
> - that it's still working... so a quite frequent output of something to
> keep me calm.
> - how long it will take... so I know how much time I will have to get
> the next cup
> of coffee to keep me tickin'.
>
> Perfect (= close to overkill, I know) would be IMO an additional output
> like:
>
> Programming Flash from 0xc0ldbeef to 0xc0ldcafe takes 112s.
> ................. |
>
> So, I don't need to estimate from the first dots how long it will take to
> complete.
>
> Regards,
>
> Clemens
Scaling the dots is trivial. The disadvantage of scaling the dots is
that they will come out at a different rate depending on the size of
what you are programming. This is OK for small things, but devolves
back into a "how long to I wait for the next dot" problem for large copies.
Hardcoding a prediction of time to program is difficult and a horrible
maintenance burden. We could do one dot's worth of programming
measuring elapsed time *before* printing the progress end marker, and
then use that to print the estimated time of completion. Cute, but
seems like overkill to me.
Here is a revised command line example that autoscales to 50 dots:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int k;
int cnt;
int scale;
if(sscanf(argv[1], "%d", &cnt) != 1) {
fprintf(stderr, "sscanf() failed\n");
return 0;
} else {
scale = (cnt >= 50) ? cnt / 50 : 1;
#ifdef ONELINEBAR
printf("%*c\r", (cnt + scale - 1) / scale, '|');
#else
printf("%*c\n", (cnt + scale - 1) / scale, 'v');
#endif
fflush(stdout);
for(k = 0; k < cnt; k++) {
if ((k % scale) == 0) {
usleep(100000);
putchar('.');
fflush(stdout);
}
}
printf("\n");
}
return 0;
}
Best regards,
gvb
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
