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

[Weddington, Eric]

This topic is on the wrong mailing list. It should be for the avr-libc-dev 
mailing list, not the avr-libc-corelib mailing list. Also please subscribe to 
the mailing lists so your posts are not moderated.

Thanks,
Eric Weddington 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> gnu.org] On Behalf Of Gjermund Stensrud
> Sent: Friday, August 06, 2010 5:59 AM
> To: address@hidden
> Subject: Re: [Avr-libc-corelib] Mappings from pins to capabilities?
> 
> 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
> > >
> 
> 
> 
>