Ein kleiner Testbildgenerator für einen ATmega8, der ein 128x124 x16Farben Bild mit der Standard VGA Auflösung 640x480 @60Hz auf einem Monitor anzeigt.
Angehängte Dateien:
-
VGA_AVR.jpg
30 KB
Und hier noch ein Beispielfoto, wie das ganze dann aussehen kann.
Das wäre doch auch für einen normalen Fernseher oder LCD-Schirm (Videosignal Tv-Norm) eine gute Daten- b.z.w. Textausgabe. Wäre das möglich? b.z.w was muss anders gemacht werden? horizontal-Frequenz ist bei Tv glaube ich 16525 Hz vertikal-Frequenz ist 50 Hz Farbe bestimmt schwierig (PAL, Burst-erzeugung) aber auch SW wäre gut.
http://www.atmel.com/journal/Archive.asp unter "AVR Video Generator with an AVR Mega163". oder auch: http://www.roboternetz.de/phpBB2/viewtopic.php?t=5880
Hallo, An sowas bin ich zur Zeit dran, eine Grafikkarte für einen Atmel allerdings erzeugt das RGB Signal nicht der Atmel sondern ein Xilinx. Einen kleinen VGA Tester gibt es schon auf meiner HP. Der Vorteil den ich mir davon verspreche eine höhere Auflösung. Mfg Ulrich
@Uli Was kann die Grafikkarte (Auflösung, Farben usw.) ? Wie hast du das Timing des Videospeichers gelöst, so dass (mehr oder weniger) geleichzeitig der Speicher Werdte an den DAC liefern kann, aber man auch neue Werte in den Speicher laden kann ?
Hallo @benedikt; Als Speicher nehme ich SRAM aus einen 486Board der damals als Cache diente (UM61256K-15). Dieser ist recht schnell 15ns. Als CPLD benutze ich einen XC9572 im PLCC84 Gehäuse. DAC gibt es nicht, wird über Wderstände erledigt 6Stück 6Bit(2Bit pro Farbe) insgesamt 64Farben das sollte ausreichen. Also meine Grafikkarte hat 2Aktive Bauteile CPLD und Speicher ;-) Zur zeit macht diese eine Auflösung von 240x240Pixel auch 512x512 wurden von mir schon getestet. Mfg Ulrich
2 Speicher ? Werden beide gleichzeitig, oder abwechselnd (einer zum schreiben, der andere zum lesen) verwendet ? Vielleicht ist das hier nützlich: http://elm-chan.org/works/crtc/report.html
@Uli Ich habe gerade mal deinen VGA Tester nachgebaut und u.a. noch eine Graustufentreppe integriert. Prellt dein Taster auch so stark wie meiner ? Teilweise überspringe ich bis zu 10 Schritte. Ein Kondensator parallel zum Taster bringt auch keine Verbesserung.
Hallo @Benedikt, Zum Taster ja meiner prellt auch etwas aber mit 1µF Kondensator klappt es recht gut. Das Projekt dient mir nur als Vorstufe zur Grafikkarte. Man kann ja ohne Probleme die Logik etwas ändern. Das projekt unter http://elm-chan.org/works/crtc/report.html ist in etwa was ich auch baue, halt nur mit einen XC9572 also eine Nummer kleiner aber mit den gleichen Funktionen, und halt mit Eagle Layout, und nicht mit ABLE sondern mit einer Schematic des CPLDs. Mfg Ulrich
@Ulrich, dein CPLD/VHDL interessiert mich auch, allerdings aus Sicht eines anderen Projektes. Wie synchronisierst du die gemeinsammen Zugriffe auf deinen 15ns SRAM ? Willst du auch wie elm chang mit einem externen #WAIT Signal arbeiten um die Zugriffe des AVR's künstlich zu verlängern ? Wenn ja wäre die eher uninteressant für mich, denn ich suche eine Lösung die sozusagen aus dem SRAM+ CPLD ein Dual-Port-SRAM macht ohne den AVR auszubremsen. Gruß Hagen
Hallo @Hagen, Ich realisiere ein wechselnden zugriff auf den Speicher mit 32Mhz, 16Mhz für die GraKa und 16Mhz AVR, der Prozessor(AVR) wird Syncron mit 32/2 betrieben (also 16MHz). Bei einen Speicher mit einer Zugriffszeit von 15ns könnte man diesen mit etwa 66MHz betreiben also ein Dualportram mit 33Mhz ist doch schon ordentlich. Bin aber noch im Versuchsstadium. Mfg Ulrich
Ok, du gehst den gleichen Weg wie ich, interessant. Auch ich will den AVR durch den CPLD takten, aber nicht um synchron zu sein da laut Datenblätter von Atmel das XMEM Interface ein asynchrones ist. Das heist im Klartext: es gibt keinen festen zeitlichen Zusammenhang zwichen AVR Clock und XMEM Timing. Laut Atmel kann man das XMEM also nicht duch einen gemeinsammen Clock synchronisieren. Auch ich benutze pro Pixel 8Bit und nur 6Bits davon enthalten RGB. Die restlichen 2Bits sind denoch wichtig für zusätzliche Softwarefeatures wie Sprites usw. In diesen 2 Bits wird die Bildebene definiert, zb. für Kollisionen, Hintergünde und Palettenmanipulationen. Man kann also über diese 2 Bits eine Bildebene definieren die nur Fonts enthalten. Eine andere Ebene ist der Hintergrund. Nun ist es ein einfaches sehr effizient den über den Hintergrund gezeichneten Font wieder sauber zu löschen. Das Gesamttiming läuft darauf hinaus das in 62ns Zugriffszeit des AVR's der CPLD insgesamt zwei Zugriffe auf den SRAM durchführen kann. Zusätzlich ist es ja noch so das der AVR insgesamt 3 Takte a 62ns benötigt von denen aber real nur 1 Takt tatsächlich ein SRAM Zugriff stattfindet. In einem Speicherzugriff des AVR's, also in 3*62ns kann der CPLD rein theoretisch 1 Zugriff für den AVR und 5 Zugriffe für sich selber durchführen. Denoch kann es zu einem Versatz/Delay kommen und der CPLD muss 30ns warten. Deswegen beschränke ich mich auf ein rein sequentiell wechselnden Zugriff auf den SRAM. 30ns für AVR, 30ns für CPLD, usw. usw. Mein derzeitiges Problem ist die Addressaufbereitung und Dekodierung der Pixeldaten. Im Gegensatz zu dir ist bei mir aber eine Pixelumkodierung nötig. Du musst ja nur sequentiell zeilenweise 8 Bits pro Pixel laden und die untersten 6 Bits direkt am RGB Port ausgeben. Dafür reicht ja ein 12 Bit Caching bei dir aus. Ich benötige aber von einer 64 Pixel-Spalte (senkrecht) zu einem Zeitpunkt immer nur die Rot, Grün oder Blau Anteile und das mehrmals sehr schnell hintereinander. Naja, meine bisherigen Tests gehen dann in Größenordnungen für die es keine CPLD's mehr gibt. Mir gehen die Makrozellen zu schnell aus da ich viele Counter benötige. Gruß Hagen
Hallo @Hagen, Mein Ziel ist es erstmal eine einfache Graka für 8Bit µC also nichts besonderes(Pixel setzen und löschen ohne Sprites und Schnickschnack). Bis dahin läuft auch alles recht gut. Bei größeren Sachen würde ich einen XCS05 benutzen also schon einen FPGA. Diesen gibt es sogar noch in einem PLC84 Gehäuse. Bis dahin brauche ich aber noch etwas Zeit :-) Mfg Ulrich
Ist das ein Joke oder meinst du die Frage ernst. SVGA -> Super VGA, das bedeutet mindestens 256 Farben, ergo 1 Byte pro Pixel, 1024*768*1 = 768 Kb an Bildspeicher. Na denn mal los ! Die 512x512 Auflösung die Ulrich hinbekommen will ist schon enorm viel. Nicht so sehr für den CPLD, da dieser einfach sequetiell die Siagnale erzeugen kann, aber der AVR wird es schon schwerer haben 256Kb an Speicher zu beackern. Es sei denn man baut den CPLD als Textbasierten Grafikkontroller auf. Bei einem Font von 8x16 Pixel benötigt man einen Displayspeicher für die Texte von 6Kb Größe + den Fontspeicher mit 4Kb. Statt CPLD wird das dann aber eher eine Aufgabe für einen FPGA. Gruß Hagen
hallo, im forum "avr-risc" und im "bascom-forum" bei roboternetz.de gibt es ein asm-programm von jan baare auf dem avr8-8 und avr8-16 mit 28 buchstaben und 24 zeilen. über ein terminalprogramm kann man diese oberfläche bedienen. erste sahne ist das. es läuft mit dem fbas-signal. es ist ein sehr intressantes projekt. ich kann jetzt meine daten vom robby mit dem videosender auf meinen pc anzeigen mit win-tv. mfg pebisoft
der asm-source-code für den avr8-8 liegt auch mit dabei, kann mit avr-studio umgesetzt werden und bearbeitet werden, wenn man z.b. andere sonderzeichen haben möchte. mfg pebisoft
hallo, hier die beiden progamme. schaut mal ins obengenannte forum rein, ihr werdet staunen, wie weit die video-projekte auf dem avr8 schon sind (ich würde sagen , schon fast abgeschlossen). mfg pebisoft
der Link von Joachim -> http://www.roboternetz.de/phpBB2/viewtopic.php?t=5880 verlinkt exakt auf diesen Code. Durch die Ansteuerung des FBAS gibts nur Schwarz/Weis, ergo MGA und nicht VGA wie hier. "ich kann jetzt meine daten vom robby mit dem videosender auf meinen pc anzeigen mit win-tv", Du sendest per Funk vom Robbi den Bildschirminhalt zum Empfangsteil mit dem Code von Jan im AVR um dort ein FBAS zu erzeugen das am eingeschalteten PC in die WinTV eingespeist wird. Hm, warum nicht gleich im PC eine Software installieren die per Funk-RS232 diese Daten empfängt und dann in einem Terminal ähnlichem Fenster darstellt ? Schätze mal das es um eine Machbarkeits-studie geht :) denn solche Terminal-Programme gibts ja schon als Freeware. Gruß Hagen
halle, es gibt noch kein programm mit 28 buchstaben und 24 zeilen, was durch den avr8 realisiert wird in fbas , und durch ein terminalprogramm gesteuert wird. mfg pebisoft
auf dem robby wird das fbas-signal mit den avr8 erzeugt. dieses bild stellt die daten vom robby optisch dar und der videosender schickt das bild zum pc zur win-tv-karte, damit ich die daten überwachen kann. mfg pebisoft
mit vga wird der ganze bildschirm blockiert. mit der win-tv-karte habe ich nur einen teil des bildschirmes in beschlag um dann mit einem anderen programm zum robby über rs232-funk zu reagieren. mfg pebisoft
achso, du überträgst das FBAS Videosignal per Funk. Ich nahm an das es im Grunde vernünftiger wäre die binären Daten zb. per Funk-RS232, Bluetooth oder WLAN an den Rechner zu senden. Andererseits kosten ja Video-Funk-Systeme mit eigenem Monitor auch nicht die Welt, man käme dann ohne PC aus. Denoch, Joachim hat schon ziemlich am Anfang auf diesen Source verlinkt und hier im Thread geht es primär um ein VGA System, sprich Farbdarstellungen. Dies ist über FBAS nur sehr schwer mit einem AVR alleine zu machen, es sei denn man benutzt zusätzlich einen RGB to Composite Wandlerchip. Der Source von Benedikt erzeugt statt einem Composite Signal ein RGBVH Signal das direkt in den Computermonitor eingespeist werden kann. Gruß Hagen
schlecht ist, das der avr bei euch übertaktet wird. hier sollte man beim avr8-16 bleiben und das projekt verwirklichen. auch wird im tread geschrieben , das man tricksen musste um das zu realisieren. also ein unsauber geschriebener programmcode. versucht es mal auf dem weg, den der chip hergibt. mfg pebisoft
>schlecht ist, das der avr bei euch übertaktet wird. Es geht auch unübertaktet, allerdings erreicht man dann nur etwa 100x124 Pixel Auflösung >auch wird im tread geschrieben , das man tricksen musste um das zu realisieren. Ist immer eine Definitionssache, ob man das als Trick oder als geschickte Programmierung bezeichnet... >also ein unsauber geschriebener programmcode. Das ist jetzt aber eine Beleidigung ! Der Programmcode ist nicht unsauber geschrieben, sondern durchaus durchdacht. Wenn du es allerdings besser kannst, dann kannst du gerne deine Version posten. >versucht es mal auf dem weg, den der chip hergibt Das habe ich, und wie du auf den Bildern siehst, gibt der Chip es her. PS: Wenn man nichtmal weiß was FBAS ist, dann würde ich mal ganz leise sein bei diesem Thema...
Hallo @Benedikt, Ich wollte gerade schon in den Keller gehen und mich aufhängen ;-) Einige kappieren es ja nie. Mfg Ulrich
hallo ulrich nicht in den keller gehen, du musst noch für meine gute pension sorgen die ich jetzt schon bekomme. aber vielleich schafft ihr das programm noch ohne den avr-8 zu überdrehen. mfg pebisoft
Hi PebiSoft, das wird nicht so ohne weiteres funktioneren, eine einfache Rechnung zeigt das. Also Jan hat 28x24 Zeichen, ich nehme mal Zeichen mit 8x8 Pixeln an, macht 224x192=43008 Pixeln. Benedikt hat eine Auflösung von 128x124=15872 Pixeln. Der Unterschied besteht aber darin das bei Monochrome Anziege, wie bei Jan's Code mit seinem FBAS das Signal interlaced codiert wird, also halbiert sich die tatsächliche Auflösung schon mal auf 2*25*224*96=1075200 Pixel pro Sekunde. Bei Benedikt werden in der Sekunde 60*128*124=952320 Pixel benötigt. Man sieht das kommt schon sehr nahe an Jan's Timing heran. Jetzt bleibt aber noch das Problem das das VGA Timing, speziell die Zeilenfrequenz von ca. 31KHz eingehalten werden muß. Ein weiter Unterschied besteht ob man ein Textbasirtes Display oder ein Grafikorientiertes Display programmiert. Bei Jan wird ein Zeichensatz benötigt und 8 Pixel können monochrom in 1 Byte gespeichert werden. Das bedeutet pro Pixelzeile mit 28 zeichen fallen auch nur 28 Speicherzugriff mit jeweils 3 Takten an. Bei Benedikt sieht die Sache komplizierter aus, pro 128 Pixelzeile muß man schon 64 mal a 3 Takte zugreifen. Auf die Gesamtauflösung pro Sekunde also: Jan = 2*25*224/8*96*3 = 403200 Takte für den Speicherzugriff Ben = 60*128*124/2*3 = 1428480 Takte für den Speicherzugriff Damit muß Benedikts MCU Takt mindestens 360% höher sein als bei Jans Aufgabenstellung. Jan taktet mit 8 MHz, 8 MHz * 3.6 = 28.8 Mhz wären mit Jans Programmierkünsten als MCU Takt nötig um das gleiche wie Benedikt zu schaffen. Wie du siehst, das was Benedikt gemacht hat ist ähnlich wenn nicht sogar besser programmiert. Zudem musst du berücksichtigen das es sich um zwei komplett verschiedene Aufgabenstellungen handelt. Jan: Composite FBAS, monochrom, 50 Hz interlaced Halbbilder. textorientiert Ben: RGB-VH, 16 farbig, 60 Hz non-interlaced Vollilder, grafikorientiert Gruß Hagen
Da ein AVR eine 1 MIPS Machine ist, spielt es im Grunde keine Rolle ob man einen ATMega8 oder ATMega128 benutzt, man benötigt immer minimal 25Mhz Pixeltakt für echtes VGA. Exakt aus diesem Grunde will Ulrich einen CPLD/FPGA einsetzen, da es 1.) interessanter ist, 2.) man bis zu 66MHz takten kann, und 3.) den angeschlossenen AVR von einer eigentlich stupiden Arbeit entlastet. Um einen besseren Einblick in die Timings zu erlangen empfehle ich dir http://www.xess.com/appnotes/vga.pdf http://xtiming.sourceforge.net/cgi-bin/xtiming.pl http://www.hut.fi/Misc/Electronics/circuits/vga2tv/#general http://www.hut.fi/Misc/Electronics/faq/vga2rgb/calc.html Gruß Hagen
Hallo, Für alle die es interessiert, das Layout der GraKa zur Zeit beschränkt auf 64K also max. 256x240 Pixel (Farbe). Mehr Speicher ist aber kein Problem. Der Code für den Xilinx kommt in den nächsten Tagen. Es kann der XC9572 oder XC95108 benutzt werden. Als Speicher benutze ich Cache aus einem alten 486er Mainboard. Dieses Board diente mir bisher als Basis. Mfg Ulrich
Hi Ulrich, willst du unbedingt Grafiken ermöglichen ? Angenommen mal ein Textorientiertes System für 640x480x16 wobei man entweder mit 8x8,8x10 oder 8x12 Pixel Zeichensatz arbeitet. Man benötigt also für einen ASCII Zeichensatz mit 256 Zeichen maximal 12*256 = 3072 Bytes. Der Bildschirmbuffer enthält nun jeweils 2 bytes, 1 Byte ASCII und 1 Byte Farben, jeweils 4Bit für Vordergrund und Hintergrund. Nimmt man die höchste Zeilenauflösung so hat man 640x480 mit 8x8 Zeichen -> 80x60 Spalten/Zeilen ergo 80*60*2= 9600 Bytes für den Bildschirmbuffer maximal. Das macht dann zusammen 3072 + 9600 = 12.4Kb ! Je nach benutzten Zeichensatz bekommt man bei 640x480 Pixel eine Textauflösung von 80x60, 80x48 und 80x40 Blockzeichen. Zur besseren Darstellungen hatten viele alte VGA's noch einen speziellen 9 Bit Modus. Statt 8 Pixel pro Zeichenbreite wurden virtuell 9Bit angezeigt. Somit entstand eine Auflösung von 720x480 Pixel. Der Zeichensatz war denoch pro Zeichen nur 8 Pixel breit und bei der Anzeige wurden bei ASCII < #128 das 9. Pixel einfach auf die Hintergrundfarbe gesetzt und bei ASCII >= #128 der 8. Pixel nochmal als 9. Pixel dargestellt. Sinn und Zweck der Sache war das bei normalen Textzeichen die Darstellungsqualität und das Aspektratio sich verbesserte, und bei den sogenannten Blockzeichen oberhalb #127 es denoch möglich wurde Balkengrafiken zu zeichnen. So wie halt früher unter DOS. Warum textorientiert ? Ich meine das es am AVR wichtiger wäre Text usw. auf einem Monitor auszugeben und zudem sinkt der Memoryoverhead durch den kleinen Displaybuffer drastisch. Falls nun noch Platz im CPLD bleibt (schätze mal minimal 47 Makrozellen gehen drauf) kann man nun im restlichen Speicher sogenannte Overlays/Sprites einbauen. Im Grunde braucht man ja meistens kleinere Grafiken. Man definiert dann deren X/Y Koodinate im Bereich [0..79,0..59], die Breite und Höhe dieser Sprites muß immer ein Vielfaches der Fontgröße sein. Jeder Pixel dieser Sprites ist 8Bit groß und stellt die 64 möglichen Farben dar. Der CPLD kann nun bei der Darstellung diese Sprites auf dem Bildschrim über-zeichnen. Ok, das wird aber wohl zu viel des Guten sein :=) Nochwas, laut deinen Schaltplan generierst du HSnyc und VSync. Es wäre jetzt noch gut das Composite Sync zu erzeugen. Dies ist einfach eine XOR Verküpfung von H/VSync (wenn ich mich nicht irre). Dieses Sync wird zb. von neueren Fernseher mit SRGB Eingängen oder über SCART benutzt. Gruß Hagen
@Ulrich lassen sich die beiden fehlenden Bits aus dem 8bit Speicher einfach so ausgeben, oder werden die für was anderes verwendet ? Ich habe nämlich noch einige RAMDACs aus ISA Grafikkarten rumliegen, und die haben eine Farbtabelle eingebaut um aus insgesamt 262144 Farben auswählen zu können. Vor allem wenn man Fotos darstellt, dann können 16 frei wählbare Farben besser sein, als 256 feste. Daher werde ich den auf jedenfall dem Widerstands DAC bevorzugen. @bierbach Ich habe noch eine andere Schaltung hier, die erzeugt ein echtes PAL FBAS Signal mit 256 frei wählbaren Farben und 512x256 Pixel Auflösung. Und der verwendet AVR läuft mit nichtmal 8MHz... Bei der Software musste ich auch nicht tricksen, dafür ist aber die Harware etwas aufwendiger.
Hier eine andere Version eines Testbildgenerators. Bei dieser Software steht das Timing im Vordergrund. Es lässt sich so ziemlich jede nur erdenkliche Auflösung mit beliebigem Timing generieren. Das dargestellte Testmuster ist dagegen eher einfach, aber es reicht um einen Monitor bei verschiedenen Auflösungen ohne PC zu testen.
Hi, Den RAM den du benutzt ist der noch zb bei reichelt verfügbar? kann man die auflösung und frequenz auf tv werte bringen? Mit nem rgb zu pal hoschi könnte man ja dann ein bild auf dem tv erzeugen...
Wofür eigentlich Register r0-r2? Da steht, wenn ich das richtig sehe nur 0,1 und 255 drin. ?! Wo liegen die Vorteile?
Wenn man 32 Register hat, aber nur etwa 5 benötigt kann man doch mal etwas verschwenderisch sein, oder ? null und eins benötigt man öfters mal wie z.B. bei add und adc
Hier ein kompletter Low Cost Monitortester (1 IC, 9 passive Bauteile in der Minimalversion) mit 11 Auflösungen von 640x480 bis 1600x1200 und Horizontalfrequenzen von 31kHz bis 92kHz. Ich habe einen mega48 verwendet, da dieser für 20MHz spezifiziert ist. Ein mega8 funktioniert jedoch auch (auch wenn das Datenblatt nur 16MHz angibt.) Allerdings muss dann der Code minimal angepasst werden (Timer Registername ändern.)
@ Benedikt: Es gibt doch auch Immediate-Wert-Add-Funktionen im AVR ?! Und diese dauern doch genausolange als würde man 2 Register addieren.
meinst du adiw ? Der Befehl benötigt aber ein bestimmtes Registerpaar, und wenn ich sowiso genügend Register habe, dann sind mir die beiden zusätzlichen Register egal.
Mach addier mal ne 8bit zu ner 16bit Variablen, da freuste dich über das Null-Register.
hallo, die verkauften auf http://www.tvterminal.de/ sind doch auch nur programmierte mega8 denke ich, und die machen noch mehr sachen, gleichzeitig http://www.tvterminal.de/eBay-Fotos/TVT-MD-11T_schaltplan_640x521.GIF
Nicht ganz klar, was du sagen willst. Vermutlich meintest du diesen Link: http://cgi.ebay.de/TVT-MBKD-11-IC-fuer-Text-Grafik-auf-TV-mit-9600-Baud_W0QQitemZ5855885182QQcategoryZ12949QQssPageNameZWDVWQQrdZ1QQcmdZViewItem P.S. Dat Ding ist für TV und nicht für VGA !
um das Tv Signal hinzubekommen müssen die Signale nicht noch schneller kommen als wenn die 3 RGB Kanäle getrennt sind ? kann man nicht den Video RAM einer Grafikkarte irgendwie selber beschreiben, ich denke da an so eine ISA Karte, gabs da nich sogar mal welche mit 8 bit ? das als .lib in bascom einbinden..... so einen 15" TFT zu bedienen währ doch mal was, als so nen 240x128 Grafik LCD für mindestens genau so viel euros
Die Idee mit der ISA VGA Grafikkarte hatte ich auch schon, und da bin ich nicht der einzige. Leider wird jede Grafikkarte anderst angesteuert, die ganze Kompatibilität wird nur durch die VGA BIOS erreicht. Jede Karte liefert die Treiber also quasi selbst mit.
@Benedikt Hallo Habe mir deinen kleinen Monitortester nachgebaut. Habe auch einen ATMEGA48 eingesetzt. Leider bekomme ich nicht die gewünschten Impulse für h-sync und v-sync raus. Die sind bei mir total daneben. Anstatt 32µs habe ich 22µs. Wie kommt das? Habe ich irgendwie die Fuses falsch gesetzt? Für Hilfe wäre ich echt dankbar Gruß Ben
Hat der Quarz die richtige Frequenz (22MHz) ? In der Software sind die Register auch entsprechend für den mega48 angepasst ?
würd mir jemand den IC brennen? ich bin da nähmlich nicht so gut drin, brauchte den für Computerservice, fange mit Gewerbe an. THX
Nur den CHip brennen oder die schaltung aufbauen?
Dann schreib mir einfach mal ne Mail (meld dich an und klick auf meinen namen)
In der Software ist die Belegung beschrieben: Es sind nur ein paar Widerstände neben der normalen Beschaltung notwendig.
Hallo, ich habe den Testbildgenerator überarbeitet und die Quarzfrequenz auf 20 MHz reduziert. So ist kein Übertakten des ATmega88 mehr notwendig. Siehe: http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/VgaGen.htm
Ich habe das Projekt leicht verschoben, liegt jetzt unter: http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/VgaGen/VgaGen.htm
Benedikt schrieb: > Ein kleiner Testbildgenerator für einen ATmega8, der ein 128x124 > x16Farben Bild mit der Standard VGA Auflösung 640x480 @60Hz auf einem > Monitor anzeigt. Habe den Testbildgenerator nachgebaut komme aber mit den Fuses nicht klar. LowFuse 0xDE, HighFuse 0xDF, WR 0xFF, Lock 0xFF, Cal FFFFFF9A Mit dieser Einstellung bekomme ich nur dünne Vertikale Streifen. .. mit der Bitte einen Neuling zu helfen... DANKE!
Zum Testbildgenerator habe ich keine direkt zutreffende Frage aber: VGA ist doch eine "analoge" Schnittstelle. Also habe ich mir mit einem Arduino die erforderlichen Sync.-Impulse erzeugt und an die Anschlüsse für R,G und B jeweils eine Gleichspannung 0,3V-1V angelegt. Statt Videoinhalt also nur je eine farbige Fläche. Der Monitor ( 17" Medion ) bleibt dunkel! Was mach ich falsch?
Der (mein) Testbildgenerator mit ATmega88 ist nun dort: http://www.tu-chemnitz.de/~heha/Mikrocontroller/VgaGen/ Inzwischen gibt es den Arduino Uno mit dem kompatiblen ATmega328; allerdings wäre da der Quarz zu ändern (auf 20 MHz), womit die serielle Schnittstelle für den Urlader nicht mehr läuft. Es war eben anno 2010 kein Arduino-Projekt. @fritzkarl_w: Monitore bleiben üblicherweise dunkel, wenn das Timing nicht (quarz-)genau passt. Außerdem erwarten Monitore (und Fernseher), dass während der Austastlücke tatsächlich Schwarz anliegt; eine Klemmschaltung tastet diesen Wert als Schwarzwert ab. Damit überlebt das RGB-Signal auch AC-Kopplung (also Kondensatoren, Hochpässe), und das Bild stimmt trotzdem. Permanentes Grün (1 V= auf G) kann demnach als Schwarz interpretiert werden. @willi047: Fuses stehen im Makefile. Bei moderneren Projekten im Quelltext, sie werden dann Teil der ELF- bzw. HEX-Datei; beißt sich allerdings mit dem Brennprogramm avrdude. Bei einem anderen, auch größeren ATmega muss man davon ausgehen, dass weder Fuses noch Hex-Datei austauschbar sind! Nur C-Quelltext ist austauschbar. Da muss man sich selbst vortasten. Da aus falschen Fuses häufig Taktprobleme resultieren, ist es ratsam, die OSCOUT-Fuse zu setzen und mit dem Oszilloskop oder Frequenzmesser die Funktion des Pins (siehe Datenblatt) zu prüfen. Genau dazu ist diese Fuse gut. Mit einem Multimeter allein ist man bei Mikrocontroller-Projekten weitestgehend blind, also behindert.
Thread beobachten
Seitenaufteilung abschalten
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.