Re: [avrdude-dev] device signature string

[Brian Dean]

On Fri, Dec 12, 2003 at 07:24:56PM +0100, Michael Mayer wrote:

> Right now, the autodetection hack is just a private
> proof-of-concept. I don't send a patch right now because I feel
> these structural changes have to be discussed first (if you are
> interested to include this functionality) What do you think about
> this topic?

I kind've like the idea of auto detection, where applicable.  The
STK500 is kind've special since you need to know certain part
parameters to send to the STK500 before you can actually even enter
programming mode in order to read the signature bytes.  However, it
may be possible to tell the STK500 the part is any old chip, simply
for the purposes of reading the signature bytes, then re-initialize
the STK500 session using the actual part that we queried.

About your implementation - I don't know any details about how you
implemented it, and maybe you already did this, but I would suggest a
new field in the AVR part structure that is a linked list of possible
signature values.  While in general, parts have only 1 possible
signature value, I've seen several data sheets that have eratta
stating that parts made before such and such a date have a different
signature value than parts after that date.  Thus, we need to support
a "list of signatures", that the current signature is compared
against.

The lists.c / lists.h module already makes creating linked lists of
any data type very easy - you've probably already seen their use with
the list of parts, etc, list of memory types within each part, etc.

In fact, it might make certain operations easier if you make the
actual "signature" elements themselves simply be an instance of an
AVRMEM structure.  I haven't looked too deeply into that, so that is
just a starting suggesting.

The YACC grammer for handling a list of values is also pretty trivial.
If you are not sure about that, let me know and I can send an example
of what to do to handle that.

Thanks!
-Brian