Arduino und TVOut

Hallo...

es gibt ja diese schöne TVOut Libary.
Die funktioniert auch Super, habe auch ein Pong spiel damit
Programmiert für den Fernseher (AV IN).

Jetzt hab ich mir mal die Libary etwas genauer angeschaut.
Meine C-Programmier Fertigkeiten sind noch etwas bescheiden, da ich
erst ins zweite Semester komme...

... und das alles sieht so unglaublich kompliziert aus. Ich habe
mir mal etwas zu Bildübertragung durchgelesen und finde, dass
es eigentlich ein garnicht so kompliziertes prinzip ist.

Ich mag es immer nicht, schon fertige Libarys zu benutzen.
Das ist nichts besonderes und man lernt dabei auch genau garnichts!
Also habe ich mich entschlossen, selber eine eigene Ansteuerung
für den AV-IN am Fernseher zu bauen.

Was steckt wirklich dahinter? Ist es wirklich so Kompliziert wie
die Libary es vermuten lässt? Sprich: Hab ich etwas nicht bedacht?
Oder ist man durchaus als Anfänger in der Lage, sich in dieses
Gebiet einzulesen und loszulegen?

Grüße,
Philipp

Ich glaube nicht, daß die Videosignalausgsgabe in C geschrieben ist, sondern in Maschienensprache da nur so die genauen Timings eingehalten werden können.
Zum Anfangen die Libraries zu verstehen ist es besser Du fängst mit anderem an.
Grüße Uwe

Ich habe mal gerade in die Lib reingeschaut. C garniert mit Inline Assembler. Sehr nett. Aber sicher nicht für Anfänger. Leute die sowas studieren nehmen aber garantiert keinen Schaden wenn sie sowas trotzdem durchanalysieren. Von sowas lernt man mehr als von einer Anfängervorlesung :wink: Mit Google kann man ja recht schnell rausbekommen was die eher esoterischen Teile bedeuten :slight_smile:

Nun habe ich mich in das Gebiet etwas eingelesen. Ich weiss,
dass Arduino über nicht Assembler Befehle nicht Optimal für sowas ist,
vor allem was das Timing angeht. Aber es soll angeblich Funktionieren
für ein sehr Simples Schwarz-Weiß Bild.

Ich habe im Moment Probleme mit den Synchronistationsignalen.
Auf Wikipedia ist das ganz gut erklärt und ich halte mich
auch daran. Doch bekomme ich keine anständige Synchronisation.

Ich gehe wie folgt für für H-Sync:
(uS = Microsekunden)

  1. 0,3 Volt für 1.5 uS (Vordere Schwarzschulter)
  2. 0 Volt für 4,7 uS (Horizontaler Zeilenwechsel)
  3. 0,3 Volt für 5,8 uS (Hintere Schwarzschulter)
    dannach:
  4. Bildübertragung für 52 uS

Fertig und das ganze wieder von vorne bis... tja bis wann..
Man geht von 625 Zeilen aus und soll - jetzt wird mein Wissen darüber etwas
Diffus - so wie ich das verstanden habe nach der hälfte c.a einen Vertikaler Sync
gesendet werden, der aus 5 Vortrabanten besteht, 5 Sync-Impulsen und
wieder 5 Nachtrabanten.

Dann sollte das zweite Feld beginnen also wieder Hsync bis Zeile 622 und dann
wieder V-Sync bis Zeile ~5.

Das will alles nicht so recht funktionieren :frowning:

Ist meine Annahme aber soweit richtig?
Ich bekomme höchstens paar flimmernde Streifen zu sehen, die, woher auch
immer sein mögen...

Wie bekommst Du denn die 1,5 uS oder 4,7 uS ohne Assembler hin? Wenn ich mich nicht verrechne, sind bei 16MHz eine uS genau 16 Takte und damit im Idealfall 16 Befehle. Das ist für eine Hochsprache wie C schon ziemlich knapp.
Poste doch mal den Code den Du bisher hast.

Hab ich nen Denkfehler? Bei 16 MHz dauert ein Takt 62,5 Nanosekunden, also 62.500 Mikrosekunden. Da haben wir für die 1,5µs nette 41667 Taktzyklen zur Verfügung. Knapp ist was anderes - sofern ich mich nicht verrechnet habe.

Hmm, evtl. irre ich mich ja auch.
16 MHz sind doch 16.000.000 Take pro Sekunde
Damit sind es 16.000.000 / 1000 = 16.000 pro Millisekunde
und damit dann 16.000 / 1000 = 16 pro Microsekunde.

Oder hab ich da gerade einen riesen Denkfehler in meiner Rechnung?

sofern ich mich nicht verrechnet habe

hast Du.

gruß stefan

sth77:
Hab ich nen Denkfehler? Bei 16 MHz dauert ein Takt 62,5 Nanosekunden, also 62.500 Mikrosekunden. Da haben wir für die 1,5µs nette 41667 Taktzyklen zur Verfügung. Knapp ist was anderes - sofern ich mich nicht verrechnet habe.

62,5nS sind nicht 62500µS sondern 62500pS oder 0,0625µS

Um zur Anzahl der Takzyklen zu kommen mußt Du die Zeit durch die Zykluszeit dividieren also 1500nS/62,5nS=24 oder 1,5µs / 0,0625µS =24.

Grüße Uwe

Oh je, das war ne arbeitsreiche Woche. Wenn nicht einmal das einfache Umrechnen funktioniert, sollte ich heute wohl früher Feierabend machen... Schönen Dank für die Richtigstellung!

Nur so nebenbei:
Bei meinem Arcademonitor wird das H- und V-Sync-Signal über eine einlzige Leitung übertragen...

Ob das hilft oder nur mehr verwirrt, weiß ich nicht.
Ich hoffe allerdings ersteres! :wink:

Gruß
Reinhard

Okay, nachdem ihr mich erfolgreich verwirrt habt...
Hab ich jetzt mal Nachgerechnet:

T = 1/f
<> T = 1 / 16.000.000 Hz
<> T = 0,0625 µS
Bei 16 Mhz dauert eine Peroiode (ein Takt also) 0,0625 µS
Und somit sind in 1.5µS z.b 24 Befehle möglich da:
1.5 µS / 0.0625 µS = 24

Somit ist mein Vorhaben möglich!!?

Ich glaube ich sollte mal den Code völlig neu überarbeiten
und mir was elegantes einfallen lassen. Bisher ist es
nur eine Abfolge von Signalen... Vor allem
was den V-Sync angeht....

Hat jemand evtl kurze Anregungen?

MindCode:
Hab ich jetzt mal Nachgerechnet:

Und somit sind in 1.5µS z.b 24 Befehle möglich da:
1.5 µS / 0.0625 µS = 24

Nein. Somit sind nicht 24 Befehle, sondern x Befehle die zusammen 24 Taktzyklen brauchen, möglich.

Nicht jeder Maschienenbefehl braucht nur 1 Takt, es gibt auch solche die 2,3 bis 5 brauchen.

Grüße Uwe

hi,

Ein Vorteil gegenüber anderen Mikroprozessor-Familien ist, dass sich dank der RISC-Architektur die meisten Register-Befehle innerhalb eines Systemtakts abarbeiten lassen, ausgenommen Sprung- und Multiplikationsbefehle sowie Zugriffe auf das Speicherinterface (u. a. RAM und I/O-Ports). Somit ist diese Architektur sehr schnell im Vergleich zu anderen.

da geht's aber um assembler-befehle. Dein C muß ja erst in maschinensprache übersetzt werden, und da werden aus einem C-befehl viele maschinen-befehle.

trotzdem viel glück, man kann's ja probieren...

gruß stefan

Ach das hatte ich garnicht bedacht...
...auch wenns nur Pegel und Delaybefehle sind!

Naja mit meiner Methodik funktioniert das
ohnehin nicht. Ich komme nich drum rum
mich mit der TVOut Libary auseinanderzusetzen... :slight_smile:

Vielen dank euch allen!

Ich habe noch ein paar Info´s gefunden. Vielleicht ist das für Dich noch nützlich:

http://www.mikrocontroller.net/topic/53140#new

Ein paar allgemeine Infos:

Ein Fernsehsignal in s/w am AV-Eingang ist ein BAS-Signal.
Mit Farbsignal dazu dann FBAS.
Das Fernsehsignal besteht aus 50 Halbbildern = 25 Vollbildern.
Jedes Vollbild besteht aus 625 Zeilen.
Ein Halbbild "beschreibt" jede zweite Zeile, also theoretisch 312,5 Zeilen pro Halbbild.
Davon abgezogen werden die Zeilen, in deren "Zeit", besser Taktzyklus, der vertikale Rücklauf fällt.
Somit sind etwa 575 Zeilen pro Vollbild "sichtbar", also 287,5 Zeilen pro Halbbild mit Signal zu füttern und die restlichen 25 Zeilen bleiben für den (vertikalen) Bildrücklauf.
Jede Zeile ist 64 µs lang und besteht aus der vorderen und hinteren Schwarzschulter (Zeilenrücklauf) und 52 µs Bildinhalt.
Das Synchronsignal ist dabei 1,5 µs Schwarz-Level, 4,7 µs Synchronsignal (der einzige Signalanteil negativ zum Schwarzanteil) und nochmals 5,8 µs Schwarz-Level.
Der Vertikalrücklauf sind reine Synchronanteile: 2,5 Zeilen, 2,5 Zeilen, 2,5 Zeilen (Vortrabanten, V-Sync, Nachtrabanten).
Die theoretisch verbleibenden Zeilen gehen im realen Signal unter, da der Bildrücklauf länger ist als das Bildrücklauf-Synchronsignal, effektiv werden bei TV-Geräten sogar duch Ränder noch weniger Zeilen dargestellt (oben und unten abgeschnitten).
Entsprechend diesen Daten müssen die Timings sein.

Dirk

Noch zu sagen wäre daß im Bildrücklauf die Daten für den Teletext übertragen werden.
Grüße Uwe

Hi,

ja, Uwe hat, wie immer, recht.
Das aufmodulierte Farbsignal und den dazugehörigen Träger hab ich ebenfalls nicht erwähnt.

Dirk