Re: [Simulavr-devel] [patch #6780] Automatic AVR device generation

[Onno Kortmann]

Hi,
> > To use:
> > It is not yet integrated into the built system, before compiling but after
> > placing the .xmls into the directory .../src/fab/atmel-xml call the
> > 'avr-fab.py' script.
> >
> >   
> How is it invoked and used?
Just apply the patch (and those before), install python-cheetah (thats the 
package name
at least on debian), put the .XML files from a WINE
installation of AvrStudio (those in the PartsDescriptionfiles folder) into the
folder .../src/fab/atmel-xml and then do a "avr-fab.py". This should generate
the tiny2313 and the tiny15 model in the ...src/ directory.

> Would you use it as part of a regular build or something you
> did as a beginning step of writing support for a new CPU model?
Well, I did it to make functional yet incomplete models of the tiny2313 and the 
tiny15l.
And I thought that having at least some of the commonalities factored out
in a template would already help a bit in making new AVR device classes faster 
:-)

> My only technical comment is that it needs CVS Id strings in
> the source and generated files. :)
Yes, I can do that. As I'm working with git here (and using git-cvsimport to 
connect to the CVS),
I'm not used to $Id$s any more.

> In general are you thinking of the code generated aggregating
> tailoring existing subcomponents like cpu core, timer, etc?
Yes, exactly. I glimpsed at the datasheets and thought that the existing timer 
models
(and the other things) should match for the two test/example models. I left out 
the other
stuff as I was quite unsure whether it matches or not.

I think that incomplete devices models are ok as long as the parts which are 
implemented are
believed to be right - if one accesses unimplemented parts, one gets an error 
log message
and I think this should be enough to notify people that some things do not work 
yet.

I would go even as far as to suggest that even if all esoteric differences of 
subcomponents
between various models are not known, it would be helpful to have autogenerated 
models of
most AVR parts. (I don't care so much whether my approach would be used or 
something 
based on xmlstar or whatever, as long as we get more devices)

Those parts/subcomponents of parts which are thoroughly tested (preferably, of 
course, 
in an automated test using some real AVR code) could then be marked as 'stable' 
and the 
others as 'unstable/incomplete'. I also think that the existing models should
still be marked as partly incomplete (for example, the input capture in the 
timer was/is missing).

What do you/the others think?

Best regards,

Onno