Hallo, ich fang gerade an ein Projekt zu planen welches ein Farbbild (bmp) auf dem TV ausgeben soll (FBAS) ich werde dazu 3x 8bit Flash oder eeprom benutzen - an deren Ausgang ein 8bit D/A wandler angeschlossen ist. Die Werte errechnet eine Software, welche vorerst auf nem PC laufen soll. die 3 analogwerte werden dann von einem RGB/PAL converter in FBAS gewandelt. Die syncronisationssignale werden ebenfalls im eeprom abgelegt, und über logische verknüpfungen erkannt (0V) Nun ist meine Überlegung ob ich die Palette im 8bit Bitmap-file nicht einfach ignorieren sollte, da der D/A wandler eh nicht mehr auflösen kann... BTW: für tolle ideen bin ich gerne zu haben
Ist das Flash schnell genug, um die Bildpunkte in Echtzeit auszugeben? Ich habe schon mal einen PAL-Farbbildspeicher mit Eprom gebaut und im "TV-Amateur" (www.agaf.de) veröffentlicht. Der hatte allerdings nur 8 Bit insgesamt, also je drei für Rot und Grün und 2 für Blau. als 3Bit-DAC hatte ich R/2R/4R Widerstände. Als PAL-Coder benutzte ich den fremdsynchronisierbaren TDA8501. Die Eagle-Files könnte ich hier mal uploaden.
Wenn du 3x8bit verwendest, dann hast du 24bit... Wieso nimmst du also nicht gleich 24bit BMPs ?
So sieht ein Testbildgenerator mit drei Flash aus
250 ist aber heftig. Da kann man sich gleich einen PC mit Grafikkarte und TVOut hinstellen. Der hat dann nicht nur 2 Bilder, sondern bis zu 25 verschiedene pro Sekunde...
So ein Testbild läuft beispielsweise auf der Amateur-Relaisfunkstelle Hornisgrinde im Schwarzwald auf 1278 MHz. Als zweiter Farb-Testbildgeber mit Wetterstations-Einblendungen ist ein alter ZX Spektrum am Werk. Außerdem gibts noch eine Außenkamera, die derzeit den Blick auf eine verschneite Winterlandschaft zeigt.
sorry! ICH HABE MICH VERTAN! natürlich bei 3x8bit=24bit wie blöd! da kann ich ja dann echt n 24bit bmp nehmen. Such grad noch nach ner einfachen basic-umgebung für blödis. PC-Programmierung mach ich nur wenns unbedingt sein muss :-)) zum testen kann man ja erstmal nen scart-tv nehmen, oder?
Ja, aber nicht jeder TV kann RGB... Wenn du 3x 512kByte verwendest, solltest du mit 13,1072MHz Taktfrequenz auf (sichtbare) 680x576 Pixel Auflösung kommen. Woher nimmst du diesen Takt ? Ich hatte bei meiner SW Version ziemliche Probleme, einen geeigneten Quarz dafür zu finden.
mmmhhh - syncronisation ist ja, wenn ichs richtig verstanden habe kommen die sync impule ja immer am anfang der zeile, bzw in zwischenzeilen die nicht angezeigt werden. eine zeile dauert dann immer 64µSec? bei 320x240 würde also dann ein pixel 52µSec/320pixel= 0,1625µSec dauern - da bräuchte man nen 6,1538 mhz takt. der einzig gängige quarz wäre dann aber 6,14 - also können wir nur 319 pixel darstellen, damit kann man leben, oder? Oder mach ich da jetzt nen denkfehler?
Beschreib doch mal genau was du vorhast, ich habe in der Richtung schon einiges gemacht, vielleicht kann ich ja bei der Schaltungsentwicklung etwas mithelfen. Generell gibt es zwei Möglichkeiten, um aus einem Speicher ein Bild zu erzeugen: a) Man speichert das Bild mitsamt Sync Signalen im Speicher. Dadurch geht zwar einiges an Speicherplatz verloren, aber man benötigt nur noch einen Adresszähler und hat am Ausgang schon das fertige Videosignal als Digitalsignal. b) Man speichert nur das Bild. Dadurch spart man einiges an Speicher, benötigt aber eine zusätzliche Logik (z.B. uC) der die Sync Signale erzeugt, solange die Datenausgabe vom Speicher stoppt und zu Beginn der nächsten Zeile wieder startet. Welches von beiden Verfahren möchtest du verwenden ?
Ich hatte an 1) gedacht. Zeitkritisches Programmieren ist mit bascom immer so ein kleines problem :-)) Weiss ned obs vielleicht Sinn macht, nen Flash zu verwenden und dort dann 3 "Images" abzulegen, welche dann einmal beim starten von nem µCOM in 3xSram gespeichert werden? - Dann könnte man den Flash über seriell mit hilfe des µcom bequemer programmieren
1/13,1072MHz = 76,3 nsec das wird für Flash schon etwas schnell, Eproms mit 70nsec Zugriffszeit sind jedenfalls selten
Also die Idee mit dem SRAM scheint nicht allzuschlecht zu sein, oder?
Wenn du das so machst, dann wird das nichts mit 240 Zeilen: Wenn man die Zeilenanzahl verändern will, muss man eine Zeile doppelt ausgeben, was dann wieder eine größere Menge an Logik erfordert, wenn man nicht 256 oder 512 Pixel pro Zeile verwendet.
@Christoph Kessler Die Angabe in den Datenblättern lautet maximal 70ns. Ein 70ns Flash schafft in der Praxis die 13,1MHz also ohne Probleme. Auch mit 90ns geht es bei den üblichen Raumtemperaturen.
mmhh also mit 680x576 hast du es schonmal ans rennen gebracht? hast du die sync - signale mit einer logik erzeugt oder auch in dem eeprom/flash abgelegt? ich will den schaltungsaufwand so gering wie möglich halten...
Angehängte Dateien:
-
tvbild.jpg
210 KB
Ich finde leider den Schaltplan nicht, aber mir mal ein Foto vom Aufbau: Links oben ein LC OSzillator als Quarzersatz für die 13,1MHz, darunter der Synchronzähler für die 19bit Adresse. In der Mitte der 512kB Flash Speicher, daneben ein Latch für die Daten und der DAC. Darüber noch ein Videodetektor und darunter ein Videotreiber mit Umschalter der automatisch auf den Videoeingang umschaltet, sobald ein Videosignal anliegt. Ansonsten kommt ein nettes Testbild. Das ganze war als FBAS gedacht, funktioniert aber aufgrund der mangelnden Samplerate nur als superscharfes BAS Signal. In dem Flash ist ein Vollbild des Videosignals mitsamt aller notwendigen Infos (Sync, Farbburst usw.) enthalten. Für ein Farbbild müsste man entweder die Samplerate erhöhen, oder man verwendet 2-3Flash Speicher. Den Sync könnte man als 1 bit ausführen, so dass immer noch 15 oder 23bit für die Farben bleiben. Die RGB Infos und das Sync Signal kommt dann in einen RGB-FBAS Converter. Da die Horizontalauflösung eines TVs nicht so gut ist, könnte man 256kB Speicher verwenden und hätte so 340x576 was immer noch ein gutes TV ergibt.
ich denke die variante mit 2-3 flash-speicher ist echt okay. wenn die spannungsversorgung einigermaßen stabil ist, kann man sicher ein widerstandsnetzwerk als d/a wandler nehmen. du hast einen cpld als binärzähler programmiert.. mhh das spart ne menge platz. und man könnte damit aus einem viel höheren takt mit einigen zählern etc den geeigneten takt auszählen, oder?
Ja, genau das war der Grund warum ich den CPLD genommen habe: Den Takt hätte ich eventuell teilen können, falls ich einen Quarz gefunden hätte, der irgendein Vielfaches von 13,1 bzw. 6,55MHz hat. Außerdem hätte ich für 19bit 3x 8bit Zähler HC590 o.ä. gebraucht die dazu eventuell nicht ganz synchron sind usw. Also einiges mehr an Aufwand und nicht so flexibel.
mit cpld hab ich mich noch gar nicht auseinandergesetzt.... das werde ich mir wohl erst noch aneignen dürfen... gibts da software wo man éinfach logische verknüpfungen zusammenfügen kann? Ist schon halbwegs wichtig, dass man ein bauteil hat, was ne höhere frequenz abkann... und cplds sollen das wohl... wenn wir 3x8 bit machen, kann ich ja einfach die bytes direkt auslesen aus dem bitmap.. hab mir mal ne qbasic besorgt und mach grad n bisschen mit datei lesen rum...
So. Habe mir mal ein testbild gemacht. Die Pixelfarbenreihenfolge scheint B G R zu sein. Jetzt schau ich mir mal die Sync. an...
Hier mal mein BMP -> (F)BAS Konverter für QBasic.
so ähnlich habe ich jetzt auch angefangen.... wie denkst du machen wir das mit dem D/A? ganz normal an 5V und dann mit nem 1/5 teiler auf 1V teilen? Meine nächste überlegung zielt auf die sync - pulses... ein extra eeporm wär ein bisschen doof und außerst übertrieben. ein - zwei bit dafür nehmen - reicht das aus? also haben dann zwei farben nur 7 bit. das wäre denke ich am akzeptabelsten - weil man dann nicht grossartig mit verknüpfungen arbeiten muss...
Es reicht sogar 1 bit, denn man braucht ja nur Composite Sync: Composite Sync erhält man, wenn man V und HSync XOR verknüpft. Ist dann zwar kein echtes BAS Signal, aber gut genug für 1 Halbbild. Will man dagegen beide Halbbilder verwenden, muss das Sync Signal etwas aufwendiger berechnen, so wie in meinem Programm. Hier ist alles genau beschrieben: http://www.2cool4u.ch/tv_signal_measurement/tv_signale_grundlagen/tv_signale_grundlagen.htm Als DAC verwende ich einen TDA8702. Am Anfang hatte ich einen R2R DAC mit Emitterfolger als Endstufe verwendet. Am Ausgang dann einen Spannungsteiler um auf die 0,7Vss zu kommen.
der TDA8702 geht mit 75 Ohm intern nach +VccA, deshalb braucht man noch einen großen Koppel-C und evtl. Klemmdiode. Ja Qbasic war noch eine einfache Programmiersprache, da werden noch keine Witwen und Waisen eliminiert und Töchter enterbt oder wie das heutzutage objektorientiert heißt
mit diesen sch**** sync signalen. ich les es mir grad zum 80sten mal durch - aber es will ned in meinem kopp. h-sync ist mir klar 1,5µsec 0,3V dann 4,7µsec 0V dann 5,8µsec 0,3V dann gehts weiter.. Aber V-Sync? resignierendes kopfschütteln also vor/nachtrabanten sind da, um jeweils die halbe zeile auszugleichen?? und die hauptimpulse sind immer gleich. ODER BIN ICH ZU BLÖD?
Über Sync-Signale gibts die ausführlichen Informationen im Datenblatt zum Philips Syncpulsgenerator SAA1101. Das sind "amtliche" Timings für höchste Ansprüche: http://www.semiconductors.philips.com/pip/SAA1101_CNV_2.html Er wird nicht mehr produziert, aber das Datenbaltt gibts noch, ich meine von meinen Namensvettern www.kessler-electronic.de habe ich ihn damals bezogen.
Danke für den link. habe mal in der bücherecke gekramt... da habe ich ein buch von 1955 gefunden - jedenfalls ist die auflage damals erschienen. da ist es ähnlich erklärt... Also geht das eigentliche bild erst ab der 7. Zeile los -bzw das 2te halbbild in der 8ten zeile? MMHH mal schauen ob ich da was mit nem AVR und BASCOM (nicht lachen) anrichten kann.. wenn ich den austastimpuls für das erste halbbild nach 100zeilen schicke, dürfte er ja nur ungefähr die erste hälfte des Bildschirms beschreiben??
SO: habe jetzt mal ein wenig geschmökert ;-)) ich habe mich fpr ein 4,9152Mhz Quarz entschieden, gibt es auch als quarzoszillator. bei 52µsec bildinhalt hätte ich ca 254 bildpunkte pro zeile. D.H ein Bildpunkt würde 0,2034µsec. dauern - damit bekommt man auch 1,5µsec für den horizontal - sync aufgelöst. Zum testen werde ich ein S/W bild bauen, welches nur die hälfte der Zeilen (ungerade) des Fernsehers nutzt. Da komme ich erstmal mit nem 128k eeprom klar... Wenn das läuft werde ich volle auflösung und dann Farbe in angriff nehmen...
Wie steuerst du den Speicher an ? Wenn du nur einen einfachen Adresszähler dranbaust, dann wird das Halbbild 416 Zeilen lang. Macht ziemlich genau 37,5fps, das ist etwas zu wenig für einen TV...
mmhh also binärzähler und dann reset durch &gatter bei zeile 313... hatte ich gedacht. habe keine cpld-kenntnisse.
Angehängte Dateien:
-
vsync.gif
4,3 KB
Hallo lang lang ists her... Ich habe jetzt eine ähnliche software mit TP zum laufen gebracht, da finde ich den Dateizugriff einfacher. nur mit den pixeln bin ich mir noch nicht ganz einig geworden. ich will erstmal bei s/w bleiben, und frage mich gerade ob ich bei 240 zeilen bleibe oder 576 wie das eigentlich sollte vorziehe? also einen 29f040 hab ich bereits bestellt... als zähler werden erstmal hc161 herhalten auf meinem steckbrett.. Nun meine frage.. Ich erzeuge die signale im anhang als vsync.. danach sende ich einfach 576 zeilen mit hsync am anfang? oder muss ich die entsprechenden signale für das andere halbbild senden?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.