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

[Ulrich Prinz]

Hi!

Sorry, may be the text is somewhat large and at some points the tone is 
a bit commanding. It is only my view so keep it as a suggestion.

The GPIOs will get a problem more and more. The reason is simple, the 
features of the pins increase tremendously. While the AVR only has 
input, output and pullup, the STM features input, input pullup, output 
open collector, output push pull, input analog, alternate function1 and 
alternate function2. This already came up with certain SAM7/9 and others.
The second problem is, that AVR internal devices take over GPIO ports 
them selves. It is enough to configure TX as output and RX as input and 
the USART works. With SAMx, STM32 and others it is needed to configure 
the pin to the desired function first, before you can use the device.
And if that is not enough, the power saving features come up. So it is 
necessary to enable the clock to a GPIO port before you can use it.

Ah, not to forget: If you connect different drivers or chips to a pin 
that is driven by a device it might be needed to switch the port even 
again. So if you use a small I2C connection you like to configure the 
SDA/SCL as "output alternate function1 + pullup". If you have a larger 
bus with more devices, you like to configure it as "output alternate 
function1 + open drain" as you supply external resistors for the bus.

---
I even saw totally different options to configure pins in firmware 
libraries manufacturers supply with their chips.

STM uses a small struct for configuration of every peripheral. You fill 
it with the configuration data and call a config function... Done.
It is really neat and with Nut/OS you can simply pull the config struct 
from heap, and release it after calling the config.

This is elegant as the config options for the ports are in two 
registers, 4bits per one of 16 pins per port. So you can say that you'd 
like to set up pins 1,2, 6, 9, 11 as input pullup at once. with a simple 
for loop and an atomic access per 8 pins.

May be I am wrong, but Nut/OS features the other way round by 
configuring one pin with many options.
If you like to configure the external memory bus of an STM32F103 you'll 
get happy with 16+8+4 control lines...

We need to keep it simple but we need to unify it as in other cases 
porting Nut/OS will be difficult and keeping the examples going with 
every architecture will be a problem. But I am pretty sure that the few 
existing tokens will not fit very tight and blow up the code.

I have only one idea for that:
The Nut/OS configuration for GPIOs features a minimum set of options 
that fit to all chips. This will keep the examples running.
Then there might be an optional alternate set of configuration options 
that can be enabled and supports CPU/architecture specific options.

For keeping it compliant, it will be needed to add chip specific GPIO 
configuration to the single devices (USARTs, ADC, SPI...). So if you 
register a USART, the driver has to reconfigure the GPIOs directly.
In my port I added a nutconf option to select the alternate placement of 
pins where a device has this option (USART, CAN, SPI, I2C, Memory)

For me, I'd like to see the ports base address as the token for the port 
in all architectures with more than 8 bit bus width. It doesn't make any 
difference in memory consumption for the variables but enables lot of 
shortcuts for the controlling code. In result the code will be smaller 
and faster even not using pointers from the base offset.
It is then not needed to translate ports from numbers that doesn't tell 
anything to the programmer. I don't like to translate A=0,B=1,C=2...
I use NUT_GPIO_PORTA/B/C... and nothing else.

----

With clause Nr.4 there should be no problem as long as the code is kept 
in the AVR32 architecture. So we show we do not use the code outside on 
other CPUs.

With SAM3 there will be some difference as the code for the CortexM3 
core is licensed from ARM and this license is applying to the ARM core 
itself. It is compatible with BSD too, so the CMSIS code can be taken 
for all CortexM3 based CPUs in Nut/OS.
And it is much better to read than the ATMEL code, so I take that one 
for the core of SAM3U too.

Best regards
Ulrich