Forum: Mikrocontroller und Digitale Elektronik Unterschiede zwischen ATmega8 und ATmega16


von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Hallo,
ich hatte ein Projekt anfangs für einen ATmega8 geplant, und auch schon 
Code programmiert, bzw. zusammengetragen, und nun schon viele Stunden 
Zeit damit verbracht. Im Laufe der Zeit benötigte ich aber immer mehr 
RAM, und Portpins, was die Kapazität eines ATmega8 sprengt. Also will 
ich nun einen ATmega16 verwenden, der ja mehr RAM, sowie mehr Portpins 
hat.
Meinen Code, den ich ursprünglich für den Mega8 geschrieben hatte, will 
ich nun eben für den ATmega16 anpassen.
Wo liegen die genauen Unterschiede zwischen den beiden µCs, bis auf den 
größeren RAM des Mega16, und die höhere Portpinanzahl?
Gibt es da irgendwelche vergleichende Tabellen, in denen wirklich jeder 
noch so kleine Unterschied angeführt wird, oder muss ich mich durch die 
Datenblätter arbeiten?
Auf der ATMEL- Seite soll sich angeblich eine solche Tabelle befinden, 
ich könnte sie bis jetzt leider noch nicht entdecken.

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

von Sven P. (Gast)


Lesenswert?

Ja, diese Tabelle gibts bei Atmel. Wenn du C-Code schreibst, dürfte sich 
die Portierung indes auf ein paar Registernamen beschränken.

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Ach ja, genau hatte ich vergessen, der Code ist in GCC.
Kann mir eventuell einer den Link zu dieser Tabelle schicken?
Stehen da auch die verschiedenen Register, usw. drin?

Vielen Dank schon einmal im voraus.
Gruß, Steffen

von fubu1000 (Gast)


Lesenswert?

Hallo,
seit wann hat der Atmega16 mehr RAM als der 8er ?
Nimm lieber gleich nen Atmega32 (2kB SRAM) oder 644er (4kB SRAM).

Gruß.

von Sven P. (Gast)


Lesenswert?

Evtl. tuns ja auch schon die 48 und 88er ATmegas, dafür gibts die 
Migration Notes als Application Note bei Atmel, da stehen dann die 
Veränderungen haarklein drinne.

von risu (Gast)


Lesenswert?

Hallo,

> Kann mir eventuell einer den Link zu dieser Tabelle schicken?

http://atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

Gruß

 risu

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Sorry, mein Fehler, ich meinte nicht RAM, sondern Flash!

Der ATmega48 ist doch sogar kleiner, wie der Mega8, und der 88 ist von 
den technischen Daten fast identisch mit dem ATmega8.

Vielen Dank schon mal im Voraus.
Gruß, Steffen

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

@ risu: Vielen Dank, die Tabelle ist schon mal sehr nützlich!!!!!
Aber eine sehr genaue Tabelle, in der dann auch wirklich die Register 
aufgeführt sind, die bei beiden µCs anders sind, gibt es nicht, oder?
D.h. das muss ich dann eben im Datenblatt vergleichen?

Gruß, Steffen

von risu (Gast)


Lesenswert?

Hallo Steffen,

eine Tabelle, die die Namen der SFRs der verschiedenen AVRs vergleicht, 
kenne ich nicht. Wenn Du hier ( 
http://atmel.com/dyn/products/devices.asp?family_id=607 ) mal nach dem 
Wort "migrating" suchst, findest Du ein paar Vorschläge von Atmel, wie 
man von einem AVR zum nächsten übergeht.

Ansonsten kannst Du in erster Annäherung Dein Programm für den neuen 
Zielprozessoor kompilieren und alle Fehlermeldungen des Compilers mit 
den beiden Datenblättern in der Hand "reparieren".

Gruß
 risu

von Manfred B. (vorbeigeschlendert)


Lesenswert?

Wechseln auf mega168:
mach doch die Probe aufs Exempel und ändere in deinem Makefile die CPU 
auf einen mega168 und lass deinen Code mal compilieren... die meisten 
Änderungen bekommst du dann mit, denn das ein oder andere Register hat 
einen anderen Namen bekommen... und an diesen Stellen schadet ein Blick 
ins Datenblatt auch nicht...

und: 'AVR094: Replacing ATmega8 by ATmega88'
http://atmel.com/dyn/resources/prod_documents/doc2553.pdf

und: 'AVR095: Migrating between ATmega48, ATmega88 and ATmega168'
http://atmel.com/dyn/resources/prod_documents/doc2554.pdf

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Ich hab jetzt folgendes gemacht: Mein Projekt mit allen libs, usw. in 
AVR Studio geöffnet. Dann hab ich unter Project, Configuaration Options, 
beim Eintrag "Device" von ATmega8 auf ATmega16 umgestellt. Anschliessend 
auf build active configuration geklickt, und siehe da:
Build succeeded with 0 Warnings...

Heißt das nun, dass mein Proggi bis jetzt 100% kompatibel zum ATmega16 
ist?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

von Johannes M. (johnny-m)


Lesenswert?

Steffen O. wrote:
> Heißt das nun, dass mein Proggi bis jetzt 100% kompatibel zum ATmega16
> ist?
Das kommt auf Dein "Proggi" (echt blödes Wort) an. Beim ATMega8 liegen 
z.B. viele der alternativen Portfunktionen an anderen I/O-Pins als beim 
Mega16. Z.B. hat der ATMega8 die Analog-Eingänge für den ADC an Port C, 
der ATMega16 hat sie an Port A (den der ATMega8 gar nicht hat). D.h., 
zumindest die I/O-Pin-Konfigurationen müssen vermutlich komplett 
überarbeitet werden (also Datenrichtung, Pull-Ups, usw.). Bei den Timern 
und der restlichen Peripherie sollte es eigentlich keine größeren 
Probleme geben. Die Bezeichnungen und Bitpositionen müssten weitgehend 
übereinstimmen.

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Johannes M. wrote:
> Steffen O. wrote:
>> Heißt das nun, dass mein Proggi bis jetzt 100% kompatibel zum ATmega16
>> ist?
> Das kommt auf Dein "Proggi" (echt blödes Wort) an.

Lass mich doch ;-)).

> Beim ATMega8 liegen
> z.B. viele der alternativen Portfunktionen an anderen I/O-Pins als beim
> Mega16. Z.B. hat der ATMega8 die Analog-Eingänge für den ADC an Port C,
> der ATMega16 hat sie an Port A (den der ATMega8 gar nicht hat). D.h.,
> zumindest die I/O-Pin-Konfigurationen müssen vermutlich komplett
> überarbeitet werden (also Datenrichtung, Pull-Ups, usw.).

D.h. ich muss eigentlich nur meine Hardware verändern? Ist eh nicht so 
tragisch, da ich den eigentlichen Schaltungsaufbau bis jetzt wirklich 
nur mit ein paar Strichen skizziert hab.

> Bei den Timern
> und der restlichen Peripherie sollte es eigentlich keine größeren
> Probleme geben. Die Bezeichnungen und Bitpositionen müssten weitgehend
> übereinstimmen.

Ok, dann werd ich also die Software nochmal vergleichen mit dem 
Datenblatt des ATmega16, vielleicht find ich ja noch irgendwelche 
Unterschiede.

Gruß, Steffen

von User (Gast)


Lesenswert?

Im allgemeinen sind die AVR vom Code her, untereinander alle sehr 
kompatibel miteinander. Das einzige was du immer ändern musst, sind die 
I/O Pins/Ports. Die sind entweder woanders, gar nicht vorhanden, oder 
(wie z.B. beim ATmega32) werden von JTAG, usw. benutzt.
Alles andere sollte bis auf ein bisschen alles gleich sein.
Übrigens: Einen Code in GCC gibt es nicht, das ist nur der Compiler. 
Wahrscheinlich wird dein Code daher in C sein.

von Steffen O. (derelektroniker) Benutzerseite


Lesenswert?

Hallo,
danke auch dir für deine Antwort!!!
Ja, genau, also die Pheripherie am µC muss ich eben entsprechend anders 
an den Mega16 anschliessen, und zur Sicherheit schau ich nochmal die 
Datenblätter beider Controller an, vielleicht fällt mir ja noch ein 
Unterschied auf.

Gruß,  Steffen

von Johannes M. (johnny-m)


Lesenswert?

User wrote:
> Im allgemeinen sind die AVR vom Code her, untereinander alle sehr
> kompatibel miteinander.
Das ist ein Gerücht. Zumindest zwischen der (weit verbreiteten) ersten 
ATMega-Generation (z.B. ATMega8, 16, 128) und den in den letzten paar 
Jahren neu auf den Markt gekommenen AVRs gibt es z.T. erhebliche 
Unterschiede in den Registerbezeichnungen. Allerdings hat ATMEL mit der 
neueren Generation versucht, die Registerbezeichnungen tatsächlich zu 
vereinheitlichen, indem z.B. auch bei µCs, die nur ein UART haben, der 
Index "0" für die Register verwendet wird (z.B. UCSR0A anstelle von 
UCSRA).

ATMEL hat das ganze aber in Form von Migration Notes für fast alle 
sinnvollen Fälle ziemlich ausführlich dokumentiert.

> Das einzige was du immer ändern musst, sind die
> I/O Pins/Ports. Die sind entweder woanders, gar nicht vorhanden,
Das passiert aber nur beim Wechsel zwischen nicht pinkompatiblen AVRs, 
was (wie in diesem Fall) eher die Ausnahme ist.

> oder
> (wie z.B. beim ATmega32) werden von JTAG, usw. benutzt.
Das ist dann zunächst mal eine Fuse-Angelegenheit (OK, man kann das 
JTAG auch aus dem laufenden Programm heraus deaktivieren).

von User (Gast)


Lesenswert?

> Das ist dann zunächst mal eine Fuse-Angelegenheit
Natürlich ist es "nur" ein Fuse. Aber ab Werk ist er nun mal aktiviert, 
und der betroffene Port nicht für andere Zwecke nutzbar.

> z.T. erhebliche Unterschiede in den Registerbezeichnungen.
Das ist doch aber nur für Assembler Coder wichtig, oder? In C übernimmt 
das umrechnen doch der Compiler. Kann sein dass ich damit jetzt komplett 
falsch liege, glaube aber zumindest bei C stimmt das.

von Johannes M. (johnny-m)


Lesenswert?

User wrote:
>> z.T. erhebliche Unterschiede in den Registerbezeichnungen.
> Das ist doch aber nur für Assembler Coder wichtig, oder? In C übernimmt
> das umrechnen doch der Compiler. Kann sein dass ich damit jetzt komplett
> falsch liege, glaube aber zumindest bei C stimmt das.
Das ist Quatsch! Ich glaube, Du hast noch nie einen AVR in C 
programmiert, wenn Du meinst, dafür die Registernamen nicht kennen zu 
müssen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.