Hi, gibt es eigentlich Bezeichnungen oder Identifikationsmöglichkeiten für die Core Version bei AVR Controllern? Es gibt ja verschiedene Versionen. von den alten AT90S über die ersten ATmega bis hin zu den aktuellsten. Ich meine damit die Cores, die identische Befehlssätze, Features usw haben. So können die Mega8 noch nicht das Togglen durch Beschreiben des PIN Registers, die Mega88 können das. Wie kann man rausfinden, welche zusammengehören, ohne jedes einzelne Datenblatt zu studieren?
Zusammen gehören definitiv die Typen, die in einem Datenblatt zusammengefaßt sind, bspw. Mega48/88/168/328 oder Tiny24/44/84. Bei allen anderen sind, wenn auch kleine, Unterschiede zu erwarten.
Das es kleine Unterschiede vor allem in der Registerbelegung gibt ist klar. Ich meine jetzt eher grundlegendere Unterschiede wie zb der Sprung von Mega8 auf Mega88, Erweiterungen wie die Möglichkeit, über das PIN Register zu toggeln und sowas. Ich vermute, dass alles vom Mega8 bis Mega128 einschließlich Mega8515 und 8535 den gleichen Core hat. Genauso wie Mega48 bis Mega644. Die P und PA Versionen sollten zumindest von der Funktion identisch sein.
Die definitive Antwort hat nur das Datenblatt. Grob gerechnet ist der jüngste Schnitt bei den ,normalen' AVRs (also nicht Xmega) gemacht worden mit folgenden Eigenschaften, die du dann auch wieder gemeinsam findest. Jeweils eins davon genügt letztlich als Kriterium. . nur noch ein RC-Oszillator (8 MHz bzw. 9,6 Mhz bei ein oder zwei Typen), dafür einen clock prescaler (CLKPR), mit dem man den Takt runterteilen kann, sowie eine CKOUT-Fuse, mit der man den Takt auf ein Pin rausführen kann . neuer Watchdog, der alternativ zum Reset auch einen Interrupt auslösen kann und ein wenig mehr Streicheleinheiten benötigt (WDRF manuell löschen), bevor man ihn nach einem Reset wieder los wird . Beschreiben von PINx togglet ein Ausgangspin Weiß nicht, ob ich was vergessen habe.
Markus Burrer schrieb: > Ich vermute, dass alles vom Mega8 bis Mega128 einschließlich Mega8515 > und 8535 den gleichen Core hat. Das betrifft übrigens weniger den CPU-Core, sondern die Peripherie- module.
Jörg Wunsch schrieb: > Das betrifft übrigens weniger den CPU-Core, sondern die Peripherie- > module. Die Peripheriemodule sind eh ein Krampf bei den AVR. Die unterscheiden sich ja teilweise sogar innerhalb eines Controllers voneinander, speziell im Mega128. Sprich, die Register liegen bei gleichen Modulen nicht in der gleichen Reihenfolge. Zum Glück haben die bei den Xmega aufgeräumt, auch wenn damit die Abwärtskompatibilität aufgegeben wird.
Hi >Sprich, die Register liegen bei gleichen Modulen nicht in der gleichen >Reihenfolge. Wen interessiert das? MfG Spess
Jemanden, der den gleichen Code für multiple Peripheriemodule verwendet, und dafür die Register relativ zu einem Pointer addressiert, der auf die Basisadresse des Peripheriemoduls zeigt. Sowas geht beispielsweise bei ARMs und PIC30 weil die I/O-Register dort in geschlossenen Blöcken angeordnet sind. Dürfte aber bei AVRs eher selten vorkommen.
Beim XMega geht das auch.
spress schrieb: Wen interessiert das? A. K. schrieb: > Jemanden, der den gleichen Code für multiple Peripheriemodule verwendet, > und dafür die Register relativ zu einem Pointer addressiert, der auf die > Basisadresse des Peripheriemoduls zeigt. Sowas geht beispielsweise bei > ARMs und PIC30 weil die I/O-Register dort in geschlossenen Blöcken > angeordnet sind. > > Dürfte aber bei AVRs eher selten vorkommen. Genau deshalb hat Atmel bei den Xmega so radikal aufgeräumt. Versuch doch mal beim Mega128, beide USARTs zu nutzen. Du darfst den kompletten Code 2x schreiben oder musst dir einen dabei abbrechen, den Code so anzupassen, dass er mit beiden USARTs funktioniert. Beim Mega128 liegen die Register für USART1 schön hintereinander von 0x98 bis 0x9D. USART0 liegt verteilt von 0x09 bis 0x0C, 0x90 und 0x95. Beim 2560 sind zwar alle Module identisch, aber in einer anderen Reihenfolge als zb USART1 beim Mega128. Und so zieht sich das durch sämtliche AVR.
Markus Burrer schrieb: > Beim Mega128 liegen die Register für USART1 schön hintereinander von > 0x98 bis 0x9D. USART0 liegt verteilt von 0x09 bis 0x0C, 0x90 und 0x95. Dafür kannst halt die UART0 noch mit IN/OUT benutzen. Das dürfte aber in erster Linie historischer Ballast gewesen sein: das Teil war eine Ablösung für den ATmega103, und damit war die Kompatibilität zu diesem (siehe M103C-Fuse, die bei Auslieferung gesetzt ist) wichtiger als irgendwelche Neuerungen. Letztlich ist das Teil ja nun auch fast 10 Jahre alt, ich würde es als Anfangs- fehler beiseite legen, aus denen sie später gelernt haben. > Und so zieht sich das durch sämtliche AVR. Nö, die neueren (so ab ca. 2005) sind allesamt deutlich ,,rechtwinkliger'', auch schon vor dem Xmega.
Ja, es wurde mit der Zeit besser, dass stimmt. Trotzdem dürften vor allem die Compiler Programmierer fluchen. Da sind die Xmega ein echter Segen
Markus Burrer schrieb: > Ja, es wurde mit der Zeit besser, dass stimmt. Trotzdem dürften vor > allem die Compiler Programmierer fluchen. Da sind die Xmega ein echter > Segen Was interessieren den Compiler-Programmierer die Peripheriemodule?
A. K. schrieb:
> Was interessieren den Compiler-Programmierer die Peripheriemodule?
Ich rede von Bascom, IAR usw. Das es die gcc Programmierer nicht
interessiert ist klar. Da fluchen höchstens diejenigen, die versuchen,
brauchbare Librarys zu schreiben, die universell einsetzbar sind. Dazu
gehöre ich auch
Ok, du meinst die Library-Programmierer der Compiler-Hersteller. Dem IAR-Compiler selbst ist das genauso egal wie dem GCC.
Markus Burrer schrieb: >> Was interessieren den Compiler-Programmierer die Peripheriemodule? > Ich rede von Bascom, IAR usw. Bascom ja. IAR ist in dieser Hinsicht genauso wenig betroffen wie GCC, da er keine Peripherie-Bibliotheken auf höherer Abstraktionsebene (Zeichen-Ein-/Ausgabe statt Registerebene) mitliefert. Ist aber alles in allem simpel zu lösen, indem man einfach eine Tabelle mit den Steuerregistern des jeweiligen Peripheriemoduls anlegt. Auf Effektivität (mögliche Benutzung von IN/OUT statt LDS/STS) kommt es ja dann sowieso nicht mehr an. Sicher, die Lösung beim Xmega sieht schöner aus. Im Prinzip könnte man eine derartige Variante wohl auch für andere moderne AVRs schreiben, wenn man will. Man darf ja auch als Programmierer ruhig mal aufhören, rückwärtskompatibel bis zur Jungsteinzeit sein zu wollen. Wer eben unbedingt einen ATmega128 dem ATmega1281 vorziehen will, kann sich dann halt seinen Kram selbst zimmern.
Jörg Wunsch schrieb: > Bascom ja. IAR ist in dieser Hinsicht genauso wenig betroffen wie GCC, > da er keine Peripherie-Bibliotheken auf höherer Abstraktionsebene > (Zeichen-Ein-/Ausgabe statt Registerebene) mitliefert. Nicht? Ich dachte, der bietet sowas auch an. Oder war das Keil? Irgend ein C Compiler hatte sowas meine ich > > Sicher, die Lösung beim Xmega sieht schöner aus. Im Prinzip könnte > man eine derartige Variante wohl auch für andere moderne AVRs > schreiben, wenn man will. Man darf ja auch als Programmierer ruhig > mal aufhören, rückwärtskompatibel bis zur Jungsteinzeit sein zu > wollen. Wer eben unbedingt einen ATmega128 dem ATmega1281 vorziehen > will, kann sich dann halt seinen Kram selbst zimmern. Da hast du wohl recht. Aber die Leute kaufen immer noch Mega32 mit 16MHz Quarz und wundern sich, wenn es Datensalat bei der Datenübertragung gibt. Wie kann man dann erwarten, dass die so weit denken?
Markus Burrer schrieb:
> Wie kann man dann erwarten, dass die so weit denken?
Indem man sie die Software selbst schreiben lässt. ;-) Dann werden
sie auch merken, dass der ATmega324 nicht nur pinkomatibel und
viel aufgeräumter ist, sondern auch noch ein paar andere nützliche
Dinge bietet (wie eine zweite USART).
Jörg Wunsch schrieb: > Dann werden sie auch merken, dass der ATmega324 nicht nur pinkomatibel und > viel aufgeräumter ist, sondern auch noch ein paar andere nützliche > Dinge bietet (wie eine zweite USART). Und teurer. Und bei Ramschläden wie Pollin oder Reichelt bekommt man den nichtmal. Nichtmal Conrad hat den. Und wenn der da nicht zu bekommen ist interessiert das auch kaum jemand
Markus Burrer schrieb: [ATmega32 vs. ATmega324] > Und teurer. Digikey (um mal jemanden zu nennen, bei dem du sofort beide kaufen könntest): EUR 6,38 für den ATmega32, EUR 4,70 für den ATmega324P. > Und bei Ramschläden wie Pollin oder Reichelt bekommt man den > nichtmal. Pollin ist da eh' indiskutabel. Warum Angelika immer so lange wartet, bis da mal was aktualisiert wird, weiß der Geier. CSD hat beide, allerdings ist dort in der Tat der '32 billiger als der '324 (und beide billiger als Digikey, wenn man die Märchensteuer einrechnet). Preispolitik, warum auch immer die so verschieden ausfällt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.