mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bastelidee ascii text auf PAL TV


Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haste auch ans Interlacing gedacht?

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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?...

>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

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Einen PAL-Encoder? No way, da braucht es ein FPGA.

Beitrag "PAL/NTSC Encoder in VHDL"

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht sollte ich es eher über rgb scart versuchen?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grobi schrieb:
> vielleicht sollte ich es eher über rgb scart versuchen?

Das setzt voraus, daß der Fernseher so etwas unterstützt.

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...das setze ich dann einfach mal vorraus. Mein TV kanns...
und das könnte dann doch auch non interlaced laufen.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das RGB Signal am TV ist genauso interlaced wie die anderen Signale.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :)

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Standa...

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.