mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik VGA-Ausgabe in Elektronikprojekt einbauen


Autor: mythbu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich plane gerade ein Elektronikprojekt, wo ich eine VGA-Ausgabe einbauen 
möchte. Momentan besteht das Projekt aus einem Mikrocontroller mit 
externem SRAM. Der µC ist die ganze Zeit beschäftigt, rechnet etwas und 
legt die darzustellenden Daten im SRAM ab. Wie früher: ein Byte ist ein 
Zeichen, dass dargestellt wird auf z.B. 24x80 Zeichen Ausgabe.

Ich weiß, dass man mit dem µC VGA-Ausgabe machen kann. Das geht hier 
aber nicht, da der "Haupt" µC wirklich die ganze Zeit zum rechnen 
braucht (ATMega@20 MHz). Also ist es die einzige Lösung aus meiner 
Sicht, wenn man einen zweiten µC einbaut, der auch mit dem SRAM 
verbunden ist und sich nur um die VGA-Ausgabe kümmert. Allerdings ist 
mir nicht klar, wie das mit der Abfrage des "Bildspeichers" 
funktionieren soll:

1.) Der Darstellungs µC kann den Adressbus belauschen und bei einer 
Adresse im Bereich des Bildspeichers den Datenwert abfangen und im 
internen SRAM speichern für die Darstellung. Falls er aber gerade eine 
VGA-Zeile zeichnet hat er ja keine Zeit um auf solche Interrupts zu 
reagieren. Daher gehen die Daten somit für Ihn verloren.

2.) Falls er dann die verlorenen Daten aus dem SRAM lesen möchte geht 
das auch wieder nicht, da ja der Haupt µC gerade zugreifen könnte und 
nicht angehalten werden kann.

Meine Frage ist nun an Euch, wie man solch ein Problem lösen kann. 
Eigentlich ist das ja ein typisches Problem eines Heimcomputers aus den 
80ern. Da war's dann so gelöst, dass der Systemtakt eben auf PAL/NTSC 
abgestimmt war und alles um die Grafikausgabe "drumherumgebaut" wurde. 
In späteren VGA-Karten wird ja ein VRAM verwendet, dass lesen und 
schreiben gleichzeitig zulässt. Leider ist beides keine Option für mich.

Kann man vielleicht mit dem Xilinx CPLD XC9536 XL eine Lösung finden (36 
macrocells, 800 gates)? Ich habe zwar noch nie was mit FPGAs & CPLDs 
gemacht, aber weil diese hier so günstig waren, hab' ich mir einfach mal 
welche in China bestellt.

Viele Grüße!

Autor: Guest (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
mythbu schrieb:
> Kann man vielleicht mit dem Xilinx CPLD XC9536 XL eine Lösung finden (36
> macrocells, 800 gates)? Ich habe zwar noch nie was mit FPGAs & CPLDs
> gemacht, aber weil diese hier so günstig waren, hab' ich mir einfach mal
> welche in China bestellt.

Der ist billig weil er scheiße ist. Mit nem vernünftigen FPGA geht das 
natürlich recht elegant, der macht aus deinem SRAM dann eben ein 
DualPort RAM. Kann der Rechen-uC die Daten nicht anderweitig 
weitergeben?

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:
> Meine Frage ist nun an Euch, wie man solch ein Problem lösen kann.

Mit einem µC, der zum einen über genug internes RAM verfügt und zum 
anderen den RAM-Inhalt per DMA als VGA-Signal ausgeben kann.
Als Beispiel STM32F4xx oder STM32F7xx.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:
> wenn man einen zweiten µC einbaut, der auch mit dem SRAM
> verbunden ist

Hier hat es einer mit nem 8051 und ohne externes SRAM gemacht:

http://community.silabs.com/t5/8-bit-MCU/Random-La...

mythbu schrieb:
> Der Darstellungs µC kann den Adressbus belauschen und bei einer
> Adresse im Bereich des Bildspeichers

Du brauchst doch nur vom ATMega 8 Pins als "Datenbus" und z.B. 10 Pins 
als Adressbus mit dem "zweiten µC" verbinden und der macht das dann 
ohne/mit seinem SRAM, zumal das nur unidirektional WRITE-ONLY ist.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR Mikrocontroller als GPU zu missbrauchen ist ein nettes Experiment, 
taugt aber nicht für reale Anwendungen.

Schau mal: 
http://www.watterott.com/de/Micro-VGA-Mikrocontrol...

Abgesehen davon ist VGA schon lange veraltet, deswegen würde ich bei 
einer Neuentwicklung auf eine aktuelle Schnittstelle setzen.

Ich persönlich nutze gerne Tablets/Smartphones als Display. Das kann man 
wahlweise über eine selbst geschriebene APP realisieren oder über den 
Web Browser und einen Webserver auf dem Mikrocontroller.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
mythbu schrieb:
> rechnet etwas und legt die darzustellenden Daten im SRAM ab.

Gegenvorschlag:

Schieb die darzustellenden Daten über eine serielle Schnittstelle 'raus.
Das kann auch --sofern vorhanden-- DMA-Hardware in Deinem µC übernehmen, 
sofern die Rechenzeit wirklich komplett knapp wird.

Die Daten können dann von einem Terminal angezeigt werden.

Das Terminal ist entweder aus dem Museumskeller geklautes DEC VT100, ein 
Programm auf einem PC (Teraterm oder das "beliebte" Hyperterminal), oder 
eben ein µC, der die VGA-Ansteuerung übernimmt, und dabei das RAM 
komplett selbst verwaltet.

Hier gibt es so etwas als Bastelprojekt:

http://geoffg.net/terminal.html

Der Vorzug eines Terminals ist der, daß mit den entsprechenden 
Steuersequenzen auch Cursorpositionierung, Selektives Löschen von 
Bildschirminhalten und Ändern von Textattributen (Farbe etc.) möglich 
ist.

(Und spätestens da wird klar, warum "Bray" oder "hterm" keine 
Terminalprogramme sind, die können so etwas nämlich gerade nicht)

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und spätestens da wird klar, warum "Bray" oder "hterm"
> keine Terminalprogramme sind

Es gab auch mal Text-Terminals, die nicht mehr konnten als 
Typenrad-Drucker. Ich musste man mit so einem Ding arbeiten, war echt 
ätzend.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Es gab auch mal Text-Terminals, die nicht mehr konnten als
> Typenrad-Drucker.

Die gute alte Teletype (auch "Fernschreiber" genannt). Ja, lang ist's 
her.
Im Unix-Devicenamen für serielle Schnittstellen /dev/tty lebt sie fort.

Und der sogenannte Texteditor "vi" kann im Grunde immer noch damit 
arbeiten.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:

> Also ist es die einzige Lösung aus meiner
> Sicht, wenn man einen zweiten µC einbaut, der auch mit dem SRAM
> verbunden ist und sich nur um die VGA-Ausgabe kümmert. Allerdings ist
> mir nicht klar, wie das mit der Abfrage des "Bildspeichers"
> funktionieren soll:

Am einfachsten, indem man beide Controller einfach immer abwechselnd auf 
den Displaybuffer zugreifen läßt.

Der Aufwand für die nötige Logik hält sich stark in Grenzen, das kann 
man durchaus noch mit Standardlogikbausteinen abfackeln.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch RAM Bausteine mit zwei Schnittstellen, die sind für genau 
solche Anwendungsfälle erfunden worden. 
https://de.wikipedia.org/wiki/Dual-Port-RAM

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:

> Meine Frage ist nun an Euch, wie man solch ein Problem lösen kann.
> Eigentlich ist das ja ein typisches Problem eines Heimcomputers aus den
> 80ern. Da war's dann so gelöst, dass der Systemtakt eben auf PAL/NTSC
> abgestimmt war und alles um die Grafikausgabe "drumherumgebaut" wurde.

Du kannst einfach einen uC mit eingebautem LCD-Controller verwenden.
zB: http://www.microchip.com/wwwproducts/en/PIC24FJ256DA210
Da sind schon 96k RAM eingebaut. Hinter die Datenleitungen dann DACs, in 
die HSYNC und VSYNC Leitungen 74HCT-Gatter für 5V-Pegel, und das wars.

Alternativ zB:
http://www.nxp.com/products/microcontrollers-and-p...

Oder ein externer LCD-Controller, zB:
http://vdc.epson.com/index.php?option=com_docman&t...

Oder Du verwendest NICHT VGA, sondern ein LCD zB mit ILI9341 Controller.

fchk

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Der Vorzug eines Terminals ist der, daß mit den entsprechenden
> Steuersequenzen auch Cursorpositionierung, Selektives Löschen von
> Bildschirminhalten und Ändern von Textattributen (Farbe etc.) möglich
> ist.

Ein Terminal ist erst einmal ein Ein-/Ausgabegerät. Welche 
Steuersequenzen verarbeitet werden ist gerätespezifisch.

> (Und spätestens da wird klar, warum "Bray" oder "hterm" keine
> Terminalprogramme sind, die können so etwas nämlich gerade nicht)

Es sind Terminalprogramme, die den ASCII-Zeichsatz beherrschen sowie die 
Steuersequenzen Wagenrücklauf und Zeilenvorschub.
Das reicht für ein einfaches Terminal.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann mach mal mit "bray" oder "hterm" eine TTY-Konsole auf ein 
unix/linux-System auf und versuch' damit zu arbeiten.

Wenn man eine Definition auf den allerkleinsten Nenner herunterbricht, 
wird sie sinnlos. Deine "Terminal"-Definition ist sehr hart an der 
Sinnlosigkeit.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde an Deinen uC eni Raspberry oder BeagleBone anhängen, welches 
dann die Visualierung macht. Das ist einerseits kostengünstig und Du 
kannst dann ganz normale Bildschirme anhängen, direkt über HDMI / DVI 
oder auch mittels Adapter VGA (Deine Anforderung).
Datenaustausch zwischen Deinem uC und dem Embedded Computer z.B. per 
UART.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Dann mach mal mit "bray" oder "hterm" eine TTY-Konsole auf ein
> unix/linux-System auf und versuch' damit zu arbeiten.

Warum sollte ich das tun? Ich brauche weder Linux noch Unix.

> Deine "Terminal"-Definition ist sehr hart an der
> Sinnlosigkeit.

Ein Terminal mit kleinem Funktionsumfang ist bestens geeignet, um zum 
Beispiel in einem Mikrocontrollersystem Parameter einzustellen und Daten 
abzufragen/auszugeben. Wenn Du das sinnlos findest - bitteschön.

Autor: Johnny B. (johnnyb)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Ein Terminal mit kleinem Funktionsumfang ist bestens geeignet, um zum
> Beispiel in einem Mikrocontrollersystem Parameter einzustellen und Daten
> abzufragen/auszugeben. Wenn Du das sinnlos findest - bitteschön.

Dieser Meinung bin ich ebenfalls.
Zwar nicht unbedingt Massentauglich (Sekretärin mit hellem Haar ;-) ), 
aber für Entwickler finde ich ein gutes Terminal super zum arbeiten.

Autor: mythbu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und WOW ... sind das viele Antworten.

Etwas möchte ich klarstellen: Ich arbeite mit dem ATMega1284p @ 20 MHz. 
Der hat 128 KB Flash und 16 KB RAM und ich würde auch gerne in diesem 
Bereich bleiben (der STM32F4xx hat eine ganz andere Architektur ...). 
Ich will jetzt nicht alles lang und breit erklären, aber der Rechen-µC 
ist wirklich "zu" und hat kaum mehr Zeit. Darauf läuft nämlich eine 
harte Echtzeitanwendung.

Das mit dem Dual-Port-RAM hört sich aber eigentlich nach der Lösung an, 
die ich gesucht habe. Dazu folgende Fragen:

1.) Wie kann ich als "normaler Mensch" so ein RAM erstehen? Und wo 
überhaupt?
2.) Man kann das doch sicher mit einem FPGA auch nachbauen. Habt Ihr 
eine Seite auf Lager, wo es mehr Informationen dazu gibt?
3.) Das Ziel ist ein fertiges Projekt mit eigener Platine. Ich kenne nur 
FPGAs auf Development Boards. Das ist auch der Grund, warum ich mich 
noch nicht damit beschäftigt habe. Könnt Ihr mir ein FPGA-Modell nennen, 
dass es auch in irgendeiner SMD-Variante gibt, die man noch händisch 
löten kann?

Viele Grüße!

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Dieser Meinung bin ich ebenfalls.
> Zwar nicht unbedingt Massentauglich

Ähm, das ist was anderes.

Putty ist ein richtiges Terminalprogramm -- nicht zu vergleichen mit 
"Bray" oder "hterm".

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 1.) Wie kann ich als "normaler Mensch" so ein RAM erstehen? Und wo
> überhaupt?

Ich wuerde es mal bei Digikey probieren. Vielleicht auch auf dem 
Flohmarkt. Ich hab den Eindruck als wenn diese Rams in den letzten 
10Jahren etwas ausser Mode gekommen sind.

> 2.) Man kann das doch sicher mit einem FPGA auch nachbauen. Habt Ihr
> eine Seite auf Lager, wo es mehr Informationen dazu gibt?

Wieso? Wenn du halbwegs Ahnung von FPGAs haettest dann wuerde du das 
einfach so runterschreiben. Wenn nicht dann ist das erlernen der 
Umgebung um ein Einzelstueck fuer eine Bastelsache zu machen ziemlich 
dumm im Vergleich zum kauf eines Dualportrams.
Ausserdem setzt das natuerlich vorraus das dein Atmel mit 3.3V oder 
weniger laeuft.

Mir fällt da noch was anders ein. Gab es nicht mal DRAMs die 
unterschiedliche Anschluesse fuer DataIn und Out hatten? Vielleicht 
laesst sich damit ja was zaubern.

Olaf

Autor: anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das Projekt anscheinend noch im Planungsstadium ist und da es auch 
zunehmend schwieriger wird, (funktionsfähige) Monitore mit VGA 
aufzutreiben sowie dein µC anscheinend schon am Limit ist ein 
alternativer Vorschlag:

Raspberry Pi Zero (3,3V kompatibel, HDMI Ausgang serienmäßig, dazu USB, 
Betriebssystem, jeder Menge Rechenleistung im Vergleich zum ATMega) um 5 
EUR oder so.

Autor: Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arcade-Platinen und manche Homecomputer (z.B. Apple 2) haben einen Teil 
des RAMs als Videospeicher genutzt, ohne dedizierte Dual-Port-RAMs zu 
verwenden.

Der Systemaufbau war einfach Hardwaremäßig so gestaltet, dass nur zu 
bestimmten Zeiten in das Video-RAM geschrieben wurde.

Die Arcade-Video-Textlayerausgabe funktioniert in der Austastlücke des 
Videosignals: hier werden die Textbytes in ein 6116 SRAM geschrieben. 
Jedes Byte repräsentiert ein Zeichen an einer bestimmten Stelle des 
Bildschirms. Beim Auslesen des Bytes wird das Zeichenbyte zum Adressbyte 
eines Zeichengenerator-EPROMs, die niederwertigen 3 Bits werden von 
einem Zähler raufgezählt, bei jeder Bildzeile die nächste Adresse... Die 
Ausgabebytes des Character-EPROMs wiederum werden in ein Schieberegister 
geladen und mit 8 Pixel-Clocks in das Videosignal geschoben (bei 
normalem Video-Signal 15kHz ist der Pixel-Clock ca. 6 MHz)

Die Steuerung der Zeilen-/Spalten und sonstigen Zähler benötigt aber 
eine große Menge an TTL-ICs... Dafür hängt ein ganz normales RAM am 
Prozessordatenbus.

Das ganze lässt sich übrigens prima in einem einfachen FPGA nachbilden!

Autor: waflija (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vor allem werden die in euren Artikeln genannten Auflösungen / 
Wiederholraten mit heutigen Monitoren schlicht nicht funktionieren. 
Minimum bei den meisten TFT ist 800x600 @ 50hz. Was mindestens 29Mhz auf 
ja RGB entspricht. Das schaft der µC einfach nicht. Mit dem RAM könnte 
das gehen, der Aufwand ist aber enorm und die Schaltung aufgrund der 
Frequenzen nicht mehr wirklich per Hand zu löten.

-> Warum nicht ein kleines TFT direkt mit 5V und SPI, USB oder UART 
Eingang? Gibts aber wenigen Euro bei 480x320+ Auflösung.

Autor: waflija (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
z.B. Ebay-Artikel Nr. 252431865727 - hat sogar touch schon 
mit drin.

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sollte einen Echtzeit Rechner nicht mit Visualisierungs Zeug 
belasten. Denn allenfalls moecht man die visualisierung auch debuggen, 
und dabei kann man den Echtzeitprozees nicht stoppen.

Ein Echtzeitprozess muss mit hoher Zuverlaessigkeit laufen, eine 
Visualisierung nicht.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:
> Das mit dem Dual-Port-RAM hört sich aber eigentlich nach der Lösung an,
> die ich gesucht habe.

Glaub mir, das willst Du garnicht haben.
Dein ATmega müßte > 20 Adress- und Datenleitungen zur freien Verfügung 
haben, um es überhaupt anzusteuern. Auf der anderen Seite des RAMs 
herrscht dann aber immer noch gähnende Leere.

Was genau willst Du denn anzeigen? Muß es VGA sein; muß es in Farbe 
sein?
Oder reicht tatsächlich ein 320x240 TFT (15 Zeilen mit 40 Zeichen, gut 
abzulesen), welches serielle Daten empfängt und anzeigt?

Autor: S.B.Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst folgendes tun:

- Bau Deine Anwendung so, dass sie mit Terminalsteuersequenzen
  die Daten ausgibt. Aber Achtung, Terminals sind nicht
  beliebig schnell. Mindestens die serielle Anbindung ist
  das erste Nadeloehr.

- Schreib Dir eine Hintergrundroutine, die die Visualisierungs-
  daten periodisch auf das Display schreibt.
  Nur diese Hintergrundroutine muss die Terminalsteuersequenzen
  senden. Der Rest kann so weitermachen wie bisher.

- Haeng ein TFT mit eigenem Bildwiederholspeicher dran.

- Dual-Port-RAM duerfte bei einem AVR wohl ziemlich sein.
  Oder kann Deiner externen RAM adressieren?
  Habe ich vor 30 Jahren als Kaefergrab (215x170) fuer
  eine Z80 Farbgrafik realisiert. Die hat echte Arbitrierung
  gemacht, funktionierte also auch mit asynchronen Zugriffen.

Viel Erfolg

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
waflija schrieb:

> Vor allem werden die in euren Artikeln genannten Auflösungen /
> Wiederholraten mit heutigen Monitoren schlicht nicht funktionieren.
> Minimum bei den meisten TFT ist 800x600 @ 50hz.

Unsinn, die beherrschen nach wie vor alle Standard-VGA-Modi. Sonst 
könntest du nämlich z.B. kein BIOS-Setup bedienen...

> Was mindestens 29Mhz auf
> ja RGB entspricht.

Nö, das gilt natürlich nur, wenn man die volle Auflösung ausnutzen will. 
Wenn man die Ansprüche an die Auflösung verringert, genügt auch ein 
entsprechend geringerer Pixelclock. Genau das ist ja der Vorteil bei der 
Verwendung der analogen VGA-Schnittstelle, man ist nicht an einen 
vorgegebenen Pixeltakt gebunden, es gibt nur eine Obergrenze.

Nur die Syncs müssen halt einem VGA-Standardmodus entsprechen. Das ist 
mit einem Mega1284P@20MHz leicht zu realisieren, für die Syncs muss ja 
nichtmal die MCU aktiv werden, die kann man allein mit den Timern 
abfackeln.

Und was dann die erzielbare Auflösung angeht, liegt die theoretische 
Grenze bei 10MHz (schnellstmögliche Ausgabe bei 20MHz Systemtakt) durch 
31kHz (H-Sync), was unter Abzug des H-Blank so ungefähr 320 Pixeln 
horizontal entspricht. Damit lassen sich natürlich sinnvoll keine 80 
Zeichen pro Zeile darstellen, aber 40..60 gut lesbare Zeichen pro Zeile 
sind machbar, das hängt dann allein vom Geschick des Font-Designers ab. 
Mit einem Mega1284P könnte man die Zeichen sogar in vier Farben 
darstellen (dank der zwei verfügbaren SPI-fähigen UARTs).

Na klar, im Verhältnis zu richtigen Displaycontrollern ist das alles 
garnix. Aber es geht immerhin. Genau das hast du aber abgestritten.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> liegt die theoretische Grenze bei ... so ungefähr 320 Pixeln

> Unsinn, die beherrschen nach wie vor alle Standard-VGA-Modi.
> Sonst könntest du nämlich z.B. kein BIOS-Setup bedienen...

Welches Bios läuft auf 320x200 Punkten?

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keines, aber VGA gibt 320x200 mit exakt demselben Timing aus wie 
640x400; jede Pixelzeile wird doppelt ausgegeben.

VGA kennt nur eine Zeilenfrequenz (ca. 31.5 kHz), und zwei 
Bildwechselfrequenzen, 60 und 70 Hz.

Der Textmodus arbeitet wie Dein niedrigstauflösender Graphikmodus mit 70 
Hz (und 400 sichtbaren Pixelzeilen). Bei 480 sichtbaren Pixelzeilen 
reduziert sich die Bildwechselfrequenz auf 60 Hz.

Und das waren auch schon die Timingunterschiede.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es was aus diesem Forum sein darf...
Beitrag "VT100-Terminal (VGA+PS2)"

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
>> liegt die theoretische Grenze bei ... so ungefähr 320 Pixeln
>
>> Unsinn, die beherrschen nach wie vor alle Standard-VGA-Modi.
>> Sonst könntest du nämlich z.B. kein BIOS-Setup bedienen...
>
> Welches Bios läuft auf 320x200 Punkten?

Keins. Die laufen üblicherweise in einem VGA-Textmodus. Es gibt aber 
auch welche, die im klassischen VGA-Grafikmodus 640x480 laufen. Das sind 
vor allem welche, die für notorische Klickibuntis selbst im BIOS-Setup 
schon Mausunterstützung bieten wollen...

Das alles spielt aber eigentlich keine Rolle. Fakt ist, das jeder 
aktuell erhältliche Monitor noch die Timings aller klassischen VGA-Modi 
darstellen kann, jedenfalls so lange er über die klassische 
VGA-Schnittstelle verfügt.

Das liegt einfach daran, dass er sie sonst nicht als VGA-Schnittstelle 
bezeichnen dürfte. Capisce?

Und wenn du das Prinzip, einen VGA-Modus mit verringerter Auflösung zu 
benutzen nicht kennst, wirst du schon im VGA-Standard selber fündig. 
(Wenn du in der Lage wärest, diesen zu lesen und zu verstehen.) Noch 
sehr viel deutlicher und vielleicht sogar für dich ansatzweise 
verständlich wird das Prinzip bei SVGA, nämlich bei dem lange Zeit für 
DOS-Spiele überaus beliebten Modus 320x200 (in dann 256 Farben). Das 
Timing dieses Modus entspricht nämlich exakt dem des klassischen 640x480 
(der nur 16 Farben darstellen kann). Logischerweise arbeitet also der 
SVGA-Modus mit den 256 Farben dem halben Pixeltakt. Capisce?

Und genau nach dem gleichen Schema kann man im Prinzip jedem VGA-Modus 
eine beliebige andere Auflösung überhelfen. Die spielt nämlich 
eigentlich überhaupt keine Rolle für den Monitor. Wichtig ist für den 
nur, dass die Syncs passend sind. Für den eigentlichen Bildinhalt 
interessiert er sich eher weniger. Den schmeißt er einfach nur so auf 
seinen Schirm, wie er reinkommt. Wenn sich der Bildinhalt nicht bei 
jedem "erwarteten" Pixel ändert, ist ihm das scheißegal. Schließlich 
stellt man auch dann, wenn man den Modus tatsächlich mit voller 
Auflösung benutzt, nicht nur Schachbrettmuster dar. Capisce?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:

> Etwas möchte ich klarstellen: Ich arbeite mit dem ATMega1284p @ 20 MHz.
> Der hat 128 KB Flash und 16 KB RAM und ich würde auch gerne in diesem
> Bereich bleiben (der STM32F4xx hat eine ganz andere Architektur ...).

Herzlichen Glückwunsch. Wäre die Sackgasse noch nicht erfunden worden, 
der Preis wäre an Dich gegangen. Ja, ich weiß, dass Du aus Deiner 
kuschligen Ecke nicht weg willst.

> 1.) Wie kann ich als "normaler Mensch" so ein RAM erstehen? Und wo
> überhaupt?

Digi-Key und Mouser haben so viele, die müssen sie verkaufen. Aber dafür 
solltest Du einen externen Memory Bus haben. Dein 1284 hat den nicht. 
Ein 1281 hat den, läuft aber nur mit 16 MHz. Dumm gelaufen.

> 2.) Man kann das doch sicher mit einem FPGA auch nachbauen. Habt Ihr
> eine Seite auf Lager, wo es mehr Informationen dazu gibt?

Ja, kann man. Du könntest Dir zB einen Spartan 3e nehmen 
(Xc3s200e-4tq144c) und ein VHDL-Buch Deiner Wahl.

Muss man aber nicht. Ein fertiger LCD-Controller wie Epson S1D13781 oder 
SSD1963 ist einfacher. Aber auch dafür solltest Du einen externen Memory 
Bus haben. Besser ist das. Stichwort Sackgasse.

> 3.) Das Ziel ist ein fertiges Projekt mit eigener Platine. Ich kenne nur
> FPGAs auf Development Boards. Das ist auch der Grund, warum ich mich
> noch nicht damit beschäftigt habe. Könnt Ihr mir ein FPGA-Modell nennen,
> dass es auch in irgendeiner SMD-Variante gibt, die man noch händisch
> löten kann?

siehe oben. 144 Pins im 0.5mm Raster.

fchk

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Logischerweise arbeitet also der SVGA-Modus mit den 256 Farben dem
> halben Pixeltakt.

Nö. Da bringst Du was durcheinander. SVGA ist was anderes als der 
niedrigauflösende 256-Farb-Modus.

Deine "capisce" kannst Du Dir übrigens auch sparen; es mag Dich 
überraschen, aber man darf auch Umgangsformen entwickeln.

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:
> 2.) Man kann das doch sicher mit einem FPGA auch nachbauen. Habt Ihr
> eine Seite auf Lager, wo es mehr Informationen dazu gibt?

Klar, am besten packst du deinen AVR auch noch mit in den FPGA.
http://opencores.org/project,avr_core

> 3.) Das Ziel ist ein fertiges Projekt mit eigener Platine. Ich kenne nur
> FPGAs auf Development Boards. Das ist auch der Grund, warum ich mich
> noch nicht damit beschäftigt habe. Könnt Ihr mir ein FPGA-Modell nennen,
> dass es auch in irgendeiner SMD-Variante gibt, die man noch händisch
> löten kann?

Z.B. Spartan-3E und 6 LX gibts in 144 TQFP. Gut, Pin Abstand 0,5 mm. 
Kann man aber noch gut von Hand löten. Flussmittel drauf, Lötzinnkugel 
drüber ziehen und ggfs. Lötbrücken mit Entlötlitze entfernen, fertig. 
Geht schneller als einen DIP-40 zu löten.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:

> Nö. Da bringst Du was durcheinander. SVGA ist was anderes als der
> niedrigauflösende 256-Farb-Modus.

Stimmt. Den gab's schon bei VGA selber. Da habe ich tatsächlich etwas 
durcheinander gebracht. Naja, zu meiner Entschuldigung: ist echt lange 
her...

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Möglichkeit wäre auch ein PSoC5. Gut, ist auch ein ARM M3, aber mit 
einem kleinen FPGA dabei. Dazu ist das Starterkit mit um die 10 € 
relativ preiswert.

http://www.eevblog.com/forum/projects/no-bitbangin...

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da VGA eine hohe Speicherbandbreite braucht und viel RAM für den 
Bildspeicher ist die effektivste Umsetzung mit einem Display Controller 
wie z.B. SSD1963, der VGA Timings kann. Gibt's viel Beispielcode um es 
an den eigenen uC anzuflanschen. Wenn dir fertig kaufen zu lame/teuer 
ist, halt selber machen.
http://www.versamodule.com/vm8.html

Gruß,

dasrotemopped.

Autor: Göran (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mythbu schrieb:
> ich plane gerade ein Elektronikprojekt, wo ich eine VGA-Ausgabe einbauen
> möchte.
Wie wäre es denn mit sowas:
http://www.watterott.com/de/Micro-VGA-Mikrocontrol...

Die Fragen sind doch auch:

1. Wie schnell muss das gehen?

2. Wieviel darf es kosten?

3. Welche Kenntnisse und Fähigkeiten hast Du bzw. willst Du evtl. 
erlernen?

Grüße,
Göran

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Die Fragen sind doch auch:
1. Wie schnell muss das gehen?
2. Wieviel darf es kosten?
3. Welche Kenntnisse und Fähigkeiten hast Du bzw. willst Du evtl.
erlernen?

Naja, das Uebliche : sofort, nichts, keine, keine , dh ein 4-Nuller

Allenfalls ist auch ein PIC Mediakit mit einem TFT drauf als 
Visualisierer geeignet. Per serieller Anbindung oder so.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Görna, lies doch erst mal den Thread, bevor Du bereits gesagtes und 
empfohlenes wiederholst.

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man nicht ein wenig Tricksen mit zB.

MAX7456-EUI monochrome on-screen display

Hab ich selbst keine Erfahrung, war nur so eine Idee.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hier hat es einer mit nem 8051 und ohne externes SRAM gemacht:
>http://community.silabs.com/t5/8-bit-MCU/Random-La...

SRAM? Ach was, völlig übertrieben:
http://hackaday.com/2011/08/31/vga-video-output-wi...

;-)

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> MAX7456-EUI monochrome on-screen display

Das Ding ist für PAL/NTSC-Timing, kann also nur mit Fernsehern verwendet 
werden. Will man das noch?

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
> da VGA eine hohe Speicherbandbreite braucht und viel RAM für den
> Bildspeicher ist die effektivste Umsetzung mit einem Display Controller
> wie z.B. SSD1963, der VGA Timings kann.

hast du den Thread gelesen?

Beitrag "Re: VGA-Ausgabe in Elektronikprojekt einbauen"
scheint mir am einfachsten, nicht "hohe Speicherbandbreite und viel RAM"

Ein simpler AVR der in VGA Timing Text ausgibt.

Autor: dasrotemopped (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>hast du den Thread gelesen?
>Beitrag "Re: VGA-Ausgabe in Elektronikprojekt einbauen"
Ja, geht immer mit dem Kompromiss einher, die Auflösung zu reduzieren,
die Farbtiefe zu reduzieren, exakte Timings einzuhalten, ein bisschen 
übertakten, usw ... technisch interessante Kniffe.

Die Idee vom TO, einen CPLD und einen Atmega zur Erzeugung von
einem VGA Signal zu benutzen hatte ich auch schon, hat geklappt.
http://www.dasrotemopped.de/index.php?var=projekte&nr=9

Es hat sich aber schnell herausgestellt, das die Kompromisse, die die 
minimalistischen Lösungen erfordern, die Benutzbarkeit einschränken.
Darum habe ich eine technisch potentere Lösung bevorzugt, die aber auch 
nicht teuer sein muss:
Youtube-Video "STM32F429 LTDC VGA 800x480 adapter"
Da das Disco Board 8MB RAM hat steht der vollen Grafikpracht nichts im 
Weg, ein Terminal wie der TO benötigt ist da auch drin.

Wer es noch schlanker will, dann reicht auch ein Nucleo Board mit einem 
ili9341, das man ohne Probleme als Terminal mit 20x20 Zeichen nutzen 
kann.
Kein sperriger Monitor, per UART ansteuerbar, klein und kompakt.

Im Gegensatz zu einer zusammengegoogleten Linksammlung habe ich diese 
Lösungen selbst umgesetzt. Kann sich jeder seine Meinung zu bilden.

Gruß,

dasrotemopped.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wer es noch schlanker will, dann reicht auch ein Nucleo Board mit einem
>ili9341, das man ohne Probleme als Terminal mit 20x20 Zeichen nutzen
>kann.

Ich bin auch ganz begeistert von dem ILI9341 Display:
Beitrag "Re: 2.2'TFT ILI9340 und Arduino"

Es scheint mir aber so, dass man fast nur noch die "Touch"-Version zu 
kaufen findet.

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.