Hey hat jemand hier schon mit dem xplain board gespielt? Ich hab noch keins, frage mich aber ob sich das board lohnt um damit video signale zu erzeugen bzw. ein TFT anzusteuern. Nach den Spezifikationen sollte das doch gut gehen: 75Mhz, 8MB SDRAM. Spricht etwas dagegen? Ansonsten würde ich mich mal dareinstürzen.
>75Mhz
Wie kommst Du denn darauf?!
Ich glaube, daß man mit dem XMEGA schon ein paar Pixel auf den Schirm zaubern kann, aber für echtes Video wird´s nicht reichen. Das ist die Stärke eines AVR32-Controllers, zum Beispiel.
Ich möchte hauptsächlich einen einfachen grafikchip synthetisieren. Alá SNES grafik etc. mal sehen was sich machen lässt.
Der hat doch - wenn ich richtig informiert bin - diesen tollen DMA-Controller, der Peripheriegeräte ohne CPU-Belastung koppeln kann. Dann könnte man doch vielleicht einen Teil des RAMs (eine Bildzeile) per DMA über Schieberegister ausgeben? Die CPU müsste dann nur am Beginn und am Ende der Bildzeile steuernd eingreifen. Gruß, bix
Ja klar kannst du an einen XMEGA getacktet mit 32Mhz ein kleines TFT oder OLED hängen. Ich habe ein OLED mit 320x3x240 von CMEL am XMEAG angesteuert im 8Bit Mode. Texte und Symbole kann mein noch unoptimierter Code flüssig schreiben. Beim schreiben eines Vollbilds allerdings ist der Bildaufbau doch deutlich zusehen. Allerdings ist mein Code wie gesagt noch unopimiert (nutzte kein DMA o.ä.) und ich steuere im Moment noch mit 8Bit an nicht mit 18Bit.
Wenn Du schon ein neues Board kaufen willst, dann machts doch keinen Spass, wenn Du schon optimieren musst um Deine Grundanforderungen abzudecken. Da würde ich lieber was nehmen, was gleich ohne Handstände funktioniert und noch Reserven hat, also mehr Rechenleistung als ein XMEGA bzw. zusätzlich einen Grafikcontroller auf dem Board verbaut hat.
naja genau das versuche ich ja gerade zu erfahren OB der prozesor wirklich damit überlastet wäre. ich will kein HDTV signal umrechnen sondern CGA/VGA Grafik wenns hochkommt.
Also irgendein VGA Signal wirst Du schon generieren können, aber was vernünftiges kannst Du sicherlich nicht machen damit.
Kann die DMA eigentlich über einen Port des X-Mega Daten schreiben, oder geht das nur mit Peripherie wie z.B. dem DAC? Falls die DMA das schafft, müsste eigentlich eine Auflösung von 1024x768 Punkten möglich sein ( Ich glaube, eine Zeile benöigt 50uSec, d.h. 1000 Punkte benötigen eine Pixeltakt von 20MHz ).
Hallo Klaus, ja kann sie. Das ist das tolle an dieser DMA, sie kann von jeder Adressquelle (ein Port ist z.b. an eine Adresse gekoppelt) an eine beliebe Adresse schreiben. Also z.b. von PORTA nach PORTB über DMA geht auch. Man kann auch Timer Register mit Hilfe der DMA überschreiben usw. Wobei ein kleiner ATmega88 hat ja auch schon VGA Signal ausgegeben inkl. Sound, und das fließend... Siehe hier: http://www.linusakesson.net/scene/craft/
Hallo Joe, das Craft-Demo kenne ich schon. Akesson ist zweifelsohne genial. Beim XPLAIN sehe ich allerdings dank des RAM-Speichers von 8MB die Möglichkeit, richtige VGA-Bilder zu erzeugen. Hast Du den DMA-Modus schon einmal verwendet? Ich bin auf der Suche nach einem Beispiel, bei dem ein Speicherbereich auf einen Port ausgegeben wird. Ein kleines Problem könnte es beim XPLAIN noch geben: Die Wait-States des RAMS. Ich könnte mir vorstellen, dass der DMA-Transfer vom RAM zum Port gar nicht mit 20MHz machbar ist. Gruß, Klaus
Schau mal nach dieser App Note AVR1304: Using the XMEGA DMA Controller Dort ist ein Treiber mit dabei, der die Verwendung ganz einfach macht. Als Übergabeparameter für das Ziel gibst Du die Adresse des Ports an, die Destination stellst du als "fixed" ein (das heißt die Zieladresse bleibt immer dieselbe), die Source Adresse Deines Arrays und z.b. als "increasing" dann kopiert die DMA byte für byte. Es gibt verschiedene Modi, z.b. 8byte auf einen Rutsch usw. Wie schnell das ganze geht hängt davon ab ob die CPU zwischendrin auf das SRAM zugreifen muß (damit wäre die DMA blockiert). Besser wärs vielleicht das EBI zu verwenden und die Daten von dort aus zu holen. Kannst ja einen einfachen Test machen: Einen Array mit 0x00,0x01,0x00,0x01 usw füllen, und dann die DMA so programmieren: Startadresse des Arrays, Adresse auto-increase, Auto-reload Zieladresse des Ports, Adresse fixed höchste Burst Einstellung Nach erreichen der Endadresse des Arrays beginnt die DMA wieder von vorne, wenn du die Anzahl der Wiederholungen entsprechend setzt (0-255, wobei 0=endlos). Dann misst mal mit nem Oszi was da hinten rauskommt
>Beim XPLAIN sehe ich allerdings dank des RAM-Speichers von 8MB die >Möglichkeit, richtige VGA-Bilder zu erzeugen. >Hast Du den DMA-Modus schon einmal verwendet? Sehe die Chance nicht. Schau dir das Timing für 4Bit SDRAM im Manual an. Du setzt voraus das das DMA ungestört und in jedem CPU Takt ein Datenbyte aus dem SDRAM holen könnte. Beides ist nicht der Fall. Im besten Fall benötigst du 23 SDRAM Takte, was rund 12 CPU Takte sind, für 2 Datenbytes lesend. Ergo: 1 Datenbyte = minimal 6 CPU Takte Latenz. Jetzt könnte man den Burst Mode DMA benutzen, zb. 8 Bytes, um den SDRAM besser anzusteuern. SDRAM ist nur so schnell wenn man größere Datenblöcke am Stück liest. Durch diesen Burst Mode dürfte der Durchsatz steigen aber deine Synchronität bei der Ausgabe der Daten ist flöten. Ergo: SDRAM -> DMA -> UART in MSPIMode um das Timing sauber zu bekommen. Das MSPI der UARTs kann aber wiederum nicht mit dem DMA Burst Mode. Kommt noch der Punkt hinzu das jeder DMA Transfer durch die CPU geblockt werden kann wenn die CPU selber den Datenbus benötigt. XMegas DMA ist also höchstens ein Pseudo-DMA da der DMA nicht volllständig transparent über eigenen Datenbus mit der Peripherie arbeiten kann. Denoch meine ich das mit dem XMega mehr VGA Auflösung drinnen sein muß als das was wir von den nomalen Megas her kennen, die dann aber ebenfalls ausgelastet sind. Gruß Hagen
Hallo Hagen, vielen Dank für die ausführliche Antwort. > Sehe die Chance nicht. Schau dir das Timing für 4Bit SDRAM > im Manual an. Du setzt voraus das das DMA ungestört und > in jedem CPU Takt ein Datenbyte aus dem SDRAM holen könnte. > Beides ist nicht der Fall. Im besten Fall benötigst > du 23 SDRAM Takte, was rund 12 CPU Takte sind, für 2 Datenbytes > lesend. Ergo: 1 Datenbyte = minimal 6 CPU Takte Latenz. Hier habe ich mal den Code aus dem XPLAIN-SDRAM access Beispiel kopiert: [c] /* Initialize EBI. */ EBI_Enable( EBI_SDDATAW_4BIT_gc, EBI_LPCMODE_ALE1_gc, EBI_SRMODE_ALE12_gc, EBI_IFMODE_3PORT_gc ); /* Initialize SDRAM */ EBI_EnableSDRAM( EBI_CS_ASPACE_8MB_gc, /* 8 MB address space. */ (void *) SDRAM_ADDR, /* Base address. */ false, /* 2 cycle CAS Latency. */ false, /* 11 Row bits. */ EBI_SDCOL_8BIT_gc, /* 8 Column bits. */ EBI_MRDLY_1CLK_gc, /* 1 cycle Mode Register Delay. */ EBI_ROWCYCDLY_1CLK_gc, /* 1 cycle Row Cycle Delay. */ EBI_RPDLY_1CLK_gc, /* 1 cycle Row to Pre-charge Delay. */ EBI_WRDLY_1CLK_gc, /* 1 cycle Write Recovery Delay. */ EBI_ESRDLY_1CLK_gc, /* 1 cycle Exit Self Refresh to Active Delay. */ EBI_ROWCOLDLY_1CLK_gc, /* 1 cycle Row to Column Delay. */ 0x03FF, /* 1023 cycle Refresh Period (32.8 ms @ 2MHz). */ 0x0100 ); /* 256 cycle Initialization Delay (128 us @ 2MHz). */ /c] Ich habe mich bis jetzt mit dem RAM noch gar nicht eingehend beschäftigt. Für mich erstaunlich: Das memory-interface des XMega lässt sich tatsächlich für ein 4Bit Ram initialisieren. Mir fällt es schwer, aus der Initialiserung auf die von Dir angegebenen 23 SDRAM Takte zu schließen, aber ich nehme jetzt einfach mal an, dass Deine Angaben stimmen. Was mich wundert: in dem Atmel Demo kann man laut Kommentartext nur 64K addressieren ( angeblich weil der AVR-GCC pointer nur 16 bit hat ). Mit Deinen Angaben von 12 CPU Takten/Byte käme man auf eine Datenrate von 32MHz/12=2,66MByte/sec. Das ist zu langsam für VGA. Wenn man mit dieser Geschwindigkeit statt per DMA die Daten vom RAM in die UART schiebt, würde es für einfarbige Bilder vielleicht reichen.
6 CPU Takte pro Byte, und das kannst du im XMega Manual A nachlesen bei Timings. Die aktuellen XMegas haben keinen Port L und somit kann man mit den Teilen ausschließlich nur 4Bit SDRAM ansteuern. Interessant ist der Punkt das Schreben teilweise schneller geht als Lesen. Bei meinen Arbeiten mit FPGAs und DDR2-SDRAM ist das immer andersrum. Man kann per DMA den kompletten 24 Bit Addressraum ansprechen, das hat nichts mit dem WinAVR-GCC zu tun. Muß man per SW und WinAVR GCC auf einzelne Bytes im erweiterten Addressbereich zugreifen so muß man mit künstlichen 32Bit Zeigern arbeiten und mit kleineren Makros diesen Zeiger in zb. RAMPZ + Z vorher laden. Ist also nur eine Frage der Programmierung. Nicht elegant unter GCC aber machbar wenn man sein Projekt bischen danach konstruiert. Gruß Hagen
Übrigens, nutzt du SRAM statt SDRAM am XMega so hast du 1.) 8 Bit Datenbus, 2.) mehr Datendurchsatz und 3.) mehr Kosten pro Datenbyte. Siehe XMega Manual A. 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.