www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Video-Farbausgabe mit ATmega88


Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da es hier meist darum geht, möglichst viele Zeichen in eine Zeile zu 
bekommen, möchte ich erstmal nachfragen, inwieweit Interesse an 
Farb-Videoausgabe mit AVR's besteht. Ich habe dazu erstmal aufgestellt, 
was ich für möglich halte:

-ATmega88 mit 20MHz Takt
-20 Zeilen a 24 Zeichen
-Zeichentabelle mit 256 Zeichen
-8 Farben für Vordergrund/Hintergrund
-Für jedes Zeichen ein Attribut-Byte 
(Hintergrundfarbe,Vordergrundfarbe,Blinken)

Entweder als kleines Modul mit serieller Schnittstelle (max. 115kbps, 
Sender muss auf ACK warten) oder als Modul zum Einbinden in eigene 
Projekte. Speicherbedarf beträgt ungefähr 4-5 Kbytes für 
Interrupt-Routine und Zeichentabelle.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie willst Du die Farbe erzeugen bzw. was für Video meinst Du? Willst Du 
ein FBAS-Signal für den Fernseher erzeugen?

http://www.mikrocontroller.net/articles/TV-out

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RGB für den Scart-Eingang bzw. FBAS via CPLD.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe genau das gestern abend programmiert:
Und zwar meine 40x25 TV Software erweitert, so dass pro 2Zeilen 
zusätzlich noch eine Farbe möglich ist.
Für jedes Zeichen eine Farbe wäre schöner, aber dafür reicht der RAM 
nicht.
Da ich nur noch etwa 20 Bytes frei habe, kann ich leider nur pro 2 
Zeilen 1 Farbbyte ausgeben.

Dazu habe ich den FBAS Generator von Joerg mit 2x 3bit Eingänge 
(Vordergrund/Hintergrundfarbe) und dem eigentlichen Pixeldatensignal 
erweitert. Zusätzlich noch ein Blanking Eingang der alles auf Schwarz 
schaltet.
Das ganze funktioniert prinzipiell schon, nur ich bekomme leider kein 
Farbbild.

@Joerg
Ich betreibe den FBAS Encoder mit 32MHz. Daher habe ich bei der DDS den 
Wert von 9080 auf 4540 verringert.
Das müsste passen, oder ?

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt
Wenn Du statt Farbe nur ein wanderndes Muster siehst, liegt pnmode auf 
'0'? Wenn kein Muster zus sehen ist, liegt cgsel auf '1'? Das Signal 
schaltet zwischen Farbe und Graustufen um. Besser als 32MHz ist es, 
einen Vorteiler zu verwenden, der auf 16MHz teilt. Zumindest bei 15ns 
CPLDs kann es sonst Probleme geben. Du kannst auch mal Deinen VHDL-Code 
posten und ich schaue mal nach.

Jörg

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe keine Streifen, nur weiße bzw graue Buchstaben.
pnmode=0 (->PAL)
cgmode=0 (->Farbe)

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
setze cgsel auf '1', das Signal ist ein bisschen unglücklich bezeichnet.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dann ist ein Fehler in deiner Beschreibung:
"’0’ selects colour mode and ’1’ selects greylevel mode"

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stimmt, das hast Du recht, ich werde heute abend mal den Code 
überarbeiten. Das Ganze kam dadurch, dass die Taster auf meinem 
CPLD-Board nach Masse schalten.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie bekomme ich das ganze nicht so recht zum laufen:
Ein Problem sind die Pegel:
Der 9536/72 gibt keine 5V sondern nur 3-4,5V je nach Last aus.
Hattest du damit keine Probleme ?

Wenn ich 0 als Farbwert ausgebe ist alles schwarz. Bei 1-6 kommt weiß 
raus und bei 7 grau (im Graustufenmodus).
Im Farbmodus bekomme ich bunte Muster. Anscheinend habe ich also 
Probleme mit der Frequenz.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch der Rest vom Code.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deinen Code habe ich leider nicht in einen 9536 bekommen. Zuallererst 
mal die Widerstände überprüfen und vielleicht ein kleines Testprogramm 
mit Farbbalken in den AVR programmieren, im Graustufenmodus sollte eine 
Grautreppe mit relativ dunklem Grau beim Blau zu sehen sein. Das 
eigentliche Encoder-Modul lasse ich mittlerweile größtenteils 
automatisch erzeugen. Ich werde mal den Innenwiderstand messen und mit 
einbeziehen, ob sich die Sache noch etwas optimieren lässt. Die 8 MHz 
Pixeltakt erzeugen allerdings auch 4 MHz Bandbreite bei Y und das könnte 
schon Probleme bei der Darstellung geben.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Könnt Ihr mich mal Einnorden? Hier ist eine Anfrage über eine Farbgrafik 
/ Farbtext auf den Fernseher, dann wird auf Benedikts Projekt verwiesen, 
welches aber im dazu gehörigen Thread und dem dortigen TVout.zip nur RGB 
ausgibt. Jetzt ist plötzlich von FBAS die rede und einem dafür nötigen 
CPLD.

Was ich suche ist eine einfache Möglichkeit Farbgrafik in ein FBAS 
Signal einzumischen. Da die dafür früher immer gern verwendeten Bauteile 
wie TV-Text Generator und Video-MUX werden Stück für Stück abgekündigt.

Daher wäre eine Lösung mit ATmega+RAM+CPLD ideal. Das Zeug ist frei 
verfügbar, langfristig verfügbar und ebenso leicht ersetzbar.

Ich habe einen ATmega32 oder 64, XilinX 9572 CPLD und eine halbe Tonne 
guter alter 10ns/5ns Chache-RAMs aus etlichen frisch verschrotteten 
Mainboards.

Also bitte, wo ist der Link auf den Schaltplan mit dem CPLD, VHDL... Ich 
würde da so gern mit machen.

Gruß, Ulrich

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> Was ich suche ist eine einfache Möglichkeit Farbgrafik in ein FBAS
> Signal einzumischen. Da die dafür früher immer gern verwendeten Bauteile
> wie TV-Text Generator und Video-MUX werden Stück für Stück abgekündigt.

Das wird sehr schwer bis unmöglich, ohne das FBAS Signal in RGB 
aufzusplitten, RGB einzufügen und das ganze wieder in FBAS zu wandeln.
Da du dann analoge Videosignale hast, nützt dir das hier nichts, denn 
der CPLD mit der Software von Joerg verlangt als Input digitale RGB 
Werte.

> Daher wäre eine Lösung mit ATmega+RAM+CPLD ideal. Das Zeug ist frei
> verfügbar, langfristig verfügbar und ebenso leicht ersetzbar.

Versuch mal schnellen asynchronen RAM neu zu kaufen...

> Ich habe einen ATmega32 oder 64, XilinX 9572 CPLD und eine halbe Tonne
> guter alter 10ns/5ns Chache-RAMs aus etlichen frisch verschrotteten
> Mainboards.

5ns Asynchrone SRAMs ?

Eine angepasste Version der Grafikkarte von Ulrich Radig, die auf H und 
VSync des Videosignals synchronisiert ist, sollte hier besser passen.
Gleichzeitig kann man hier auch noch eine Alpha Farbe definieren, die 
dann den Multiplexer steuert der zwischen Video und Einblendung 
umschaltet.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 5ns Asynchrone SRAMs ?
>
> Eine angepasste Version der Grafikkarte von Ulrich Radig, die auf H und
> VSync des Videosignals synchronisiert ist, sollte hier besser passen.
> Gleichzeitig kann man hier auch noch eine Alpha Farbe definieren, die
> dann den Multiplexer steuert der zwischen Video und Einblendung
> umschaltet.

Sind 10ns, 15ns und 20ns Typen. 5er sind leider keine dabei. Leider sind 
zumindest vom W24M257AK-15 (Winbond) die Datemblätter offline. Muss da 
mal in meinen alten Datenbeständen suchen. Die anderen Chips muss ich 
noch checken.

Das mit Ulrichs Karte ist genau das Problem, der Videochip ist/wird 
abgekündigt, denke ich.

Ich weiß auch nicht, warum ich erst nach RGB und wieder zurück muss. 
Über ein 'Fastblanking', kann ich doch direkt im FBAS zwischen dem, was 
die CAM sendet und meiner Einblendung hin und her schalten. Wozu erst 
alles umwandeln, mischen und wieder zurück?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> Ich weiß auch nicht, warum ich erst nach RGB und wieder zurück muss.
> Über ein 'Fastblanking', kann ich doch direkt im FBAS zwischen dem, was
> die CAM sendet und meiner Einblendung hin und her schalten. Wozu erst
> alles umwandeln, mischen und wieder zurück?

Wenn du ein Farbbild zusätzlich einfügen willst, musst du den Farbträger 
mit dem orginalen Farbträger synchronisieren. Ich wüsste nicht wie das 
gehen soll, bzw. wenn doch, dann nur mit viel Aufwand. Alle üblichen 
Systeme die ich kenne (wie z.B. Videorekorder) gehen alle den Weg 
FBAS->RGB, Bild einfügen, RGB->FBAS

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz so abwegig scheint es mir nicht mehr zu sein, farbigen Text in ein 
FBAS Signal zu mischen. Und zwar deswegen, weil der DDS-Counter relativ 
einfach auf ein externes Burst-Signal synchronisierbar ist 
(Nulldurchgang). Mit hohen  Auflösungen sollte aber nicht zu rechnen 
sein.

- Ein Analog-Komperator extrahiert das Synchronsignalgemisch (0,1V 
Schwelle)

- das Ergebnis geht auf einen Interrupt-Pin des Controllers

- der AVR erzeugt sein eigenes Timing, welches zunächst freilaufend ist.

- In einer Startphase synchronisiert sich der AVR vertikal indem er die 
Pulslängen am Pin misst und seinen internen Zeilenzähler entsprechend 
setzt.

- Später wird dann nur noch der Timer im AVR bei der Startflanke des 
horizontalen Synchonsignals (im Bereich der sichtbaren Zeilen) 
zurückgesetzt.

- Der AVR erzeugt zwei Signale, während denen das CPLD das Ende des hor. 
Synchonimpules und die Phasenlage des Bursts über einen zweiten 
Analogkomperator (0,25 V Schwelle) bestimmt.

- Danach geht der AVR in den Sleep und wartet, bis das CPLD die 
Videoausgabe freigibt

- Der PAL-Encoder in der neuen Version könnte fast 1:1 als 
Teilkomponente übernommen werden.

- Drei Bits steuern RGB, ein viertes Bit schaltet bei "1" einen 
Analogmultiplexer vom Original- auf des selbsterzeugte FBAS-Signal um, 
wenn ein Pixel dargestellt werden soll.

Das größte Problem würde ich darin sehen, das Timing sauber hinzukriegen 
UND aus der momentanen Phasenlage des Bursts den Farbträger 
phasenrichtig zu synchronisieren (es gibt ja bei PAL zwei Möglichkeiten 
;-) Aber zumindest theoretisch sollte es machbar sein.

Gruß Jörg

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich

Den PAL-Encoder findest du hier im Forum "Codesammlung" und auch bei
http://www.opencores.org

@Benedikt
Hast Du mal die neue Variante vom Encoder ausprobiert? Da Du in Deiner 
Variante von ersten Design alles mit 32MHz getaktet hast, kann das CPLD 
wahrscheinlich zu langsam gewesen sein, da lt. Timing-Report bei 32MHz 
ein 7ns-Teil gerade noch so gehen sollte (clock limit 31,7 MHz). In der 
neuen Version sind die Pfade ein bisschen weniger kritisch und das 
Chrominanzsignal lässt sich extern noch etwas filtern.

Gruß Jörg

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.