RE: [avr-libc-dev] [RFC] Suggestion on how to rapidly implement supportfor atmega2560-2561

[Darcy Watkins]

Hi,

OK I guess I'll need some feedback on the file.  I attached it to a post last 
week (Mon 9/12/2005 9:17 AM - Subject: RE: [avr-libc-dev] RFD: more avr-libc 
API changes).  If anyone needs it again, I can post it again, otherwise I am 
assuming that it is preferred by the list to minimize unnecessary use of 
attachments.

Below are a few chunks of the generated code.  First some vector definitions.  
Note that this is trying out the "ISR_" macro scheme some of you talked about.  
It can just as easily be SIGNAL.  One problem so far is that many of the 
interrupt/signal names are different from before.  We will need a backwards 
compatibility provision - but I think that it would only need to support legacy 
signal names (i.e. only use new names for timers 4 and 5 and USART 2 and 3, 
etc).

Note the redundant macros.  The first macro is intended to preserve the vector 
info even if the second macro is ever redefined.  It makes more sense in the 
I/O module sections later.  For ISR vectors, I couldn't embed the first macro 
inside the second one because the token pasting doesn't substitute the first 
macro with its value before token pasting it while expanding the second macro.  
Someone please refresh my memory if there is a trick available to get around 
this.  It has been a while since I used macros this way.  It works fine in the 
I/O modules section because there is no token pasting involved.


// External Interrupt Request 0
#define _VECTOR_INT0    1
#define ISR_INT0        _VECTOR(1)

// External Interrupt Request 1
#define _VECTOR_INT1    2
#define ISR_INT1        _VECTOR(2)

....

// Timer/Counter3 Overflow
#define _VECTOR_TIMER3_OVF      35
#define ISR_TIMER3_OVF  _VECTOR(35)

// USART1, Rx Complete
#define _VECTOR_USART1_RX       36
#define ISR_USART1_RX   _VECTOR(36)

....


Now with the I/O modules, the "_ADDR_" macro preserves the address in case a 
downstream include file ever needs to undefine and then redefine the main 
register definition macro using the same address.  Note that it is also handy 
for autogenerating the word register macros.

In the existing header files, the I/O module registers are defined, then all 
the bit definitions.  My parser groups the definitions associated with an I/O 
module.  I hope this is ok.  I think it redefines a macro more than once in 
some cases, but I plan to add provision in the utility to prevent duplicate 
macro definitions by commenting them out.

////////////////////////////////////////////////////////////////////////
// I/O Module: ANALOG_COMPARATOR

// ADC Control and Status Register B
#define _ADDR_ADCSRB    123
#define ADCSRB  _SFR_MEM8(_ADDR_ADCSRB)

#define ACME    6       // Analog Comparator Multiplexer Enable

// Analog Comparator Control And Status Register
#define _ADDR_ACSR      48
#define ACSR    _SFR_IO8(_ADDR_ACSR)

#define ACD     7       // Analog Comparator Disable
#define ACBG    6       // Analog Comparator Bandgap Select
#define ACO     5       // Analog Compare Output
#define ACI     4       // Analog Comparator Interrupt Flag
#define ACIE    3       // Analog Comparator Interrupt Enable
#define ACIC    2       // Analog Comparator Input Capture Enable
#define ACIS1   1       // Analog Comparator Interrupt Mode Select bit 1
#define ACIS0   0       // Analog Comparator Interrupt Mode Select bit 0

// Digital Input Disable Register 1
#define _ADDR_DIDR1     127
#define DIDR1   _SFR_MEM8(_ADDR_DIDR1)

#define AIN1D   1       // AIN1 Digital Input Disable
#define AIN0D   0       // AIN0 Digital Input Disable

...

// USART Baud Rate Register High Byte
#define _ADDR_UBRR0H    197
#define UBRR0H  _SFR_MEM8(_ADDR_UBRR0H)

#define UBRR11  3       // USART Baud Rate Register bit 11
#define UBRR10  2       // USART Baud Rate Register bit 10
#define UBRR9   1       // USART Baud Rate Register bit 9
#define UBRR8   0       // USART Baud Rate Register bit 8

// USART Baud Rate Register Low Byte
#define _ADDR_UBRR0L    196
#define UBRR0L  _SFR_MEM8(_ADDR_UBRR0L)

#define UBRR7   7       // USART Baud Rate Register bit 7
#define UBRR6   6       // USART Baud Rate Register bit 6
#define UBRR5   5       // USART Baud Rate Register bit 5
#define UBRR4   4       // USART Baud Rate Register bit 4
#define UBRR3   3       // USART Baud Rate Register bit 3
#define UBRR2   2       // USART Baud Rate Register bit 2
#define UBRR1   1       // USART Baud Rate Register bit 1
#define UBRR0   0       // USART Baud Rate Register bit 0

// Define above pair as a word register
#define UBRR0   _SFR_MEM16(_ADDR_UBRR0L)

...

The generated include file, in its present state, is used instead of avr/io.h 
but if I know how avr/io.h will be modified, it shouldn't be too difficult to 
modify my XML parser utility to generate the file based on it using the 
existing scheme.  Everything is at an experimental stage right now.  With the 
right feedback, I should be able to tweak the utility, regenerate the files and 
then finish them off by hand editing them.

What I need most at this time is a summary of what has been agreed to for 
changes to the API so that I can incorporate them into these two new include 
files and then keep everything else the same (or at least provide for backwards 
compatibility).


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
Sent: Monday, September 19, 2005 11:13 PM
To: Darcy Watkins
Cc: address@hidden
Subject: Re: [avr-libc-dev] [RFC] Suggestion on how to rapidly implement
supportfor atmega2560-2561


Darcy Watkins wrote on Dienstag, 20. September 2005 00:40 :
> Do you mean like this type of file?  ... (except following the current
> scheme instead of what I schemed up here).
>
> This one was generated by my experimental parser using the XML file for the
> ATmega2561.
>
Unthough I didn't check it so far: It looks quite good! :-). 
I think, however, that there might remain a couple of places where one still 
needs to hand-edit the generated file right now. Namely I have been looking 
at the required symbols for the EEProm handling and there are possibly also 
some symbols for the watch-dog support.? 
Anyway, I think your XML parser could be a *big* help. It would be very good 
IMO, if one could make the whole header generation automatically!

Yours,

Bjoern