Hallo,
ich arbeite mit verschiedenen Xmegas beruflich für verschiedene Zwecke.
Es gibt den zum Beispiel größeren Xmega256A3BU und den abgespeckten
Xmega ATxmega128D3-MH.
Jetzt ist meine Frage, wie die Befehlssätze für die beiden sind. Sind
sie 1:1 unter einander portierbar oder gibt es hier gewisse
Unwägbarkeiten und Fallstricke, die man beachten muss.
Ich will eine Software zwischen verschiedenen Xmegas portieren. Also vom
Evaluationsboard auf die eigentliche Hardware mit dem kleineren Xmega.
Ich will hier schon mal eine Fehlerquelle ausschließen.
Ich bin mir der absoluten Kompatibilität sicher, will aber hier nochmal
auf Nummer sicher gehen.
xmega-slave schrieb:> Ich bin mir der absoluten Kompatibilität sicher
Wirklich? Was soll dann die Frage? Deren bloße Existenz ergibt doch nur
einen Sinn, wenn du dir eben nicht sicher bist.
Und vermutlich bist du dir nicht sicher, weil eben ein "Downgrade" nicht
erwartungsgemäß funktioniert.
Wenn das so ist, wäre es nur zu fair, auch uns zu sagen, worauf du
entwickelt hast und worauf es nicht läuft. Dann brauchten wir nämlich
wie du nur zwei XMega-DBs zu vergleichen und nicht ((alle)²-alle)/2.
Häh?
Ich würde ja Fragen, ob es in den Peripherie Modulen Unterschiede gibt
...
Wenn du in C schreibst, sollte es ja s***** egal sein, ob der
Befehlssatz gleich ist.
Oder programmeirst du die in ASM?
Würde ich bei einem solchen Prozessor von abraten ... mal von einzelnen
Timing Sachen die man bei Bedarf dazulinkt abgesehen.
Meiner Kenntnis nach gibt es keinen Unterschied. Aber ASM in einem
Umfang das ich den Befehlssatz wirklich kenne benutze ich nur auf PICs
für low-cost Massenware. Wenn es einen Unterschied gibt, werden das
Sonder Befehle für den größeren Speicherbereich sein behaupte ich jetzt
mal.
Der Code ist in reinem C geschrieben. Also fast nur reinem C. Leider -
was ich überhaupt nicht toll finde - gibt es ja bei jedem Entwickler und
Entwicklungsumgebungen für jeden Microcontroller solche Sonderbefehle.
Ich würde lieber nur den Standard C99-Code benutzen, aber da Atmel auch
für Hobbybastler interessant sein will, erweitern sie den Befehlssatz
mit ihren eigenen komischen Befehlen wie "PORTE.DIR = PIN1_bm" . Sicher
kann man auch diesen Controller mit dem Standard C-Code programmieren
(PORTE.DIR |= 0x01), aber wenn ich schon fertige Code-Snippets und
Treiber implementiere, dann wimmelt es ja schon so von spezifischen
Atmel-Befehlen.
Und diese unterscheiden sich ja schon ATmega zu Xmega. Da hab ich schon
jetzt Angst, dass da auch unter den Xmegas jetzt wieder Unterschiede
gibt.
Ich bin eigentlich Anwendungsprogrammierer in VB, VC++ und VC# und mache
auch gerne Webdesign. Aber jetzt bin ich nun mal zu dieser Arbeit
verdonnert worden.
xmega-slave schrieb:> Und diese unterscheiden sich ja schon ATmega zu Xmega. Da hab ich schon> jetzt Angst, dass da auch unter den Xmegas jetzt wieder Unterschiede> gibt.
Eigentlich ist das schöne an der Xmega-Reihe doch, dass diese quasi
Module haben. Wenn ein Modul vorhanden ist, dann auch vollkommen
identisch. Der USART im XmegaXYZ ist genauso wie XmegaZYX sofern es denn
vorhanden ist. Höchstens die Basisadresse ist anders, also USARTE1
anstatt USARTC1 etc. Und der von dir erwähnte Befehlssatz sind nur
Bitdefinitionen. Ist doch schön wenn man direkt im Quellcode sehen kann
was dieses Bit oder die Gruppe an Bits tut, anstatt jedesmal ins
Datenblatt schauen zu müssen.
Du kannst eine USART_init-Funktion schreiben die nur eine Basisadresse
zum USART-Modul erwartet und kannst sie dann für alle USARTs im Xmega
verwenden, ist doch klasse.
Die Befehle sollten identisch sein, bis auf ggf. Befehle für erweiterten
Speicherbereich, die bei den kleinen Typen, die den nicht haben auch
nicht unterstützt werden. Wenn man in C Programmiert ist das aber auch
egal.
Mit reinem C99 oder ähnlichem kommt man am µC prinzipbedingt nicht aus,
weil da einfach er Zugriff auf die Hardware nicht drin ist. Dafür gibt
es von Atmel (bzw. den anderen µC Herstellern) passend zu den µCs
Include Dateien, die den Hardware spezifischen Teil enthalten - der
eigene Code kann dann reines C sein. Man hat halt nur das Interface zu
den Includes, die je nach µC verschieden sein können, oder wie wie beim
Arduino auch Übergreifend (ARM und AVR) sein können. Auch wenn es nicht
so aussieht passt so etwas wie "PORTE.DIR = PIN1_bm" noch zu C99. Nicht
mehr dem Standrad entspricht die Definition von PORTE.DIR .
Ich verstehe nicht was an "PORTE.DIR = PIN1_bm" nicht Standard sein
soll. PORTE ist ein struct, das global definiert ist, und DIR ist eben
ein Wert davon und PIN1_bm ist ein define auf 0x01. Davon abgesehen ist
dein Code gar nicht identisch. Bei "PORTE.DIR |= 0x01" taucht plötzlich
ein |= auf. Meinest du beim ersten Beispiel eventuell "PORTE.DIRSET =
PIN1_bm"? Hier könnte man auf die Idee kommen, dass Atmel irgendwie
komische Sachen zu C dazu erfunden haben damit "PORTE.DIRSET = PIN1_bm"
identisch zu "PORTE.DIR |= 0x01" ist. Aber tatsächlich existiert das
DIRSET Register in der Hardware und ist kein spezielles
Software-Konstrukt. Das einzige was meiner Meinung nach nicht ganz
Standard ist, sind die Flash/EERROM Attribute aber Hardvard-Architektur
und C passt nunmal nicht so optimal zusammen.
Hi,
also den Unterschied zwischen Definitionen/Makros und "Befehlen" bzw.
dem eigentlichen C sollte schon klar sein. Wie willst Du ohne die
Definitionen programmieren?
*(0x42) = 0x20;
sagt niemandem was, aber bei
TIMERA.TCRA = (1<<TC_ENABLE);
weiß man doch gleich was gemeint ist.
ich finde die Definitionen von Atmel sehr sehr gut & sinnvoll, sogar
besser als die von der STM32-Reihe (aber das ist ein anderes Thema).
