Vga Signal: Ein VGA Signal besteht ja aus einem vsync, hsync, r,g u. b Signal. hsync: Wird eine Zeile geschrieben, so liegt an diesem Pin high an. Nachdem die Zeile geschrieben wurde, liegt an diesem Pin ein low Signal an. Das low Signal bleibt solange aktiv, bis die nächste Zeile beginnt. vsync: Wird ein Bild geschrieben, so liegt an diesem Pin high an. Wurde das komplette Bild geschrieben, so liegt an diesem Pin low an bis das nächste Bild beginnt. R,G u.B : An diesen Pin wird eine Spannung von 0-0,7 Volt angelegt, woraus dann die Farbe generiert wird. Ich wollte nur Nachfragen ob das so stimmt.
>VGA Signal per Mikrocontroller erstellen -> Timings Mit welchem Controller? Hier ein Beispiel: Beitrag "VGA Ausgabe per STM32F4 Discovery-Board"
Ich werde mir eventuell ein günstiges arm Board kaufen, welches über die entsprechende Taktfrequenz, Ram u. USB Anbindung verfügt. Ziel ist es eine USB VGA Grafikkarte mit einer Auflösung von 800x600 u. 1024x768 Pixel zu erstellen. Die Bilder werden im png Format über die usb Schnittstelle in einem Protokoll übertragen. In dem Protokoll hab ich dann noch eine CRC Prüfsumme, die dann der Mikrocontroller mit den RAW Daten abgleicht. Gab es einen CRC Fehler, wird das entsprechende Paket noch einmal angefordert. Gab es keinen CRC Fehler, so wird das nächste Paket angefordert. Ram: Das Ram nutze ich für 3 Sachen. 1) Ablage der Pakete 2) RAW Format des Bildes was gerade dargestellt wird 3) RAW Format des Bildes was in der Zwischenzeit per usb übertragen wird. Um die zeitkritischen Sachen wie vsync, hsync, r g u. b verwende ich einen Timer
unbekannt schrieb: > Ein VGA Signal besteht ja aus einem vsync, hsync, r,g u. b Signal. Ja. > hsync: > Wird eine Zeile geschrieben, so liegt an diesem Pin high an. Nicht unbedingt. > Nachdem die Zeile geschrieben wurde, liegt an diesem Pin ein low Signal > an. Nicht unbedingt. > Das low Signal bleibt solange aktiv, bis die nächste Zeile beginnt. Das ganz sicher nicht. > vsync: [genau derselbe Quatsch] > R,G u.B : > An diesen Pin wird eine Spannung von 0-0,7 Volt angelegt, woraus dann > die Farbe generiert wird. Naja, die drei Spannungen ergeben letztlich die dargestellte Farbe und Helligkeit. Die Formulierung kann man wohl gerade so als halbwegs treffend durchgehen lassen. > Ich wollte nur Nachfragen ob das so stimmt. Nein, tut es nicht. Es fehlt in der Darstellung die Differenzierung sync vs. blank (sowohl horizontal als auch vertikal) und es fehlt die Tatsache, daß beide Sync-Signale nicht unbedingt "low-aktiv" sein müssen, sondern die sog. "Polarität" dieser Signale zur Signalisierung bestimmter VGA-Modi und Stromspar-Zustände benutzt wird.
Nein, tut es nicht. Es fehlt in der Darstellung die Differenzierung sync vs. blank (sowohl horizontal als auch vertikal) und es fehlt die Tatsache, daß beide Sync-Signale nicht unbedingt "low-aktiv" sein müssen, sondern die sog. "Polarität" dieser Signale zur Signalisierung bestimmter VGA-Modi und Stromspar-Zustände benutzt wird. Was meinst du genau mit sync vs. blank (sowohl horizontal als auch vertikal)? Ist das die vordere u. hintere Schwarzschulter, also Zeilen als auch Spalten die nicht dargestellt werden? http://tinyvga.com/vga-timing/800x600@72Hz Daten für eine Zeile: Scanline part Pixels Time [µs] Visible area 800 16 Front porch 56 1.12 Sync pulse 120 2.4 Back porch 64 1.28 Whole line 1040 20.8 Die vordere Schwarzschulter 56 Pixel u. hintere Schwarschulter 64 Pixel ergibt doch die vsync Länge von 56 + 64 = 120 Pixel. Leider wird bei diesen Timingtabellen nicht mit angegeben, ob bei einer aktiven Zeile das vsync high ist. Wenn ich es aus der Tabelle entnehme, nehme ich an, dass das vsync Signal nur für 120 Pixel aktiv ist u. dann low ist. Das gleiche natürlich auch beim vsync Signal
unbekannt schrieb: > Ziel ist es eine USB VGA Grafikkarte mit einer Auflösung von 800x600 u. > 1024x768 Pixel zu erstellen. Das mit einem ARM in Software? Mutig. Hast Du Dir mal angesehen, was für einen Pixeltakt eine VGA-Karte bei diesen Auflösungen verwendet?
hi , ja ich wollte es probieren..bei ebay gibt es recht gute Boards für wenig Geld. Das einzigste was mir aber Probleme bereitet, ist das Erzeugen der Spannungen bei r g u. b. Könnte man dies eventuell mit D/A Wandler bewerkstelligen? Es gibt bestimmt D/A Wandler die schnell sind. Wenn es so gehen könnte, könnte mir jemand einen passenden D/A Wandler empfehlen? Preislich sollte der D/A Wandler auch nicht so teuer sein. Da ich ja zeitglich an r g u. b eine Spannung zwischen 0-0,7 V anlegen muß, müßte ich hier 3 D/A Wandler einsetzen. Noch eine Frage zu dem r,g u. b Pin. An diesen Pins liegt ja die Spannung 0-0,7 Volt an. r = 256 Bit g = 256 Bit b = 256 Bit Verhält es sich linear? Wenn ich bei r z.b den Wert 100 habe.....100 * 0,7 / 256 = 0,2734375 Volt
unbekannt schrieb: > Das einzigste was mir aber Probleme bereitet, ist das Erzeugen der > Spannungen bei r g u. b. > > Könnte man dies eventuell mit D/A Wandler bewerkstelligen? Nicht nur eventuell, sondern sogar ganz sicher. > Da ich ja zeitglich an r g u. b eine Spannung zwischen 0-0,7 V anlegen > muß, müßte ich hier 3 D/A Wandler einsetzen. So isses. > Noch eine Frage zu dem r,g u. b Pin. > An diesen Pins liegt ja die Spannung 0-0,7 Volt an. Das muß nicht so sein. Diese Spannungen dürfen "floaten", also AC-gekoppelt sein. Wichtig ist nur, daß die maximale Amplitude des Signals 0,7V nicht nennenswert übersteigt, die absolute Spannung ist hingegen ziemlich unwichtig. > r = 256 Bit > g = 256 Bit > b = 256 Bit Nein. Maximal werden zehn Bit pro Kanal verwandt. Normalerweise nur 8 Bit und früher(TM) auch oft noch deutlich weniger. Das hängt einfach davon ab, was man darstellen will. Acht Bit pro Kanal (16M Farben) reichen eigentlich völlig aus, was die Fähigkeiten der menschlichen Rezeptoren betrifft. Die zwei zusätzlichen Bits bei bestimmten Anwendungen (Druckvorstufe und sowas) dienen vor allem dazu, Reserven für das Farbmanagement zu schaffen. > Verhält es sich linear? Über die ganze Kette betrachtet: Praktisch nie. Genau deswegen gibt es Sachen wie das Farb-Management.
unbekannt schrieb: > Ziel ist es eine USB VGA Grafikkarte mit einer Auflösung von 800x600 u. > 1024x768 Pixel zu erstellen. was für einer Farbtiefe schwebt dir denn da vor ? bei 8bit pro Pixel (= 256 Farben) brauchst du bei 1024 x 768 Pixel 768 kByte RAM bedeutet du brauchst ein externes RAM (ich kenne zumindest keinen ARM der soviel internes RAM hat) unbekannt schrieb: > Es gibt bestimmt D/A Wandler die schnell sind. die gibt es bestimmt, aber du brauchst laut Spezifikation bei 60Hz @ 1024x768 einen Pixelclock von 65 MHz bei seriellen Wandlern und 8bit Auflösung musst du diese mit 520 MHz ansteuern (grob gerechnet) und davon 3 gleichzeitig viel Spaß dabei :-) Hinweis : das Farbsignal kannst du auch per R2R-DAC machen Gruss Uwe
unbekannt schrieb: > Es gibt bestimmt D/A Wandler die schnell sind. > Wenn es so gehen könnte, könnte mir jemand einen passenden D/A Wandler > empfehlen? http://www.wayengineer.com/index.php?main_page=product_info&cPath=50_55&products_id=160
Für den Anfang würde ich mal mit 3 Bit Grün und je 2 Bit Blau und Rot beginnen. Als "Wandler" reichen dann ein paar Widerstände an den Portpins. Damit kannst du schon schöne bunte Bilder machen und bekommst einen Eindruck von der Genauigkeit, die du beim Timing brauchst. Der Schritt zu den 8 Bit pro Farbe kann dann als nächstes kommen.
unbekannt schrieb: > Ziel ist es eine USB VGA Grafikkarte mit einer Auflösung von 800x600 u. > 1024x768 Pixel zu erstellen. > > Die Bilder werden im png Format über die usb Schnittstelle in einem > Protokoll übertragen. > > In dem Protokoll hab ich dann noch eine CRC Prüfsumme, die dann der > Mikrocontroller mit den RAW Daten abgleicht. Ich gehe davon aus, dass die Ausgabe ruckelfrei sein soll. Dann müssen 60 PNG Bilder mit 1024*768 Pixel pro Sekunde dekomprimiert werden. Es wäre sehr sinnvoll, wenn du uns den von dir ausgewählten Controller nennen würdest, der dies schafft. Nur damit man weiß, welchen Typ man einsetzen könnte, wenn man mal etwas mehr* Rechenleistung benötigt. (*mehr als ein ATmega etc leistet)
Ing schrieb: > unbekannt schrieb: >> Ziel ist es eine USB VGA Grafikkarte mit einer Auflösung von 800x600 u. >> 1024x768 Pixel zu erstellen. Troll. >> Die Bilder werden im png Format über die usb Schnittstelle in einem >> Protokoll übertragen. Troll. >> In dem Protokoll hab ich dann noch eine CRC Prüfsumme, die dann der >> Mikrocontroller mit den RAW Daten abgleicht. Troll.
Rufus Τ. Firefly schrieb: > Das mit einem ARM in Software? Mutig. Ach Rufus, solche grandiosen Ideen kommen hier alle paar Wochen vorbeigeflogen - du weißt das ja. Wenn der TO sich nicht mal die Mühe macht, mal auszurechnen, was er erstmal an Pixeltakt benötigt, sich ebenfalls keine Mühe macht, den Bedarf an Video-RAM mal zu überschlagen und so weiter, dann weiß man, das das alles nur heiße Luft ist. Gut Nacht sag ich dazu. W.S.
Bitte 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.