Hallo.
Gegeben ist ARM M3 mit max 67 Mhz.
Ich habe 0 (Null) Erfahrung mit ARM Architektur/Programmierung und nur
wenig mit µC allgemein.Deswegen frage ich mal hier, ob so ein µC für
VGA Bildschirm (z.B. 1280x1024) ausreichend ist.
Der µC soll nichts besonderes ausrechnen, nur den externen Datenfluss
auf dem Bildschirm mit ca. 25 FPS ausgeben.
Das Problem ist, dass ich hauptsachtlich FPGA benutze, aber für die
Bildschirmsteuerung ist FPGA ziemlich aufwändig. Klar kann man mit FPGA
alles realisieren, aber ich will das Rad nicht neu erfinden. Außerdem
habe ich gehört, dass ARM schon richtige Bibliotheken dafür hat, also
wäre die Bildschirmsteuerung samt Mustergenerierung etc, damit viel
einfacher.
Also nochmal die Frage, reicht ARM M3 aus?=)
Hmm, stimmt, habe ich ganz vergessen die Info anzugeben:
Das Bild ist RGB mit 16 Bit Auflösung. Zurzeit ist es nur geplannt,
dass der µC nur die Pixeldaten (über 3 pins für R,G und B
entsprechend) von dem FPGA empfängt, und direkt auf dem TFT
ausgibt.Also muss der µCdie ganze Synchronisierung etc. behandeln.
Später, wenn noch Ressourcen übrig sind, würde ich gerne auch Text und
simple 2D Grafiken anzeigen.
Wäre das möglich?
Frank K. schrieb:> Text? Grafik? monochrom? Farbe?>> Wenn der Videocontroller entsprechend nachhilft, kannst Du eine ganze> Menge machen.
Was meinst du mit Videokontroller?
Genauer gesagt handelt es sich um Cypress Psoc 5PL Dev Board.
http://www.cypress.com/?rID=51577
Hi,
Ich habe jetzt nicht so viel Erfahrung mit FPGA, aber ich dachte bisher
das dies doch eher einfacher mit einem FPGA zu machen ist als mit einem
Mikrocontroller. Ist das notwendige Timing damit nicht leichter und
stabiler zu erreichen?
Gruß Martin
Ich habe auch mal VGA mit einem FPGA gemacht. Soweit ich mich erinnere
war der Basis-Pixeltakt 25MHz. Es wird also schon sehr sportlich, wenn
man mit einem 67 MHz Prozessor ein 25 MHz RGB-Signal darstellen will.
Das sind rund 2.5 Takte pro RGB-Pixel.
Das reicht kaum aus, den Wert aus dem Speicher zu holen und auf einen
Port zu geben. Geschweige denn, noch Graphiken nebenbei zu zeichnen.
Oder sehe ich da irgendetwas falsch?
@Wilder Kater mit Schwanz,
ich habe mit dem STM32F4 (bei 168MHz) eine VGA Ausgabe mit
640x480 Pixel programiert
wobei die reale Auflösung bei 320x240 liegt
bei 8bit Farbe braucht das ca. 76 kByte RAM
das Hauptproblem ist der Pixeltakt der Horizontalen Zeile
bei 640 Pixel und 50 Hz Bildwiderholrate sind das ca. 25MHz
das habe ich mit dem STM nicht hinbekommen !!
ich habe dann die Auflösung halbiert und brauche damit
nur noch mit ca. 13MHz die Pixelwert per DMA ausgeben
das schafft der STM gerade noch so
hier gibt es ein Youtube Video
von meiner Library (allerdings nicht von mir)
http://www.youtube.com/watch?v=axJRn_WZFY0
1280 Pixel halte ich also auch für "sehr schwer"
wenn nicht gar unmöglich
(lass mich da aber gern belehren)
ich habe das ganze auch schon per FPGA gelöst
der Aufwand für das anzeigen sind ca 20 Zeilen VHDL :-)
(für ein Statisches Bild aus dem RAM)
..soviel zu deinem "ziemlich aufwändig"
wobei ich hier nicht wüsste wie man hier deinen geforderten
"externen Datenfluss" ins RAM bekommt
(was dieser Datenfluss auch immer heißen mag)
Gruss Uwe
Hm. Also einen Tft Display mit 1280 x1024 habe ich mit meinem Fpga
board erfolgreich gesteuert. Die ganze Synchronisation ist wirklich mit
fpga leicht zu schafen. Nur die ganze kompligierte ausgabe wollte ich
mit vhdl nich machen, sprich Textausgabe,grafen etc. Eine sache ist ja
ein Bild aus SRAM auslesen, andere sache die verdammte Buchstaben zu
generieren.
PS.
Ich bin der Fragesteller
>Hm. Also einen Tft Display mit 1280 x1024 habe ich mit meinem Fpga>board erfolgreich gesteuert
dann teil die Aufgabe doch auf :
benutz das FPGA um die Daten aus dem Grafik-Speicher
per VGA auf dem Bildschirm anzuzeigen
und schaff eine Schnittstelle zu einer externen CPU (welche auch immer)
und lass die CPU das Aufbereiten der Grafik-Daten übernehmen
dann muss die CPU nur noch in der "Austastzeit"
die Daten zum FPGA übertragen
oder einfacher : benutz zwei Bildpuffer
einer wird vom FPGA angezeigt, der zweite wird
gemütlich von der CPU beschrieben
(und es muss nur noch hin- und her- geschaltet werden)
Gruss Uwe
Meinst du, dass sowohl FPga als auch der mikrocontroller den
gemeinsammen Speicher benutzen?D.h der mikro generiert text.etc,
schreibt die pixeldaten auf dem Sram chip, und Fpga gibs die daten aus.
Das wäre eine Möglichkeit.
>Meinst du, dass sowohl FPga als auch der mikrocontroller den>gemeinsammen Speicher benutzen?
Ja...entweder als externes RAM oder einfacher
ein internes DUAL-Port-RAM im FPGA
wo die schreib/lese funktionen vom FPGA verwaltet werden können
oder gleich eine Soft-CPU im FPGA
(wenn du dazu die Möglichkeit hast)
Gruss Uwe
Wilder Kater mit Schwanz schrieb:> Ich habe 0 (Null) Erfahrung mit ARM Architektur/Programmierung und nur> wenig mit µC allgemein.Deswegen frage ich mal hier, ob so ein µC für> VGA Bildschirm (z.B. 1280x1024) ausreichend ist.
VGA ist 640x480
Ansonsten kommt es drauf an, an was du da eigentlich gedacht hast. So
wie du schreibst, ist alles nur wirr.
Wenn du dir meit nem CPLD oder FPGA ne passende Ansteuerung für ein
Display machst, dann passt ein ARM (sofern er nen externen Bus hat)
immer.
Wenn du aber dran denken solltest, den ARM den Bildrefresh machen zu
lassen, bist du komplett auf dem Holzweg.
Ansonsten ist 800x480 die sinnvolle obere Grenze bei uC wie z.B.
LPC2478.
W.S.
Ja, ich denke der Plan steht nun fest.
FPGA wird die ganze Display Steuerung übernehmen, zumal das FPGA
Board sowieso eine ordentliche VGA Schnittschtelle + 512KB SRAM und 8MB
SDRAM besitzt.
Der Text und diverse Grafen werden von ARM Modul generiert und in SRAM
auf FPGA Board geschrieben.Das sollte ARM porblemlos schafen. Die
Aktualisierungsrate für den Text usw. kann problemlos unter 25 fps
liegen. Hauptsache das Bild von der CCD Kamera wird Live übertragen,
aber das schaft FPGa schon ohne probleme.
Ich muss nur herausfinden, wie ich die grafische ARM-Komponente in
die Pixelmatrix konventiere....
>Ich muss nur herausfinden, wie ich die grafische ARM-Komponente in>die Pixelmatrix konventiere....
ich würde da gar nichts "konvertieren" sondern die CPU mit dem FPGA so
verbinden, das die CPU das Grafik-RAM vom FPGA wie ein eigenes externes
RAM bedienen kann (mit entsprechenden Bus- und Steuerleitungen)
und der FPGA muss dann nur noch den Inhalt vom Grafik-RAM per VGA
ausgeben
SO wuerde ich das auch machen.
Das FPGA liest (in einer Art Endlosschleife) die Daten aus
dem RAM (Bildspeicher) und ist fuer die Ansteuerung und das
Timing des Displays zustaendig. Der ARM Mikrocontroller ist
fur die Aufarbeitung der Daten zustaendig und schreibt diese
dann jeweils in den Bildspeicher.
1280x1024x16 Bit= 2,5Mbyte Pro Frame
Für das SRAM zu viel.
Wie schnell ist denn dein SDRAM.
Bei 25Hz und 2,5Mbyte Pro Frame sind das 62,5MByte/s.
Und wenn du da zwischendurch auch noch reinschreiben willst das ganze
mal 2, also 125MByte/s. Mit nen 66MHzx16Bit SDRAM sportlich.
>..da Du ja den gesamten Bildchirmspeicher im µC benötigst.
Das benötigte RAM (einige MB) wird wohl weder im uC noch im FPGA
ausreichend vorhanden sein, so dass man auf jedes Fall externes RAM
anbinden muss, das dann mit DualPort-Beschaltung.
Uwe schrieb:> Mit nen 66MHzx16Bit SDRAM sportlich.
Hähä.. ja, so ähnlich seh ich das auch.
Nun gut, für solche Fälle sollte man ein 32 Bit breites RAM verwenden,
aber es bleibt ne echte Herausforderung - selbst für Könner.
W.S.
