[En-Nut-Discussion] Added AVR32 changes to the trunk

[Michael Fischer]

Hello Thiago,

 >I'm getting back into doing Nut/OS and AVR32 code. All changes
 >looks good, but I'm not sure I follow the rationale for using the
 >atmel gpio implementation.
It is easier to explain it with an example.

In case of usart.c you are using the following lines of code:

GpioPinConfigSet(AVR32_GPIO_BANK(USART_RX_PIN),
                  AVR32_GPIO_PIN(USART_RX_PIN),
                  AVR32_GPIO_FUNCTION(USART_RX_FUNCTION));

The USART_RX_PIN comes from the original Atmel defines where the
PIN define is calculated as follow:

PIN = (bank*32)+pin

In case of PA17 the value is (0*32)+17 = 17,
and for PB2 = (1*32)+2 = 34

Here bank-a is defined with 0 and bank-b with a. At the same time
the old GpioPortConfigSet use the bank define to access the AVR32 port:

volatile avr32_gpio_port_t *gpio_port = &AVR32_GPIO.port[bank];

And this is the problem if the user use in the application the
NutOS defines for NUTGPIO_PORTA which is 1.

If the user want to set a pin e.g. PA17 he use the following code:

GpioPinSet(NUTGPIO_PORTA, 17, 1);

or

GpioPinSetHigh(NUTGPIO_PORTA, 17);


Internally the bank, in our case NUTGPIO_PORTA which is defined to 1,
will be used to access the AVR32 port:

volatile avr32_gpio_port_t *gpio_port = &AVR32_GPIO.port[bank];

and this is wrong in the case of AVR32, with one the PORT-B will
be accessed. At the same time we could NOT use the following
statement:

*gpio_port = &AVR32_GPIO.port[bank-1];

Because it will not work if we use the Atmel defines.

Therefore I have changed the code.

An other solution could be to change the defines for NUTGPIO_PORTx.
Move this defines to the port depending code, and every port must
define it. In this case the application can still use this define,
and it works inside the driver too.

Best regards,

Michael