avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Butterfly (was: Before a release...)


From: Jan-Hinnerk Reichert
Subject: Re: [avrdude-dev] Butterfly (was: Before a release...)
Date: Fri, 28 Nov 2003 00:35:10 +0100
User-agent: KMail/1.5.1

On Thursday 27 November 2003 23:29, Michael Mayer wrote:
> On Thu, Nov 27, 2003 at 22:40:42 +0100, Jan-Hinnerk Reichert wrote:
> > On Thursday 27 November 2003 18:04, Michael Mayer wrote:
> > > On Thu, Nov 20, 2003 at 19:37:08 +0100, Jan-Hinnerk Reichert

> > Most of the duplicated functions are empty anyway. Perhaps we
> > should change the default-functions in "pgm.c". So, that
> > non-critical functions - like setting a LED - don't return an
> > error, if they are undefined
>
> This would be a nice thing to do. It would simplify both, avr910.c
> and butterfly.c.

Has anyone else an opinion on this?

> > > Or the 'v'-command: A real avr910 is expected to return a two
> > > byte string showing the hardware version. The butterfly doesn't
> > > implement this command and just returns a single '?'.
> >
> > This could change in a future version of the Butterfly-firmware.
> > So the "b" still seems the best way, if one wants autodetection.
>
> Yes, you are really paranoid ;-)

Just a little bit ;-)
Seriously, it is commented out in the code, IIRC. So, I think it is 
not there, because it hasn't fitted in the bootloader section. This 
just gives me a bad feeling.
BTW: Sourcecode produced by Atmel almost always makes me feel that way 
;-((

> > Also, testing changes is easier, if they only
> > affect one programmer (especially, if you have no access to the
> > other one ;)
>
> True. A big plus for the new type.

I will probably look into some avr910-cleanup soon, but right now I 
feel that the *global* cleanups are giving a greater benefit.

> I will start working on a new version.

Keep in mind that I will move some functions around at the start of 
next week. However, I believe that "avr910.c" and other programmer 
specific files will not be effected by this ;-)

For more details look at the "avrpart.c"-thread.

/Jan-Hinnerk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]