WinAVR

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Bernard Fouché
Joerg Wunsch wrote:

> Nope, avrdude.conf contains quite a bit other stuff, in particular the
>
>definition of the various programming adapter layouts.  Also, I think the
>XML files don't have the actual ISP commands used as this knowledge is
>not required for AVR Studio.
>
>  
>
If you look at 'AVR068: STK500 Communication Protocol', you'll see on
page one:

"All device specific values can be found in the xml files for each part.
The xml files
are distributed with AvrStudio 4.11 or later. Download the latest AVR
Studio 4.X
from the Atmel web site, http://www.atmel.com/products/AVR/. The xml
file format
is described in section 6."

And I had to look at these xml files to find what was the command to
send to have
the write routine of 'v2' to work for eeprom since 'AVR068' refers to
symbolic
names for command values, these symbolic names being resolved in the xml
files.

If Atmel is acting this way, then an external tool that process their
xml files to update
particular sections of  avrdude.conf and write an updated file would be
fine. (and
have 'v2' getting command values from avrdude.conf and not hard written in
the functions)

  Bernard


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Joerg Wunsch
As Bernard Fouché wrote:

> >...  Also, I think the
> >XML files don't have the actual ISP commands used as this knowledge is
> >not required for AVR Studio.

> If you look at 'AVR068: STK500 Communication Protocol', you'll see
> on page one:

Sure, for the STK500 protocols, everything is supposed to be there.
But for manually bit-banging your ISP programmer, the information is
completely missing.

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

E. Weddington
In reply to this post by Bernard Fouché
Bernard Fouch? wrote:

> E. Weddington wrote:
>
>> And a big thanks to you and your colleagues for using v2 so much and
>> testing out all the functionality!
>>
>> Eric
>>
> Well, we just had to work you know :-) and it took less time to
> understand what was going wrong in v2
> than looking for ways to downgrade a bunch of stk500 and avrisp we
> just received, because avrdude is
> very well designed and it is very easy to fiddle with it.
>
> Now it would be nice to have avrdude to be able to process the  XML
> definition files in
> Atmel\AVR Tools\Partdescriptionfiles\ that avrstudio4 now provides.
>
> These files could also replace avrdude.conf file format, if ever one
> can reproduce these XML files without
> copyright problems from Atmel. That would allow avrdude to be
> completely synchronised with Atmel
> delivery of new targets and their particular settings. For instance,
> for v2, the value of the commands to
> send to the ISP are defined in these files and so one can expect that
> v2 needs a particular command
> value for target A and another for target B to do the same job.
>
> Maybe it's alreay the case, I did not look in details at all the XML
> files, I just focused on atmega64 &
> 128, my usual targets.

This has been discussed before and I would certainly welcome such a
change. For the moment, I wouldn't worry about the copyright issue;
Joerg and I can start asking around to see what it would take to remove
that restriction.

>
> From these files one should be also able to produce avrdude.conf but
> also "include/avr/io*.h" files.
>
> So maybe an external tool would be better to parse Atmel XML files and
> then produce io*.h files
> for avr-libc and avrdude.conf for avrdude.

Take a look at the avr-libc project. IIRC, there are some python-based
tools. I can't remember if one of them was supposed to do just that.

Eric


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

E. Weddington
In reply to this post by Joerg Wunsch
Joerg Wunsch wrote:

>As Bernard Fouch? wrote:
>
>  
>
>>Now it would be nice to have avrdude to be able to process the XML
>>definition files in Atmel\AVR Tools\Partdescriptionfiles\ that
>>avrstudio4 now provides.
>>    
>>
>
>Alas, Atmel considers these files ``Intellectual Property'' and thus
>forbids redistribution outside of AVR Studio.  I've already tried to
>get them opening their policy, but as this touches company lawyers and
>such, this policy is probably not going to change quickly.
>  
>

Oh, bother....

>  
>
>>These files could also replace avrdude.conf file format, ...
>>    
>>
>
>Nope, avrdude.conf contains quite a bit other stuff, in particular the
>definition of the various programming adapter layouts.  Also, I think the
>XML files don't have the actual ISP commands used as this knowledge is
>not required for AVR Studio.
>
>  
>

Well, another solution would be to do an XML-to-XML conversion, then
adding the info we need. I know of a command line tool that would work
for the conversion.

Eric


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Bernard Fouché
In reply to this post by Brian Dean
Brian Dean wrote:

> Note that I did not see any improvement in programming time, however.
>
>My simple test with a 20K program file using an AVRISP reporting
>itself as firmware revision 2.1 takes 55 seconds to program.  If I
>recall, this is about 3 times as long as the Version 1 protocol.
>
>  
>
I've just flashed an atmega64 with a 51602 bytes flash file + 2k eeprom
+ set the fuses.
Everything was wrote/verified. I use the linux 'time' command and got:

real 0m43.811s
user 0m0.073
sys 0m0.290s

I wonder if, when upgrading an isp or stk500 from v1 to v2, the upgrade
software puts
the internal clock to a very low speed. Also I've noticed on v1 that if
cable that runs from
the isp to the target is in a bad condition, then the transfert to the
target would slow.

  Bernard


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Joerg Wunsch
In reply to this post by Joerg Wunsch
As Joerg Wunsch wrote:

> I've got still one STK500 with a 1.x firmware around, so I could
> compare them.

Read times (according to avrdude's progress bar + time display) to
read a full ATmega128:

stk500[v1]    41 s
stk500v2      15 s
jtag2fast     25 s
jtag2/USB     13 s

The first three measurements have been run across the same serial
line, the fourth is only included for comparision.

It's interesting that the JTAG code (that uses larger block reads for
the actual packet payload) is slower than the STK500v2 code (that uses
single-byte reads).

I think I'd rather rename "jtag2" (the one with the ICE's default
speed of 19200 Bd) into "jtag2slow", and "jtag2fast" into "jtag2", so
people will by default use the 115200 Bd connection.

Btw., the latest code causes a lot of singnedness warnings here.

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Brian Dean
On Mon, Aug 29, 2005 at 11:05:04PM +0200, Joerg Wunsch wrote:

> Read times (according to avrdude's progress bar + time display) to
> read a full ATmega128:
>
> stk500[v1]    41 s
> stk500v2      15 s
> jtag2fast     25 s
> jtag2/USB     13 s

Hmmm, wonder what's wrong with my setup?  Here's what I get:

         Programmer Type : STK500V2
         Description     : Atmel STK500 V2
         Hardware Version: 15
         Firmware Version: 2.1
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 5.0 V
         Oscillator      : 3.686 MHz
         SCK period      : 10.9 us

...

avrdude: reading flash memory:

Reading | ################################################## | 100% 332.91s

Over 5 and a half minutes to do the same thing yours does in 15
seconds.

It should be noted that this is an "AVRISP" I am using, not an STK500.
Also, I did not update the firmware on this device, it came installed
with Rev 2.1 from Digi-Key where I recently bought it.

Even under the V1 protocol, a real STK500 is faster than an AVRISP,
though.  Is it possible that the AVRISP just very slow under V2?  I
hope there is another explanation - as Bernard suggested perhaps my
oscillator is not set correctly or something.  Do the above hardware
settings look right?  What do yours show, Joerg?  Bernard?

Note that I did check two seperate systems - first on my MacOS X using
a USB->RS232 dongle, and second on my FreeBSD 5.4 system using the
motherboard serial port and the timing is nearly identical, so I think
we can eliminate the host system as the problem.

OK, well, feeling a little dangerous, I just set the SCK period down
to 1.1 us - the fastest allowed, and that dropped the read time down
to 27 seconds - much more appetizing.  Is it safe to do this?  I did
do a program and verify and it checked out OK.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Galen Seitz
Brian Dean <[hidden email]> wrote:

>
> OK, well, feeling a little dangerous, I just set the SCK period down
> to 1.1 us - the fastest allowed, and that dropped the read time down
> to 27 seconds - much more appetizing.  Is it safe to do this?  I did
> do a program and verify and it checked out OK.
>

As long as the internal clock frequency of the target AVR is greater or
equal to four times the SCK frequency, I think you should be okay.  I
ran into SCK frequency problems on my initial programming attempts with
the mega48.  The internal oscillator of the mega48 runs at 8 MHz, but the
clk divide by 8 fuse defaults to on.  Thus I have to set the SCK period
to >= 4 us for unprogrammed parts.

galen



_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Brian Dean
In reply to this post by Joerg Wunsch
On Mon, Aug 29, 2005 at 11:05:04PM +0200, Joerg Wunsch wrote:

> Btw., the latest code causes a lot of singnedness warnings here.

These have been bugging me too.  I think it is GCC 4.x - must be a new
warning that complains about passing unsigned char * when char * is
expected, and vice versa.  I've cleaned all these up and a few others.

Should build clean now.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Joerg Wunsch
As Brian Dean wrote:

> > Btw., the latest code causes a lot of singnedness warnings here.

> These have been bugging me too.  I think it is GCC 4.x - ...

For me, it eventually happened with GCC 3.4.x.

> must be a new warning that complains about passing unsigned char *
> when char * is expected, and vice versa.  I've cleaned all these up
> and a few others.

Thanks.  There was a couple of outstanding in usb_libusb.c, which I've
cleaned up.  I also took the liberty to add your ChangeLog entry for
that. ;-)

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Joerg Wunsch
In reply to this post by Brian Dean
As Brian Dean wrote:

> Even under the V1 protocol, a real STK500 is faster than an AVRISP,
> though.

Oh, I didn't have an AVRISP with v1 firmware left for verification.
I'm surprised they behave that differently, I thought the AVRISP is
nothing else but the programming circuitry of the STK500.

> Do the above hardware settings look right?  What do yours show,
> Joerg?  Bernard?

Sorry, I forgot to mention that I've been using the 1.1 µs SCK clock
for all measurements.

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: WinAVR

Bernard Fouché
In reply to this post by Joerg Wunsch
Joerg Wunsch wrote:

>stk500[v1]    41 s
>stk500v2      15 s
>jtag2fast     25 s
>jtag2/USB     13 s
>
>The first three measurements have been run across the same serial
>line, the fourth is only included for comparision.
>
>It's interesting that the JTAG code (that uses larger block reads for
>the actual packet payload) is slower than the STK500v2 code (that uses
>single-byte reads).
>  
>
The time took by the application and the system calls is nearly
non-existent (see my previous email
done with time(1): use+sys were very low, that's normal with the high
speed cpu we now have for
years).

Nearly all the time is spent waiting for the serial com so it is
essential to look at all the possible
ways to remove any unneeded serial traffic, especially when there is an
send/expect behavior.

For stk500v2 avrdude now  tries to send the lowest number of
'positionning' packets (you have to
position a pointer in the ISP before reading or writing a page of bytes)
instead of setting the
pointer before writing each pages, or never setting it.

When looking at the code for stk500v1, the pointer is positionned each
time before each page write
and if one looks at stk500_loadaddr(), setting the read/write pointer
means sending bytes to the ISP
and then waiting to receive an answer. That could slow the whole process
a lot but I dunno if this
is mandatory for the v1 protocol, or if, like v2, the pointer moves up
automatically after each page
read or page write. If so, we can earn some time here by removing
unneeded positionning traffic.

Maybe some other protocols could also be optimized by looking how they
are implemented and
try to have the lowest possible serial traffic?

  Bernard


_______________________________________________
avrdude-dev mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
12