www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik xmega/xplain vga signal


Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
>75Mhz

Wie kommst Du denn darauf?!

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine ich gelesen zu haben, was hast du denn im kopf?

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay korrektur, intern 32Mhz extern 16Mhz.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte hauptsächlich einen einfachen grafikchip synthetisieren. Alá 
SNES grafik etc. mal sehen was sich machen lässt.

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendein VGA Signal wirst Du schon generieren können, aber was 
vernünftiges kannst Du sicherlich nicht machen damit.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein nettes Video.
Mit XMEGA128 und Nokia LCD.

http://www.youtube.com/watch?v=QBre6VE8iF0

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ).

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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

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.