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.
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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.