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

[Joe Pardue]

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