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
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.
