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#M46046 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.
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.
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
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-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m3/lpc1700-cortex-m3/scalable-mainstream-32-bit-microcontroller-mcu-based-on-arm-cortex-m3-core:LPC1788FET208 Oder ein externer LCD-Controller, zB: http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=11&Itemid= Oder Du verwendest NICHT VGA, sondern ein LCD zB mit ILI9341 Controller. fchk
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.
Angehängte Dateien:
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.
2ter Atmel der seriell annnimmt und VGA ausgibt http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm Beitrag "AVR VGA Terminal" http://tinyvga.com/ https://www.uni-koblenz.de/~physik/informatik/ECC/vga.pdf https://www.google.de/search?q=vga+text+atmel&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=P2DtV93QCcOv8wfmh5bYCw sind doppelte Beiträge bei, aber genug zum lesen
:
Bearbeitet durch User
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...
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-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/
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.
:
Bearbeitet durch User
Görna, lies doch erst mal den Thread, bevor Du bereits gesagtes und empfohlenes wiederholst.
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.
>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-with-an-attiny/ ;-)
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.
Angehängte Dateien:
-
Nucleo_ili9341.jpg
180 KB
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.