Hallo, vielleicht kann mir jemand von Euch mit Informationsmaterial oder ähnlichem weiterhelfen. Ich möchte mich mit dem Thema PAL-Signal beschäftigen und bräuchte einen Einstieg. Ganz genau wüsste ich gern mehr über den Aufbau des Videosignals (Cinch-Gelb). Es gibt dort eine Analogleitung und eine Signalleitung. Aber wie genau sieht das Signal aus? Am liebsten wär mir ein einfaches (unrealistisches z.B. 320x240 Pixel oder kleiner) Beispiel, das mir einleitend die Synchronisierungen und die Farbinformationen (analog zum wirklichen Aufbau des Signals) vorstellt. Am Ende sollte ein entsprechender Bildschirm die Signale fehlerfrei in ein Bild umwandeln. Kennt jemand einen bewährten µC, der solche Ausgaberoutinen packt? Ich bedanke mich und wünsch Euch auf diesem Weg ein schönes Osterfest!! /Daniel
Sorry! Ich habe ihn versehendlich zweimal versendet. Vielleicht könntet Ihr den anderen Beitrag löschen? tut mir leid!
http://www.2cool4u.ch/tv_signal_measurement/tv_signale_grundlagen/tv_signale_grundlagen.htm In den Anhang habe ich PAL Signal gepackt. Wenn du dieses mit 16MS/s abspielst, bekommt du ein (mehr oder weniger) farbiges Bild mit 768x576 Pixel zu sehen. Ein (sinnvolles) PAL Signal kann man mit einem normalen uC nicht erzeugen. Das einzige was geht ist ein nicht so hochauflösendes SW Signal. Meistens wird dafür ein AVR verwendet, wie z.B. hier: http://www.serasidis.gr/circuits/colour_bar_gen/colour_bar_gen.htm
Sinnvoller ist es vielleicht, zunächst auf Farbe (PAL) zu verzichten und ein einfaches FBAS-Videosignal zu untersuchen. Das ist dann halt schwarzweiß. Bei der Google-Suche hilft dann vielleicht auch der Begriff "composite video"; das hier verwendete Videosignal ist nämlich aus der eigentlichen Bildinformationen und den Synchronisationssignalen (hsync, vsync) zusammengesetzt. Betrachtet man diese drei Teile getrennt, so erhält man etwas, was dem Videosignal an der VGA-Buchse von Computern gar nicht so unähnlich ist, mit den wesentlichen Unterschieden des Timings (viel höhere Zeilenfrequenz) und der Tatsache, daß das Halbbildverfahren (interlace) bei Computerbildschirmen glücklicherweise nicht mehr verwendet wird. Benedikt hat es -davon abgesehen- schon sehr gut auf den Punkt gebracht.
Es gibt VGA zu PAL/NTSC Chips. Als Eingänge das HSync/VSync und die analogen RGB Signale. Die Chips arbeiten mit 14.XXX MHz und erzeugen aus diesen Inputs ein PAL oder NTSC Signal. Wichtig ist aber das zum Unterschied zum echten VGA Signal dort mit Interlaced Video Frames gearbeitet werden muß die dann exakt mit 50/60 Hz arbeiten. Man kann sicherlich auch diese Arbeit durch eigene Chips erledigen lassen. Bei OpenCores gibts dazu glaube ich eine Umsetzung für FPGA's. Das Problem dabei ist die Codierung der sogenannten Color Burst am Anfang jeder Bildzeile. Dabei ist nicht so sehr die Erzeugung der analogen Burst das Problem sondern vielmehr deren Codierungen. Bei dieser Codierung müssen relativ komplexe Matrixberechnungen durchgeführt werden. Die wirst du auf einem "langsammen" AVR garantiert nicht umgesetzt bekommen. Gruß Hagen
"...zunächst auf Farbe (PAL) zu verzichten und ein einfaches FBAS-Videosignal..." Und ich dachte immer, das F in FBAS steht für Farbe? Wenn ich mich recht entsinne, bedeutet FBAS Farb-Bild-Austast-und Synchron(-signal). Dann wäre ein BAS-Videosignal schwarz/weiß, also nur Helligkeitsinformation (Bild) zusammen mit Austast-und Synchronsignal. Gruß Ingo
@Ingo: Das mag gut und gerne so sein, vor allem: Es klingt plausibel. Wer hat schon alle Akronyme parat?
g Warum liest du nicht die Links! Oben hat doch jemand das von der Wiki gepostet und in dem Link ist ein Link auf BAS: http://de.wikipedia.org/wiki/FBAS Was Ingo bestätigt.
Naja, es sollte auf keinen Fall besserwisserisch von mir klingen, ich hatte das halt noch so in Erinnerung. Leider kann ich zur eigentlichen Problemlösung nicht viel beitragen, muß aber Rufus recht geben, wenn er meint, erstmal mit einem einfachen s/w-Signal anzufangen. Es war zu Zeiten, als es noch keine Mikrocontroller gab zumindest mit ein paar TTL-ICs und minimaler analoger Technik möglich, ein einfaches, fernsehtaugliches Ping-Pong zusammen zu löten. Gruß Ingo
Das mit dem Ping-Pong hört sich sehr interessant an. Gibt es dazu eigentlich Beschreibungen im Internet?
Auch da kann ich nicht wirklich weiterhelfen. Meine Aussage zu diesem Ping-Pong-Spiel beruht nur auf einer dunklen Erinnerung :-) Es könnte eine entsprechende Bauanleitung mal Anfang der 80er Jahre im "Funkamateur" (DDR-Zeitschrift) gewesen sein, aber sicher bin ich mir da nicht. Ich kann mich zumindest erinnern, das mir das vom technischen Aufwand durchaus nicht zu umfangreich erschien. Preislich aber schon, zumal selbst einfache TTL-ICs wie 4-Bit-Dezimal/Binärzähler (D192/D193) 20 Mark oder mehr kosteten. Insofern war ein Nachbau für mich eh nicht im Bereich des möglichen. Gruß Ingo
Da gabs mal ein bausatz vom conrad (siehe conrad katalog 2003 seite 918) aber irgendwie gibts den nichmehr, jedenfalls was das der letzte überrest den ich finden konnte: http://kaufen.conrad.de/telespiel_bausatz-36.asp. Kannst ja mal beim C anfragen ob die dir die Anleitung als PDF schicken können. Ich hätte auch interesse. MfG Simon
Die heutigen Telespiele sind alle gleich: uC + Beschaltung, 2 Widerstände (um Spannungspegel für Sync, Schwarz und Weiß zu erzeugen) und das Benutzerinterface
Hallo! Erstmal danke für die vielen Antworten! Inzwischen bin ich bei der Suche nach passenden Controllern angelangt, also PAL/NTSC-Encoder, die interessant für mein Vorhaben wären. Vielleicht hat der eine oder andere schon mit diesen Komponenten gearbeitet... Was mich interessiert sind weniger die Chips, die in Echtzeit umrechnen. Besser wär ein Encoder mit integriertem RAM o.ä., der zunächst mit den Bildinformationen bespielt wird und sie dann dargestellt (wie z.B. bei OSD). Ich such noch weiter, aber vielleicht kann mir der eine oder andere seine Erfahrungen mitteilen. Vielen Dank!! /Daniel
Guck mal hier rein: http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=217 Da wird ein PAL BAS-Videosignal mit einem AVR Mega-8 erzeugt. MfG Willi
Hier geht's ganz ohne Halbleiter mit Pong http://www.cyberniklas.de/pongmechanik/ und hier mit PIC http://www.rickard.gunee.com/projects/video/pic/pong.php
Danke! Hab über meine Uni ne Menge Bastelmöglichkeiten, mag mich daher nicht mit S&W zufrieden geben. Ideal wär halt die Darstellung eines Speicherinhalts als Farbsignal im PAL- oder NTSC-Format. Sind aber trotzdem hilfreich die Links - zumindest um die Signale besser kennenzulernen. /Daniel
Hast du dir das Video im ersten Link angeschaut? Wenn das nichts zum basten ist.... Hammer g... finde ich
:)) Ja - nicht schlecht, aber das gibt es doch schon in Briefmarkengröße für's Handy. Ansonsten tendiere ich mehr dazu, mir einen Tischtennisschläger zu nehmen und ein 3D-Spiel an der frischen Luft zu genießen :)). Aber mal im Ernst - mich stört, dass die Darstellung ziemlich pixlich und in Schwarz-Weiß ist. Respekt vor denen, die Videosignale über ihren AVR (sozusagen von Hand) erzeugen. Aber mit einem entsprechenden Chip (Kosten schätze ich so auf 20 - zumindest, was ich bisher so gefunden habe) wird einem die Darstellung der Informationen im korrekten Format abgenommen. Was ich allerdings zu teuer finde ist die Voraussetzung eines zweiten Prozessors, der den Encoder auf gleicher Frequenz (also in Echtzeit) mit Daten versorgt. Ein Speicher im Encoder der halt kontinuierlich als Bild dargestellt wird, wär besser. Dann kann man auch einen langsamen µC davor setzen und bei Bildwechselwunsch den Speicher neu beschreiben. Hat jemand eine Idee, welcher Encoder für meine Zwecke gut ist? Im Prinzip möchte ich "günstig" ein Bitmap als OSD verwenden. Daaaanke!! /Daniel
Cool, danke! Ich denke, ich werde nicht drumherum kommen, einen µC im gleichen Takt mitlaufen zu lassen der das RGB-Signal liefert, oder? Ich danke Euch!
Mit einem AVR + PAL/NTSC Encoder wirst du da aber nicht großartige Auflösungen erreichen. Wir hatten erst letztens hier einen Thread der einen CPLD dazwischen setzt. Sprich ein CPLD + SRAM erzeugt kontinuierlich ein VGA Bild. Dessen RGB+HSync+VSync Ausgänge können nun direkt an einen Computer Monitor oder eben als Futter für einen PAL/NTSC Encoder dienen. Solltest du einen Monitor direkt anschließen so hast du enorme Freiheit mit dem Timing. In dem Thread habe ich auch einige Links zur Berechnung der Timings gepostet. Mit einem PAL/NTSC Encoder bist du eingeschränkter da du dort das Timing genauer einhalten musst. Mein derzeitiges VHDL für einen VGA Karte im CPLD benötigt ca. 144 Makrozellen. Am CPLD werden ein 256Kb SRAM und der AVR über das XMEM Interface angeschlossen. Es kommen also AVR's wie der ATMega162/128 etc in Frage. Der CPLD steuert den SRAM so an das der AVR und der CPLD selber quasi gleichzeitig auf den SRAM zugreifen können, sprich der AVR kann mit 0 Waitstate auf das SRAM zugreifen und der CPLD denoch im Hintergrund das VGA Bild erzeugen. Das Timing für den VGA-Part im CPLD kann durch den AVR programmiert werden, ebenso die Farbauflösung. Möglich sind 64 oder 16 Farben, 4 Graustufen oder Monochrome Farbauflösung. Soweit so gut, praktisch getestet habe ich das Ding allerdings noch nicht :-) Aber Ulrich Radig hat seine VGA Karte schon fertig und lauffähig, einfach mal in der CodeLib danach suchen. Das es schon fertige PAL/NTSC Encoder mit integriertem Display RAM gibt glaube ich nicht. Das wäre ja dann eine komplette VGA Grafikkarte in einem Chip. Gruß Hagen
Wow, das ist wirklich eine Antwort, wie man sie sich wünscht, danke. Muss jetzt erstmal die Informationsflut mit Hilfe von viel Kaffee verarbeiten :). Werd Euch entsprechende Fortschritte (sofern sie eintreten) hier veröffentlichen. /Daniel
Argh - hab in das Video vorhin nur hineingeschaut. Ist ja eine witzige Idee. Toll!
@Hagen: Wozu brauchst Du soviele Makrozellen? Ulrich kommt mit der Hälfte aus. Das soll jetzt keine Kritik sein; so eine Grafikkarte steht auch auf meiner TODO-Liste und da würde es mich halt schon interessieren. Insbesondere, da es den XC95144XL nicht im 44-poligen Gehäuse gibt. Markus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.