avrdudes / avr-libc

The AVR-LibC package provides a subset of the standard C library for AVR 8-bit RISC microcontrollers.
https://avrdudes.github.io/avr-libc/
Other
247 stars 53 forks source link

[patch #5647] Patches to add ATmega3290P device to binutils, gcc. #746

Closed avrs-admin closed 2 years ago

avrs-admin commented 2 years ago

Sun 24 Dec 2006 07:52:44 PM CET

Patches to add ATmega3290P device to binutils, gcc.

file #11595: gcc-4.1.1-atmega3290p.patch file #11594: binutils-2.17-atmega3290p.patch file #11874: gcc-4.3-mega32xxp.diff file #11873: binutils-2.17-mega32xxp-pwm1.diff file #11877: avr-libc-add-mega329p-325p-3250p.diff

This issue was migrated from https://savannah.nongnu.org/patch/?5647

avrs-admin commented 2 years ago

Anatoly Sokolov Sun 24 Dec 2006 08:44:50 PM CET

IHMO it is not necessary to add  ATmega325P/329P/3250P/3290P devices in the GCC toolchain. They, from the point of view of the gcc/avr-libc, do not differ from ATmega325/329/3250/3290 devices.

ATmega165P/169P and ATmega165/169 devices have different SFR names for USART unit, therefore ATmega165P/169P devices have been added in binutils/gcc/avr-libc.

In a avr-libc-user-manual it is possible to add the information, that ATmega325P/329P/3250P/3290P devices are supported and that they are completely equivalent to devices without suffix 'P'.

Anatoly.

avrs-admin commented 2 years ago

Joerg Wunsch Tue 23 Jan 2007 11:45:53 PM CET

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 here.

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 ATmega329P.

avrs-admin commented 2 years ago

Anatoly Sokolov Wed 24 Jan 2007 11:34:53 PM CET

Joerg, thanks that you have found differences between 'P' and 'non-P' devices. My opinion: if 'P' and 'non-P' devices have differences then 'P' devices need to be added in the GCC toolchain.

avrs-admin commented 2 years ago

Anatoly Sokolov Sat 24 Feb 2007 12:19:40 PM CET

Support for ATmega325P/329P/3290P devices is added in avr-libc 1.4.6 and HEAD.

avrs-admin commented 2 years ago

Anatoly Sokolov Tue 06 Mar 2007 09:34:18 PM CET

Support for ATmega325P/3250P/329P/3290P devices is added in GCC 4.2 and HEAD (4.3).

avrs-admin commented 2 years ago

Anatoly Sokolov Mon 02 Apr 2007 09:02:57 PM CEST

Support for ATmega325P/3250P/329P/3290P devices is added in       binutils 2.18