avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] [bug #30498] Add support for new avr devices (atmega32


From: jo
Subject: Re: [avrdude-dev] [bug #30498] Add support for new avr devices (atmega324pa)
Date: Fri, 19 Aug 2011 21:28:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11

Nice idea ! that would save even more space and work, as
- the atmegaxxP has only a different signature from the respective atmegaxx (in the case that I have seen). - it would also put together all variant of different size. (atmega48, atmega88, atmega168, atmega328 for instance)


Le 19/08/2011 14:49, David Ford a écrit :
i think the alias idea is good but i'd do it differently. a part is
derived from another part name. any additional configuration overrides
the original configuration. if there's no additional configuration, it's
exactly the same except as an aliased name. this is more of a class
extension concept rather than an alias. this has the potential to
significantly compact avrdude.conf as there are numerous chips which are
nearly identical except for a few differences. a chip family is defined
based on the most common properties, and each member is then derived
from that.

[part]
parent = [parent]
[configuration that adds, or replaces, information derived from the parent]

-d


On 08/19/11 06:16, Joerg Wunsch wrote:
[...]
My suggestion is to add an "alias" field to the config syntax, which by itself is threated as a list of aliases, and is also searched. That way, devices that 
are completely identical to other devices (including their signature) can be mentioned that way, like: part id = "m88p"; desc = "ATMEGA88P"; alias = 
"ATMEGA88PA", "ATMEGA88PV"; (In case someone would want to be diligent enough, we could add all the different suffix variants like "V" or 
"L" that way.) I don't think there's a point in adding more abbreviations (the "id" field) for the "A" devices: the abbreviation is only 
useful for humans to save some typing work, so it makes sense to keep them at the shortest string possible that will select a particular entry. Opinions?

_______________________________________________
avrdude-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avrdude-dev




reply via email to

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