Portierung ATMega -> ATXMega

OP #5310998
Lesenswert?

Hallo Leute,

bislang dachte ich, der ATmega328PB würde für meine Belange ausreichen. 
Stelle aber gerade fest, dass ich doch etwas mehr brauche (noch ein 
UART, gerne 12-Bit Auflösung, mehr Timer mit besseren 
Capture-Möglichkeiten). Am naheliegendsten wäre also der Übergang zu 
einem ATXMega, etwa ATXMega32A4, ein TQFP44 lässt sich auch noch ganz 
gut löten.

Frage zur Portierung (abgesehen von der anderen Modellierung in den 
Header-Files): wie (un)ähnlich sind sich die I2C- (und auch SPI- und 
Uart)-Module?

Danke für sachdienliche Hinweise.
Gast #5311122
Lesenswert?

Die Peripheriemodule unterscheiden sich erheblich, ein Blick in die 
zugehörige Register-Doku zeigt, daß man um eine weitgehende 
Neuprogrammierung nicht herumkommt. Solltest Du etwas "höher", z.B. mit 
Bascom programmieren relativiert sich die Sache natürlich. Tipp zum 
Xmega: Nicht die A4 sondern die A4U Typen wählen, die sind neuer und 
ausgereifter da fehlerfreier.
Gast #5311128
Lesenswert?

Das gilt für alle AtXmegas, immer die -U Varuanten nehmen, also A1U, 
A3U, A4U... Auch niedlich sind die E5, die haben zwar kein USB, sind 
aber sehr klein und haben unheimlich flexible Timer und Custom Logic.
Gast #5311155
Lesenswert?

Normalerweise kapselt man seine Hardwarefunktionen. Dann fällt die 
Portierung leichter. Von Anfang an angewöhnen.

Die Xmegas sind toll, nur leider stimmt das Preis / Leistungsverhältnis 
nicht. Für Hobby aber egal.
Gast #5311273
Lesenswert?

Hans schrieb:
> Nils N. schrieb:
>> Normalerweise kapselt man seine Hardwarefunktionen. Dann fällt die
>> Portierung leichter. Von Anfang an angewöhnen.
>
> Nennt sich dann Arduino und ist ja Böse Böse.

Profis nehmen C, denn C ist ja portabel. Wann, wenn nicht in solcheinem 
Fall, soll denn die "portabilität" von C zum Zuge kommen?
Also einfach neu kompilieren...
Gast #5311285
Lesenswert?

Gast #5311408
Lesenswert?

Stefan U. schrieb:
> Hast du denn einen Programmieradapter und Debugger für den Xmega?
> Wenn nicht, dann vergleiche mal die Kosten

den Adapter kauft man einmal (momentan mal auf Microchip schauen, es 
gibt reichlich Rabatt für den Atmel-ICE). Ein vorhandener AVR ISP mk2 
(ab 20€) langt auch erstmal zum Programmieren. Viel entscheidender ist 
doch der Aufwand zum Umstieg auf eine andere und keinesfalls einfachere 
MC-Plattform. Das macht man nur wenn es sein muß!
Den Bastler interessiert dann auch nicht, daß ein Xmega etwas mehr 
kostet.
Gast #5311621
Lesenswert?

Die XMegas sind auch nur in den Apotheken so teuer. Bei richtigen 
Lieferanten bekommt man die auch recht günstig. Da der Markt aber gerade 
in den letzten Jahren stark fluktuiert, lohnt sich immer, vor einem 
Projektstart noch mal die Preise einzuholen.
Gast #5311623
Lesenswert?

Einfach neu kompilieren reicht bei der Portierung von Mega nach XMega 
aber nicht, auch dann nicht, wenn man in C programmiert. Da viele 
Peripherien komplett anders aufgebaut sind, wegen des DMA ganz andere 
Flags zum Einsatz kommen, die man bei Nichtverwendung des DMA mitunter 
händisch löschen muss, wird es ohne erneuten Einstieg in den Projektcode 
nicht funktionieren. Bestimmte Funktionen werden sicher ohne Modifkation 
einfach laufen, aber auch hier kann man aufgrund des anderen Kerns noch 
weiter optimieren, um beispielsweise Laufzeit zu sparen.
Gast #5311632
Lesenswert?

SPI schrieb:
> Einfach neu kompilieren reicht bei der Portierung von Mega nach XMega
> aber nicht, auch dann nicht, wenn man in C programmiert.

Das hat auch niemand behauptet. Trotzdem ist es wesentlich einfacher und 
simpler, wenn man nur wenige Zeilen ändern muss - anstatt den ganzen 
Assembler überarbeiten zu müssen. Normalerweise kapselt man ja die 
Hardware Funktionen, z.B. in SPI_Send(..); odr InitHardware(); etc.
OP #5311662
Lesenswert?

Danke für die Antworten.
Mir erscheinen die XMegas nach wie vor sehr interessant und auch die 
Portierung sollte kein Hexenwerk sein (C++), allerdings ist es mir doch 
im Moment zu viel Aufwand.
Die andere Alternative ist der AtMega324PB, der hat durch seine 
zusätzlichen Pins nicht das Problem, dass bestimmte HW-Features wegen 
Überlappung nicht nutzbar sind.
Gast #5311751
Lesenswert?

Randy B. schrieb:
> Die andere
> Alternative ist der AtMega324PB, der hat durch seine zusätzlichen Pins
> nicht das Problem, dass bestimmte HW-Features wegen Überlappung nicht
> nutzbar sind

Leider aber jenes schlecht erhältlich zu sein. Mehr ADU-Auflösung wie 
eingangs erwünscht ist auch nicht drin.

Nils N. schrieb:
> Es lohnt sich, du lernst portierbaren Code zu schreiben und du
> lernst das portieren selber.

Was und ob sich etwas lohnt hängt doch sehr vom Einzelfall ab. Meistens 
will man doch mit bestehenden Mitteln einfach nur ein größeres Projekt 
realisiert wissen. Portierbarer Code nutzt auch nicht neue 
Hardware-Funktionen, wie sie die XMegas mitbringen. Je portierbarer 
desto hardware-ferner, langsamer, unflexibler.
OP #5311772
Lesenswert?

Robert schrieb:
> Randy B. schrieb:
>> Die andere
>> Alternative ist der AtMega324PB, der hat durch seine zusätzlichen Pins
>> nicht das Problem, dass bestimmte HW-Features wegen Überlappung nicht
>> nutzbar sind
>
> Leider aber jenes schlecht erhältlich zu sein.

Bei digikey zu bekommen.

> Mehr ADU-Auflösung wie
> eingangs erwünscht ist auch nicht drin.

Das stimmt, wäre aber auch nur ein nice-to-have.

>
> Nils N. schrieb:
>> Es lohnt sich, du lernst portierbaren Code zu schreiben und du
>> lernst das portieren selber.

Den habe ich ;-)

Möchte ich aber neue Features benutzen (DMA, Events, CaptureChannels), 
dann muss ich auch die in meine HW-Abtraktionen einbauen, und das kostet 
dann doch mehr Arbeit, als ich momentan aufwenden möchte.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren