Atmega324PB / Atmega324PV / Atmega324P Unterschiede

Gast #6493486
Moin! Kennt von euch jemand ein ATMEL/Microchip Dokument, wo die 
Unterschiede von einzelnen uC-Subtypen beschrieben werden?

Konkret geht es um die Varianten des ATmega324, da gibts im gleichen 
TQFP44-Package u.a. diese Ausführungen:

324PV10AU
324P20AU
324PB20AU

Im Datenblatt hab ich keine Aufschlüsselung gefunden, kann von den 
Profis jmd weiterhelfen, wo die Unterschiede sind?
Gast
Johnny X. schrieb:
> 324PV10AU
> 324P20AU
> 324PB20AU
> Im Datenblatt hab ich keine Aufschlüsselung gefunden

Datenblatt 3. Ordering Information
324PV10AU 10 MHz, 1.8 - 5.5V, Temperaturbereich Industrial (-40°C to 
85°C)
324P20AU  20 MHz, 2.7 - 5.5V, Temperaturbereich Industrial (-40°C to 
85°C)
...
Gast
> ... Datenblatt hab ich keine ...

Brauchst du auch nicht. Hier gibt es genügend willfährige Geister, die 
nur darauf warten, dass jemand kommt dem sie dienen können.
H.Joachim S. schrieb:
> Bei xxPB immer sehr gut aufpassen, sind nicht pinkompatibel.

Natürlich kann man damit alte Platinen auch bestücken.
Beim 324PB sind 4 zusätzliche IO-Pins, wo vorher GND/VCC waren.
Da IO-Pins beim Reset hochohmig sind, schadet die Verbindung mit GND/VCC 
nicht. Man kann sie eben nur nicht benutzen.
Gast
>Wenn man im Datenblatt die Suchfunktion mit einer nicht verunstalteten
>Bezeichnung benutzt, lässt sich das vermeiden.
Oder man guggt im Inhaltsverz. nach.
IC-Bezeichnungen stehen in Datenblatt immer drin.
Gast
>> Bei xxPB immer sehr gut aufpassen, sind nicht pinkompatibel.
> Natürlich kann man damit alte Platinen auch bestücken..
> Beim 324PB sind 4 zusätzliche IO-Pins,.....
Ja, möglich.
Nur die sind nicht softw-kompatibel zu vorigen '324.
Also, 1:1 ersetzen geht nicht.
Gast
Das sind erweiterte/verbesserte Versionen von MCH.
Ein grosser Teil ist sicherlich unverändert, ein kleinerer Teil ist 
anders.
(mit etwas Anpassung wird es aber zu machen sein)
MCUA schrieb:
>>> Bei xxPB immer sehr gut aufpassen, sind nicht pinkompatibel.
>> Natürlich kann man damit alte Platinen auch bestücken..
>> Beim 324PB sind 4 zusätzliche IO-Pins,.....
> Ja, möglich.
> Nur die sind nicht softw-kompatibel zu vorigen '324.
> Also, 1:1 ersetzen geht nicht.

Hallo,

ich glaube wir müssen das konkretisieren. Das verhält sich wie beim 
ATmega328P vs. 328PB. Die sind binär kompatibel. Das bedeutet ein 
kompiliertes .hex File vom "P" kannste direkt auf den "PB" flashen. 
Funktioniert. Den Quellcode dagegen muss man für den "PB" anpassen vorm 
neu kompilieren, weil paar Registenamen etc. verschieden sind.

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42769-Differences-between-ATmega324-and-ATmega324PB_ApplicationNote_AVR42769.pdf

"328P/PB": 
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591418
Gast
Dort steht auch
"ATmega324PB is not a drop-in replacement for ATmega324 variants, but a
new device." Sind also nicht 100% kompatibel.
(und warum sollte man sonst weitere Bezeichnung einführen?)
Gast
MCUA schrieb:

> Dort steht auch
> "ATmega324PB is not a drop-in replacement for ATmega324 variants, but a
> new device." Sind also nicht 100% kompatibel.
> (und warum sollte man sonst weitere Bezeichnung einführen?)

Sie sind auf Ebene des Binärcodes 100% *ABWÄRTS*-kompatibel. D.h.: du 
kannst den PB nehmen, auf bestehende Board klatschen, das bestehende 
HEX-File drauf flashen und der Scheiss wird (recht wahrscheinlich) 
funktionieren.

Was du so nicht kannst: die zusätzlichen Features der PB-Variante 
benutzen. Dazu mußt du natürlich das bestehende Programm auf 
Quelltextebene erweitern. Und dabei kannst du (und wirst du relativ 
wahrscheinlich) auf das Problem stoßen, dass sich diverse symbolische 
Bezeichner geändert haben, also das Programm (selbst noch ohne 
irgendeine funktionale Änderung) erst einmal nicht 
kompilierbar/assemblierbar ist, wenn als Target die PB-Variante gewählt 
wird.

Nur C&P-Loser halten sowas für ein echtes Problem...

Schon deutlich kitzliger ist, dass sich auch Teile der Specs geändert 
haben. Dass das in einem konkreten Fall stört, merkt man dann spätestens 
daran, dass die Binärkompatibilität des Codes nicht genügt, um das 
bestehende Board zum Laufen zu bringen. Clevere Entwickler lesen 
natürlich vorher das Datenblatt und klopfen das Design auf mögliche 
Inkompatibilitäten ab. Aber im Zeitalter der C&P-Programmierer mit wenig 
oder garkeiner Ahnung von der Hardware kann man sowas wohl nicht mehr 
wirklich verlangen...
Gast
> Clevere Entwickler lesen
> natürlich vorher das Datenblatt und klopfen das Design auf mögliche
> Inkompatibilitäten ab.
Clevere Entwickler würden den nie complett 1:1 ersetzen.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 5 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.