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


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

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

Submitted by:  Roger Wolff <rewolff>
Submitted on:  Sun Feb 5 21:16:37 2012  
Category: NoneSeverity: 3 - Normal
Priority: 3 - LowItem Group: None
Status: Ready For TestPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: me: rewolff
Open/Closed: OpenRelease: None
Programmer hardware: Device type: 

(Jump to the original submission Jump to the original submission)

Fri Sep 13 09:44:12 2013, 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>
Project AdministratorIn charge of this item.
Fri Sep 13 09:22:48 2013, 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 .5completion-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 Sep 13 09:06:53 2013, 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.


Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sun Feb 12 12:33:58 2012, 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 Feb 6 07:13:13 2012, 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 Feb 5 22:18:32 2012, 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>
Project AdministratorIn charge of this item.
Sun Feb 5 21:16:37 2012, 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>


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


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Sep 13 09:44:12 2013joerg_wunschStatusIn Progress=>Ready For Test
      Assigned toNone=>joerg_wunsch
    Fri Sep 13 09:06:53 2013joerg_wunschStatusNone=>In Progress
    Sun Feb 12 12:33:58 2012rewolffAttached File-=>Added bla.hex, #25048
    Sun Feb 5 22:18:32 2012joerg_wunschPriority5 - Normal=>3 - Low

    Back to the top

    Powered by Savane 3.1-cleanup