Dear Reinhard Meyer,
Am 18.10.2010 10:40, schrieb Reinhard Meyer:
Dear Andreas Bießmann,
@@ -113,10 +112,6 @@ #define CONFIG_DBGU #undef CONFIG_USART0 #undef CONFIG_USART1
Don't #undef what has never been defined.
You know this is historic. This are the three possible interfaces for USART on this board. At least at91rm9200 known about DBGU ;) This will be addressed when merging at91rm9200/at91 and maybe avr32 usart implementation.
I know, its like that in almost all Atmel based boards. Even worse is the AT91 method, since some AT91 can have 6 UARTs. However unlikely that they are going to be used as console, this is awfully bad = <at91sam9260_ek.h>:
#define CONFIG_ATMEL_USART 1 #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_USART2 #define CONFIG_USART3 1 /* USART 3 is DBGU */ Notice the last define !!!
I know that ...
I once tried to cleanup that a bit, but it really would affect files all across AT91.
I plan to merge at91rm9200_usart and at91_usart for 2011.03. It will introduce clear naming scheme in at91 (USRT3 vs DBGU). Also I plan to remove the necessity to hardcode the base addresses in header of at91_usart.c. But to do this we need a clean basis to test the changes. Eg. at91rm9200ek and at91sam9260ek (i can get one from time to time) or your at91sam9263 based boards. I also think a lot of avr32 stuff could merge into the same drivers ... will have a look for that in future.
I do all of this in spare time at home therefore I go only little steps ... But currently are all arm boards broken (relocation), therefore is now the time to introduce new interfaces. Do you think the same way?
regards
Andreas Bießmann