Hallo zusammen,
mein XMEGA-C-Tutorial Teil1 ist online.
Das Tutorial soll den Einstieg in die Programmierung von XMEGA Controller vereinfachen.
Gruß Flo
XMEGA-C-Tutorial Teil1
Moderator: T.Hoffmann
-
CRI 93+ / Ra 93+
- Auserwählter
- Beiträge: 2801
- Registriert: So, 19.10.08, 23:56
- Wohnort: Hannover
Sieht ja recht ansprechend aus, hab's bisher aber nur überflogen.
Seit Kurzem ist übrigens Atmel Studio 6.1 final verfügbar (die 6.1 beta gab's ja schon länger)
Da ist auch ein neurerer gcc mit dabei, der eine neue Speicherklasse für Konstanten kennt, so dass man nicht mehr mit den ganzen *_P-Versionen der Funktionen arbeiten muss. Ob das PSTR()-Macro für direkt in Funktionsaufrufen angegebene Strings, die im Flash, statt im RAM landen sollen nun auch abgelöst wurde, weiß ich aber nicht.
Zusammen mit dem Feature der XMEGA-Reihe, welche einen Modus unterstützen, in dem Zugriffe aufs EEPROM genauso simpel sind wie auf RAM-Variablen, kann man dann ale Speicherbereiche gleichartig ansprechen, wie vom PC gewohnt.
(OK, mit CodeVision ging das schon immer, aber die *_P-Varnainten Funktionen muss man da auch nutzen, wenn man aus dem Flash lesen will)
BTW: was macht dieses Hardware Feature eigentlich bei wiederholtem schreiben des gleichen Inahlts? Vorher prüfen und nur bei Änderung schreiben, oder immer stupide drüberbügeln und das EEPROM abnutzen? Ich vermute letzteres. :-/
Wäre sicher auch Interessant, das bei http://www.mikrocontroller.net und http://www.roboternetz.de zu verlinken, hier im LED-Forum können vermutlich nur sehr wenige was damit anfangen.
Und auch wenn Dein Text in Deutsch ist, wäre ein Link bei http://www.avrfreaks.net/ sicher auch nicht verkehrt --- da sind auch viele deutschsprachige Leute unterwegs.
Seit Kurzem ist übrigens Atmel Studio 6.1 final verfügbar (die 6.1 beta gab's ja schon länger)
Da ist auch ein neurerer gcc mit dabei, der eine neue Speicherklasse für Konstanten kennt, so dass man nicht mehr mit den ganzen *_P-Versionen der Funktionen arbeiten muss. Ob das PSTR()-Macro für direkt in Funktionsaufrufen angegebene Strings, die im Flash, statt im RAM landen sollen nun auch abgelöst wurde, weiß ich aber nicht.
Zusammen mit dem Feature der XMEGA-Reihe, welche einen Modus unterstützen, in dem Zugriffe aufs EEPROM genauso simpel sind wie auf RAM-Variablen, kann man dann ale Speicherbereiche gleichartig ansprechen, wie vom PC gewohnt.
(OK, mit CodeVision ging das schon immer, aber die *_P-Varnainten Funktionen muss man da auch nutzen, wenn man aus dem Flash lesen will)
BTW: was macht dieses Hardware Feature eigentlich bei wiederholtem schreiben des gleichen Inahlts? Vorher prüfen und nur bei Änderung schreiben, oder immer stupide drüberbügeln und das EEPROM abnutzen? Ich vermute letzteres. :-/
Wäre sicher auch Interessant, das bei http://www.mikrocontroller.net und http://www.roboternetz.de zu verlinken, hier im LED-Forum können vermutlich nur sehr wenige was damit anfangen.
Und auch wenn Dein Text in Deutsch ist, wäre ein Link bei http://www.avrfreaks.net/ sicher auch nicht verkehrt --- da sind auch viele deutschsprachige Leute unterwegs.
-
Beatbuzzer
- Auserwählter
- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Ich hatte auch schon überlegt mich mal in die Xmegas einzuarbeiten, da ich teilweise mit Anwendungen bei den Atmegas an Grenzen stoße. Allerdings bin ich mir auch nicht sicher, ob sich die Xmegas dort stark genug absetzen und ob es nicht vielleicht klüger wäre, diese zu überspringen und gleich in was 32-bittiges oder so einarbeiten.
@CRI 93+ / Ra 93+:
Was sagst du denn als Entwickler dazu? Hast du schon mit den AVR32 gearbeitet? Die UC-3 Familie hat ja ähnlich wie die 8-bitter auch internen Flash und RAM, also vom Hardwareaufwand ähnlich...
@CRI 93+ / Ra 93+:
Was sagst du denn als Entwickler dazu? Hast du schon mit den AVR32 gearbeitet? Die UC-3 Familie hat ja ähnlich wie die 8-bitter auch internen Flash und RAM, also vom Hardwareaufwand ähnlich...
Hi Beatbuzzer,
es ist vermutlich schwer pauschal zu sagen ob es gleich besser ist auf 32-Bit umzusteigen. Bei den Atmegas bin ich gerade bei den Timern öfter mal an die Grenzen gestoßen. Da wäre der ein oder andere mehr schon oft besser gewesen. Gerade auch PWM Kanäle hat man halt mehr zur Verfügung und muss nicht sofort auf Software PWM umsatteln. Vergessen sollte man auch die zahlreichen Möglichkeiten duch DMA und Event nicht. Ist halt auch immer eine Frage ob man damit dann die komplizierteren Dinge erschlagen kann oder ob eben allein von den Voraussetzungen/Anforderungen ein 32-Bit Controller das richtigere ist.
Gruß Flo
es ist vermutlich schwer pauschal zu sagen ob es gleich besser ist auf 32-Bit umzusteigen. Bei den Atmegas bin ich gerade bei den Timern öfter mal an die Grenzen gestoßen. Da wäre der ein oder andere mehr schon oft besser gewesen. Gerade auch PWM Kanäle hat man halt mehr zur Verfügung und muss nicht sofort auf Software PWM umsatteln. Vergessen sollte man auch die zahlreichen Möglichkeiten duch DMA und Event nicht. Ist halt auch immer eine Frage ob man damit dann die komplizierteren Dinge erschlagen kann oder ob eben allein von den Voraussetzungen/Anforderungen ein 32-Bit Controller das richtigere ist.
Gruß Flo
-
CRI 93+ / Ra 93+
- Auserwählter
- Beiträge: 2801
- Registriert: So, 19.10.08, 23:56
- Wohnort: Hannover
Die 32bitter habe ich noch nicht benutzt, von den XMEGAs bisher nur den XMEGA32A4U.
Die Endung U besagt, dass er Hardware-USB drin hat (USB 2.0). Noch wichtiger ist aber, dass die Versionen ohne USB ziemlich viele hässliche Bugs im AD-Wandler haben, die bei der USB-Version gefixt sein dürften (zumindest ist die Errata-Liste von ca. 30 auf 3 Einträge geschrumpft). Tendenziell sind die U-Versionen sogar billiger. (Ich vermute die anderen gibt es nur noch als Restbestände)
Es ist schön viel Hardware drin, der interne Takt ist endlich auch in präzise verfügbar und (zumindest lt. Datenblatt, hab's noch nicht untersucht) auch eine der internen Referenzspannungen.
AD-Wandler endlich mit 12 Bit (anderswo schon laaange Standard), das sogar bis 2 MSPS (!!!), differentielle Eingänge ohne seltsame Beschränkungen wie noch beim ATmegaXX4, 0,5-64x gain stage. Und eeeeeeetliches mehr. u.A. so Nettigkeiten, wie die Möglichkeit, bei einem bestimmten AD-Wert einen Interrupt oder ein event auszulösen ...
Es fehlt aber leider ein integrierter OP vor den AD-inputs (die AD-Wandlung belastet die Eingänge, je nach Abtastrate signifikant), dafür kann man auch negative Signale bis ca. -0,4V Messen --- ohne negative Versorgungsspannung. (die Schutzdioden sind hierbei offensichtlich der limitierende Faktor)
Features haben die XMEGAS einfach DEUTLICH mehr und das alles bei fast gleichem Preis wie von Speicher und IO-Anzahl her halbwegs vergleichbare "alte" Atmegas (2-3 Euro). Wenn man jetzt etwas neues mit dem ATMega beginnt, würde ich den XMEGA empfehlen.
Das was am ehesten zu eingeschränkter Eignung führt ist für mich meist zu wenig FLASH oder zu wenig RAM oder beides. Unter 32 kB würde ich heute kein Design mehr anfangen, aber das ist natürlich auch EXTREM von den Anforderungen abhängig.
Aber es gibt auch 32 Bit z.T. derart billig, dass man wirklich überlegen kann sich da mal umzugucken. Bei Mikrocontroller.net wird der STM32 empfohlen (ARM core), geht los ab 1€.
Von ATMega auf XMEGA umzusteigen ist kein gravierender Umstieg, sehr schön sind die wesentlich durchdachteren Include-Files und dass jedes Hardware-Modul an jedem Port identisch angesprochen wird.
Die Endung U besagt, dass er Hardware-USB drin hat (USB 2.0). Noch wichtiger ist aber, dass die Versionen ohne USB ziemlich viele hässliche Bugs im AD-Wandler haben, die bei der USB-Version gefixt sein dürften (zumindest ist die Errata-Liste von ca. 30 auf 3 Einträge geschrumpft). Tendenziell sind die U-Versionen sogar billiger. (Ich vermute die anderen gibt es nur noch als Restbestände)
Es ist schön viel Hardware drin, der interne Takt ist endlich auch in präzise verfügbar und (zumindest lt. Datenblatt, hab's noch nicht untersucht) auch eine der internen Referenzspannungen.
AD-Wandler endlich mit 12 Bit (anderswo schon laaange Standard), das sogar bis 2 MSPS (!!!), differentielle Eingänge ohne seltsame Beschränkungen wie noch beim ATmegaXX4, 0,5-64x gain stage. Und eeeeeeetliches mehr. u.A. so Nettigkeiten, wie die Möglichkeit, bei einem bestimmten AD-Wert einen Interrupt oder ein event auszulösen ...
Es fehlt aber leider ein integrierter OP vor den AD-inputs (die AD-Wandlung belastet die Eingänge, je nach Abtastrate signifikant), dafür kann man auch negative Signale bis ca. -0,4V Messen --- ohne negative Versorgungsspannung. (die Schutzdioden sind hierbei offensichtlich der limitierende Faktor)
Features haben die XMEGAS einfach DEUTLICH mehr und das alles bei fast gleichem Preis wie von Speicher und IO-Anzahl her halbwegs vergleichbare "alte" Atmegas (2-3 Euro). Wenn man jetzt etwas neues mit dem ATMega beginnt, würde ich den XMEGA empfehlen.
Das was am ehesten zu eingeschränkter Eignung führt ist für mich meist zu wenig FLASH oder zu wenig RAM oder beides. Unter 32 kB würde ich heute kein Design mehr anfangen, aber das ist natürlich auch EXTREM von den Anforderungen abhängig.
Aber es gibt auch 32 Bit z.T. derart billig, dass man wirklich überlegen kann sich da mal umzugucken. Bei Mikrocontroller.net wird der STM32 empfohlen (ARM core), geht los ab 1€.
Von ATMega auf XMEGA umzusteigen ist kein gravierender Umstieg, sehr schön sind die wesentlich durchdachteren Include-Files und dass jedes Hardware-Modul an jedem Port identisch angesprochen wird.
Als genialen Vorteil sehe ich die schöne Struktur vom XMEGA. Hat man einen Timer konfiguriert und braucht das selbe nochmal so muss man lediglich ein paar Registernamen ändern. Die Struktur ist aber im Prinzip gleich. Dadurch kann man auch schnell mal vom einen Timer zum anderen wechseln.
Gruß Flo
Gruß Flo