Hi, So I'm back from travel, I'll be looking into those thing shortly.
As for notifying Atmel of mistake/errors/inconsistencies in XML files I thing it will be harder than what you make it sound like. Using the librairy, we load the XML in ram as an object tree. When I walk the tree, I can find errors but I cannot relate back to the XML line. Also, I'm not sure what should be flaged as an error. It seems to me that there is 2-3 different pattern that they follow for pin description. Are they all right? In AVR Studio XML parser, they for sure run into the same problem that I do. I'll update the header soon this week. Frederic 2009/4/1 Weddington, Eric <[email protected]>: > > >> -----Original Message----- >> From: >> [email protected] >> [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. >> org] On Behalf Of Frédéric Nadeau >> Sent: Tuesday, March 31, 2009 3:59 PM >> To: [email protected] >> Subject: Re: [avr-libc-dev] Re: [bug #25300] Additional i/o port names >> >> 2009/3/31 Weddington, Eric <[email protected]>: >> > Ideally, we need both: we need to fix the patch to the >> header files so that the definitions are in uppercase, but we >> need to generate a list of what was wrong with the XML files >> to give to Atmel. >> > >> >> Making the script to generate all in upper case is a piece of cake. >> However having the script to report all the error is more or less >> complicated. I'll see what I can do about that > > Something else I just found out: > I was testing my generator script with the ATmega6490 and it reported back > that there was duplicate definitions with the new pin definitions: > > #define SEG33_DDR DDRJ > #define SEG33_PORT PORTJ > #define SEG33_PIN PINJ > #define SEG33_BIT 1 > > #define SEG33_DDR DDRG > #define SEG33_PORT PORTG > #define SEG33_PIN PING > #define SEG33_BIT 3 > > I checked and it seems that the XML file is incorrect. :-P > > This duplicated data is in your patch too, unfortunately. > > So when you generate the new definitions, you'll need to check to make sure > that there are no duplicate definitions. If there are, you'll have to verify > which one is correct and probably fix the header by hand. > > Eric Weddington > _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
