tvgfx: 416x226 Monochrome ATmega1284p Composite Video

[Guenter B. (gooofy)]

Inspiriert von einigen Beitraegen hier und arduino-tvout wollte ich 
sehen, was allein mit dem ATmega 1284p moeglich ist, wenn man 
monochromes Composite Video erzeugen moechte. 128 KBytes Flash bieten 
viel Raum fuer Fonts und Bitmaps, 16 KBytes RAM koennen zumindest zum 
Grossteil als Grafikspeicher verwendet werden.

Den aktuellen Stand habe ich an diesen Beitrag angehaengt. Einige 
Eckdaten:

* Aufloesung: 416x226 (NTSC) or 416x256 (PAL)
* 16MHz ATmega1284p
* Voll grafisches s/w Display
* Nur zwei Pins: PD3 video, PD5 sync
* Verwendet SPI um die Video Daten auszugeben, Timer 1 fuer das 
Sync-Signal
* Minimale Aussenbeschaltung (siehe Schaltplanauszug)
* Fast ausschliesslich in C implementiert
* Composite-Signal sollte hinreichend Standard-Konform sein so, dass man 
viele billige TFT-Monitore mit Composite-IN verwenden kann (die 
angehaengten Screenshots stammen von einem 7" Car TFT)

Enthalten im Code ist auch eine recht vollstaendige Vektorgrafik-Engine, 
die vielleicht auch fuer andere Projekte in der Richtung interessant 
sein koennte:

* Linien, Rechtecke
* Kreise, Ellipsen, Kreis/Ellipsenboegen
* Splines

alles jeweils auch in verschiedenen Strichstaerken. Es sind alle 
Primitive abgedeckt, die SVG definiert - damit ist es moeglich, 
SVG-Grafiken in tvgfx-Code zu konvertieren (auch wenn aktuell noch 
Handarbeit noetig ist, ein einfaches Skript zur Hilfe ist angehaengt - 
svg2tvgfx).

tvgfx nutzt das von arduino-tvout definitierte Font-Format so, dass man 
die tvout Fonts nutzen kann. Mitgeliefert wird auch ein Skript, das 
beliebige bdf-Fonts in das Format konvertiert zusammen mit einigen 
Beispielfonts.

Selbst Vektorfonts sind nutzbar, indem man sie z.B. mit FontForge nach 
bdf rastert und dann konvertiert.

Mehr Infos auf der englischen Homepage des Projekts:

http://sites.google.com/site/guenterbartsch/home/atmega1284p-composite-video

Dank:

arduino-tvout Copyright (c) 2010 Myles Metzer
http://code.google.com/p/ardui car TFT displayno-tvout

AVR Videogenerator, 40x25 Zeichen, nur 60% CPU Auslastung ! by Benedikt
Beitrag "AVR Videogenerator, 40x25 Zeichen, nur 60% CPU Auslastung !"

Simple VGA/Video Adapter von Ibragimov Maxim Rafikovich
http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm

[M. N. (Gast)]

Guenter B. schrieb:
> dass man
> viele billige TFT-Monitore mit Composite-IN verwenden kann (die
> angehaengten Screenshots stammen von einem 7" Car TFT)

Ich finde gerade diese Monitore sehr 'undankbar'. Da kann man noch 
soviel Arbeit in die Ansteuerung stecken, und diese Monitore machen 
daraus einen Pixelbrei. So kann man/ich bei dem mittleren Bild nicht 
erkennen, was dort oben links geschrieben steht. Eine horizontale Linie 
kann doppelt aber auch sehr dünn angezeigt werden.

Hast Du Dein Signal mal auf einen Röhrenmonitor gegeben? Die liefern in 
der Regel ein deutlich besseres Bild.

Wieviel Prozent belastet denn die Bildausgabe den µC und wieviel 
Leistung bleibt noch fürs Anwenderprogramm übrig?

[Guenter B. (gooofy)]

>> dass man
>> viele billige TFT-Monitore mit Composite-IN verwenden kann (die
>> angehaengten Screenshots stammen von einem 7" Car TFT)
>
> Ich finde gerade diese Monitore sehr 'undankbar'. Da kann man noch
> soviel Arbeit in die Ansteuerung stecken, und diese Monitore machen
> daraus einen Pixelbrei.

...was natuerlich je nach Anwendung auch nuetzlich sein kann, bekommt 
man doch ein Fullscreen-Antialiasing ganz umsonst :-D

> So kann man/ich bei dem mittleren Bild nicht
> erkennen, was dort oben links geschrieben steht.

Die Kamera tut hier dem Geraet ein wenig unrecht, in Natur ist es besser 
lesbar. Es ist aber keine Frage, 8-Pixel-Fonts sind hart an der Grenze 
dessen, was noch geht in dieser Technologie.

Die Idee war hier eher, mit grossen Fonts zu arbeiten, die dann mit 
geglaetteten Kanten dargestellt werden. Deswegen auch die Skripte, mit 
denen Fonts konvertiert werden koennen.

> Hast Du Dein Signal mal auf einen Röhrenmonitor gegeben? Die liefern in
> der Regel ein deutlich besseres Bild.

Ich hatte waehrend der Entwicklung einen echten Commodore 1084S 
Videomonitor verwendet :)

Unterschiedliche Geraete werden sicher unterschiedliche Dinge mit dem 
Composite-Signal anstellen, keine Frage. Es ist gerade diese 
Flexibilitaet und die breite Verfuegbarkeit von Geraeten, die 
Composite-IN haben, die solche Loesungen fuer mich so attraktiv machen - 
die gibt es wirklich in allen Groessen, Formen und Farben und auch auf 
lange Sicht noch wird man  muehelos Anzeigegeraete finden, die ein 
Composite-Signal entgegennehmen.

> Wieviel Prozent belastet denn die Bildausgabe den µC und wieviel
> Leistung bleibt noch fürs Anwenderprogramm übrig?

habe ich nicht berechnet oder gemessen - waere mal interessant!

Spontan: es bleiben dem Hauptprogramm momentan im wesentlichen die 
Austastluecken - vor allem in der Vertikalen tut der Interrupt fast 
nichts, das wird komplett vom Timer generiert. Aber auch in den 
horizontalen Austastluecken kann der uC was anderes rechnen.

Eigentlich wird auch noch waehrend der Bildausgabe Rechenleistung 
verschenkt - wartet der Interrupt doch busy darauf, dass er wieder 
SPI-Daten loswerden kann. Ich denke, mancher Demo-Coder koennte das 
sicher nutzen fuer interessante Effekte ... eine echte Herausforderung 
waere es, den Freiraum zur Farbausgabe zu nutzen ... anyone? :)

Viele Gruesse,

   Guenter

[Christian B. (casandro)]

Sehr schön, hat denn der SPI immer noch das Problem, dass man nach 8 
Bits immer eine Pause machen muss? Das war zumindest bei den kleineren 
Mikrocontrollern so.

[Christian B. (casandro)]

Wenn Du es schaffst Pixel mit der n-fachen Farbunterträgerfrequenz 
(n>=2) auszugeben, ist Farbe kein Problem. Sonst ist es etwas aufwändig.

Oder Du nimmst RGB-Farbe, aber das ist ja trivial.

[Guenter B. (gooofy)]

Christian Berger schrieb:
> Wenn Du es schaffst Pixel mit der n-fachen Farbunterträgerfrequenz
> (n>=2) auszugeben, ist Farbe kein Problem. Sonst ist es etwas aufwändig.

PAL farbe ist definitiv aufwaendig, aber grundsaetzlich moeglich:

http://trznadel.info/kuba/avr/index3.php

man muesste sehen, ob man das weiter optimieren kann, evtl. auch durch 
eine aufwaendigere aussenbeschaltung (z.B. einen schwingkreis, der 
phasen"programmierbar" ist o. ae.)

viel gewonnen waere schon, wenn man den hintergrund einfaerben koennte - 
am besten natuerlich pro scan-line. dann koennte man z.B. warnmeldungen 
rot hinterlegen und aehnliches.

> Oder Du nimmst RGB-Farbe, aber das ist ja trivial.

klar - das gibt's natuerlich schon in anderen beitraegen.

[Guenter B. (gooofy)]

Christian Berger schrieb:
> Sehr schön, hat denn der SPI immer noch das Problem, dass man nach 8
> Bits immer eine Pause machen muss? Das war zumindest bei den kleineren
> Mikrocontrollern so.

bin nicht sicher, was du mit Pause meinst - natuerlich habe ich NOPs im 
Code - warte also, bis ich das naechste Byte zur Ausgabe abliefere 
(alles von tvout uebernommen, will mich hier nicht mit fremden Federn 
schmuecken) verwende keine Interrupts dafuer - die SPI Ausgabe ist aber 
vollkommen durchgaengig, liefert also wirklich Pixel an Pixel und nicht 
etwa Pausen zwischen den Bytes oder verdoppelte Pixel an Byte-Raendern.

Sieht man sehr schoen am Testbild, das die Demo ausgibt - dort gibt es 
einen Bereich, in dem jeder zweite Pixel gesetzt ist - ergibt je nach 
Monitorguete gleichmaessige vertikale Linien (Commodore 1084) oder ein 
homogenes Grau (billig-Car-TFT ;) )