bugAVR Downloader/UploaDEr - Bugs: bug #35456, The progress bar for STK500V2...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #35456: The progress bar for STK500V2 programmer is "wrong".

Submitter:  Roger Wolff <rewolff>
Submitted:  Sun 05 Feb 2012 09:16:37 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  3 - Low Item Group:  None
Status:  Ready For Test Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  me: rewolff
Open/Closed:  Open Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Fri 13 Sep 2013 09:44:12 AM UTC, comment #6: 

I implemented your suggestion for the paged read/write methods
(which is where I think this is mostly relevant).  It counts
all the pages to be considered beforehand now, and then reports
progress per page already processed, relative to the number
of affected pages counted before.

Please give it a try.

 Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 13 Sep 2013 09:22:48 AM UTC, comment #5: 

IMHO, what the user wants is an indication of how much longer he has to wait ("should I go get a cup of coffee?"). That's the idea of a progress bar. By progressing slowly to 5% and then jumping to the end, you lose resolution, even if you'd tell the user in advance that that's what's going to happen.

In the case of an "FSCK" you have different phases of the progress. So a developer fsck's his filesystem, concludes that phase 1 takes 50% of the time and phase 2-6 each take about 10%. So then the progress bar is programmed to show .5*completion-of-phase-1 or .5+.1*(phase-2)+.1*completion-of-current-phase.

That gets you a reasonable progress bar. And people understand that this cannot be perfect. A filesystem with millions of files may spend much more of it's time in say "phase two". So this is a difficult case.

But with avrdude, I'd say that programming time is roughly proportional to the bytes that need to be programmed. So, scanning the datafile for the bytes that need to be programmed is relatively easy and quick. And then you can set the progress bar at bytes-programmed-so-far/total-bytes-that-need-to-be-programmed.

 Roger Wolff <rewolff>
Fri 13 Sep 2013 09:06:53 AM UTC, comment #4: 

Well, due to all the changes with respect to handling files
with "holes", the progress reporting is now relative to the
entire size of the respective memory region, rather than
relative to the highest file address.

So if you have a file that contains a small application
part at the beginning, followed by a bootloader part at the
top (e.g. since you want to use SPM instructions), the
progress bar proceeds as normal for the lower memory area,
then jumps to the bootloader region, and eventually completes.

I think this is a feature rather than a bug. ;-)

I don't say this is something that cannot be changed at all,
but displaying the progress relative to the overall memory
size seems to make some sense to me.

Opinions?

 Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 12 Feb 2012 12:33:58 PM UTC, comment #3: 

attached is the hexfile with byte locations 0x100-400 cut out.

As you can see the maximum address is just beyond 1k.


(file #25048)

 Roger Wolff <rewolff>
Mon 06 Feb 2012 07:13:13 AM UTC, comment #2: 

No, I'm not programming  a bootloader. (hmm. forgot to hit "submit" after writing that last night.)

Thinking about it overnight: wouldn't then programming a bootloader then have the progress bar "jump" to almost the end and then progress slowly to 100%?

What I see is slow progress 0,....5%, and then a sudden jump to 100%, done!

 Roger Wolff <rewolff>
Sun 05 Feb 2012 10:18:32 PM UTC, comment #1: 

Do you perhaps program a bootloader?

The progress is calculated as the amount of data already
been programmed vs. the highest address to be programmed.
As data not being present in the input file are being skipped
now in the SVN version, (not) programming these data happens
within a few microseconds ...

Yes, perhaps the progress indicator should take into account
how many data are about to be programmed in the first place.
I'd consider that a minor issue, but I'll leave the bug report
open as a reminder.

 Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 05 Feb 2012 09:16:37 PM UTC, original submission:  

I'm using the latest SVN(*) (because I needed the syncbb driver a moment ago).

Anyway, when programming an AVR with an STK500V2 compatible programmer, I see the progress bar progress to about 5% and then suddenly it's done. I'm guessing that there is a 16x scaling issue in calling the progress bar functions.

If this is just a two minute "open editor change 1 line of code, close editor, commit to SVN", then please do so. If I need to delve in and figure out how the progress bar works, then let me know. I'll see if I can make time for this.




(*) Ehhhh. I think I have the almost-up-to-date SVN version, and then the patch I wrote here got added to the SVN version. So I'm lagging one patch, that's not relevant here.

Roger Wolff <rewolff>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #25048:  bla.hex added by rewolff (1KiB - text/x-hex)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by rewolff (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-13 joerg_wunsch StatusIn Progress Ready For Test
        Assigned toNone joerg_wunsch
    2013-09-13 joerg_wunsch StatusNone In Progress
    2012-02-12 rewolff Attached File- Added bla.hex, #25048
    2012-02-05 joerg_wunsch Priority5 - Normal 3 - Low

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code