[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [patch #5647] Patches to add ATmega3290P device to binuti

From: Joerg Wunsch
Subject: [avr-libc-dev] [patch #5647] Patches to add ATmega3290P device to binutils, gcc.
Date: Tue, 23 Jan 2007 22:45:53 +0000
User-agent: Mozilla/5.0 Galeon/1.2.13 (X11; FreeBSD i386; U;) Gecko/0

Follow-up Comment #2, patch #5647 (project avr-libc):

I wrote a small script to create the header file #defines out
of the XML files.  I see two differences between the non-P and
the P version:

1) All USART names have been changed to USART0.  However, this
does not match the datasheet of the non-P device, that has
already been using the USART0 names everywhere, so does our
existing header file, and we don't need to change anything

2) The following new IO register bit definitions appeared
in the ATmega3290P XML file:

--- newh/ATmega3290.h   Tue Jan 23 23:30:10 2007
+++ newh/ATmega3290P.h  Tue Jan 23 23:30:16 2007
@@ -309,6 +309,7 @@
 #define LCDCC1                         1
 #define LCDCC2                         2
 #define LCDCC3                         3
+#define LCDMDT                         4
 #define LCDDC0                         5
 #define LCDDC1                         6
 #define LCDDC2                         7
@@ -316,6 +317,8 @@
 /* LCD Control and Status Register A*/
 #define LCDCRA                 _SFR_MEM8(0xE4)
 #define LCDBL                          0
+#define LCDCCD                         1
+#define LCDBD                          2
 #define LCDIE                          3
 #define LCDIF                          4
 #define LCDAB                          6
@@ -566,6 +569,8 @@
 #define IVCE                           0
 #define IVSEL                          1
 #define PUD                            4
+#define BODSE                          5
+#define BODS                           6
 #define JTD                            7
 /* MCU Status Register*/

I think it makes sense to merge them into the existing
header file, but we certainly do need a different MCU type
macro then.

Similar changes apply to ATmega325P, ATmega3250P, and


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]