mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATXMega128 - Erste Erfahrungen


Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forumgemeinde,

in Anlehnung dessen, daß sich die ersten Muster der neuen AVR-Familie 
bei mir eingefunden haben, möchte ich dieses Thema eröffnen, um 
kommenden ATXMEGA-Einsteigern die ersten Stunden mit den neuen "Gerät" 
zu erleichtern. Gleich vorneweg: zum Programmieren und Debuggen braucht 
es momentan einzig und allein das STK600 und einen passenden Aufsatz 
(TQFP100 in diesem Fall) oder alternativ ein JTAG-ICE mkII, da kein 
anderer Programmer diesen neuen Controller unterstützt. Der Preis für 
das STK600-Bundle liegt - je nach Anbieter - bei 240 bis 270 Euro inkl. 
Steuer. Von Nutzen sind ebenfalls das aktuellste AVR-Studio4.14 und die 
von ATMEL herausgegebenen Datenblätter, Manuals und Application Notes. 
In der aktuellen Version des XMega A1 haben sich übrigens einige Errata 
eingeschlichen, auf die im Datenblatt hingewiesen wird. Die Vielfalt der 
integrierten Peripherie jedoch setzt den Anwender vor ganz neue 
Perspektiven! Die Datenblätter sind momentan noch nicht ganz 
vollständig, es macht Sinn, von Zeit zu Zeit aktualisierte Versionen bei 
ATMEL herunterzuladen. Die Serienproduktion für den ATXMega128 A1 steigt 
laut ATMEL im Juli, so daß die Teile auch bald regulär käuflich erworben 
werden können.

Unterstützung von meiner Seite wird es hauptsächlich in Assembler, sowie 
technischen Dingen rund um die Hardware geben, C-Programmierer können 
sich gerne einschalten, um ihre Berichte zu den gängigen Compilern in 
Verbund mit dem XMega abzugeben. Ich freue mich auf eine gute 
Zusammenarbeit ;-).

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es eigentlich günstige Nachbauten für den JTAG-ICE mkII? Der kostet 
ja ne ganze Menge...

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie siehts mit dem ISP-MK II aus?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR-ISP mkII unterstützt (derzeit) das PDI nicht, welches für das 
Programmieren notwendig ist. Kompatible JTAG Programmiergeräte 
unterstützt AVR-Studio nicht. Die Programmierer von 3rd Party 
Programmiersoftware werden sicher nachziehen und auch Schnittstellen für 
andere Programmiergeräte anbieten, aber momentan halt noch nicht.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann kann man glatt dein Eindruck kriegen, dass Atmel sich mit den 250€ 
Einrichtungsgebühr die Bastler vom Leib halten will.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist Unsinn. Wenn Du Dir mal anschaust, was die Geräte können, sind 
sie ihren Preis absolut wert. Zumal die AVR-Controller günstig sind. 
Schau Dir mal andere Entwicklungsumgebungen an. Wenn man das Geld nicht 
auf Tasche hat, kann man sich auch ein Mal in 5 Jahren ein Board von der 
Familie schenken lassen ;-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts gegen das STK600, aber dass es keinen einfacher Programmer gibt 
irritiert mich.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Dann kann man glatt dein Eindruck kriegen, dass Atmel sich mit den 250€
> Einrichtungsgebühr die Bastler vom Leib halten will.
Nö.
Wenn du mit den Atmel STKs einen 'normalen' Atmega im TQFP-Gehäuse 
bearbeiten willst, sind da ebenfalls 180-200 Euro zu investieren.
Im Falle der TQFP100-Varianten sind es ~260 Euronen (STK500 & 
STK503-Aufsatz). Die STKs sind dauerhaft in dieser Preisebene 
angesiedelt. Die Lösung können sein: Preiswerte Adapterplatinen, die 
eben den TQFP100/64 auf lochrastergerechte Stiftleisten umsetzen. Sowas 
gibt es für ATMega128 bereits von diversen Anbietern. Bleibt nur noch 
der PDI-Port, da wird sich mit Sicherheit auch was tun (OpenSource und 
anderes), wenn die ATXMegas im normalen Handel auftauchen.

Gruß
Jadeclaw.

Autor: klausy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin, was mir als erstes aufgefallen ist: die internen RC-Clocks sind ab 
werk relativ ungenau kalibriert. Hab zwischen meinen beiden Mustern fast 
10% unterschied. Hab allerdings noch nicht nachkalibriert. Atmel gibt 
1-2% über den gesamten Temp. und Spg. Bereich an. (Sehr optimistisch!)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um professtionell arbeiten zu können und aktuell zu bleiben, führt kein 
Weg an den STKs vorbei. Alternativen mit mehr oder weniger guter 
Qualität und Funktionalität wird es immer geben. Supportanfragen 
gestalten sich mit originaler Hardware allenfalls konkreter.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Primär dient der interne Oszillator nur als Starthilfe bzw. Failsafe 
Taktgeber. Für genauere Anforderungen sind externe Takgeber angebracht. 
Was ich gar nicht mal dumm finde, ist die Konfigurierbarkeit der 
Taktquellen per Software und nicht wie bisher per Fuse. Das Verhunzen 
der Controller durch abgeschaltete Taktquellen gehört somit der 
Vergangenheit an.

Das Muster hier läuft mit internem Taktgenerator bei: 2000.0997 Mhz 
(25°C).
Also gar nicht mal so schlecht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Dann kann man glatt dein Eindruck kriegen, dass Atmel sich mit den 250€
> Einrichtungsgebühr die Bastler vom Leib halten will.

Bastler sind einfach mal nicht der Fokus, denn damit macht man als
Firma nicht den nötigen Gewinn, um die immensen Kosten für den
Serienstart einer neuen IC-Klasse wieder einzuspielen.  Damit zählt
zwangsläufig anfangs erst einmal nur das, was die Hauptkunden
interessiert, damit man diese möglichst schnell ins Boot bekommt.

Machbar ist viel.  Weiß nicht, ob die Hardware eines AVRISP mkII
tatsächlich PDI-tauglich ist (die erste Hardwareversion der JTAG ICE
mkII ist es leider nicht), aber zumindest sollte die Dragon-Hardware
auf jeden Fall ein Programmieren via JTAG erlauben.  Es ist eben nur
einfach eine Frage der Ressourcen, solche Dinge bei Atmel nachzuziehen.
Rom wurde dem Hörensagen nach auch nicht an einem Tag erbaut. ;-)

Ich kann mir übrigens vorstellen, dass man den Dragon bereits so, wie
er ist, für eine JTAG-Programmierung benutzen kann und dass dies nur
noch keiner getestet hat -- ich auch nicht.  Für AVR Studio wäre dafür
eigentlich nur der entsprechende tag im ATxmega128A1_revD.xml notwendig.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:

> Das Muster hier läuft mit internem Taktgenerator bei: 2000.0997 Mhz
> (25°C).

Wow, ein 2-GHz-Prozessor! :-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Das Muster hier läuft mit internem Taktgenerator bei: 2000.0997 Mhz
> (25°C).
> Also gar nicht mal so schlecht.
In der Tat... 2 Gigahertz für nen AVR, das ist in der Tat nicht schlecht 
SCNR :-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Per JTAG kannst Du mit jedem Programmer an den XMega, du brauchst dafür 
nur die passende Software und da hakt es. Der Dragon unterstützt den 
XMega momentan auch über JTAG noch nicht, sagt AVR-Studio (probieren 
kann ich es hier gerade nicht). Für PDI braucht´s übrigens keine 
spezielle Hardware, der Reset-Pin und ein Datenpin + Masse werden dazu 
benötigt. Allerdings ist der Datenpin bidirektional und es wird eine 
synchrone UART mit 1s8d1p2s nachgebildet. Ein Programmer, dessen 
Controller-Anschlüsse direkt mit dem ISP-Header verbunden sind, sollte 
durch eine neue Firmware in der Lage sein, das PDI-Protokoll zu 
bedienen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Das Muster hier läuft mit internem Taktgenerator bei: 2000.0997 Mhz
>> (25°C).
>> Also gar nicht mal so schlecht.
>In der Tat... 2 Gigahertz für nen AVR, das ist in der Tat nicht schlecht
>SCNR :-)

Grrr - soll natürlich 2.097 Mhz heißen. Verdammte Null...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:

> Für PDI braucht´s übrigens keine
> spezielle Hardware, der Reset-Pin und ein Datenpin + Masse werden dazu
> benötigt.

Dem widerspricht die Aussage von Atmel, dass das JTAG ICE mkII erst
mit der neueren Hardware-Version (die mit der LED drinnen nebem dem
USB-Port) in der Lage sein wird, PDI zu reden, während die alte
Board-Version dazu nicht in der Lage sein wird.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich sind die Pins des Hauptcontrollers bei der alten 
Hardware-Revision nicht direkt, sondern über Glue-Logic oder 
Levelshifter angebunden, die eine bidirektionale Nutzung nicht erlauben. 
Insofern kein Widerspruch, sondern eine Einschränkung der alten 
Hardware. Lies meinen oberen Post nochmal bis zum Ende ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:

> Wahrscheinlich sind die Pins des Hauptcontrollers bei der alten
> Hardware-Revision nicht direkt, sondern über Glue-Logic oder
> Levelshifter angebunden, die eine bidirektionale Nutzung nicht erlauben.

Levelshifter sind aber samt und sonders überall bei den Atmel-Tools
üblich (und notwendig), einschließlich des AVRISP mkII.  Selbst der
AVR Dragon hat welche.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann man ja mit dem usbprog was machen. Eine experimentelle 
JTAG ICE mkII firmware existiert ja schon.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Levelshifter sind aber samt und sonders überall bei den Atmel-Tools
>üblich (und notwendig), einschließlich des AVRISP mkII.  Selbst der
>AVR Dragon hat welche.

Das ist schon okay, aber die Bidirektionalität ist es, die das PDI 
ermöglicht oder eben nicht, da der Controller nur programmiert werden 
kann, wenn die von ihm zurückgegebenen Daten passen. Somit scheiden die 
Programmer aus, die auf dem ISP nur Einrichtungsverkehr zulassen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei ein abschaltbarer Output und ein Input zusammen eine 
bidirektionale Leitung ergeben. Da ISP neben Reset noch 2 Ausgänge und 
einen Eingang hat, sollte das ausreichen.

Autor: Jens343 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Xmegas sind ganz schön fette Burschen, geht da nichtmehr über ISP 
programmen?

Ich hab da nen einfachen Widerstandsprogrammer, damit kommt ein 
Bootloader drauf und Ruhe ist

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genau das ist derzeit die Diskussion

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell läuft denn so die Programmierung über den 
Eindraht-Programmierer? Da kann man sich ja Kaffee holen gehen, bei den 
Programmspeichergrößen ;)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Da kann man sich ja Kaffee holen gehen, bei den
> Programmspeichergrößen ;)

Warum sollte die langsamer sein? Die Kommunikation ist von Natur aus 
eher half- als full duplex, denn dem grossen Programm in eine Richtung 
stehen nur kleine Bestätigungen in den andere Richtung entgegen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das PDI ist mindestens genau so schnell, wie seinerzeit das ISP mit dem 
STK500. Schön ist, daß man keine Programmierfrequenz mehr einstellen 
muß. 128kByte lesen dauert 3 Sekunden. Schreiben kann ich jetzt nicht 
probieren, mein derzeit nur 2kByte kurzes Programm ist in 
Sekundenbruchteilen übertragen.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> [...] Machbar ist viel.  Weiß nicht, ob die Hardware eines AVRISP mkII
> tatsächlich PDI-tauglich ist (die erste Hardwareversion der JTAG ICE
> mkII ist es leider nicht)[...]

Heißt das, dass man beim Kauf eines JTAG ICE mkII aufpassen muss, welche 
Version man kauft, da nicht alle den XMega programmieren können?
Woran erkenne ich soetwas (zum Beispiel beim Kauf über das Internet)?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der JTAG-ICE, egal welche Revision, JTAG kann, kann er die XMEGAs 
natürlich über JTAG programmieren. Kostet im Design halt 4 I/O-Pins...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. N. wrote:

> Heißt das, dass man beim Kauf eines JTAG ICE mkII aufpassen muss, welche
> Version man kauft, da nicht alle den XMega programmieren können?
> Woran erkenne ich soetwas (zum Beispiel beim Kauf über das Internet)?

. zusätzliche LED innen neben dem USB-Port, die bei aktiver USB-
  Verbindung leuchtet (sieht man durchs Gehäuse durch)

. Seriennummer beginnt mit B statt A; diese steht auf dem Etikett
  auf der Rückseite, man kann sie aber auch über USB selbst
  auslesen.  Alt: 00:A0:00:00:4C:A5, Neu: 00:b0:00:00:09:f3

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, jetzt ist es auch bei den billigen Plätzen hier hinten 
angekommen :) Danke

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es ein 'Papier', ob sich der ATXMEGA überhaupt noch 'lohnt'?  Oder 
soll man  gleich auf einen 32-Bitter, wie den AT91SAM7S256, umsteigen?

Autor: Botti Blöedsinn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute mal eher das die XMEGAs auf lange Sicht die älteren Megas 
ablösen werden (in einigen Jahren)???

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulli wrote:

> Gibt es ein 'Papier', ob sich der ATXMEGA überhaupt noch 'lohnt'?  Oder
> soll man  gleich auf einen 32-Bitter, wie den AT91SAM7S256, umsteigen?

Sind völlig verschiedene Latschen.  Der Xmega zielt auf das obere
Ende klassischer 8-bit-Controller, also zwar eine Leistungssteigerung
gegenüber existierenden ATmegas, aber bei gleichem oder geringerem
Energieverbrauch.

Ein 32-Bit-Controller (SAM7, AVR32 UC3) ist zwar noch schneller, wenn's
ums Rechnen geht, aber braucht eben auch mehr Strom, und ein
Peripheriekonzept wie die Events beim Xmega ist nun wirklich mal
eine Innovation (deren Wert sich natürlich noch in der Praxis beweisen
muss).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Das PDI ist mindestens genau so schnell, wie seinerzeit das ISP mit dem
> STK500. Schön ist, daß man keine Programmierfrequenz mehr einstellen
> muß. 128kByte lesen dauert 3 Sekunden. Schreiben kann ich jetzt nicht
> probieren, mein derzeit nur 2kByte kurzes Programm ist in
> Sekundenbruchteilen übertragen.

Klar, aber wenn man dann schon 512kByte an Flash hat.. Das läppert sich 
würde ich sagen.
Nichts desto trotz hätte man die 512kByte nicht schneller mit dem ISP 
programmieren können, das glaub ich euch. Also eigentlich völlig im 
Rahmen die Programmierzeit.

Gibts eine feste Programmierfrequenz? Oder wie läuft's da?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die PDI-Frequenz ist immer dieselbe, und zwar 2Mhz, egal ob der 
Controller selbst mit 2Mhz oder 32Mhz getaktet wird.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>in Peripheriekonzept wie die Events beim Xmega ist nun wirklich mal
>eine Innovation

Kann dazu mal jemand kurz beschreiben, was diese events sind und wofür 
sie gut sind?

Danke.

Steffen.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simpel die Hardwaremäßige Verknüpfung eines HW-Ereignisses wie Input 
Capture, ADC Wandlung, Timer Compare etcp.pp. mit einer anderen 
Hardwaremäßigen Aktion wie DMA Speicheroperation, Timer Capture etc.pp.

Beispiel: Aktion ADC Wandlung fertig als Event wird per Hardware 
verknüpft mit DMA Opatation die das ADC Ergebinss (2 Bytes) in den SRAM 
speichert, linear und sequentiell in einen voher festgelegten Buffer. 
Jedesmal wenn nun eine ADC Wandlung fertig ist kopiert der AVR 
vollständig unabhängig von Software die Resulate in den SRAM. Man muß 
nur alles per Sofwtare einmalig einstellen und wartet dann ab bis der 
zb. 1024 Worte große SRAM Buffer mit den Messwerten von 1024 ADC 
Wasndlungen befüllt wurde.

Noch interssanteres Beispiel: Timer Input Capture -> DMA. Nun messen wir 
ein Rechtecksignal aus, jeweils von Flank zu Flanke möchten wir die 
Timertick messen. Per DMA programmieren wir einen Datenbuffer im SRAM 
der 1024 solcher Meßergebnisse aufnehmen kann. Nun starten wir die 
Messung und bekommen nach 1024 Flankenwechsel vom DMA Controller einen 
Interrupt der uns sagt das alle 1024 Flankenwechsel fertig gesampelt 
wurden. Alles erfolgt vollständig per Hardware und ohne weiteren 
Software eingriff.

Oder auch umgekehrt: DMA Operation befüllt Timer Compare bei jedem 
Timeroverflow mit neuen Daten aus dem SRAM. So lassen sich also zb. aus 
einer Sinustabelle im SRAM direkt und ohne weitere SW EIngriffe die 
Output Compare Register der Timer befüllen. Am OCR Ausgang noch ein 
Tiefpassfilter und fertig ist die Sinusspannung produziert pwe PWM. Dazu 
wird nur einmalig per Software alles initaisiert und gestartet, der Rest 
(Timergesteuertes Auslesen der Sinustabelle aus dem Speicher, auch FLASH 
geht) erfolgt per Hardware selbständig.

Oder einfach: Timer soll ADC Messungen starten. Timer Event verknüft mit 
ADC. Oder Timer0 Overfloe Event taktet Timer 1. Ergo aus 2 16 Bit Timern 
mache einen 32 Bit Timer.

Ich persönlich finde diese Events im gesmmten Zusammenhang mit 
DMA,Timern/ADC etc.pp. als die für mich interessante Innovation. Umgeht 
man doch damit das probem das man normalerweise ohne diese HW-Events 
alles per IQRs+Softwarehandler machen müsste (also so wie bisher auf 
AVR8).

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>aber braucht eben auch mehr Strom, und ein
>Peripheriekonzept wie die Events beim Xmega ist nun wirklich mal
>eine Innovation (deren Wert sich natürlich noch in der Praxis beweisen
>muss).

Sehe ich auch so, Bauchschmerzen könnte der geringe SRAM machen und die 
Beschränkung auf die geringe Anzahl an Events/DMA Kanälen. Für solche 
autom. DMA Operationen denke ich wäre es ein "Optimierungsziel" die 
asynchrone Bearbeitung der so gesammelten Daten möglichst Intervallmäßig 
größer auslegen zu können. Das bedarf aber dann möglichst viel SRAM 
Speicher, und 4Kb scheinen mir da zu wenig.

Ich werde auf alle Fälle bei meinem ersten XMega den ich in die Finger 
bekomme den DMA Transfer aus dem FLASH (XMega kann linear auf 
SRAM/FLASH/EEPROM zugreifen, hoffentlich auch per DMA) in die Timer 
Compare Register ausprobieren. Also Sinustabelle im FLASH und per DMA 
wird TC gefüttert und am OCR Pin ein Tiefpass dran.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Beispiel:

SD Karte per SPI. Man initialisiert einen 512 Bytes großen Datenbuffer 
im SRAM und per DMA wird das SPI gefüttert. Also Event "SPI fertig" 
lösst DMA Transfer vom nächsten Datenbyte im 512 Bytes SRAM Buffer aus 
und kopiert von dort das Datenbyte in das SPI Datenregister. So 
transferiert man 512 Bytes = einen SD Karten Sektor, komplett in 
Hardware. Das geht natürlich auch umgekehrt, also SPI auslesen nach 
SRAM.

Oder man benutzt die vielen UARTs im I2S Modus und hat einen synchron 
arbeitenden Codec am AVR angeschlossen (also Stereo DAC oder MP3 Codec).
Der Transfer der Daten aus dem SRAM Buffer ewrfolgt dann vollständig in 
HW.
Den DMA kann man so einstellen das er mit Doublebuffering arbeitet. Man 
hat also 2 Buffer. Einer dieser Buffer wird per DMA gerade an die HW 
Peripherie übertragen den anderen Datenbuffer wird man per Software 
befüllen/berechnen. Wenn nun der DMA fertig ist switcht der autom. auf 
den zweiten Buffer und meldet dies per IRQ. Nun beackert die Software 
den ersten Datenbuffer und das geht dann immer reihum.

Die Events im Zusammenhang mit der Peripherie des DMA, lineare 
Speicherzugriffes auf SRAM/FLASH/EEPROM, den flexblen UARTs mit 
fraktional Baudrateerzeugung, den Timern Output Compare und Input 
Capture, SPI, TWI, ADC etc.pp. machen einen Sinn. Ohne diese Anbindung 
wären die Events so ziemlich stumpfe Instrumente.

Gruß hagen

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
> Event System

Das nenne ich wirklich krass! :O Was soll der Prozessor denn jetzt 
überhaupt noch selber machen? ;) Der hat ja quasi gar nix mehr zu tun 
dann, hehe.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Event System

>Das nenne ich wirklich krass! :O Was soll der Prozessor denn jetzt
>überhaupt noch selber machen? ;) Der hat ja quasi gar nix mehr zu tun
>dann, hehe.

Naja, du kannst dich in Software dann auf das wirklich wichtige 
konzentrieren, die Auswertung der gesammelten Daten bzw. die Berechnung 
der auszugebenden Daten. Und sehr oft ist es der Fall das zb. bei 
IIR/FIR Filtern oder Dekodern der Algorithmus wesentlich effizienter zu 
bauen ist wenn man einen Block von Daten in einem Rutsch abarbeiten kann 
statt Sample für Sample. Zb. bei der FFT, Fast Hadamard Transformation 
usw. ist dies so.

Davon abgesehen verspreche ich mir davon das das Gesamttiming stabiler 
bzw. berechnebarer wird, da nun andere IRQs die per Software behandelt 
werden müssen diese transparent in HW ablaufenden Prozesse nicht stören 
sollte. Auch aus dieser Sicht macht ein priorisierbarer Interrupt 
Controller wie im XMega einen Sinn.

Gruß Hagen

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn jemand schon einmal Geisterpreise für XMEGAs z.B. 128 zu Ohren 
bekommen, wie sie für kleine bis mittlere Stückzahlen verlangt werden 
werden.
8-Bitter immer weiter zu 'tunen' hat auch seine Grenzen. Wenn der Preis 
nicht zusagt, kann man doch gleich bei 32-Bittern Umschau halten. 
Abgesehen von der Stromaufnahme (für wen von uns ist die schon zwingend 
niedrig zu halten?) haben 'dickere' Prozessoren viele der neuen 
Eigenschaften schon lange zu bieten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erinnere mich an Statements, dass zumindest längerfristig die
Preise für ATxmegas geringer sein sollen als für vergleichbare
derzeitige ATmegas.

> 8-Bitter immer weiter zu 'tunen' hat auch seine Grenzen. Wenn der Preis
> nicht zusagt, kann man doch gleich bei 32-Bittern Umschau halten.
> Abgesehen von der Stromaufnahme (für wen von uns ist die schon zwingend
> niedrig zu halten?)

Für alles, was von Batterien betrieben werden soll.

> haben 'dickere' Prozessoren viele der neuen
> Eigenschaften schon lange zu bieten.

Nö, die Event-Geschichte scheint derzeit wirklich beispiellos zu sein.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nö, die Event-Geschichte scheint derzeit wirklich beispiellos zu sein.

Habe ich auch noch nirgends gesehen mit der Ausnahme das das DMA 
Handling in vielen größeren Kontrollern ebenfalls per Ereignisse durch 
andere Peripherie ausgelösst werden kann. Das bezieht sich aber nur auf 
DMA.

Aus meiner Sicht ist die umfassende Anbindung dieses Eventsytemes 
entscheidend und nicht nur für Batterieanwendung ein Vorteil. Ich denke 
das man damit auf solchen 8-Bittern nun auch Aufgaben erledigen kann die 
man ohne das System nur auf größeren MCU hätte machen können. Ergo: der 
Anwendungsbereich der XMega deckt einen kleinen aber nicht 
unentscheidenden Bereich von Anwednungen von größeren Kontrollern ab, 
und das dürfte wohl ein Kriterium für Atmel gewesen sein diese zu 
produzieren.

Das einzige was jetzt noch fehlt wäre ein DSP Coprozessor und MAC Befehl 
wie beim DSPIC, dann stünde dem Soft-MP3-Dekoder nichts mehr im Wege ;)

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 8-Bitter immer weiter zu 'tunen' hat auch seine Grenzen. Wenn der Preis
> nicht zusagt, kann man doch gleich bei 32-Bittern Umschau halten.
> Abgesehen von der Stromaufnahme (für wen von uns ist die schon zwingend
> niedrig zu halten?)


Hast du schon mal einen BLDC, Sinuswellen Motoransteuerung, 
Phasengleichrichter, DC-DC-Wandler, intelligenten Akkulader mit einem 
32-Bitter gesehen ? Alles perfekte Aufgaben für die XMegas, und das noch 
Energiesparend wo es auch drauf ankommt. Ich sage nur Timer/High 
Resolution System/Advance Waveform Generation/Fault Protection System.

Gruß Hagen

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen schrieb:
>Oder man benutzt die vielen UARTs im I2S Modus und hat einen synchron
>arbeitenden Codec am AVR angeschlossen (also Stereo DAC oder MP3 Codec).
>Der Transfer der Daten aus dem SRAM Buffer ewrfolgt dann vollständig in
>HW.

Wo hast´n das mit dem I2S her? Ich habe nur etwas von SPI-Mode für die 
UARTs gelesen.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm mit AVR32 verwechselt, sorry. Aber schön wärs gewesen, so muß man 
halt die DACs dafür nehmen, geht ja auch.

Gruß Hagen

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, 12 Bit sind immerhin >60 db Dynamik. Aber vielleicht kann man mit 
dem SPI-Mode auch I2S simulieren - hat man dann zwar 4x pro Kanal und 
Sample ein Event aber das könnte man möglicherweise geschickt 
verknüpfen... Muß man mal tiefer einsteigen...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ich weiß nicht so recht. I2S, besonders für Stereo Audio DAC, 
benötigt dann einen Links/Rechts Mastertakt. Diesen müsste man "von 
Hand" erzeugen, oder aber per synchronen Timer der dann exakt synchron 
zum SPI das dann per Events und DMA arbeitet.

Man könnte ja die Auflösung der DACs um zb. 1 Bit erhöhen indem man 4x 
schneller die Daten raussendet und dann per anologen Filter noch 
glättet. Dazu müsste man zb. den DAC Wert 128.5 simulieren indem man 
abwechselnd 128,129,128,129 raussendet.

Gruß hagen

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde mir wohl im Sommer mal die entsprechende Ausruestung holen, da 
hab ich wieder Geld uebrig.

Autor: JPR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hagen
Xmega kann per DMA nur aus EEPROM lesen, Flash geht nicht. Beschreiben 
geht gar kein NVM.

Außerdem frage ich mich, wie der DMA für die zeitkritschen Dinge des 
Lebens einsetzbar ist, immerhin gibt es nur einen Bus, den er sich mit 
der CPU teilen muss (und die ist dominant)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wirklich schade, wo im Datenblatt steht das ? Ich sehe nur das man den 
kompletten Addressbereich per DMA addressieren kann.

Über das Timing habe ich mir auch schon Gedanken gemacht, leider findet 
man derzeit darüber keine AppNotes. Normalerweise verstehe ich unter DMA 
zwei Dinge, 1.) direkter Speicherzugriff ohne CPU Interventionen und 2.) 
davon abgeleitet paralleler Zugriff durch CPU und DMA Controller auf 
Resourcen.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok gerade mal nachgelesen, Recht hast'e.
Es kann ja auch garnicht anders sein da das FLASH eben nicht linear im 
Addressbereich sichtbar ist, also nur SRAM, EEPROM und ext. MEM.
Ebenfalls ist es so das die CPU die Buspriorität hat, was allerdings 
nicht so dramatisch sein dürfte. Im Normalfall greift die CPU ja öfters 
auf den FLASH zu und damit nicht über den Bus, oder ? Dh. nur wenn CPU 
und DMA gleichzeitig auf SRAM/EEPROM/ExtMEM/Peripherie zugreifen wollen 
gibts diese Kollisionen.

Schade schade, hatte schon in Gedanken damit gespielt meine großen 
Wavetables im FLASH per DMA an den Timer Compare zu schicken.

Umsomehr finde ich die 4Kb SRAM als zu wenig, bei den kleineren XMegas.

Jetzt verstehe ich auch warum es diesen Bursttransfer gibt.

Gruß Hagen

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Außerdem frage ich mich, wie der DMA für die zeitkritschen Dinge des
>Lebens einsetzbar ist,

Noch so ein Ketzer :-)
In der AVR1600 soll ein Quadraturdecoder beschrieben sein. Nur ist diese 
Applikationsbeschreibung nirgends zu finden. Die H8S.... haben diesen 
schon 2-fach als Hardware auf dem Chip.
Gerne hätte ich bei den USARTs größere RX-FIFOs gesehen, aber da muß man 
wohl auch gleich DMA o.ä. einsetzen.
Daß man größere Speicher anschließen kann ist schön, aber der Zugriff 
mit 16-Bit Zeigern auf größere Speicherbereiche ist suboptimal.
Berechnungen von int, long oder float werden nur proportional zur 
Taktfrequenz schneller.

Erst, wenn die Teile auf dem Tisch liegen, wird sich zeigen, was man 
wirklich brauchen kann. Solange die Datenblätter nicht detailiert 
vorliegen, werde ich noch Abwarten, was wirklich geht - und was nicht. 
Soviel Zeit muß sein.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:

> Berechnungen von int, long oder float werden nur proportional zur
> Taktfrequenz schneller.

Jein.  Der Speicherzugriff ist schneller geworden, interner SRAM wird
jetzt in einem Takt statt bisher zwei Takten zugegriffen.  Das wird
sich schon auf die effektive Rechengeschwindigkeit auswirken.

Autor: JPR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hagen
Immerhin:

Man kann mit den Bus Mastern (CPU, DMA Read, DMA Write) gleichzeitig auf 
verschiedene Busslaves (I/O Mem, SRAM, EBI, EEPROM) zugreifen und somit 
ein bisschen was parallel erledigen (vgl 4.10).

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Frage:

Wie schnell bekomme ich Daten über die I/O's in das externe SRAM mittels 
DMA? Besteht die Möglichkeit überhaupt die I/O's z.B. 8/16 Bit mittels 
DMA an das externe oder interne SRAM zuverknüpfen?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die I/Os mußt Du nicht extra verknüpfen. Es gibt einen internen 
Speichercontroller (EBI, der die komplette Adress- und Datenvergabe 
steuert). An dessen extra dafür vorgesehene Pins muß das Externe RAM 
angeschlossen werden. Die betreffenden Adressen im RAM werden in die 
DMA-Register geschrieben und die auslösenden Module schreiben die Daten 
dann in der definierten Bockgröße in das RAM oder lesen es.

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigung mein Post war etwas missverständlich.

Ich möchte zum Beispiel einen externen Datenbus 16Bit über die I/O's 
einlesen und mittels DMA an den EBI geben. Hierzu würde ich gerne 
wissen, ob das möglich ist und wie schnell.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der DMA kann im Burstmode 1,2,4,8 Bytes am Stück transferieren. Das hat 
zwei Vorteile, 1. sobald der DMA von der Priorität den Bus zugesprochen 
bekommt stellt dies sicher das man zb. auch 4 Bytes am Stück 
transferiert. Der DMA hätte somit für diese 4 Einzel-Bus-Operationen die 
Priorität am Bus. 2. kann man diese Bursts auch als Datentyp ansehen, 
als Byte,Word,Long,LongLong.
Ob und wie der DMA zb. für die 2 Bytes Daten des ADC einstellbar ist 
weiß ich jetzt auch nicht.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich möchte zum Beispiel einen externen Datenbus 16Bit über die I/O's
>einlesen und mittels DMA an den EBI geben. Hierzu würde ich gerne
>wissen, ob das möglich ist und wie schnell.

Das sollte transpaent sein, dh. der Speicher am EIB wird linear 
angesprochen über das DMA.

Das sollte so schnell gehen wie EBI und DMA maximal arbeiten können, 
also 1 CPU Takt maximal. Aber, der DMA hat geringerer Buspriorität als 
die CPU, so lange also die CPU selber auf die gleiche Peripherie 
zugreift wird der DMA warten müssen. Es hängt also zu einem Teil von der 
Software und dessen Timing ab.

So gesehen kann man nicht mehr von echtem DMA reden, eher Pseudo-DMA, 
oder besser "Hardware unterstütztes Kopieren von Daten aus Peripherie zu 
Peripherie" das nicht unabhängig von der CPU ist.

Denoch verspricht es Peformancevorteile im Vergleich zum AVR8. Denn oft 
macht man in der CPU Berechnungen in deren Zeitraum man nun auch 
parallel Daten von A nach B schieben kann. Oder der Punkt das man mit 
AVR8 einen langsammen ISR Handler scheiben musste um zb. 512 Bytes an 
das SPI zu senden. Pro Datenbyte fallen also schonmal minimal die 
Tyktzyklen der Latenzen der ISR samt Opcodes an, was jetzt schonmal 
wegfällt.

Gruß Hagen

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, der Datenbus sollte viel besser ausgenutzt werden können.

Man hat z.b. eine Funktion die Daten verarbeitet, die liest am anfang 
ein oder zwei Byte aus dem SRAM, verbringt dann 8 Takte damit diese 
Daten zu verarbeiten und schreibt dann wieder ins SRAM, jetzt könnte 
zwischen dieser Zeit z.b. ein Burst mit 8 Byte im Hintergrund ablaufen, 
ohne das Programm zu stören, ist natürlich der Optimalfall, mit 
optimalem Timing ;)

Soll heißen:
Der Controller verbringt einfach viel Zeit, inder er nur auf den 
Registern arbeitet, in dieser Zeit ist der Datenbus für DMA Transfer 
frei. SPI transfer sollte dadurch zwar nicht mit Maximalem CPU Takt 
laufen (weil das Programm eben auch mal zwischendurch aufs SRAM zugreift 
(Variablen etc.)) aber es sollte VIEL schneller gehen als wie üblich in 
Software (ISR etc.)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>SPI transfer sollte dadurch zwar nicht mit Maximalem CPU Takt..

warum nicht ? SPI mit 8 Bits läuft auf dem AVR8 mit halben CPU Takt und 
benötigt somit 16 MCU Takte pro Byte. Ich habe jetzt nicht das exakte 
SPI Verhalten des XMegas im Kopf, sprich wegens Doublebuffering des SPI 
Datenregisters, aber wenn ich mich richtig entsinne kann man die UARTs 
im SPI Mastermodus laufen lassen und diese haben Doublebuffer der 
Dateregister und auch noch einen fraktionalen Baudrategeneretor. Also 
auch kein Problem ;)

Gruß Hagen

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

ich habe gestern mal ADC und DAC intern verknüppert (noch über 
Interrupt, DMA kommt später) und das Ergebnis ist echt überzeugend. In 
den ADC habe ich Musik eingespeist und gleich über den DAC wieder 
ausgeben lassen. Es war bei ausreichender Samplerate zumindest mit 
meinen Ohren im laufenden Programm vom Sound her kein Unterschied zum 
Originalsignal zu hören. Die Rauschwerte, die der ADC mitbringt, waren 
auch durchaus akzeptabel (2LSB). Ich denke, daß sich mit etwas externem 
Speicher (SRAM/SDRAM) und einer SD-Karte ein feiner Sampler 
zusammenbauen läßt. Auch Drumtrigger und Synthesizer wären denkbar. Ich 
werde mal noch ein wenig mit den einzelnen Modulen spielen und deren 
Leistungsfähigkeit testen ;-).

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Frage:

ADC nun 1MSps oder 2MSps ? mit bis zu 256x Gain oder nur 64x ? Da habe 
ich nämlich Gerüchte gehört das das nochmal geändert wurde, statt wie es 
im Preliminary stand.

Gruß Hagen

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2Msps und 64x Gain. Sowohl der ADC als auch der DAC haben aber noch 
einige Errata, was Linearität und Genauigkeit angeht. Die maximale 
Referenzspannung liegt bei 2.6 bzw 2.4V und nicht bei Vcc.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier mal ein vorläufiges FrontEnd für stereo Audio-Signale, welches das 
Einspielen über 2 Kanäle des ADC in den XMega, sowie die Ausgabe von 2 
Kanälen über den DAC ermöglicht. Es kommt ohne aktive Komponenten aus 
und erlaubt die Ausnutzung der maximalen Dynamik bei typischen 
Signalpegeln von 2Veff. Die LED, die die analoge Referenzspannung 
stellt, sollte eine Flußspannung um 2V haben, dies ist i.d.R. bei grünen 
Standard-LEDs der Fall. Somit laufen ADC und DAC mit derselben 
Bezugsspannung im spezifizierten Bereich. In der Firmware sollten die 
Referenzbits dementsprechend gesetzt sein.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir eben mal die ATXMEGA-Serie angesehen. Leider gibt es von 
diesen Kollegen keinen im DIL-Gehäuse und die Betriebsspannung ist mit 
3,6
Volt nicht gut zum Ansteuern von MOSFET oder auch von Leuchtidioten.
Fein ist der dicke fette Flash. ;-)

Hab ich das richtig übersetzt, daß die MLF 44- Gehäuse 0,5mm Pinabstand 
haben und auch keine ISP-Schnittstelle? Ich hatte so etwas noch nicht in 
der Hand (bzw. Pinzette)

...dann müßte es mit der Lötnadel und 0,5mm Zinn und einer Lupe in der 
größten Not noch gehen.

MfG Paul

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EditH:

Hab ich das richtig übersetzt, daß die MLF 44- Gehäuse 0,5mm Pinabstand
haben und daß die ATXMEGAS auch keine ISP-Schnittstellebesitzen?

Paul

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul Baumann wrote:

> Hab ich das richtig übersetzt, daß die MLF 44- Gehäuse 0,5mm Pinabstand
> haben und daß die ATXMEGAS auch keine ISP-Schnittstellebesitzen?

Ja und ja.

ISP ist durch PDI abgelöst.  Damit sollten die ,,verfuseten''
Taktquellen der Vergangenheit angehören.

MLF selbst löten ist möglich, aber fummelig.  Heißluft ist da besser,
weil du von der Seite praktisch kaum noch mit einem Lötkolben rankommst.
Für Hobbybastler ist TQFP sicher die angenehmere Alternative.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die TQFP-Gehäuse mit 0.5mm Pitch lassen sich mit 0.5mm Zinn, einer 0.4mm 
Bleistift-Lötspitze und ausreichend Flußmittel noch recht gut 
verarbeiten. Entlötlitze ist von Vorteil. Die nominal 3.3V 
Betriebsspannung sollten Dich nicht von den Features der neuen Serie 
abhalten. LEDs leuchten bereits ab 1.6V (rot) bzw. 1.8...2.2V (grün, 
gelb). Lediglich bei weiß und blau wird´s eng. Da kann man dann mit 
einem npn in Richtung einer höheren Spannung schalten. Logic-Level 
MOSFETs schalten ab 2V zuverlässig 10A und mehr. Alles keine echten 
Probleme. Wie gesagt, die Teile sind, verglichen mit den ATMEGAs, wahre 
Raketen.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo gibt es denn die Raketen?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bislang als Samples zum Beispiel bei www.ineltek.de und anderen ATMEL 
Direkt-Distris. Sind aber schnell vergriffen. Im August sollen die 
ersten XMega128A1 auf den freien Markt kommen.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch & Travelrec.

Danke für Eure Auskünfte und Anregungen.

MfG Paul

Autor: Torsten S. (tse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich platze fast vor Neugierde: Wie sieht denn der Quelltext für dieses 
ADC/DAC Experiment aus?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Quick and Dirty Assembler. Im Grunde ein zusammengereimter Extrakt aus 
den Datenblättern. Momentan macht der Controller nichts anderes, als 2 
Kanäle im Free-Running Mode vom ADC einzulesen und diese Werte per ISR 
an die beiden DAC-Kanäle zu verfüttern. Ergebnis: man hört die Musik, 
die man vorn eingibt, hinten wieder heraus. Die Qualität ist besser, als 
UKW-Radio und nicht ganz so gut, wie CD. An den analogen Filtern muß man 
sicher noch etwas feilen, die Firmware soll dann demnächst das DMA 
benutzen. Die .hex hänge ich mal an, für den, der´s probieren mag. Der 
Controller kann von 15Mhz bis 32Mhz getaktet werden, dabei ändert sich 
die Qualität des Sounds nicht. Unter 12Mhz wird´s dann räudig :-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Fortschritte: die Musike wird inzwischen mit 50kHz Samplerate in 
Stereo eingelesen und in das STK600-eigene DataFlash (aufgebohrt mit 
AT45DB081D, 1MByte) gepeichert. Auf Knopfdruck kann das etwa 7-sekündige 
Stück wiedergegeben werden. Als Zeitbasis dient jetzt ein Timer, das 
Samplen und die Ausgabe wird im Interrupt angestoßen. Das Speichern in 
das DataFlash geschieht unter Benutzung beider Buffer und ist somit 
schnell genug. Das Flash muß vor dem Speichern gelöscht werden. Als 
Sampler für einige lustige Effekte kann man die Schaltung schon 
gebrauchen, für eine Handvoll Widerstände, ein paar Kondensatoren, ein 
Quarz und 2 ICs nicht schlecht ;-).

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
News: Der ATXMega hat eine 256MB Platinum SD-Card als Musikspeicher 
bekommen. Die Karte ist ausreichend schnell und kann die Daten in 
Echtzeit und ohne Kompression mit 50kHz / 12bit, Stereo wegspeichern 
(nativ, kein Filesystem). Dazu verwende ich 2 Datenpuffer mit jeweils 
512Bytes, die jeweils wechselseitig zum Zwischenspeichen und 
Schreiben/Lesen genutzt werden. Auf die verwendete Karte passen gut 20 
Minuten Musik.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ja nur vollständige Bytes in die Karte geschrieben werden können, 
kommen wir hier auf 200kByte pro Sekunde, damit ist bei Verwendung 
externer Wandler volle CD-Qualität (176kB/s) möglich. Und bei der Größe 
heutiger Speicherkarten ist eine Komprimierung nicht unbedingt 
notwendig. Schauen wir mal, wann der erste HiFi-SD-Karten-Rekorder in 
der Codesammlung auftaucht.

Gruß
Jadeclaw.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw Dinosaur wrote:
> Schauen wir mal, wann der erste HiFi-SD-Karten-Rekorder in
> der Codesammlung auftaucht.

Aufnehmen ist nicht ganz so einfach, da nirgends spezifiziert ist, wie 
lange eine SD Karte zum Schreiben brauchen darf. Worst Case (suchen nach 
freien Sektoren im Dateisystem, langsamer Schreibzugriff usw.) ist man 
dann schnell bei 100kbyte benötigtem Puffer. Mit weniger Puffer kann, 
aber muss es nicht funktionieren.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Schreiben ist in der Tat das Problem. Lesen können alle getesteten 
Karten schnell genug, da kommt man mit den zwei 512Byte-Puffern gut aus. 
Beim Schreiben kam nur die genannte Platinum mit, die durchschnittlich 
unter 5ms pro Block lag. Leider kann man keiner Karte direkt ansehen, 
wie schnell sie wirklich ist. Für eine mit allen Karten gangbare Lösung 
müßte sicher ein externes RAM dran.

>Da ja nur vollständige Bytes in die Karte geschrieben werden können,
>kommen wir hier auf 200kByte pro Sekunde,

Da ich 12 Bit in 3 Bytes rechnen kann, komme ich mit 150kByte/s aus :-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Halli hallo,

anbei ein neues, aktives Audio-Frontend mit Linkwitz-Riley-Filtern für 
Anti-Alias und Smoothing. Es kommen in allen Filtern die gleichen 
Bauelementewerte zum Einsatz. Das Teil ist aufgebaut unf getestet unf 
klingt ganz anständig. Die Grenzfrequenz der Filter liegt bei etwa 
22kHz, was sie für den Einsatz für Sampleraten um 44.1kHz prädestiniert.

BTW: Die Analog-Digital-Wandler sind nicht so schlecht, wie in den 
Errata beschrieben wird. Bei meinem Muster wackelt lediglich das untere 
der 12Bits. Die DACs geben im S/H-Dual-Kanal-Betrieb bei 16 Clocks 
Refreshrate und 32Mhz fCPU ein leicht verrauschtes, aber sonst sauberes 
Signal, geringere Refreshraten führen zu stärkerem Rauschen. Den 
Signal/Rauschabstand müßte ich mal noch messen. Wichtig bei der ganzen 
Sache ist ein sauberes Layout mit getrennten Massen für PortA/B 
gegenüber dem Rest der Schaltung. Auf PortA/B darf kein geschaltetes 
Digitalsignal liegen, das streut sonst ein.

Im übrigen funktioniert die durch das Eventsystem gesteuerte 
Synchronwandlung Timer->Samplerate->ADC/DAC hervorragend und jitterfrei 
:-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Signal-Rauschabstand des DAC liegt bei etwa 55db nach Tiefpass. 
Etwas besser als ein gutes Tapedeck ohne Dolby-System. Für 
ernstzunehmende Musikanwendungen freilich etwas zu schlapp. Naja... 12 
Bit wären zwar theoretisch 72 db, aber die Praxis ist da wie immer 
gnadenlos ;-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

inzwischen habe ich einen I2S-24Bit ADC über einen Tiny2313 an den XMega 
angeschlossen. Der Tiny, der mit der Masterclock (12.288Mhz) des ADCs 
starr gekoppelt ist, formt aus dem seriellen Datenstrom 6 Bytes (je 3 
für linken und rechten Kanal) und gibt diese 8-Bit-parallel per IRQ an 
den XMega weiter. Dieser wird dann nur alle 48kHz gebeten, die Daten 
abzuholen. Dadurch wird der XMega in seiner Rechenarbeit kaum belastet. 
Allerdings mußte ich ihn mit interner PLL höher takten, um die 
Interrupt-Reaktionszeit zu verkürzen. Der XMega läuft jetzt mit 48Mhz. 
Alles klappt bislang problemlos, das heißt, die Musike kommt im XMega 
an. Demnächst werde ich den passenden DAC wiederum über Co-Controller 
anschließen und derweil auf einen professionellen Sound hoffen. Schönes 
Wochenende noch :)

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


Habe mittlerweile auch ein paar Muster bekommen. Weiterhin habe ich 
jetzt auch das STK 600 mir fehlt nur noch der passende Platinenaufsatz. 
Wisst Ihr welcher das ist und wo man den bekommt?
Mir ist aufgefallen das der ATXmega128A1 mehrere ISP Schnittstellen hat 
ist es egal welche man zum Programmieren nutzt?
Vielleicht sollte mal ein Profi eine eine Art "Universalanleitung" im 
Forum erstellen denn die Teile sind ja langsam verfügbar.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wisst Ihr welcher das ist und wo man den bekommt?

TQFP100, bekommt man bei Ineltek oder auf Anfrage bei CSD-electronics.
Sparen kannst Du Dir den Adapter, wenn Du Dir ein Board mit allen 
herausgeführten Portpins lötest. Der XMega läßt sich schließlich im 
System programmieren.

>Mir ist aufgefallen das der ATXmega128A1 mehrere ISP Schnittstellen hat
>ist es egal welche man zum Programmieren nutzt?

Ist egal, nämlich keine von allen. Der XMega hat einen RESET/PDICLK und 
einen PDIDATA Pin, diese beiden und Masse werden zum Programmieren und 
Debuggen benutzt. Der Controller benötigt dazu noch eine Spannung im 
Bereich von 1.8 bis 3.6V und keinen externen Takt.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oha

habe bei Segor eine Platine gefunden die man verwenden kann.

TQFP100-Adapter 0,5

Das konnte doch mit dem Teil gehen dann die PDI und Spannungs Pins 
verbinden und fertig.
Meinst Du das so?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau. Stelle nur sicher, daß sowohl das STK600 als auch das externe 
Board auf eine Spannung < 3.6V eingestellt sind. Du kannst die Spannung 
auch von VTarget des STK testhalber beziehen, wenn Du nicht zu viel 
dranhängst. Die VTarget findest Du an der ISP/PDI-Buchse an Pin 2 und an 
allen Portsteckern des STK an Pin 10. Der XMega hat übrigens einen 
ganzen Sack an internen Oszillatoren und eine 1...32x PLL, so daß man 
auch ohne externen Quarz schon viele Tests machen kann. Nach dem 
Einschalten läuft der XMega übrigens immer mit 2Mhz los und muß durch 
die Applikation auf eine andere Taktquelle geschaltet werden, wenn man 
dies wünscht.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema ADC hab ich noch eine Frage.

Hat der einen ADC der per MUX geschalten wird oder hat der mehrere ADC 
Wandler. Für mein Ambilight Projekt scheint der Controller recht 
geeignet zu sein da der Mega 16 den ich bisher verwendet hatte vom ADC 
her fast schon zu langsam wurde wenn man der Bildbereich feiner 
aufteilen wollte. Interessant ist auch das Eventsystem.
Programme sind auch in asm möglich oder muß ich mich jetzt mit C 
beschäftigen?

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der A1 hat 2 8-Kanal-ADC.
Sind aber auch schneller --> 2MSamples pro Sekunde.
Controller dieser Größe würde ich nicht mehr in Assembler programmieren.
Das Unterfunktions- und Library-Konzept, das einem eine Hochsprache 
bietet, ist bei Controllern dieser Größe schon zwingend notwendig, wenn 
das Ganze noch einigermaßen wartbar bleiben soll. Auch unter dem 
Gesichtspunkt Wiederverwendbarer Code. Zumal moderne C-Compiler einen 
recht anständigen Maschinencode abliefern. Ich bin mittlerweile an dem 
Punkt angelangt, daß ich ab 4kByte Controllergröße nur noch in C 
arbeite. Das einzige, was mich, zumindest beim GCC nervt, ist der etwas 
umständliche Zugriff auf den Programmspeicher, Stichwort Bedienertexte. 
Auf der anderen Seite ist es eine echte Strafe, ein 120kByte großes 
Assemblerprojekt warten zu wollen.

Gruß
Jadeclaw.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bislang programmiere ich den XMega 100% in ASM und er hat sich noch 
nicht beschwert ;-) Da ich sehr zeitkritisch und teilweise auch 
zyklengenau arbeiten muß (beim aktuellen Projekt), kommt eine 
Hochsprache gar nicht in Frage. Der XMega hat viele Register, die 
mitunter die Geschwindigkeit des XMega auch noch steigern, da man 
Befehle spart. Das will ich mir nicht durch umständlich laufende 
Algorithmen ausbremsen. Libraries in Form von includierten Einzeldateien 
kann man auch unter ASM im AVR-Studio4 komfortabel verwalten. Die 
Codebeispiele von ATMEL sind aber leider fast ausschliesslich in C und 
dann auch noch mit IAR geschrieben.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen hat der XMega je einen I2S-ADC und DAC plus einen optischen 
S/PDIF-Ausgang bekommen. Der Sound ist mit 16Bit und 48kHz bei gut 85db 
Dynamikumfang ausreichend für einen semiprofessionellen 
Outdoor-Wave-Recorder. Die erste SD-Karte hat´s auch schon gerissen, war 
´ne billige, aber neue CN-Memory 2GB, ist einfach so ausgestiegen im 
laufenden Betrieb. Werde sie demnächst dem Händler an den Kopf werfen. 
Die anderen Karten laufen noch einwandfrei. Ich habe den Schreibpuffer 
noch auf 6kb(!) aufgebohrt und nun auf den etwas langsameren Karten auch 
keine Probleme mehr. Die Hopser im Sektorenbereich unter $1000 sind aber 
bei allen Karten präsent und scheinen physikalischer Natur zu sein, da 
sie immer an denselben Stellen auftreten. Ich werde noch ein wenig an 
dem Projekt weiterbasteln und wenn es neue Fakten gibt, wieder hier 
anklingeln ;-) Schönen Restsonntag noch!

Autor: Gast3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaum gekauft - schon ist das STK500 wieder veraltet :-(

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö. Warum?
Die normale Tiny/Mega-Serie läuft doch weiter.
XMega, AVR32 und AT91(ARM) sind jeweils völlig separate Produktlinien 
und jede hat ihren eigenen Satz an Tools und STKs. Da die XMega-Serie 
allerdings vieles, inklusive Core vom normalen AVR übernommen hat, ist 
es denkbar, das in Zukunft eine Reihe von XMega-Tools die normalen AVRs 
auch bedienen kann. Nur das muß sich noch zeigen, in welche Richtung die 
Entwicklung da geht.

Gruß
Jadeclaw.

Autor: Frank W. (frankw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. N. wrote:
> Gibt es eigentlich günstige Nachbauten für den JTAG-ICE mkII? Der kostet
> ja ne ganze Menge...

Beitrag "AVR JTAGICE mkII Nachbau für €64,20 ( Plus 22$ Porto )"

Vielleicht hilft's.
Gruss
Frank

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wär mir aber nicht sicher, ob der Nachbau das PDI unterstützt, was 
man für die ATxmega braucht.

Autor: Frank W. (frankw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab's nicht ausprobiert - aber in der Anleitung steht :

# This hardware also supports debugging xMEGA devices via the PDI 
interface;

Gruss
Frank

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo @alle,

ich habe Eure Beiträge mit großem Interesse gelesen -auch wenn ich mit 
dem XMega (leider :-) ) keine Audioanwendung betreibe.
Ich portiere gerade von einem Mega ein GCCProgramm und habe zum EEprom 
eine Frage:
zwischen Mega64 und MEga128A1 sehe ich nur den Offset von 0x1000 Bytes, 
ansonsten ist alles gleich, oder? (wenn ich ebenfalls byteweise 
zugreifen will)

Schade, dass die Atmel.PDFs keine Beispiele mehr hat  -aus denen habe 
ich am meisten mitgenommen. Ansonsten macht das Teil echt Spass.

Gruß von
Helmut

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das EEPROM des XMEGA ist page-orientiert aufgebaut. Selbst beim 
Schreiben eines Bytes wird die ganze Page geschrieben, außerdem ist das 
EEPROM in den Speicherbereich einblendbar. Tips dazu gibt es in den 
XMega Appnotes.

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, die hab ich auch selber gerade entdeckt... (Grrr - warum nicht 
schneller?)
Sorry dass ich mein Dummpulver verschossen habe! (rotwerd)

Trotzdem danke für die schnelle Hilfe!

Gruß
Helmut

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geniales Teil, endlich kann ich eine DDS (Direct Digital Synthesis) mit 
wenig Aufwand realisieren.
Timer einstellen, das Timer Event triggert einen Single-Byte DMA 
Transfer auf einen Port. Und dazu höchst genau (Event System benötigt 2 
ClockCycles bis das Signal beim Empfänger ankommt). Wird mein neuer 
8-Kanal-Frequenz-Generator. Später schick ich statt an den Port die 
Daten an einen DAC. Wird mein neuer Signal generator. Und das mit fast 0 
Software :-D
Aha den CPU kann man dann nebenher idle legen, dann wird das ganze noch 
schön mobil. Einschalten kann ich das ganze dann auch übers Event 
System. Ein Port Pin dient dann als Event Generator :-D
WOW!!!

Autor: Helmut Ru (heru01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,

nach einigen Experimenten bin ich nun an einem Bootloader via SPI; das 
Starten aus dem Bootbereich funktioniert in der Rev. H des ATxMega128A1; 
allerdings die Interrupts via IVSEL auf Bootbereich funktionierne 
partout nicht.
Hat jemand da bereits Erfahrungen damit? (siehe Topic) In der Appnote 
ist alles mögliche beschrieben, aber die Interrupts funktionieren 
einfach nicht.

Gruß
Helmut

Autor: Helmut Ru (heru01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,
das Thema passt zu 'erste Erfahrungen' :-)

Wenn jemand seine Chiprevision lesen will: (ich fand das Thema 
hochinteressant wg. Bootloader >= Rev. H)

Lt. Atmel:

The marking mentions something like XXXXX -35953GES The 'G' in this 
conveys the Revison ID in the marking
In SW:
It is possible to get the device revision by reading the device 
signature. Please find these details from Xmega A Manual (12/08) 
-->Device Identification register-->Version(Page Number 341). While 
reading the Signature of the device via JTAGICEmkII, the JTAG ID is in 
paranthesis and the first number in this shows the revision of the 
device(if it shows 6 it is revision G).Also it is possible to get the 
revision of the device by reading the REVID register. Please find this 
detail from Xmega A Manual (12/08) -->4.20.4 REVID - MCU Revision ID 
(Page Number 43)

Komischerweise funzt der Bootloader trotz des Errata Sheets (bl 
nonfunctional, please don't use this flash area) ... Habe ganz seltene 
Aussetzer. Hmmmm.... Ich habe nämlich -entgegen der Zusage der Distris- 
Rev. G bekommen und jetzt erst Rev. H; die ich noch testen muss.

Wollt's einfach an Euch weitergeben - vielleicht hilft das mit dem 
Auslesen der Rev. noch jemandem?


Gruß
Helmut

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur so als Info, EmbedIT hat wieder ATxmega128A1 Nachschub bekommen.
http://shop.embedit.de/product__710.php

Zumindest steht dort wieder "Ab Lager".

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind aber noch Musterchips. Die Serie ist noch nicht im Gange. Zum 
Basteln reicht das Muster ja. Ich find´s nur ein wenig dreist, Muster zu 
verkaufen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jup, stimmt.

Autor: pjtec (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@netbandit:
USBprog von embedded-projects.net kann auch JTAG-ICE mkII, einen Versuch 
wär's wert.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pjtec:

Hi,

danke für die Info. Inzwischen hab ich mir günstig über die Hochschule 
ein JTAG ICE mk2 besorgt. Der USB Prog wäre zwar immer noch günstiger, 
aber jetzt steht er ja schon neben mir ;)

Autor: Steffen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Travel Rec.

Wenn du bis her alles in ASM programmiert hast, dann müsstest du mir ja 
weiter helfen können. Ich mache gerade meine ersten Gehversuche mit dem 
Xmega128A1. Experimentierplatine habe ich jetzt endlich aufgebaut und 
sie ist auch einsatzbereit. Konnte zumindest mit dem AVRISP MKII per PDI 
das Signaturbyte auslesen.

Doch ich scheitere gerade schon ganz am Anfang meines ersten Programms.

Bisher hatte ich immer einen Programmkopf:
.include "mega8.def"

- Register Deklaration
- Variablen
- Variablen + RAM-Reservierungen

- Interruptvektoren

"Programmbeginn mit:"
RESET:
- Stackpointer auf höchste Flashadresse setzen
- Portzuweisungen

-> Hauptprogramm


Nun weiß ich gerade überhautnicht wie ich da bei den Interruptvektoren 
bei dem Xmega ansetzen soll..

Wer kann mir da in ASM weiterhelfen????


Steffen H.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als erstes solltest Du mal diese Zeile schreiben:

.include "ATxmega128A1def.inc"

Die Init der Vektoren und der Clock sieht dann beispielsweise so aus, 
das RESET ist durch die entsprechende ISP-Sprungmarke zu ersetzen.
.org $0000
 jmp  RESET          ;Reset
 jmp  RESET          ;NMI, external oscillator failure
 jmp  RESET          ;PortC Int0
 jmp  RESET          ;PortC Int1
 jmp  RESET          ;PortR Int0
 jmp  RESET          ;PortR Int1
 jmp  RESET          ;DMA Channel0
 jmp  RESET          ;DMA Channel1
 jmp  RESET          ;DMA Channel2
 jmp  RESET          ;DMA Channel3
 jmp  RESET          ;RTC Overflow
 jmp  RESET          ;RTC Compare
 jmp  RESET          ;TWI_C Slave
 jmp  RESET          ;TWI_C Master
 jmp  RESET          ;Timer_C0 Overflow
 jmp  RESET          ;Timer_C0 Error
 jmp  RESET          ;Timer_C0 Compare/CaptureA
 jmp  RESET          ;Timer_C0 Compare/CaptureB
 jmp  RESET          ;Timer_C0 Compare/CaptureC
 jmp  RESET          ;Timer_C0 Compare/CaptureD
 jmp  RESET          ;Timer_C1 Overflow
 jmp  RESET          ;Timer_C1 Error
 jmp  RESET          ;Timer_C1 Compare/CaptureA
 jmp  RESET          ;Timer_C1 Compare/CaptureB
 jmp  RESET          ;SPI_C Complete
 jmp  RESET          ;USART_C0 RXComplete
 jmp  RESET          ;USART_C0 DataRegisterEmpty
 jmp  RESET          ;USART_C0 TXComplete
 jmp  RESET          ;USART_C1 RXComplete
 jmp  RESET          ;USART_C1 DataRegisterEmpty
 jmp  RESET          ;USART_C1 TXComplete
 jmp  RESET          ;AES
 jmp  RESET          ;NVM EE ready
 jmp  RESET          ;NVM SPM ready
 jmp  RESET          ;PortB Int0
 jmp  RESET          ;PortB Int1
 jmp  RESET          ;AC_B Int0
 jmp  RESET          ;AC_B Int1
 jmp  RESET          ;AC_B WindowInt
 jmp  RESET          ;ADC_B Channel0
 jmp  RESET          ;ADC_B Channel1
 jmp  RESET          ;ADC_B Channel2
 jmp  RESET          ;ADC_B Channel3
 jmp  RESET          ;PortE Int0
 jmp  RESET          ;PortE Int1
 jmp  RESET          ;TWI_E Slave
 jmp  RESET          ;TWI_E Master
 jmp  RESET          ;Timer_E0 Overflow
 jmp  RESET          ;Timer_E0 Error
 jmp  RESET          ;Timer_E0 Compare/CaptureA
 jmp  RESET          ;Timer_E0 Compare/CaptureB
 jmp  RESET          ;Timer_E0 Compare/CaptureC
 jmp  RESET          ;Timer_E0 Compare/CaptureD
 jmp  RESET          ;Timer_E1 Overflow
 jmp  RESET          ;Timer_E1 Error
 jmp  RESET          ;Timer_E1 Compare/CaptureA
 jmp  RESET          ;Timer_E1 Compare/CaptureB
 jmp  RESET          ;SPI_E Complete
 jmp  RESET          ;USART_E0 RXComplete
 jmp  RESET          ;USART_E0 DataRegisterEmpty
 jmp  RESET          ;USART_E0 TXComplete
 jmp  RESET          ;USART_E1 RXComplete
 jmp  RESET          ;USART_E1 DataRegisterEmpty
 jmp  RESET          ;USART_E1 TXComplete
 jmp  RESET          ;PortD Int0
 jmp  RESET          ;PortD Int1
 jmp  RESET          ;PortA Int0
 jmp  RESET          ;PortA Int1
 jmp  RESET          ;AC_A Int0
 jmp  RESET          ;AC_A Int1
 jmp  RESET          ;AC_A WindowInt
 jmp  RESET          ;ADC_A Channel0
 jmp  RESET          ;ADC_A Channel1
 jmp  RESET          ;ADC_A Channel2
 jmp  RESET          ;ADC_A Channel3
 jmp  RESET          ;TWI_D Slave
 jmp  RESET          ;TWI_D Master
 jmp  RESET          ;Timer_D0 Overflow
 jmp  RESET          ;Timer_D0 Error
 jmp  RESET          ;Timer_D0 Compare/CaptureA
 jmp  RESET          ;Timer_D0 Compare/CaptureB
 jmp  RESET          ;Timer_D0 Compare/CaptureC
 jmp  RESET          ;Timer_D0 Compare/CaptureD
 jmp  RESET          ;Timer_D1 Overflow
 jmp  RESET          ;Timer_D1 Error
 jmp  RESET          ;Timer_D1 Compare/CaptureA
 jmp  RESET          ;Timer_D1 Compare/CaptureB
 jmp  RESET          ;SPI_D Complete
 jmp  RESET          ;USART_D0 RXComplete
 jmp  RESET          ;USART_D0 DataRegisterEmpty
 jmp  RESET          ;USART_D0 TXComplete
 jmp  RESET          ;USART_D1 RXComplete
 jmp  RESET          ;USART_D1 DataRegisterEmpty
 jmp  RESET          ;USART_D1 TXComplete
 jmp  RESET          ;PortQ Int0
 jmp  RESET          ;PortQ Int1
 jmp  RESET          ;PortH Int0
 jmp  RESET          ;PortH Int1
 jmp  RESET          ;PortJ Int0
 jmp  RESET          ;PortJ Int1
 jmp  RESET          ;PortK Int0
 jmp  RESET          ;PortK Int1
 jmp  RESET          ;Reserved
 jmp  RESET          ;Reserved
 jmp  RESET          ;PortF Int0
 jmp  RESET          ;PortF Int1
 jmp  RESET          ;TWI_F Slave
 jmp  RESET          ;TWI_F Master
 jmp  RESET          ;Timer_F0 Overflow
 jmp  RESET          ;Timer_F0 Error
 jmp  RESET          ;Timer_F0 Compare/CaptureA
 jmp  RESET          ;Timer_F0 Compare/CaptureB
 jmp  RESET          ;Timer_F0 Compare/CaptureC
 jmp  RESET          ;Timer_F0 Compare/CaptureD
 jmp  RESET          ;Timer_F1 Overflow
 jmp  RESET          ;Timer_F1 Error
 jmp  RESET          ;Timer_F1 Compare/CaptureA
 jmp  RESET          ;Timer_F1 Compare/CaptureB
 jmp  RESET          ;SPI_F Complete
 jmp  RESET          ;USART_F0 RXComplete
 jmp  RESET          ;USART_F0 DataRegisterEmpty
 jmp  RESET          ;USART_F0 TXComplete
 jmp  RESET          ;USART_F1 RXComplete
 jmp  RESET          ;USART_F1 DataRegisterEmpty
 jmp  RESET          ;USART_F1 TXComplete

 

;Program-Code starts here
RESET:
 cli

 ldi  Temp, 0b11100000        ;setup external Oscillator: 12..16Mhz, 16k clock cycles start up, 32kHzOscLowPower
 sts  OSC_XOSCCTRL, Temp

 ldi  Temp, OSC_XOSCEN_bm        ;enable external oscillator or clock
 sts  OSC_CTRL, Temp

WaitOSC:
 lds  Temp, OSC_STATUS
 sbrs  Temp, 3            ;wait for Oscillator to be stable
 rjmp  WaitOSC

 ldi  Temp, 0b11000011        ;external Oscillator or clock as PLL input, Factor 3 (36,864 MHz)
 sts  OSC_PLLCTRL, Temp
 
 lds  Temp, OSC_CTRL
 ori  Temp, OSC_PLLEN_bm        ;enable PLL
 sts  OSC_CTRL, Temp

WaitPLL:
 lds  Temp, OSC_STATUS
 sbrs  Temp, 4            ;wait for PLL to be stable
 rjmp  WaitPLL


 ldi  Temp, $D8          ;disable I/O Register protection for 4 cycles
 out  CPU_CCP, Temp
 ldi  Temp, CLK_SCLKSEL_PLL_gc
 sts  CLK_CTRL, Temp

 clr  Null

;setup Watchdog timer
 wdr
 ldi  Temp, $D8          ;disable I/O Register protection for 4 cycles
 out  CPU_CCP, Temp
 ldi  Temp, 0b00011111        ;1 Sek. timeout, enable, change enable
 sts  WDT_CTRL, Temp


Die Portdefinitionen sind zu denen der Megas grundverschieden. Am besten 
guckst Du mal in´s Datenblatt und in´s Manual des XMega128A1.

Autor: Steffen H. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Schnelle Antwort.

Ich habe schon bemerkt, das der Xmega ja mal doch nicht mehr so viel 
gemeinsam mit den ATmega's hat. Zumindest was die I/O-Register betrifft.

Man sollte nicht nur, sondern man MUSS sich sogar UNBEDINGT mit dem 
Datasheet auseinandersetzen! Das hab ich dann auch gemerkt ;-)

Und dann auch das erste Test Progrämmchen (siehe Anhang) auf den Xmega 
zum Laufen gebracht. Mit diesem kann man nun die Ports A..D in der alt 
gewohnten Weise ansteuern.

Schade, dass es in den Codebeispielen hier noch keinen Code in ASM für 
die Xmega's gibt. Hoffentlich ändert sich das bald.

@Travel_Rec
So ähnlich wollte ich es auch machen mit den Int.-vectoren. Habe sie 
dann schließlich in der "atxmega128a1def.inc" gefunden. Nicht so 
einfach, wenn man die geraume Anzahl an Registern, Reg_Offsets, Masken 
und Bitzuweisungen sieht.. Man sieht es ja alleine schon an den 
zahlreichen (255???) Interrupt-Vectoren in deinem Beispiel. Ich werde 
also demzufolge wohl nur noch die Vectoren ins Programm schreiben, die 
ich wirklich brauche.

Meine ersten kleinen Testprogramme werde ich jetzt immer unter 
Codesammlung und "Xmega Programmierung in ASM" veröffentlichen.


Lg Steffen H.

Autor: Matthias S. (sippel96)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Travel Rec:
Mit Interesse habe ich deine Umsetzungen mit ADC und DAC gelesen.
Da ich auch ein Projekt - wenn gleich auch ohne Audio - machen möchte,
und dies ebenfalls in Assembler schreiben möchte, wäre es schön, wenn du 
die Konfiguration bzw. das Ansprechen der jew. Converter register als 
Quelltext mal zeigen könntest.
Durch die sparsame Dokumentation im Handbuch und den nervigen 
Vergleichen mit der def-Datei dreh ich gleich noch ab......Danke!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt komplette Appnotes zum ADC/DAC bei ATMEL. Du brauchst außerdem 
das Manual UND das Datenblatt.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu den AppNotes gibts auch noch Beispielcode von Atmel.

Mit dem Datenblatt alleine kommt man nicht weit, aber dafür stehen dort 
ja auch immer Hinweise auf die Manuals für die einzelnen Peripherien. 
(Unter AppNotes bei Atmel zu finden).

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Beispielcodes sind leider C. Da hat sippel96 leider Recht. Ich muß 
mal in meiner Codekiste kramen.

Autor: Anselm 68 (anselm68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mag nicht jemand nen schnellen Atmega128 nachprogrammieren? ggg

---Duck und renn----


Anselm

Autor: Matthias S. (sippel96)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den Appnotes für die"alten" AVRs waren die entscheidenen 
Registerzugriffe und Konfigurationen in C und ASM abgedruckt.
Um bestimmte, z.T. zeitkritische  Abläufe - wie bsp. Clockumschaltung - 
zu verstehen, reicht oftmals ein ASM Beispiel aus.
Nun sind die Appnotes und Codebeispiele getrennt, zum Nachvollziehen 
etwas mühselig, mal abgesehen davon, dass sie in C sind.
Mag ja sein, dass man die Bsp.codes besser in sein Programm übernehmen 
kann,
aber darum geht es mir ja nicht, da meines Erachtens Appnotes 
Erklärungen sein sollen, und nicht Programmiervorlagen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal eine Init als Beispiel:
;setup ADC
 ldi  Temp, $01   
 sts  ADCA_CALIB, Temp
 ldi  Temp, $FF   
 sts  ADCA_CALIB+1, Temp
 
 ldi  Temp, 0b00000011        ;divide Clock/64 (512khz)
 sts  ADCA_PRESCALER, Temp
 ldi  Temp, 0b00100000        ;ARefA as reference
 sts  ADCA_REFCTRL, Temp
 ldi  Temp, 0b00100001        ;pos pin ADCA0, neg pin ADCA1
 sts  ADCA_CH0_MUXCTRL, Temp
 
 ldi  Temp, 0b00101001        ;pos pin ADCA4, neg pin ADCA1
 sts  ADCA_CH1_MUXCTRL, Temp
 ldi  Temp, 0b01000110        ;SyncSweepADC-Channels 0+1 on EventChannel0 input
 sts  ADCA_EVCTRL, Temp
 
 ldi  Temp, 0b00010000        ;signed measure, Freerunning
 sts  ADCA_CTRLB, Temp
 
 ldi  Temp, 0b00000011        ;high level interrupt Ch1 on Conversion Complete, Ch0 is sampled before
 sts  ADCA_CH1_INTCTRL, Temp

 ldi  Temp, 0b00000001        ;enable ADC
 sts  ADCA_CTRLA, Temp
 
 ldi  Temp, 0b10000010        ;Differential Mode, start first conversion
 sts  ADCA_CH0_CTRL, Temp
 ldi  Temp, 0b10000010        ;Differential Mode, start first conversion
 sts  ADCA_CH1_CTRL, Temp



Gestartet wird der ADC mit
 ldi  Temp, 0b00001101        ;start conversion on ADC Ch0 and Ch1
 sts  ADCA_CTRLA, Temp

Das Ergebnis findet man in ADCA_CH0RES und ADCA_CH0RES+1.

Autor: Matthias S. (sippel96)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Travelrec!

Habe vorhin was ausprobiert, im single ended Mode, aber läuft gut,
auch wenn bei vollem clock 32Mhz intern und teile 1/4 bzw. 1/8 die 
conversion
etwas leidet (kein voller Hub, teilweise Sprünge in der Auflösung!)
Ansonsten hat mir die Registerinitialiserung sehr geholfen!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön! Weiter so :-)

Autor: Steffen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat schon mal jemand die PLL über 48MHz gebracht? Bei mir ist jedenfalls 
bei 48Mhz schluss. Laut Datasheet kann man bis auf 200Mhz gehen.

Oder mach ich mal wieder etwas verkehrt???

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Eventsystem klingt ja hochinteressant.
Kann man damit (zusammen mit DMA) auch eigene (serielle) Protokolle 
umsetzen?

Also konkret, man schreibt die Daten an eine bestimmte Adresse und bei 
einem Timer-Interrupt soll immer das aktuelle Bit den Ausgang setzen 
oder zurücksetzen. Beim nächsten Interrupt soll natürlich das nächste 
Bit verwendet werden usw.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann mit Eventsystem, Timer und DMA jede Menge eigener Protokolle 
umsetzen. Momentan bin ich beispielsweise gerade an einem I2S-Interface 
(Audio-Stream), welches eine UART als SPI-Master verwendet, ein über das 
Eventsystem synchronisierter Timer liefert die Wordclock und steuert 
einen Interrupt, DMA holt und versendet die Daten.

Autor: Steffen H. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Eventsystem funktioniert hervorragend. Allerdings gibt es keine so 
richtigen angaben über dessen Geschwindigkeit/Timing. Wieviel Takte 
hängt es hinterher(Ausführungszeit). Beim DMA-Controller hält man sich 
noch bedekter! Jedenfalls hab ich leider feststellen müssen, dass ein 
Interrupt trotz min. 8Takte Ausführungszeit noch schneller ist als 2 DMA 
Kanäle. Liegt wahrscheinlich daran, dass DMA mit einer niedrigeren 
Priorität auf den zusammen mit der CPU verwendeten Datenbus zugreift. 
Habe versucht ein TFT zum laufen zu bringen und bin ganz schnell an die 
Grenzen des XMega128A1 gestoßen. Das EBI funktioniert auch super. Doch 
wie schnell ist es? Bei einem Datatransfer aus einem 4bit SDRAM für das 
TFT ist bei mir leider schon bei ca. 2Mhz schluss. Aber es geht. 
Bildwiederholrate liegt dadurch nur noch bei ca. 30Hz, was man auch 
deutlich sieht (trotz sehr kritischen Timing), aber es zeigt was an.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Auszüge aus dem A1 Manual.

Das EBI kann CPUx2, also 64Mhz Clock. Davon abgezogen natürlich die 
SDRAM-Delays. Warum nimmst Du kein 10ns-SRAM?

Autor: Steffen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke dir Travel Rec. Das sind ganz nützliche hinweise. Warum hab ich 
das nur nicht gefunden?! Wahrscheinlich sieht man manchmal den Wald vor 
lauter Bäumen nicht.

Ich einen SDRAM genommen, da er schon auf meinem Board integriert ist. 
Über einen SRAM hab ich auch schon nachgedacht. Da hätte man zumindest 
schon mal 8bit oder sogar 16bit Daten parallel. Allerdings kann das EBI 
keine 16Bit Daten. Sind denn aber die zugriffszeiten bei einem SRAM 
nicht geringer als bei einem SDRAM???

Gruß Steffen

Autor: Steffen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab jetzt den ganzen Abend damit verbracht das Timing von EBI + 
SDRAM unter die Lupe zu nehmen. Das Ergebnis ist ernüchternd^10!

Mit einem SDRAM und einer CLK_PER2 für EBI von 96Mhz braucht es immerhin 
noch stolze 46*CLK_PER2 Takte um 2Byte Daten bereitzustellen. Macht 
23*CLK_CPU !!!

Mit einem SRAM (10ns Zugriffszeit) und einer CLK_PER2 für EBI von 96Mhz 
braucht man gerade noch 6*CLK_PER2 Takte um 2Byte Daten bereitzustellen. 
Macht 3*CLK_CPU !!!

Und ich höre immer die SDRAM´s sind sau schnell...
Einziger Vorteil von SDRAM ist wahrscheinlich die Speichergröße.

Was meint denn der Rest der Gemeinde dazu?

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SDRAMs sind grundsätzlich langsamer als SRAMs, was am inneren Aufbau der 
Speicher liegt. Zudem kommt der Refresh als zusätzlich verzögerndes 
Element dazu. SDRAMs haben eben durch den einfacheren Aufbau preisliche 
Vorteile (1 Transistor + Kondensator anstatt 6 Transistoren pro 
Speicherzelle).

Gruß
Jadeclaw.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das richtig, daß der XMega somit eigentlich nicht mehr 
Speicherdurchsatz bringt als ein herkömmlicher ATMega mit externem SRAM? 
Das wäre in der Tat recht ernüchternd.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann man so pauschal nicht sagen. Ich argumentiere zum Beispiel mit 
Nein, da es beim xmega eine DMA gibt.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DMA ist schon schön, aber ich vermisse irgendwie einen externen Trigger. 
Die Übernahme eines Datenwortes per DMA kann offensichtlich durch 
diverse interne Ereignisse angestoßen werden, aber an den trivialsten 
Fall, externe Interruptleitung, hat offensichtlich keiner gedacht - oder 
überlese ich da im Datenblatt immer wieder etwas?

Autor: Steffen H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch, man kann den DMA von extern über einen PORT-PIN triggern. Aber nur 
mit einer steigenden Flanke. Wenn man eine Fallende Flanke zur 
Triggerung benötigt, muss man einfach den PORT-PIN invertieren.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach per Event System vom Port aufs DMA. Dann den PORT noch 
entsprechend konfigurieren, dass ein bestimmter Pin das Event Signal 
auslöst.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan:

>Mit einem SDRAM und einer CLK_PER2 für EBI von 96Mhz braucht es immerhin
>noch stolze 46*CLK_PER2 Takte um 2Byte Daten bereitzustellen. Macht
>23*CLK_CPU !!!
>Mit einem SRAM (10ns Zugriffszeit) und einer CLK_PER2 für EBI von 96Mhz
>braucht man gerade noch 6*CLK_PER2 Takte um 2Byte Daten bereitzustellen.
>Macht 3*CLK_CPU !!!

Ich denke das deine zahlen nicht stimmen können. Nimmt man SRAM mit 10ns 
am EBI und betrachtet den 3-Port SRAM mit ALE12 dann kann man bis zu 
16MB anschließen.

Liest man 1024 Bytes von diesem SRAM dann benötigt man 1024*2 + 1024/256 
*2 CLK_PER2 Takte macht 1028 CPU Takte. Das liegt daran das die ALE 
Signale und damit die Latches nur beim Überschreiten einer Speicherseite 
(256 bytes für ALE1 und 64KBytes für ALE2) angesteuert werden.
Das funktioniert aber nur im SRAM Modus nicht im LPC Modus. denn im LPC 
Mode werden Datenbus und Teile des Addersbusses muliplext, das bremst 
aus.
Zudem bedeutet dies das linear sequienteller Zugriff bevorzugt wird zu 
wahlfreien Zugriff. Nachlesen kann man das im Manual A.pdf man muß es 
nur erstmal begriffen haben ;)

Beim SDRAM komme ich auf 4.5 CPU Takte pro Byte Lesezugriff. Das konnte 
ich real ausmessen. Wichtig sind dann die korrekten Timings die man 
einstellen muß.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens mit CLK_PER2 von 94MHz läuft der AVR mit 48MHz Takt minimal, 
das ist bischen ausserhalb der Spezifikation. Letzendlich ist das aber 
irrelevant für die Berechnungen da das EBI immer nur maximal 2x 
schneller als der CPU Takt sein kann, Prescaler C zwischen EBI und CPU 
kann /1 und /2.

Gruß hagen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.