Re: [Avr-libc-corelib] Mappings from pins to capabilities?

[Gjermund Stensrud]

I noticed the AVR Xmega family uses a new way of mapping registers. As described
here:
http://blog.omegacs.net/2010/06/27/getting-started-with-xmega-differences-from-atmega-part-2/

I find this new way of defining registers very organized and practical.

Is it possible to adopt this way of mapping to ATmega and ATtiny?

Or am I missing the issue here?

- Gjermund

On Wed, 4 Aug 2010 20:33:13 -0400 "Joe Pardue" <address@hidden> wrote

> Please bear with me on this since I'm not entirely sure I'm following what
> is being said here. I am building code that compiles for different devices
> depending on which one is defined. I use a long name that tells what a
> register actually is since I have trouble remembering what the mnemonic
> means. In example below, the Butterfly (ATmega169 has only one USART) has
> different register names from the ATmega328 and ATmega644 which have two
> USARTS).
> 
> 
> 
> #if defined(Butterfly)
> 
> 
> 
>    // ATMega with one USART
> 
>    #define USART_BAUD_RATE_HIGH                    UBRRH
> 
>    #define USART_BAUD_RATE_LOW                    UBRRL
> 
>    #define USART_CONTROL_STATUS_REG_A            UCSRA
> 
>    #define USART_CONTROL_STATUS_REG_B            UCSRB
> 
>    #define USART_CONTROL_STATUS_REG_C            UCSRC
> 
>    #define USART_ENABLE_TRANSMITTER            TXEN
> 
>    #define USART_ENABLE_RECEIVER                   RXEN
> 
>    #define USART_READY_TO_TRANSMIT            UDRE
> 
>    #define USART_TRANSMIT_COMPLETE         TXC
> 
>    #define USART_RECEIVE_COMPLETE               RXC
> 
>    #define USART_DATA_REG                                    UDR
> 
>    #define USART_STOP_BIT_SELECT                      USBS
> 
>    #define USART_CHARACTER_SIZE_0                  UCSZ0
> 
>    #define USART_CHARACTER_SIZE_1                  UCSZ1
> 
>    #define USART_REGISTER_SELECT                      URSEL
> 
> 
> 
> #elif defined(BeAVR40) || defined(Arduino)
> 
> 
> 
>    // ATMega with two USARTs - USART 0
> 
>    #define USART_BAUD_RATE_HIGH                     UBRR0H
> 
>    #define USART_BAUD_RATE_LOW                    UBRR0L
> 
>    #define USART_CONTROL_STATUS_REG_A            UCSR0A
> 
>    #define USART_CONTROL_STATUS_REG_B            UCSR0B
> 
>    #define USART_CONTROL_STATUS_REG_C            UCSR0C
> 
>    #define USART_ENABLE_TRANSMITTER            TXEN0
> 
>    #define USART_ENABLE_RECEIVER                   RXEN0
> 
>    #define USART_READY_TO_TRANSMIT            UDRE0
> 
>    #define USART_TRANSMIT_COMPLETE         TXC0
> 
>    #define USART_RECEIVE_COMPLETE               RXC0
> 
>    #define USART_DATA_REG                                    UDR0
> 
>    #define USART_STOP_BIT_SELECT                      USBS0
> 
>    #define USART_CHARACTER_SIZE                      UCSZ00
> 
> 
> 
> #else
> 
>    #error "no USART definition for MCU"
> 
> #endif
> 
> 
> 
> I presume that the same idea could be extended to the pins if we abstract a
> higher-level name for the generic function and then associate it with a
> particular mnemonic for a specific device. I can't see the sense in trying
> to automate this with the XML files. Instead I would have examples for
> several devices and then let the user who has a new device to add, simply
> follow the procedure indicated for the previous devices. Are we talking
> about the same sort of thing or am I missing something?
> 
> 
> 
> Joe
> 
> 
> 
> ----- Original Message -----
> From: "David A. Mellis" <address@hidden>
> To: <address@hidden>
> Sent: Tuesday, August 03, 2010 10:18 AM
> Subject: [Avr-libc-corelib] Mappings from pins to capabilities?
> 
> 
> > Hi,
> >
> > I'm the lead software developer for Arduino, an ATmega8, 168, 328, and
> > 1280 based development platform.  One of the issues we struggle with
> > is mapping, across multiple cpu's, the port / bit of a pin to the
> > other capabilities of the pin (i.e. the labels in the pin
> > configurations section of the datasheet) - for example, in order to
> > write a function to both set a pin as an output and enable PWM on that
> > pin.  Right now, that requires maintaining a mapping between, say, PG5
> > and 0C0B.  This seems like it would be a great thing to include in the
> > corelib in some form.  The ideal would be a way to go in both
> > directions.  One possibility is to define this as a series of macros,
> > which could run at compile-time if the parameters are known.  But
> > really, any implementation would be fine.  I know there are a lot of
> > complications in doing this across the whole AVR line, but that's one
> > of the reasons that it seems to make sense in the corelib: it would be
> > a chance to resolve all the tricky issues once in a way that other
> > developers could take advantage of.  Certainly, it would be a big help
> > for Arduino.
> >
> > What do you think?
> >
> > David
> >