[En-Nut-Discussion] Nut/OS for AT90CAN128 processor

Henrik Maier hmlists at focus-sw.com
Mon Feb 7 22:35:47 CET 2005


Hello Nut/OS developers,

Nut/OS runs now on a AT90CAN128 processor. The port was more difficult
than I thought as Atmel changed the complete SFR structure and interrupt
vector order for the AT90CAN128. The fact that the avr-libc EEPROM
routines lock-up for the AT90CAN128 didn't make it easier.

Before publishing the port and the changes, I like to discuss and
request for comments on some changes which are required for the new CPU.

Due to the Atmega103 history of the code base, the source contains a lot
of sections like the following example:

#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__)
extern NUTDEVICE devDebug0;
#ifdef __AVR_ATmega128__
extern NUTDEVICE devDebug1;
#endif

In order to support new MCUs like AT90CAN128, ATMEGA64, and in the
future ATMEGA256, I suggest to use a more generic check like
"#if defined(__AVR__)" instead of "#if defined(__AVR_ATmega128__) ||
defined(__AVR_ATmega103__)" AND "#if !defined(__AVR_ATmega103__)"
instead of "#ifdef __AVR_ATmega128__".

Rationale is that ATMEGA103 is a legacy device which is still
supported, however there are quite a few AVR devices which are more
compatible to the ATMEGA128 and it is easier to support them by
checking for a non-ATMEGA103 device.

As most of these ifdefs deal with checking for the presence of the
second UART, one could also check against UDR1 to check if a second UART
is available for the device. Same issue with the ifdefs to compile the
additional interrupts for the ATMEGA128. One could check for the
presence of the SIG_... (e.g. SIG_EEPROM_READY) definition to compile
them in instead of the MCU definition.

I personally prefer the latter concept as it is more MCU independent and
  so hopefully more future proof.


Any ideas suggestions are welcome.

Henrik



More information about the En-Nut-Discussion mailing list