[U-Boot-Users] [PATCH] Add flash programming counter]

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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