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 ;-).
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.
Dann kann man glatt dein Eindruck kriegen, dass Atmel sich mit den 250€ Einrichtungsgebühr die Bastler vom Leib halten will.
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 ;-)
Nichts gegen das STK600, aber dass es keinen einfacher Programmer gibt irritiert mich.
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.
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!)
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.
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.
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.
Travel Rec. wrote: > Das Muster hier läuft mit internem Taktgenerator bei: 2000.0997 Mhz > (25°C). Wow, ein 2-GHz-Prozessor! :-)
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 :-)
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.
>> 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...
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.
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 ;-)
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.
Vielleicht kann man ja mit dem usbprog was machen. Eine experimentelle JTAG ICE mkII firmware existiert ja schon.
>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.
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.
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
Wie schnell läuft denn so die Programmierung über den Eindraht-Programmierer? Da kann man sich ja Kaffee holen gehen, bei den Programmspeichergrößen ;)
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.
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.
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)?
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...
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
Ach so, jetzt ist es auch bei den billigen Plätzen hier hinten angekommen :) Danke
Gibt es ein 'Papier', ob sich der ATXMEGA überhaupt noch 'lohnt'? Oder soll man gleich auf einen 32-Bitter, wie den AT91SAM7S256, umsteigen?
Ich vermute mal eher das die XMEGAs auf lange Sicht die älteren Megas ablösen werden (in einigen Jahren)???
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).
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?
Die PDI-Frequenz ist immer dieselbe, und zwar 2Mhz, egal ob der Controller selbst mit 2Mhz oder 32Mhz getaktet wird.
>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.
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
>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
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
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.
>> 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
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.
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.
>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
> 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
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.
Ä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
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...
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
Ich werde mir wohl im Sommer mal die entsprechende Ausruestung holen, da hab ich wieder Geld uebrig.
@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)
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
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
>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.
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.
@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).
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?
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.
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.
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
>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
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.)
>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
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 ;-).
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
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.
Angehängte Dateien:
-
AudioFrontEnd.png
9,1 KB
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.
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
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
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.
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.
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.
@Jörg Wunsch & Travelrec. Danke für Eure Auskünfte und Anregungen. MfG Paul
Ich platze fast vor Neugierde: Wie sieht denn der Quelltext für dieses ADC/DAC Experiment aus?
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 :-)
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 ;-).
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.
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.
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.
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 :-)
Angehängte Dateien:
-
AudioFrontEnd_active.png
14 KB
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 :-)
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 ;-)
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 :)
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.
>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.
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?
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.
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?
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.
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.
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!
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.
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
Ich wär mir aber nicht sicher, ob der Nachbau das PDI unterstützt, was man für die ATxmega braucht.
Ich hab's nicht ausprobiert - aber in der Anleitung steht : # This hardware also supports debugging xMEGA devices via the PDI interface; Gruss Frank
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
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.
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
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!!!
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
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
Nur so als Info, EmbedIT hat wieder ATxmega128A1 Nachschub bekommen. http://shop.embedit.de/product__710.php Zumindest steht dort wieder "Ab Lager".
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.
@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 ;)
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.
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.
1 | .org $0000 |
2 | jmp RESET ;Reset |
3 | jmp RESET ;NMI, external oscillator failure |
4 | jmp RESET ;PortC Int0 |
5 | jmp RESET ;PortC Int1 |
6 | jmp RESET ;PortR Int0 |
7 | jmp RESET ;PortR Int1 |
8 | jmp RESET ;DMA Channel0 |
9 | jmp RESET ;DMA Channel1 |
10 | jmp RESET ;DMA Channel2 |
11 | jmp RESET ;DMA Channel3 |
12 | jmp RESET ;RTC Overflow |
13 | jmp RESET ;RTC Compare |
14 | jmp RESET ;TWI_C Slave |
15 | jmp RESET ;TWI_C Master |
16 | jmp RESET ;Timer_C0 Overflow |
17 | jmp RESET ;Timer_C0 Error |
18 | jmp RESET ;Timer_C0 Compare/CaptureA |
19 | jmp RESET ;Timer_C0 Compare/CaptureB |
20 | jmp RESET ;Timer_C0 Compare/CaptureC |
21 | jmp RESET ;Timer_C0 Compare/CaptureD |
22 | jmp RESET ;Timer_C1 Overflow |
23 | jmp RESET ;Timer_C1 Error |
24 | jmp RESET ;Timer_C1 Compare/CaptureA |
25 | jmp RESET ;Timer_C1 Compare/CaptureB |
26 | jmp RESET ;SPI_C Complete |
27 | jmp RESET ;USART_C0 RXComplete |
28 | jmp RESET ;USART_C0 DataRegisterEmpty |
29 | jmp RESET ;USART_C0 TXComplete |
30 | jmp RESET ;USART_C1 RXComplete |
31 | jmp RESET ;USART_C1 DataRegisterEmpty |
32 | jmp RESET ;USART_C1 TXComplete |
33 | jmp RESET ;AES |
34 | jmp RESET ;NVM EE ready |
35 | jmp RESET ;NVM SPM ready |
36 | jmp RESET ;PortB Int0 |
37 | jmp RESET ;PortB Int1 |
38 | jmp RESET ;AC_B Int0 |
39 | jmp RESET ;AC_B Int1 |
40 | jmp RESET ;AC_B WindowInt |
41 | jmp RESET ;ADC_B Channel0 |
42 | jmp RESET ;ADC_B Channel1 |
43 | jmp RESET ;ADC_B Channel2 |
44 | jmp RESET ;ADC_B Channel3 |
45 | jmp RESET ;PortE Int0 |
46 | jmp RESET ;PortE Int1 |
47 | jmp RESET ;TWI_E Slave |
48 | jmp RESET ;TWI_E Master |
49 | jmp RESET ;Timer_E0 Overflow |
50 | jmp RESET ;Timer_E0 Error |
51 | jmp RESET ;Timer_E0 Compare/CaptureA |
52 | jmp RESET ;Timer_E0 Compare/CaptureB |
53 | jmp RESET ;Timer_E0 Compare/CaptureC |
54 | jmp RESET ;Timer_E0 Compare/CaptureD |
55 | jmp RESET ;Timer_E1 Overflow |
56 | jmp RESET ;Timer_E1 Error |
57 | jmp RESET ;Timer_E1 Compare/CaptureA |
58 | jmp RESET ;Timer_E1 Compare/CaptureB |
59 | jmp RESET ;SPI_E Complete |
60 | jmp RESET ;USART_E0 RXComplete |
61 | jmp RESET ;USART_E0 DataRegisterEmpty |
62 | jmp RESET ;USART_E0 TXComplete |
63 | jmp RESET ;USART_E1 RXComplete |
64 | jmp RESET ;USART_E1 DataRegisterEmpty |
65 | jmp RESET ;USART_E1 TXComplete |
66 | jmp RESET ;PortD Int0 |
67 | jmp RESET ;PortD Int1 |
68 | jmp RESET ;PortA Int0 |
69 | jmp RESET ;PortA Int1 |
70 | jmp RESET ;AC_A Int0 |
71 | jmp RESET ;AC_A Int1 |
72 | jmp RESET ;AC_A WindowInt |
73 | jmp RESET ;ADC_A Channel0 |
74 | jmp RESET ;ADC_A Channel1 |
75 | jmp RESET ;ADC_A Channel2 |
76 | jmp RESET ;ADC_A Channel3 |
77 | jmp RESET ;TWI_D Slave |
78 | jmp RESET ;TWI_D Master |
79 | jmp RESET ;Timer_D0 Overflow |
80 | jmp RESET ;Timer_D0 Error |
81 | jmp RESET ;Timer_D0 Compare/CaptureA |
82 | jmp RESET ;Timer_D0 Compare/CaptureB |
83 | jmp RESET ;Timer_D0 Compare/CaptureC |
84 | jmp RESET ;Timer_D0 Compare/CaptureD |
85 | jmp RESET ;Timer_D1 Overflow |
86 | jmp RESET ;Timer_D1 Error |
87 | jmp RESET ;Timer_D1 Compare/CaptureA |
88 | jmp RESET ;Timer_D1 Compare/CaptureB |
89 | jmp RESET ;SPI_D Complete |
90 | jmp RESET ;USART_D0 RXComplete |
91 | jmp RESET ;USART_D0 DataRegisterEmpty |
92 | jmp RESET ;USART_D0 TXComplete |
93 | jmp RESET ;USART_D1 RXComplete |
94 | jmp RESET ;USART_D1 DataRegisterEmpty |
95 | jmp RESET ;USART_D1 TXComplete |
96 | jmp RESET ;PortQ Int0 |
97 | jmp RESET ;PortQ Int1 |
98 | jmp RESET ;PortH Int0 |
99 | jmp RESET ;PortH Int1 |
100 | jmp RESET ;PortJ Int0 |
101 | jmp RESET ;PortJ Int1 |
102 | jmp RESET ;PortK Int0 |
103 | jmp RESET ;PortK Int1 |
104 | jmp RESET ;Reserved |
105 | jmp RESET ;Reserved |
106 | jmp RESET ;PortF Int0 |
107 | jmp RESET ;PortF Int1 |
108 | jmp RESET ;TWI_F Slave |
109 | jmp RESET ;TWI_F Master |
110 | jmp RESET ;Timer_F0 Overflow |
111 | jmp RESET ;Timer_F0 Error |
112 | jmp RESET ;Timer_F0 Compare/CaptureA |
113 | jmp RESET ;Timer_F0 Compare/CaptureB |
114 | jmp RESET ;Timer_F0 Compare/CaptureC |
115 | jmp RESET ;Timer_F0 Compare/CaptureD |
116 | jmp RESET ;Timer_F1 Overflow |
117 | jmp RESET ;Timer_F1 Error |
118 | jmp RESET ;Timer_F1 Compare/CaptureA |
119 | jmp RESET ;Timer_F1 Compare/CaptureB |
120 | jmp RESET ;SPI_F Complete |
121 | jmp RESET ;USART_F0 RXComplete |
122 | jmp RESET ;USART_F0 DataRegisterEmpty |
123 | jmp RESET ;USART_F0 TXComplete |
124 | jmp RESET ;USART_F1 RXComplete |
125 | jmp RESET ;USART_F1 DataRegisterEmpty |
126 | jmp RESET ;USART_F1 TXComplete |
127 | |
128 | |
129 | |
130 | ;Program-Code starts here |
131 | RESET: |
132 | cli |
133 | |
134 | ldi Temp, 0b11100000 ;setup external Oscillator: 12..16Mhz, 16k clock cycles start up, 32kHzOscLowPower |
135 | sts OSC_XOSCCTRL, Temp |
136 | |
137 | ldi Temp, OSC_XOSCEN_bm ;enable external oscillator or clock |
138 | sts OSC_CTRL, Temp |
139 | |
140 | WaitOSC: |
141 | lds Temp, OSC_STATUS |
142 | sbrs Temp, 3 ;wait for Oscillator to be stable |
143 | rjmp WaitOSC |
144 | |
145 | ldi Temp, 0b11000011 ;external Oscillator or clock as PLL input, Factor 3 (36,864 MHz) |
146 | sts OSC_PLLCTRL, Temp |
147 | |
148 | lds Temp, OSC_CTRL |
149 | ori Temp, OSC_PLLEN_bm ;enable PLL |
150 | sts OSC_CTRL, Temp |
151 | |
152 | WaitPLL: |
153 | lds Temp, OSC_STATUS |
154 | sbrs Temp, 4 ;wait for PLL to be stable |
155 | rjmp WaitPLL |
156 | |
157 | |
158 | ldi Temp, $D8 ;disable I/O Register protection for 4 cycles |
159 | out CPU_CCP, Temp |
160 | ldi Temp, CLK_SCLKSEL_PLL_gc |
161 | sts CLK_CTRL, Temp |
162 | |
163 | clr Null |
164 | |
165 | ;setup Watchdog timer |
166 | wdr |
167 | ldi Temp, $D8 ;disable I/O Register protection for 4 cycles |
168 | out CPU_CCP, Temp |
169 | ldi Temp, 0b00011111 ;1 Sek. timeout, enable, change enable |
170 | 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.
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.
@ 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!
Es gibt komplette Appnotes zum ADC/DAC bei ATMEL. Du brauchst außerdem das Manual UND das Datenblatt.
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).
Die Beispielcodes sind leider C. Da hat sippel96 leider Recht. Ich muß mal in meiner Codekiste kramen.
Mag nicht jemand nen schnellen Atmega128 nachprogrammieren? ggg ---Duck und renn---- Anselm
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.
Hier mal eine Init als Beispiel:
1 | ;setup ADC |
2 | ldi Temp, $01 |
3 | sts ADCA_CALIB, Temp |
4 | ldi Temp, $FF |
5 | sts ADCA_CALIB+1, Temp |
6 | |
7 | ldi Temp, 0b00000011 ;divide Clock/64 (512khz) |
8 | sts ADCA_PRESCALER, Temp |
9 | ldi Temp, 0b00100000 ;ARefA as reference |
10 | sts ADCA_REFCTRL, Temp |
11 | ldi Temp, 0b00100001 ;pos pin ADCA0, neg pin ADCA1 |
12 | sts ADCA_CH0_MUXCTRL, Temp |
13 | |
14 | ldi Temp, 0b00101001 ;pos pin ADCA4, neg pin ADCA1 |
15 | sts ADCA_CH1_MUXCTRL, Temp |
16 | ldi Temp, 0b01000110 ;SyncSweepADC-Channels 0+1 on EventChannel0 input |
17 | sts ADCA_EVCTRL, Temp |
18 | |
19 | ldi Temp, 0b00010000 ;signed measure, Freerunning |
20 | sts ADCA_CTRLB, Temp |
21 | |
22 | ldi Temp, 0b00000011 ;high level interrupt Ch1 on Conversion Complete, Ch0 is sampled before |
23 | sts ADCA_CH1_INTCTRL, Temp |
24 | |
25 | ldi Temp, 0b00000001 ;enable ADC |
26 | sts ADCA_CTRLA, Temp |
27 | |
28 | ldi Temp, 0b10000010 ;Differential Mode, start first conversion |
29 | sts ADCA_CH0_CTRL, Temp |
30 | ldi Temp, 0b10000010 ;Differential Mode, start first conversion |
31 | sts ADCA_CH1_CTRL, Temp |
Gestartet wird der ADC mit
1 | ldi Temp, 0b00001101 ;start conversion on ADC Ch0 and Ch1 |
2 | sts ADCA_CTRLA, Temp |
Das Ergebnis findet man in ADCA_CH0RES und ADCA_CH0RES+1.
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!
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???
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.
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.
Angehängte Dateien:
-
TFT_XMega1.jpg
100 KB -
TFT_XMega2.jpg
260 KB
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.
Angehängte Dateien:
-
XMega_EventTiming.jpg
64 KB -
XMega_DMATiming.jpg
33 KB -
XMega_DMATiming2.jpg
49 KB
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?
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
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?
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.
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.
Das kann man so pauschal nicht sagen. Ich argumentiere zum Beispiel mit Nein, da es beim xmega eine DMA gibt.
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?
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.
Einfach per Event System vom Port aufs DMA. Dann den PORT noch entsprechend konfigurieren, dass ein bestimmter Pin das Event Signal auslöst.
@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
Ü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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.