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
Ja, diese Tabelle gibts bei Atmel. Wenn du C-Code schreibst, dürfte sich die Portierung indes auf ein paar Registernamen beschränken.
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
Hallo, seit wann hat der Atmega16 mehr RAM als der 8er ? Nimm lieber gleich nen Atmega32 (2kB SRAM) oder 644er (4kB SRAM). Gruß.
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.
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
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
@ 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
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
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
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
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.
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
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.
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
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).
> 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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.