Dragon: mega slow at dumping Flash, normal ?

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

> I do mean VERY slow. I timed it at a full minute for one single
> kilo byte of data from Flash.

IIRC, the Dragon ships with a terribly slow default ISP rate.  Bump
it, either using the "sck" command of the terminal mode in avrdude, or
with the -B option.  A good default value is 10 µs SCK period, this
is safely below the < 250 kHz requirement to handle AVRs shipping with
the 1 MHz RC oscillator.

For ISP, the SCK period value is "sticky" in the Dragon's EEPROM, so
it will default to the value used last time.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Sun, 28 Jun 2009 23:18:34 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> IIRC, the Dragon ships with a terribly slow default ISP rate.  Bump
> it, either using the "sck" command of the terminal mode in avrdude, or
> with the -B option.  A good default value is 10 µs SCK period, this
> is safely below the < 250 kHz requirement to handle AVRs shipping with
> the 1 MHz RC oscillator.
>
> For ISP, the SCK period value is "sticky" in the Dragon's EEPROM, so
> it will default to the value used last time.


Thanks Joerg. Unfortunately, neither option seem to have any effect on
the transfer speed of the Dragon. Target (ATmega32) runs at 16MHz, so
it's not a limiting factor. Well maybe my Dragon is defective...
mmpffff....


--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

> Or might this be a problem in the terminal mode of avrdude, rather
> than the Dragon ?

Sorry, I didn't read your message to the end at first.

Yes, the terminal mode uses one byte at a time transfers, it's
terribly slow.  It's really only intended for having a quick view into
a few bytes of memory.

Please use the -U options when you're interested in speed.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 00:19:17 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> Vincent Trouilliez <vincent.trouilliez@...> wrote:
>
> > Or might this be a problem in the terminal mode of avrdude, rather
> > than the Dragon ?
>
> Sorry, I didn't read your message to the end at first.
>
> Yes, the terminal mode uses one byte at a time transfers, it's
> terribly slow.  It's really only intended for having a quick view into
> a few bytes of memory.

Yeah but it's very fast with my crappy // port DIY cable ('bsd' style),
it's only when using my Dragon that somehow terminal mode becomes
super slow. That's why I am trying to find out if it's because of the
Dragon that's crap (sorry Atmel) or if the terminal mode somehow has
some bug that makes it slow with the Dragon, but fast with a DIY cable.
I still have not been able to figure out which of the Dragon or
avrdude, is at fault... so I can't take action ! ;-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-2]

On Mon, 29 Jun 2009, Vincent Trouilliez wrote:

> On Mon, 29 Jun 2009 00:19:17 +0200 (MET DST)
>
> j@... (Joerg Wunsch) wrote:
> > Vincent Trouilliez <vincent.trouilliez@...> wrote:
> > > Or might this be a problem in the terminal mode of avrdude,
> > > rather than the Dragon ?
> >
> > Sorry, I didn't read your message to the end at first.
> >
> > Yes, the terminal mode uses one byte at a time transfers, it's
> > terribly slow.  It's really only intended for having a quick view
> > into a few bytes of memory.
>
> Yeah but it's very fast with my crappy // port DIY cable ('bsd'
> style), it's only when using my Dragon that somehow terminal mode
> becomes super slow. That's why I am trying to find out if it's
> because of the Dragon that's crap (sorry Atmel) or if the terminal
> mode somehow has some bug that makes it slow with the Dragon, but
> fast with a DIY cable. I still have not been able to figure out which
> of the Dragon or avrdude, is at fault... so I can't take action ! ;-)

The Dragon is slow because there is a lot more protocol overhead, so 1
byte at a time transfers are very wasteful.

On the plus side since the Dragon is smart you can transfer big chunks
of data to it and it will do the rest at the speed you specify.

FWIW I use a Dragon (with FreeBSD) in ISP mode and I don't have speed
problems with -U for programming parts. Although I did have to adjust
the SCK rate at first.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[rew]

On Mon, Jun 29, 2009 at 11:07:12AM +0930, Daniel O'Connor wrote:

> > Yeah but it's very fast with my crappy // port DIY cable ('bsd'
> > style), it's only when using my Dragon that somehow terminal mode
> > becomes super slow. That's why I am trying to find out if it's
> > because of the Dragon that's crap (sorry Atmel) or if the terminal
> > mode somehow has some bug that makes it slow with the Dragon, but
> > fast with a DIY cable. I still have not been able to figure out which
> > of the Dragon or avrdude, is at fault... so I can't take action ! ;-)
>
> The Dragon is slow because there is a lot more protocol overhead, so 1
> byte at a time transfers are very wasteful.

The crappy DIY parallel cable requires a couple of IO instructions,
for every bit transferred. An IO instruction to a parallel port takes,
even on a modern computer, about a microsecond. So you'll get about 1
million divided by N bits per second of tranfer speed on your DIY
cable. N is the number of IO instructions required, two or three.

The way USB is built, you can only send or recieve stuff at 1kHz rate.
(i.e. there is a slot you can use (or not) every ms.) Thus if for
example you read a disk drive one block at a time, you'll get exactly
1000 blocks per second. (my measurements indicate somewhere between
999.9 and 1000.1 well within measurement errors)...

Anyway, if you have an USB device, and require some protocol overhead
for every byte, then you'll easily incur an "almost 1ms" delay for
everything you do. This could easily make some stuff 1000x slower than
the direct IO approach....

If the dragon is a serial device, sending a byte at 19k2 requires
about half a ms, and the same applies....

I have an AVR development board, and it can be programmed
out-of-the-box over the USB. However this is SLOW! it takes around 45
minutes to program the "you're an STK500 now" program in
there. Luckily I had to do this only once. :-) (except for debugging
the STK500 firmware).

This is due to the multiple 1ms delays that occur for every
bit. Optimizing my programming methods could be done, however this
isn't easily applied to the AVDUDE source: AVRDUDE assumes that it can
examine the resulting shifted-out bits immediately after sending a
byte. The way to optmize such programming through the FTDI232 chip is
to set the bitbang bitrate on the FTDI and just send it a block of
data. The FTDI can then send back the resulting bitstream. You can
achieve very high bitrates using this technique, but the returning
bits can only be sampled/checked after sending a whole block of data.

Anyway, I have my own STK500 now... :-)

        Roger.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** [phone] **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

Thanks Daniel and Roger !

I have now my anwser... even if not a pleasing one.

Geez, I bought a USB programmer and Dragon, thinking it would be way
faster than my antic // cable... only to find out it's exactly the
opposite ! How ironic, antic interfaces that smoke circles around modern
ones ! Likewise, me thinks the old serial port is unlikeley to die
anytime soon then...

Oh well, I will just put my Dragon in a drawer and use my // cable
again. I will just need to buy an extra // interface card for my
computer (because my printer is on the // port too, and I got tired of
swapping all the time, one of the reasons I wanted USB !), but I doubt
it will cost me more than this door stop of a dragon ! Hell no, even as
a door stop it's no use ! ;-/
Well, lesson learned... newer, shinier and more expensive is not always
better or even as good... far from that.

Thanks for the technical insight chaps, I know where to stand now...


Regards,

--
Vince, disappointed ? euphemism...


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[David Kelly]

On Jun 29, 2009, at 6:04 AM, Vincent Trouilliez wrote:

> Geez, I bought a USB programmer and Dragon, thinking it would be way
> faster than my antic // cable... only to find out it's exactly the
> opposite ! How ironic, antic interfaces that smoke circles around  
> modern
> ones ! Likewise, me thinks the old serial port is unlikeley to die
> anytime soon then...


You insist on programming in ISP mode, doesn't your AVR have JTAG  
mode? (Generally JTAG has to be enabled from ISP.)

Anyway, the device programs quickly in JTAG, thats the only mode I  
use once the part has been initialized.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.





_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 07:26:17 -0500
David Kelly <dkelly@...> wrote:

>
> On Jun 29, 2009, at 6:04 AM, Vincent Trouilliez wrote:
>
> > Geez, I bought a USB programmer and Dragon, thinking it would be way
> > faster than my antic // cable... only to find out it's exactly the
> > opposite ! How ironic, antic interfaces that smoke circles around  
> > modern
> > ones ! Likewise, me thinks the old serial port is unlikeley to die
> > anytime soon then...
>
>
> You insist on programming in ISP mode, doesn't your AVR have JTAG  
> mode? (Generally JTAG has to be enabled from ISP.)
>
> Anyway, the device programs quickly in JTAG, thats the only mode I  
> use once the part has been initialized.

Hi Dave,

I have already replied to this particular point in a previous message, scrollback ;-)

Wel okay, here it is for your convenience ;-)

http://lists.gnu.org/archive/html/avr-chat/2009-06/msg00020.html


Regards,

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-2]

On Mon, 29 Jun 2009, Vincent Trouilliez wrote:
> Thanks Daniel and Roger !
>
> I have now my anwser... even if not a pleasing one.
>
> Geez, I bought a USB programmer and Dragon, thinking it would be way
> faster than my antic // cable... only to find out it's exactly the
> opposite ! How ironic, antic interfaces that smoke circles around
> modern ones ! Likewise, me thinks the old serial port is unlikeley to
> die anytime soon then...

If you use it the right way it IS faster.

USB, like PCIe and other busses is a high latency high throughput thing.

FIFO memory is cheap and allows faster performance with less
synchronisation which is good when you have a lot of cores :)

> Oh well, I will just put my Dragon in a drawer and use my // cable
> again. I will just need to buy an extra // interface card for my
> computer (because my printer is on the // port too, and I got tired
> of swapping all the time, one of the reasons I wanted USB !), but I
> doubt it will cost me more than this door stop of a dragon ! Hell no,
> even as a door stop it's no use ! ;-/
> Well, lesson learned... newer, shinier and more expensive is not
> always better or even as good... far from that.

I don't understand why you don't use -U?
It is just as fast as the old parallel cable I use but saves a bunch of
CPU time (not that it is a big issue). I am using it in ISP mode, I
have used it in JTAG mode too, but most recently I was updating
firmware on a board which didn't have JTAG, it worked just fine.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 22:38:45 +0930
"Daniel O'Connor" <darius@...> wrote:

> I don't understand why you don't use -U?

Because it's hardly as convenient as the terminal mode !
I am not a masochist... if -U was better in my use case, than the
terminal, I would use it of course ! ;-)

This terminal mode is a really cool feature of avrdude, I just love it,
hence why I am both surprised and annoyed that my switch from // to USB
had a negative impact in this dept. !

However now I think of it, it's not unfixable, there is hope, I will
file a bug report in avrdude about that... things can be improved,
there is no fatality I think.


--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-2]

On Mon, 29 Jun 2009, Vincent Trouilliez wrote:

> On Mon, 29 Jun 2009 22:38:45 +0930
>
> "Daniel O'Connor" <darius@...> wrote:
> > I don't understand why you don't use -U?
>
> Because it's hardly as convenient as the terminal mode !
> I am not a masochist... if -U was better in my use case, than the
> terminal, I would use it of course ! ;-)
>
> This terminal mode is a really cool feature of avrdude, I just love
> it, hence why I am both surprised and annoyed that my switch from //
> to USB had a negative impact in this dept. !
>
> However now I think of it, it's not unfixable, there is hope, I will
> file a bug report in avrdude about that... things can be improved,
> there is no fatality I think.

Mostly I just do 'make prog' which runs avrdude -U ...

Terminal mode can be useful for some things but I usually only use it to
change fuses or check my code has modified EEPROM as I expect.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 23:40:31 +0930
"Daniel O'Connor" <darius@...> wrote:

> Terminal mode can be useful for some things but I usually only use it to
> change fuses or check my code has modified EEPROM as I expect.

Same here, but I also like to have a look at the first KB's of Flash as
well. I found it helpful to trouble shoot string problems, or to verify
padding, or to check that my approximate knowledge of C's syntax did
put the right address in a table of function pointers, or whatever... I
just find it quite nice to be able to easily have a quick look at the
first KB's of Flash, in a formatted way, while having also access to
EEPROM and fuses and everyting, all from the same place. IOW... I just
looove this terminal feature of avrdude hence my desire for it,
generally, to become as good as it can get ;-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

> Same here, but I also like to have a look at the first KB's of Flash
> as well.

If you instead look at the hex dump of the .bin file, you'll be much
faster. ;-) If you program the device using the -U option, it will by
default add a verify run, so afterwards, you can be reasonably sure
the contents of your .bin file matches the contents of your flash.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 20:08:31 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> If you instead look at the hex dump of the .bin file, you'll be much
> faster. ;-)

Mmpf... my make file doesn't create that file it seems. Only hex I have
is the object file that goes into the AVR...
How do you create this hex dump automatically from the makefile, when compiling ?
And most importantly... is it actually formatted like the terminal mode
in avrdude ? That is, hex address at the left of each line, then 2
groups of 8 bytes, then the ASCII conversion in the last column ?

0000  0c 94 d4 07 0c 94 3f 15  0c 94 f1 07 0c 94 f1 07 | ... .?. ... ...|
0010  0c 94 f1 07 0c 94 f1 07  0c 94 f1 07 0c 94 2d 08 | ... ... ... .-.|
0020  0c 94 f1 07 0c 94 f1 07  0c 94 f1 07 0c 94 f1 07 | ... ... ... ...|
0030  0c 94 f1 07 0c 94 82 14  0c 94 f1 07 0c 94 e9 13 | ... ... ... ...|

Regards,

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Bill Gatliff]

Vincent Trouilliez wrote:
>
>> If you instead look at the hex dump of the .bin file, you'll be much
>> faster. ;-)
>>    
>
>  


Oh, I forgot to ask... is it "mega" slow, or "mibi" slow?  :)


/me ducks


b.g.

--
Bill Gatliff
bgat@...




_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 13:34:16 -0500
Bill Gatliff <bgat@...> wrote:

> Oh, I forgot to ask... is it "mega" slow, or "mibi" slow?  :)


Oh don't get me started on this subject !
I just read a full two page article yesterday on this subject, in my
Electronic mag (Elektor) ! :-O

This is silly... especialy more since there are TWO conventions: an
international one and a French one. So if I use the French one I will
be correct, but will nonetheless confuse the rest of the world even more
than they already are.

I won't use Ki/Mi/Ti just because it looks and sounds horrible to my
ears and eyes, and because I never found that people were *that*
confused by the old system. It was clear to technical people for which
it mattered, and confusing to non-technical people but the latter kind
don't really need to know anyway. With this new system, it will be even
less clear to non-technical people, but more of a problem, it will
start to become unclear to even the techies too ! :-/

I say go back to the old units and prefixes, the new system's solution
is worse than the problem it tried to solve, IMHO of course ;-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

Vincent Trouilliez <vincent.trouilliez@...> wrote:

>> If you instead look at the hex dump of the .bin file, you'll be
>> much faster. ;-)

> Mmpf... my make file doesn't create that file it seems.

Than make a makefile that does it. ;-)

All you have to do is replacing the -O ihex by -O binary in the
avr-objcopy command.

> How do you create this hex dump automatically from the makefile,
> when compiling ?

I don't.

> And most importantly... is it actually formatted like the terminal
> mode in avrdude ?

That's the "classical" layout for a hexdump, I'd say.  That would
be an example:

% hd lcmeter.bin | head -20
00000000  0c 94 04 01 0c 94 2d 01  0c 94 2d 01 0c 94 67 01  |......-...-...g.|
00000010  0c 94 2d 01 0c 94 2d 01  0c 94 2d 01 0c 94 2d 01  |..-...-...-...-.|
00000020  0c 94 2d 01 0c 94 2d 01  0c 94 2d 01 0c 94 43 01  |..-...-...-...C.|
00000030  0c 94 2d 01 0c 94 2d 01  0c 94 2d 01 0c 94 2d 01  |..-...-...-...-.|
00000040  0c 94 2d 01 0c 94 2d 01  0c 94 f3 01 0c 94 2d 01  |..-...-...ó...-.|
00000050  0c 94 2d 01 0c 94 2d 01  0c 94 2d 01 0c 94 2d 01  |..-...-...-...-.|
00000060  0c 94 8e 01 0c 94 2d 01  0c 94 2d 01 0c 94 2d 01  |......-...-...-.|
00000070  0c 94 2d 01 0c 94 2d 01  0c 94 2d 01 0f 08 18 18  |..-...-...-.....|
00000080  18 08 0f 00 0f 08 1b 1b  1b 08 0f 00 1f 00 00 00  |................|
00000090  00 00 1f 00 1f 00 03 03  03 00 1f 00 1f 00 1f 1f  |................|
000000a0  1f 00 1f 00 1f 01 1d 1d  1d 01 1f 00 1f 01 01 01  |................|
000000b0  01 01 1f 00 02 05 05 06  00 01 05 05 06 00 01 04  |................|
000000c0  05 06 00 01 03 05 06 00  01 03 04 06 00 01 03 03  |................|
000000d0  06 00 01 03 03 07 00 20  20 20 20 20 20 20 4c 43  |.......       LC|
000000e0  20 4d 65 74 65 72 00 20  20 20 20 20 20 20 20 44  | Meter.        D|
000000f0  4c 38 44 54 4c 00 43 61  6c 69 62 72 61 74 69 6e  |L8DTL.Calibratin|
00000100  67 2e 2e 2e 00 6e 61 6e  00 69 6e 66 00 00 40 7a  |g....nan.inf..@z|
00000110  10 f3 5a 00 a0 72 4e 18  09 00 10 a5 d4 e8 00 00  |.óZ. rN....¥Ôè..|
00000120  e8 76 48 17 00 00 e4 0b  54 02 00 00 ca 9a 3b 00  |èvH...ä.T...Ê.;.|
00000130  00 00 e1 f5 05 00 00 80  96 98 00 00 00 40 42 0f  |..áõ.........@B.|

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Vincent Trouilliez]

On Mon, 29 Jun 2009 21:37:53 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> Than make a makefile that does it. ;-)
>
> All you have to do is replacing the -O ihex by -O binary in the
> avr-objcopy command.

Oh, simple enough indeed ! :-)

> % hd lcmeter.bin | head -20

Oh ! I didn't know there were a utility specialized in this ! That's one
of the things I just love in *nix... a myriad of innocent looking, 2+
letter commands that can do lots of cool/useful things, and that
can be combined at will ! :-)

I added an option in my makefile now:

hd:
        hd object_flash.bin | less

now I just need to type "make hd", quick enough to type, and I
instantly can navigate the hex dump with the PageUP/PageDown keys,
lovely ! :-)

Thanks Joerg :-)

--
Vince


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-2]

On Tue, 30 Jun 2009, Vincent Trouilliez wrote:

> On Mon, 29 Jun 2009 23:40:31 +0930
>
> "Daniel O'Connor" <darius@...> wrote:
> > Terminal mode can be useful for some things but I usually only use
> > it to change fuses or check my code has modified EEPROM as I
> > expect.
>
> Same here, but I also like to have a look at the first KB's of Flash
> as well. I found it helpful to trouble shoot string problems, or to
> verify padding, or to check that my approximate knowledge of C's
> syntax did put the right address in a table of function pointers, or
> whatever... I just find it quite nice to be able to easily have a
> quick look at the first KB's of Flash, in a formatted way, while
> having also access to EEPROM and fuses and everyting, all from the
> same place. IOW... I just looove this terminal feature of avrdude
> hence my desire for it, generally, to become as good as it can get
> ;-)

I think you'll find objdump on your resulting binary much, much
faster :)

I have the following makefile rules too (BSD make though)..

CPPFLAGS+=-Wa,-adhlmsn=${<:T:S/.c/.lst/}
LDFLAGS+=-Wl,-Map=${PROG}.map,--cref

.elf.dmp:
        ${OBJDUMP} -S ${.IMPSRC} > ${.PREFIX}.dmp

This gives you a lot of information about how the compiler has decide to
build your code.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat