avr-libc-dev
[Top][All Lists]
Advanced

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

RE: [avr-libc-dev] RFD: more avr-libc API changes


From: Darcy Watkins
Subject: RE: [avr-libc-dev] RFD: more avr-libc API changes
Date: Mon, 12 Sep 2005 09:16:49 -0700

Hi,

Attached (in zip archive) is a generated include file from my experimental
parser that I have used for some experiments using the new ATmega2561 on an
old STK300 board.

My experimental parser utility uses the PUG XML parser I found at
thecodeproject.com.  Right now, I am compiling as a console program using
VC++ 7.2 but the notes with the parser source suggest that it shouldn't be
too difficult to port it to GCC.  Then we could have it available in Windows
and Linux.

I couldn't find the Python program you mentioned in either the WinAVR
distribution or in the avr-libc source package so I can't comment on using
or updating that one instead.

In its current form, the attached include file is equivalent to avr/io.h and
the avrXXX.h file.  For now, you include this file instead of avr/io.h.  And
for the ATmega2561, you lie to GCC telling it that you are using an
ATmega128 (and then make use of several hacks and tricks to bypass the
startup code, etc).

Apart from license comments and stuff at the top and bottom of the file,
most of the comment text is straight from description entities in the XML
file.

You will also see I incorporated some of the ideas being tossed around for
interrupt names (i.e. using ISR_ prefix instead of SIGNAL_ prefix).

Still one minor glitch.  If the XML defines the register (or bit definition)
more than once, it gets defined as a macro more than once (you will see
warnings as you compile target code).  To get past this, I will need to
build a symbol table and check it to avoid generating a duplicate macro.  If
it is a duplicate, instead of defining the macro again, just generate a
comment mentioning it has already been defined earlier.

If this utility scheme has merit, we could have a makefile rule that
generates the part description include file per project and then deprecate a
whole lot of part specific include files.  avr/io.h could be modified to
include the generated file by default, or include deprecated part files if a
special macro is defined in the makefile to be passed during the compile
process.  That places control of upgrading in the hands of the developer.



Regards,

Darcy

--------------------------------------------------------------
Darcy L. Watkins             email: address@hidden
Senior Software Developer++  phone: (604) 455-2000
TASC Systems, Inc.           fax:   (604) 888-2712
9415 - 202 Street,           web:   http://www.tascsystems.com
Langley B.C. Canada V1M 4B5
--------------------------------------------------------------



-----Original Message-----
From: address@hidden
[mailto:address@hidden
Behalf Of Rolf Ebert
Sent: Saturday, September 10, 2005 11:38 AM
To: Joerg Wunsch; address@hidden
Subject: Re: [avr-libc-dev] RFD: more avr-libc API changes


>> I did some more work on an experimetal utility to parse the part
>> description XML files from AVRStudio into device specific include
>> files.
>
> Umm, but you know that Atmel already ships such a utility as part of
> AVR Studio, do you?
>
> Unfortunately, it's Windows-only, and as it apparently uses
> Microsoft's XML library, it cannot even be made run easily under the
> Wine emulator.  But it can generate the skeleton of GCC/avr-libc
> header files.

There is no need to tell Jörg, but others have perhaps overlooked the
Python parser Atmel2libc.py in avr-libc/xml.

We use a modified version of that script (Atmel2avrada.py) in AVR-Ada
quite successfully to generate Ada's equivalent of the avr/io*.h files.

     Rolf


_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Attachment: gen_h_file.zip
Description: Zip compressed data


reply via email to

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