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!
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?
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.
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-Latency-with-Laser-Bee-Branch-Instructions/m-p/178156#M46046mythbu 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.
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-Mikrocontroller-VGA-Grafikkarte
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.
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)
> 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.
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.
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.
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.
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.
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.
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.
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.
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!
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".
> 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
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.
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!
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.
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.
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?
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
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.
> 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?
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.
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?
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
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.
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.
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...
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.
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-Mikrocontroller-VGA-Grafikkarte
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
> 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.
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?
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.
>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:
https://youtu.be/seekcKivPwA
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.
>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.
