ATXMEGA: Don't Panic!

[Detlev T. (detlevt)]

Hallo Leute

ich bin gerade dabei, von den MEGAs auf die XMEGAs umzusteigen. Der 
erste Schritt war erst einmal ein Schock. Nichts ist noch so, wie ich es 
gewohnt war. Als hätte ich noch nie einen AVR programmiert. Mit Hilfe 
der Appnotes (Treiber) für die Hardware finde ich mich aber inzwischen 
in dem Konzept einigermaßen zurecht. Da kann ich nur jedem anderen auch 
raten, sich die genau anzusehen.

Ich muss da die Ingenieure von Atmel echt einmal loben. Die haben sich 
wirklich Gedanken gemacht, wie man derartige Controller besser 
programmieren kann und hatten den Mut, die ganzen "alten Zöpfe" 
abzuschneiden. Jetzt muss nur noch die Errata-Liste kürzer werden. ;-)

Neueinsteiger aus der PC-Welt haben es wahrscheinlich noch leichter, 
sich hier zurecht zu finden als alte AVR-Hasen, die sich umgewöhnen 
müssen. Das neue Konzept unterstützt eine abstraktere Herangehensweise 
als bisher indem man z.B. einer Routine zur Ansteuerung der Hardware 
einen Zeiger auf die Hardware mitgibt anstatt in deren Quelltext die 
Ports "hard" zu kodieren. Man schreibt also nicht mehr Routinen der Art 
uart_init(), uart1_init() usw. - was bei bis zu 7 USARTs ein nicht zu 
unterschätzender Vorteil ist. :-)

Also - nicht gleich nach dem ersten Blick in die Datenblätter aufgeben. 
Die Mühe lohnt sich meiner Meinung nach. Nur XMEGAs im DIP-Gehäuse 
könnte man noch vemissen.

Gruß, DetlevT

[aaaaa (Gast)]

XMEGAS in DIL/DIP dürfte wohl kaum möglich sein in der größe...

Ist aber auch nicht so schwer zu löten das 0.5mm Raster.


Ja die neuen Atxmegas sind schon recht gut! Kenn sogar einen der hat den 
Webserver (normalerweise atmega32/64?) auf einem atxmega128 zum laufen 
gebracht. war viel arbeit, hat aber funktioniert.

[Visitor (Gast)]

Dein A-Ha Erlebnis hat jeder der einmal von µC X auf µC Y umgestiegen 
ist ;-). Also nicht besonderes !

Wenn du uns im Forum etwas mitteilen möchtes (ausser dass du den XMega 
nun toll findest!) dann beschreib doch mal wo deine Probleme beim 
Umstieg waren, welche Internetseiten dir ggf. weitergeholfen haben etc.

Aber evtl steht du ja noch unter Schock :-)

[Peter D. (peda)]

Detlev T. schrieb:
> und hatten den Mut, die ganzen "alten Zöpfe"
> abzuschneiden.

Leider nicht nur die Zöpfe!

Pin- und spannungskompatibel zu den üblichen ATtiny/ATmega wäre schon 
sinnvoll gewesen.
Dann würde das Pimpen existierender Projekte erheblich leichter fallen.
Aber nichtmal die 64- und 100-Pinner sind pinkompatibel.

Daher, wenn ich eh alles komplett neu machen muß, dann kann ich ja 
gleich nen Cortex M3 nehmen.


Peter

[Simon K. (simon)]

@Peter: Hm, das ist glaube ich nicht so einfach, weil der ATxmega ja 
intern komplett anders funktioniert.

Aber mit dem Cortex M3 hast du Recht. Hab zwar auch schon was mit dem 
ATxmega gemacht, aber so richtig "gezündet" hat der bei mir nicht. Einen 
ARM kriegt man schon fast günstiger, ist schneller, hat 32-Bit und den 
gibt es von mehreren Herstellern.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Detlev T. schrieb:
> Jetzt muss nur noch die Errata-Liste kürzer werden. ;-)

Wird sie aber nicht, denn Atmel kümmert sich nicht drum. Seit der 
Ankündigung der Serie in 2008 ist die Liste nur gewachsen.

[Sebastian H. (sh______)]

aaaaa schrieb:
> XMEGAS in DIL/DIP dürfte wohl kaum möglich sein in der größe...
>
> Ist aber auch nicht so schwer zu löten das 0.5mm Raster.
>

Ich seh das ähnlich wie die anderen. Wenn schon TQFP, dann kann ich 
direkt nen CortexM3 nehmen. Ist auch einfach zu programmieren aber ist 
dann direkt noch ne ganze ecke Leistungsfähiger. Zumal es Preislich 
überhaupt keine Unterschiede macht. Die Cortex bekommt man ja auch schon 
ab 1-2€.

Die XMega wären nur als DIL/DIP interessant wenn man mal schnell ne 
Schaltung auf Lochraster bauen möchte. Aber da tun es im Normalfall auch 
die normalen ATMega :)

[Christoph B. (christophbudelmann)]

Simon K. schrieb:
> Aber mit dem Cortex M3 hast du Recht. Hab zwar auch schon was mit dem
> ATxmega gemacht, aber so richtig "gezündet" hat der bei mir nicht. Einen
> ARM kriegt man schon fast günstiger, ist schneller, hat 32-Bit und den
> gibt es von mehreren Herstellern.

Ich hatte mich auch erst gefragt, wozu der XMega gut sein soll, wenn wir 
doch schon Erfahrungen mit den normalen ATmegas und den Cortex-M3 haben 
- inzwischen möchte ich die XMega aber nicht mehr missen, da wir zum 
einen die AES-Einheit sehr gut gebrauchen können (die selbst in vielen 
Cortex-M3 nicht enthalten ist) und die XMega relativ viele UARTS in 
Bezug auf die Gehäusegröße haben. Viel mehr brauche ich für viele 
unserer Projekte derzeit nicht und da sind die XMegas auch einfach 
günstiger.

[Ben _. (burning_silicon)]

gibts den Cortex M3 als irgendeine DIP-Variante? Ich überlege auch 
schon, mir die dinger mal anzuschauen, aber TQFP lötet sich schlecht auf 
Experimentierplatinen und ich muß auch mal schauen was man da für eine 
Programmierumgebung bzw. Programmer braucht.

[Christoph B. (christophbudelmann)]

Ben _ schrieb:
> gibts den Cortex M3 als irgendeine DIP-Variante? Ich überlege auch
> schon, mir die dinger mal anzuschauen, aber TQFP lötet sich schlecht auf
> Experimentierplatinen und ich muß auch mal schauen was man da für eine
> Programmierumgebung bzw. Programmer braucht.

Die meisten Cortex-M3 kommen mit Bootloader, so dass man nur noch eine 
serielle Schnittstelle benötigt. Ansonsten eignen sich viele 
JTAG-Adapter natürlich auch zum Programmieren. DIP-Versionen kenne ich 
keine, aber es gibt recht viele einfache Eval-Boards. Wir haben uns 
selber mal beispielsweise Platinen gemacht, wo ein STM32F103 drauf 
passt, inklusive USB, LDO, JTAG-Buchse, paar Taster und LEDs und halt 
Stiftleisten zum Aufstecken auf Bread-Boards. Ähnliches gibt es von 
Olimex und anderen Anbietern aber auch.

[Ben _. (burning_silicon)]

Die Bootloader-Variante mag ich nicht. Ich flash die Dinger lieber 
komplett, dann kann man sich keinen Bootloader zerschießen woraufhin man 
sich aus dem Ding aussperrt.

Gibts die Dinger auch mit 40-60 Pins, so daß man sie vielleicht auf 
einer Adapterplatine nach DIP verwenden kann?

[Christoph B. (christophbudelmann)]

Ben _ schrieb:
> Die Bootloader-Variante mag ich nicht. Ich flash die Dinger lieber
> komplett, dann kann man sich keinen Bootloader zerschießen woraufhin man
> sich aus dem Ding aussperrt.

Ich arbeite seit Anfang 2009 mit den STM32, mich auszusperren habe ich 
bislang noch nicht geschafft und es ist mir auch von keinem anderen 
bekannt.

> Gibts die Dinger auch mit 40-60 Pins, so daß man sie vielleicht auf
> einer Adapterplatine nach DIP verwenden kann?

Klar, LQFP-48 beispielsweise.

[Ben _. (burning_silicon)]

Hmm ist die Verwendung eines Bootloaders zwingend notwendig? Wenn nicht 
krieg ich den mit Sicherheit irgendwie getrasht... **fg**

[Christoph B. (christophbudelmann)]

Ben _ schrieb:
> Hmm ist die Verwendung eines Bootloaders zwingend notwendig?

Du kannst auch über JTAG programmieren. Geht zwar schneller, benötigt 
aber einen Adapter und normalerweise mehr Platz auf der Platine.

> Wenn nicht
> krieg ich den mit Sicherheit irgendwie getrasht... **fg**

Sag Bescheid, wenn du es geschafft hast. Mir fällt spontan nichts ein, 
wie man das ohne weiteres hinbekäme (abgesehen vom Zerstören des 
gesamten Chips).

[Ben _. (burning_silicon)]

chip erase?

[Christoph B. (christophbudelmann)]

Ben _ schrieb:
> chip erase?

Löscht zumindest beim STM32 nicht den Bootloader.

[Ben _. (burning_silicon)]

wie kann man ihn dann deaktivieren?

[Peter D. (peda)]

Ben _ schrieb:
> Hmm ist die Verwendung eines Bootloaders zwingend notwendig? Wenn nicht
> krieg ich den mit Sicherheit irgendwie getrasht... **fg**

Ohne Gewähr:
Der Bootloader läßt nur mit parallel Programmierung killen.
Das JTAG läßt sich aber durch Setzen der PLL auf unsinige Werte killen.
Der Bootloader ist somit der Notnagel.

Beitrag "Cortex-M3 "Core is locked-up" (J-Link + Segger)"


Peter

[Christoph B. (christophbudelmann)]

Zwei Pins des Mikrocontrollers dienen zur Auswahl des Speichers, aus dem 
der Mikrocontroller starten soll: User Flash, System Memory 
(=Bootloader) oder SRAM.

[Ben _. (burning_silicon)]

"user flash" ist das on-chip flash, genau wie beim AVR?

[Peter D. (peda)]

Simon K. schrieb:
> @Peter: Hm, das ist glaube ich nicht so einfach, weil der ATxmega ja
> intern komplett anders funktioniert.

Warum sollte man nicht VCC, GND, Reset, XTAL und UART, I2C usw. auf die 
gleichen Pins legen können?
Die zusätzlichen Funktionen kann man ja verteilen, wie man lustig ist.

Ich weiß jetzt nicht, ob das durch Patenschutz gesperrt ist, aber es 
gibt einen PIC, wo die Peripherie ziemlich wahlfrei geroutet werden 
kann.
Sowas hätte man selbstverständlich auch in den XMega einbauen müssen.

Es ist schon seltsam, wie die einzelnen MC-Hersteller absichtlich nicht 
über den Tellerrand schauen und einfach den aktuellen Stand der Technik 
ignorieren.


Peter

[Christoph B. (christophbudelmann)]

Ben _ schrieb:
> "user flash" ist das on-chip flash, genau wie beim AVR?

Ja.

[Sebastian H. (sh______)]

Ben _ schrieb:
> gibts den Cortex M3 als irgendeine DIP-Variante? Ich überlege auch
> schon, mir die dinger mal anzuschauen, aber TQFP lötet sich schlecht auf
> Experimentierplatinen und ich muß auch mal schauen was man da für eine
> Programmierumgebung bzw. Programmer braucht.

Gibt eigentlich für alle Größen Adapterplatinen die man problemlos 
verwenden kann. Kann dann z.B. aussehen wie im angehängten Bild :)

Programmer gibts den J-Link von Segger für 60€ (für Privat). So nen Teil 
für den Preis hätte ich für die ATMegas auch gerne :)

[Ben _. (burning_silicon)]

Au jaaaa ... manhatten-style... **fg**

Kommt der JTAGICE MK2 mit den Dingern klar? Wahrscheinlich nicht, aber 
60 Euro ist auf jeden Fall ziviler als ein JTAGICE.

Schön wäre eine Adapterplatine wo die benötigten Quarze usw. gleich mit 
drauf sind, dann braucht man sich damit nicht mehr auf dem Lochraster 
rumzuplagen.

[Detlev T. (detlevt)]

aaaaa schrieb:
> XMEGAS in DIL/DIP dürfte wohl kaum möglich sein in der größe...

Die 4-er im TQFP-44 Gehäuse haben doch auch nicht mehr Beinchen als ein 
ATMEGA32, oder?

Peter Dannegger schrieb:
> Pin- und spannungskompatibel zu den üblichen ATtiny/ATmega wäre schon
> sinnvoll gewesen.
> Dann würde das Pimpen existierender Projekte erheblich leichter fallen.
> Aber nichtmal die 64- und 100-Pinner sind pinkompatibel.

5V halte ich heute für nicht mehr sinnvoll. Viele Peripherie-ICs 
vertragen nur noch 3,3V. Und die Hardware ist dann doch so 
unterschiedlich, dass ich mich frage, was da "Pinkompatibel" heißen 
soll. Ein funktionierendes Mega-Projekt würde ich nicht auf XMEGA 
umstellen wollen, das ist doch zuviel Arbeit.

Visitor schrieb:
> Wenn du uns im Forum etwas mitteilen möchtes (ausser dass du den XMega
> nun toll findest!) dann beschreib doch mal wo deine Probleme beim
> Umstieg waren, welche Internetseiten dir ggf. weitergeholfen haben etc.

Das größte Problem: Die Peripherie ist nicht mehr da, wo sie war. Und 
sie wird anders angesprochen. Beispiel: PB4 als Eingang konfigurieren:

alt:
DDRB &= ~(1 << PB4);
neu:
PORTB.DIRCLR = PIN4_bm;

Diese Struktur bringt mich auch dazu, die Treiber deutlich abstrakter zu 
schreiben. Eine blinkende LED an PB4 würde ich z.B. jetzt so machen:

#include <avr/io.h>
#include <util/delay.h>

typedef struct{
                 Port_t * port;
                 uint8_t pin_bm;
                 } LED_t;

void LED_init(LED_t * led)
{
  led->port->DIRSET = led->pin_bm; // Pin als Ausgang
} 

void LED_toggle(LED_t * led)
{
  led->port->OUTTGL = led->pin_bm;
}

int main(void)
{
  LED_t led;

  led.port = &PORTB;
  led.pin = PIN4_bm;
   
  LED_init(&led);

  while(1)
    {
      LED_toggle(&led);
      _delay_ms(250);
    }
}

Vorteil: Ist bei meinem nächsten "Projekt" die LED an einem anderen Pin, 
muss ich nur die Werte im LED_t-struct ändern, nicht mehr den Quelltext 
des Treibers. Das ist viel eleganter, aber ich muss mich halt stark 
umstellen. Geholfen haben mir da die Texte und vor allem der Quelltext 
der Appnotes von Atmel für die Peripherie, um dieses Prinzip zu 
verstehen.

[2ter Gast (Gast)]

Detlev T. schrieb:
> Ist bei meinem nächsten "Projekt" die LED an einem anderen Pin,
> muss ich nur die Werte im LED_t-struct ändern, nicht mehr den Quelltext
> des Treibers. Das ist viel eleganter, aber ich muss mich halt stark
> umstellen. Geholfen haben mir da die Texte und vor allem der Quelltext
> der Appnotes von Atmel für die Peripherie, um dieses Prinzip zu
> verstehen.

Alternativ schon mal über defines nachgedacht

#define   LED_PORT      PORTB
#define   LED_PIN_BM    (1U << 1U)

[Detlev T. (detlevt)]

2ter Gast schrieb:
> Alternativ schon mal über defines nachgedacht

Ja klar, so geht es auch - bis man zwei LEDs blinken lassen will. Ich 
brauche dann nur eine zweite Variable vom Typ LED_t - und du? :-)

Die MEGAs hatten bislang nur eine SPI-Schnittstelle, eine TWI und ein 
USART (ja,ja, inzwischen gibt es auch welche mit zweien). Da gab es 
keine Auswahl. Die XMEGAs haben da viel mehr. Da will ich doch nicht für 
jeden der 7 USARTs eigene Routinen schreiben müssen - auch wenn das 
größtenteils Copy&Paste ist.

Das ist so schon eine prima Idee.

[2ter Gast (Gast)]

Detlev T. schrieb:
> Ja klar, so geht es auch - bis man zwei LEDs blinken lassen will. Ich
> brauche dann nur eine zweite Variable vom Typ LED_t - und du? :-)

Letzlich ist der Schreibaufwand gleich, nur belege ich bei LED usw. mit 
ner Variable keinen Speicher. Du musst die ja auch erstmal 
"initialisieren".
Ich schreibe weiteres define. Deine Abstraktion zum Ansteuern der Port 
Pin finde ich nicht elegant.

Und natürlich mache ich kein Copy&Paste bei identischen Peripherals. Die 
"Idee" mit den structs von Atmel ist ein alter Hut.