Hi, ich hab schon lang nach ner einfachen Möglichkeit gesucht um mit nem Mikrocontroller irgendwas auf nem TV anzuzeigen. Ich weiss da es da schon zig Möglichkeiten gibt aber ich hab mir da mal selbst was überlegt da ich grad passende Bauteile noch rumfliegen habe wie z.B ein paar avrs, XC9572-15 cpld, ein paar 8KB15ns srams. Meine Idee wäre eine 40x25 ascii Symbol Anzeige mit 16 Vordergrund- und 16 Hintergrundfarben auf einem PAL TV (720x576). Die ascci Symbole sollen 8x8 Pixel sein aber auf dem TV praktisch 2fach vergrößert auf 16x16 Pixel dargestellt werden. Ist nach meiner Ansicht sonst einfach zu klein. Der Bildspeicher soll in Pixel- und Farbspeicher aufgeteilt werden. Ein ascii Symbol besteht aus 8x8 Bit wobei die bits die Pixel darstellen. Bit = 1 bedeutet Vordergrundfarbe anzeigen, 0 = Hintergrundfarbe anzeigen. Also 8 byte im Pixelspeicher und 1 byte im Farbspeicher. Bit 0-3 des Farbbyte sind die Vordergrundfarbe und 4-7 die Hintergrundfarbe. Macht also insgesamt 40*25*8 = 8000 Byte Pixelspeicher und 40*25 = 1000 Byte Farbspeicher. Werd ich dann wohl 2 von den 8KB srams nehmen müssen. Das generieren des PAL TV Bildes wollte ich dem cpld überlassen, ich weiss das der das eigentlich können müsste. Leider hab ich mit den dingen überhaupt keine Erfahrung noch keine Plan wie ich das umsetzen könnte. Ich stelle mir das so vor : der cpld hat eine Statusleitung die anzeigt ob er gerade auf den Speicher zugreift, tut er das nicht kann der "grafikcontroller", zu dem ich später komme, auf den Inhalt des Pixel- und Farbspeichers zugreifen. Da ja 720 Pixel in einer Zeile dargestellt werden müssen (ich weiss das es weniger sichtbare Pixel sind) und ich ja aber nur 40*16 = 640 Pixel an eigentlichen Pixeln in einer Zeile habe, kann sozusagen die zeit von Pixel 0-37 vom grafikcontroller genutzt werden um den Speicher mit Pixel- und Farbdaten zu füllen. an Pixel 38 ließt der cpld ein byte aus dem Pixelspeicher. Wenn ich mich nicht irre liegt doch die ungefähre Dauer für einen PAL Pixel bei ~72ns oder? da würde dann sogar ein 50ns sram ausreichen, komme ich ja mit den 15ns richig gut hin. bei Pixle 39 ließt der cpld das Farbbyte ein. An Pixel 40 wird entsprechend Bit 0 des Pixelbytes die Vorder- oder Hintergrundfarbe ausgeben. Ab diesem Zeitpunkt hätte der grafikcontroller wieder Zeit den Speicher zu bearbeiten. Pixel 41 Bit 0 des Pixelbytes wir nochmal ausgegeben weil ja 2fach vergrößert wird. Pixel 42 dann Bit 1, Pixel 43 Bit 1, Pixel 44 Bit 2 usw. Pixel 54 also nach 14 Pixel wird Bit 7 angezeigt. Ab diesem zeitpunkt kann der grafikcontroller nicht mehr auf den Speicher zugreifen.Das nächste byte wird aus dem Pixelspeicher geladen, Pixel 55 wieder Bit 7 und das nächste entsprechende Farbbyte wird geladen und ganze Vorgang wiederholt sich bis der Bildspeicher ausgegeben wurde. Mit dieser Methode habe ich 14 Pixel Zeit um ein ascii Symbol 8Byte in den Pixelspeicher zu schreiben und ein Farbbyte in den Farbspeicher. 640*400 / 14 = ~18285 Symbole und Farben pro Bildanzeige. 18285 / (40*25) = 18 Vollbildupdates pro Bildanzeige. 18 * 25 = 450 update FPS. Das sollte doch wohl schnell genug sein. Als Grafikcontroller wollte ich nen avr einsetzen da ich den programmieren kann und dort das generieren der Pixel- und Farbdaten geschehen kann. Die ascii Symbole werden zeilenweise im Pixelspeicher abgelegt z.B. Symbol an Position 0,0 hat die Pixelspeicheradressen 0, 40, 80, 120, 160, 200, 240, 280. Symbol an Position 1,0 hat die Pixelspeicheradressen 1, 41, 81, 121, 161, 201, 241, 281. Symbol an Position 0,1 hat die Pixelspeicheradressen 320, 360, 400, 440, 480, 520, 560, 600. Symbol an Position 1,1 hat die Pixelspeicheradressen 321, 361, 401, 441, 481, 521, 561, 601. Die Adresse des Farbbytes für Symbol an der Position 0,0 ist 0. Für Position 1,0 = 1. Für Position 0,1 = 40. Für Position 1,1 = 41. etc. Der Grafikcontroller soll eine art Statemachine für die Anzeige sein z.B. einmal eine bestimmte Farbe gesetzt wird sie für die nächsten Symbole übernommen, er übernimmt die cursorpositionierung etc. Also der Grafikcontroller bekommt also vom Benutzersystem über irgendein Protokoll praktich den Befehl WriteLine und dann die ascii zeichen, packt das in nen buffer und wenn der cpld ihm die zeit gibt den Speicher zu beschreiben setzt er das dann praktisch auf den Pixel und Farbspeicher um. Bekomm ich da eigentlich schwierigkeiten wegen der zugriffszeit beim sram, 15ns sram vs 65ns avr ? Das wäre sonst doof. Wenn man dem Grafikcontroller eine art burst kommando implementiert mit dem man ganze Bildschirmseiten plus Farbinfos schicken kann bräuchte man für ((40*25) * (1 byte Pixeldaten + 1 byte Farbdaten)) * 25 FPS = ~ 50000 Byte/s oder 400000 Bits/s das bei 16MHz avr wären ~ 2,5% theoretische Auslastung, wenn man das SPI als maß nimmt @ 8MHz = 5% der verfügbaren Bandbreite um z.B. flüssig ascii Animationen oder ascii GUIs in Farbe darzustellen. In meinem Kopf klingt das alles soweit ganz logisch, ABER was meint ihr??? Totaler Blödsinn? Hab ich mich derbe verrechnet?
oh, nöö, aber das würde doch eigentlich kein problem darstellen, ob erst zeile 1 dann 3 usw oder 1 dann 2 angezeigt wird sollte doch egal sein, das muss halt nur der cpld berücksichttigen wenn er die pixel und farbdaten ließt.
Und wie machst du dann noch die Quadraturamplitudenmodulation? Irgendwie muss ja noch Farbe rein, so wie du das beschreibst weisst du wohl nicht wirklich wie ein PAL-Signal für eine Zeile aussieht...
ok zugegeben so genau bin ich da noch nicht eingestiegen aber wäre es möglich das der cpld das farbsignal durch z.B. 8 ausganssignale über widerstände die miteinander verschaltet sind einstellt ?
Grobi schrieb: > aber wäre es möglich das der cpld das farbsignal durch z.B. > 8 ausganssignale über widerstände die miteinander verschaltet > sind einstellt ? Theoretisch ja, aber du hast offenbar den Post von Andreas nicht gelesen? Die Stichworte waren PAL und Phasenmodulation, Quadraturmodulation http://de.wikipedia.org/wiki/Phase_Alternating_Line Es ist übrigens eine ziemlich schlechte Idee, farbige Zeichen auf einem Bildschirm darzustellen, denn die Farbauflösung ist einiges schlechter als die SW-Auflösung...
also so ganz hab ich das mit der Quadraturmodulation noch nicht verstanden, ich dachte wirklich es würde reichen halt in dem moment wo der Pixel angezeigt werden soll eine Spannung 0-1v oder so auszugeben. Wo hab ich das denn nur her?? Naja gut aber mal ganz abgesehen davon das es sich ja dabei um ein Problem handelt das man in der cpld logik lösen muss und ich meine wirklich das schonmal irgendwo auf opencores oder so gesehen zu haben das es geht. Wie hört sich denn der Rest so an?
@ Grobi (Gast) >verstanden, ich dachte wirklich es würde reichen halt in dem moment wo >der Pixel angezeigt werden soll eine Spannung 0-1v oder so auszugeben. >Wo hab ich das denn nur her?? Vom VGA Monitor, dort ist das so, weil man direkt RGB Signale erzeugt. > Naja gut aber mal ganz abgesehen davon das >es sich ja dabei um ein Problem handelt das man in der cpld logik lösen >muss Einen PAL-Encoder? No way, da braucht es ein FPGA. >gesehen zu haben das es geht. Wie hört sich denn der Rest so an? >Meine Idee wäre eine 40x25 >ascii Symbol Anzeige mit 16 Vordergrund- und 16 Hintergrundfarben auf >einem PAL TV (720x576). Gibt es schon. http://www.mikrocontroller.net/forum/codesammlung?filter=terminal >Die ascci Symbole sollen 8x8 Pixel sein aber auf dem TV praktisch 2fach >vergrößert auf 16x16 Pixel dargestellt werden. Ist nach meiner Ansicht >sonst einfach zu klein. Damit ist aber dein (720x576) Unsinn. Und die Praxis zeit, dass diese volle Auflösung eher die Theorie ist, und mit einem VGA-Bild in 640x480 sehr wenig gemeinsam hat. Var allem wegen dem Interlacing und der damit beim PAL nur effektiven Wiederholrate von 25 Hz. Wer mal einen Amiga hatt kennt das, die HighRes Modi waren praktisch unbrauchbarer Flimmermist. Bleib bei Old School 320x256 und gut, spart Speicher und Taktrate. > Wenn ich mich nicht irre liegt doch die ungefähre >Dauer für einen PAL Pixel bei ~72ns oder? Kann man ja ausrechnen. 15,625 Khz Zeilenfrequenz =64us x 720 Pixel = 88,8 ns/Pixel, wen ich jetzt keine Horizontallücken vergessen habe. ;-) Grob gesehen bist du auf dem richtigen Weg, aber PAL ist halt recht komplex in der Erzeugung. Nimm lieber SW oder einen VGA-Monitor, das ist deutlich einfacher. MFG Falk
Falk Brunner schrieb: > Einen PAL-Encoder? No way, da braucht es ein FPGA. Beitrag "PAL/NTSC Encoder in VHDL"
Grobi schrieb: > vielleicht sollte ich es eher über rgb scart versuchen? Das setzt voraus, daß der Fernseher so etwas unterstützt.
...das setze ich dann einfach mal vorraus. Mein TV kanns... und das könnte dann doch auch non interlaced laufen.
Das RGB Signal am TV ist genauso interlaced wie die anderen Signale.
Das Interlace ist kein Problem, Fernseher "verdauen" auch 312p50. Das wird dann halt mit deutlichen Lücken zwischen den Zeilen dargestellt, funktioniert aber. So hat praktisch jeder "Homecomputer" seinen als Monitor missbrauchten Fernseher angesteuert, denn mit Interlace und 25Hz-Geflacker wäre das Resultat annähernd komplett unbrauchbar gewesen. Die wenigsten "Homecomputer" hatten Vertikalauflösungen von deutlich über 200 Pixelzeilen, warum wohl?
Hallo! In der Zeitschrift "Circuit Cellar" 01/2010 ist ein Artikel über die Anzeige von farbigen Bildschirmseiten am Fernseher veröffentlicht worden. Dort wurde ein Videotext Encoder aufgebaut. Damit ist Farbe auch ohne PAL möglich. Man muss nur ein "leeres" Bild erzeugen das auch nur s/w sein kann. Eine graue Fläche mit Zeilen- und Bildsynchronsignalen reicht. Vorteil: läßt sich über den jetzt nicht mehr benötigten Analog-Tuner einspeisen, Bildqualität kommt vom internen Videotextdecoder, kann mit der TV-Fernbedienung gesteuert werden. Nachteil: Quasi-Statische Bilder (Seiten), im Zeichensatz und bei der Farbe auf Möglichkeiten des Videotext beschränkt.
>Vorteil: läßt sich über den jetzt nicht mehr benötigten Analog-Tuner >einspeisen SCART müsste ja auch möglich sein. Jedenfalls ne interessante Möglichkeit per Videotext was anzuzeigen :)
...mir is da noch was eingefallen was die TV out Sache betrifft, so wie ich das bis jetzt rausgehört habe wäre es warscheinlich viel einfacher mit dem cpld ein rgb vga signal h & v sync für 720x576@50Hz oder 640x400@50Hz zu erzeugen und dann mit einer einfachen konverter schaltung wie z.B. auf : http://www.epanorama.net/circuits/vga2rgbs.html beschrieben auf den Ferseher zu bringen. Oder liege ich da wieder falsch?
VGA ist auch RGB + Sync... Nur ist bei VGA der Hsync und der Vsync noch getrennt. Von einem FBAS-Signal bist du damit immer noch meilenweit weg. Wenn das Sync-Signal sowieso im CPLD genereiert wird, dann doch gleich am besten so, dass es direkt passt. Dann braucht man die Zusammenfassung hinterhier nicht mehr. Warum nimmst du nicht einen VGA-Monitor zur Anzeige? Das würde das Ganze recht einfach machen: http://lmgtfy.com/?q=avr+vga
Ich würd das schon sehr gerne mit dem cpld lösen wegen des gegenüber einem avr höheren Pixeltakt also größerer Auflösung. VGA scheint doch eher die einfache Variante zu sein, das wirds dann wohl werden. Aber vorher muss ich mir wohl erstmal n paar gute tutorials zu cpld und vhdl zu genüge führen. Gibt es für diese XC95xx von xilinx eigentlich eine etwas schlankere IDE als das 3,2GB Monster DesignSuite Teil?
Grobi schrieb: > VGA scheint doch > eher die einfache Variante zu sein, das wirds dann wohl werden. Und warum nicht RGB mit Fernseh-Timing (625i50) und einem nachgeschalteten PAL-Encoder?
Rufus t. Firefly schrieb: > Und warum nicht RGB mit Fernseh-Timing (625i50) und einem > nachgeschalteten PAL-Encoder? daran hatte ich auch schon gedacht, dachte nur das die encoder ics so teuer wären darum wollt ich drauf verzichten, aber bei reichelt gibts den tda8501 für 2,45€ die sind wohl noch drin :)
@ Grobi (Gast) >zu genüge führen. Gibt es für diese XC95xx von xilinx eigentlich eine >etwas schlankere IDE als das 3,2GB Monster DesignSuite Teil? Ja, nimm ISE 6.3 mit Service Pack 3, das reicht locker und ist nur 2x 250MB. MFG Falk
hmm mir ist grad im Keller noch ne alte ET4000 VGA karte in die Hände gefallen, die hat eine SC11483CN80 16 Bit hicolor palette drauf, die ich noch nicht mal ablöten müsste, welche zwar keine sync aber dafür rgb und blank signale erzeugen kann. Dann bräuchte der cpld ja im prinzip "nur" noch aus dem sram lesen, die sync signale erzeugen, und die pixelclock und farbadresse für die palette einstellen. Wenn ich das alles aufs Fernsehtiming einstelle (625i50)und über rgb scart ausgebe sollte es doch klappen!
Wenn Du NTSC nimmst, so tust Du Dich eventuell leichter. Du fängst mit einem 14,318MHz Takt an, der ist 4 mal die Farbunterträgerfrequenz von NTSC. Daraus gewinnst Du 4 Signale mit der Farbunterträgerfrequenz und einer Phasenverschiebung von 0° 90° 180° und 270°. Daraus mischt Du dann über externe Widerstände Deinen Farbunterträger je nach dem welche Farbe Du haben willst. Aus den 14,318MHz machst Du durch Teilen durch den Faktor 455 ein Signal mit der doppelten Zeilenfrequenz. Daraus generierst Du Dir dann die Zeilensynchronisation, sowie die Bildsynchronisation mit all seinen Vor- und Nachtrabanten. http://www.pembers.freeserve.co.uk/World-TV-Standards/Line-Standards.html Die ganzen Faktoren sind auf einfachen Primzahlen basierend, so dass die Implementierung mit einfacher Hardware möglich ist. Bei NTSC ist das noch ein klein wenig einfacher, da dort die Farbunterträgerfrequenz ein Vielfaches der doppelten Zeilenfrequenz entspricht. Interlacing musst Du natürlich machen, sonst wird Dein Fernsehgerät nicht unbedingt korrekt synchronisieren. Besonders Videorekorder werden da Schwierigkeiten machen. Aber Du kannst natürlich in beiden Halbbildern das selbe Bild ausgeben.
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.