mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bezeichnung zur Identifikation der AVR Core Version?


Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Peripheriemodule sind eh ein Krampf bei den AVR.

Nanana!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Sprich, die Register liegen bei gleichen Modulen nicht in der gleichen
>Reihenfolge.

Wen interessiert das?

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim XMega geht das auch.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, du meinst die Library-Programmierer der Compiler-Hersteller. Dem 
IAR-Compiler selbst ist das genauso egal wie dem GCC.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist jetzt Haarspalterei

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.