OSD mit LM1881 und Arduino Nano

[Ted Barth (Gast)]

Hallo zusammen,

ich will mir ein grafisches OSD für PAL-Videos basteln.
Das Video hat eine vertikale Auflösung von 625 lines.
Als Plattform zur Informationssammlung (WLAN, etc) will ich einen 
Raspberry Pi Zero nutzen. Dieser redet mit einem Arduino Nano o.ä, 
welcher mithilfe eines LM1881 ein dynamisches Pixelbild zeichnet. Ein 
Max7456 reicht hier wegen der Begrenzung auf einzelne Zeichen leider 
nicht aus.

Schafft der Arduino Nano die 625 Zeilen?
Habt ihr alternative Vorschläge?

Vielen Dank für Eure Hilfe!

[Harald (Gast)]

Warum tust du dir das an? Durch die Quadrocopter-Szene gibt es 
zahlreiche Module für diesen Zweck. Auch vom abgekündigtem MAX7456 kann 
man hier und da noch Boards bzw. auch das nackte IC kaufen. Damit ist 
OSD vernünftig machbar.
Suche mal nach „osd Module“

[Harald (Gast)]

Ok hätte ganz durchlesen sollen, den MAX7456 kennst du. Frage bleibt 
trotzdem, wie das mit einem Arduino gehen sollte.

[TU Student 1. (student0)]

625 Zeilen sind es nur dann, wenn du Interlaced-Signale generierst. 
Meistens sind simple OSD jedoch progressiv, auch wenn das Signal 
interlaced ist.

Ich habe einen softwarebasierten Videocontroller am XC164 an der Uni 
implementiert und damit ein OSD zu machen war eine Laborübung.  Anbei 
das Labor-Skriptum von damals, dass einige Aspekte der Theorie erklärt 
und eventuell hilfreich sein wird.

Ein grafikbasiertes OSD am ATMEGA328P wird schwierig:
Für einen 1bpp-Framebuffer brauchst du S = H * V / 8  Bytes RAM.

Mit den ganzen 2048 Bytes RAM des ATMEGA328 schaffst du bei einem 4:3 
Seitenverhältnis und quadratischen Pixeln ca. 18 * 8 = 144 Pixel 
horizontal und 112 Zeilen vertikal.

Die SPI-Taktfrequenz (max. 8 MBit/s bei 16 MHz) ist kein Problem, den du 
erreichst damit ca. 416 Pixel / Zeile horizontal:
H_Res = f_Shift * T_active     mit T_active ca. 52 us bei PAL/CCIR-625.

Mehr als ca. H_Res = 280 Pixel machen bei 5.5MHz Video-Bandbreite keinen 
Sinn.

[Ted Barth (Gast)]

Hallo Harald,

Ich hätte dann Gebrauch von der TVOut Library gemacht (sry, habe zu 
wenig Infos gegeben). Die schafft aber wegen des geringen RAMs nur die 
halbe Auflösung. Da braucht man schon was dickeres. Warum man bei mehr 
als 160 horizontalen Pixeln einen ganzen Port braucht, verstehe ich 
genauso wenig, wie das dann geschaltet werden soll:


[code]To the desired resolution. There are a few restrictions to this 
however:

_RESOLUTION_HORIZONTAL must be set to a multiple of 8. _

(_RESOLUTION_HORIZONTAL/8)*_RESOLUTION_VERTICAL must be smaller than the 
amount of SRAM the Arduino has, It also must leave some memory for the 
user applications and the library to run.

160 is currently the maximum supported resolution, Higher is possible 
but it will require the use of a whole port rather than pin. EX: the 
analog pins may be all used to output video, but none could be used for 
any other output.
In the future I do plan to implement an easer way to change the 
resolution.[code]

https://sourceforge.net/p/arduino-tvout/wiki/Useage/

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Ted Barth schrieb:
> Warum man bei mehr
> als 160 horizontalen Pixeln einen ganzen Port braucht, verstehe ich
> genauso wenig, wie das dann geschaltet werden soll

Ein Read-Modify-Write braucht nun mal mehr Takte, als wenn man einfach 
den ganzen Port anpustet.
Aber dein grösseres Problem ist die Synchronisierung des Overlays. Du 
solltest H-Sync des AVR mit dem H-Sync des Originalsignals verkoppeln, 
damits nicht horizontal zittert, der V-Sync setzt den Generator dann auf 
Null zurück.