ATMega32 16 MHz PAL mit Farbe ohne externen Chip

Hier ist ein Telefunken PALcolor Farbfernsehgerät mit dem Signal, sowie 
ein chinesischer Monitor mit Colorast Einstellung.

Zum Inhalt des Testmusters.
Das Gitter ist für Geometrie, braucht man heute nicht mehr wirklich oft.
Die Farbbalken sind nach EBU Norm mit 75% Helligkeit.
Die Grauflächen sind für die Linearität
Dann kommt die Bildmitte, immer wieder ein beliebter Hingucker.
Dann kommt ein Multiburst mit 1 MHz, 2MHz, 3MHz, 4 MHz, 4,43 MHz und 
4,89 MHz. Die letzten 3 Muster sind praktisch wenn man bestimmen will 
wie symmetrisch der Frequenzgang des Filters für die Farbe ist. 4 MHz 
und 4,89 MHz liegen gleich weit weg vom Träger und sollten somit 
ähnliche Cross Colour Störungen hervorrufen.

Das Signal ist natürlich noch keinesfalls normgerecht, aber gut genug 
dass zumindest meine beiden Geräte was damit anfangen können. Aber es 
ist schon erstaunlich was man mit so wenig machen kann.

Neue Version, jetzt mit 16 Zeichen Text.
Einfach über die serielle Schnittstelle mit 9600 bps schicken. Alle 
Zeichen <14 schicken den Cursor nach links. Geht man über den Rand 
hinaus, fängt er vorne wieder an.

Das dürfte grob jetzt am oberen Rand dessen liegen was der Controller 
diesbezüglich kann. Man kann vielleicht noch ein paar Kilobyte Speicher 
einsparen, aber für neue Zeilen in Farbe reicht das nicht wirklich.

Hier jetzt die Fotos.

Der Text wird übrigens am MOSI ausgegeben.

a) keines. Die Pascalprogramme erzeugen Assemblercode. Als 
Pascal-Compiler habe ich den freepascal Compiler verwendet.

b) Mach ich so bald ich daheim bin.

Hier ist der Schaltplan. Die Werte sind hier gerechnet. Ich habe den R2R 
Wandler mit 120 und 240 Ohm aufgebaut. Dann stimmen aber die Pegel nicht 
was aber trotzdem funktioniert. R6 müsste ich noch bestimmen. Er müsste 
den Ausgangspegel um 0.7 V hochziehen.

R13 habe ich in der Praxis noch nicht ausprobiert. Ich habe aber noch 
das Problem, dass die Texteinblendung (SPI) nach dem Poweron Reset nicht 
funktioniert, nach einem normalen Reset aber schon.

Zur Software:
signalerzeugung/makesignals (Pascal) erzeugt die Daten für die Zeilen 
welche in samples.inc gespeichert werden.
makeimagecode (Pascal) erzeugt die Datei image.inc aus der Datei 
testimage.txt in der drin steht welche Zeilen man wo haben will. Das 
Programm kümmert sich, zur Zeit, auch darum, dass die richtigen Phasen 
ausgegeben werden.

generator.asm ist das eigentliche Assemblerprogramm.
seriell.inc sind die Routinen für die serielle Schnittstelle. Diese 
werden über ein Delay immer dann aufgerufen, wenn grad mal Zeit ist.

samples.inc enthält die von makesignals erzeugten Zeilen. Diese werden 
durch delays RLE-kodiert und belegen somit weniger Platz.

In meiner lokalen Version ist jetzt auch ein Zeilenpaar mit Abwechselnd 
U+- und V+- drin um Pal-Decoder zu testen. Ich hoffe durch Optimierungen 
jetzt im Urlaub auch noch ein zweites Zeilenpaar zu schaffen, dann sieht 
das noch mehr nach FuBK aus.

Hier ist die aktuelle Version. Einiges hat sich geändert. Es gibt jetzt 
eine Tabelle namens "image" welche ein Byte pro Bildzeile enthält. Diese 
Tabelle wird mit Hilfe des Programms "makeimagecode" erstellt. Der 
Inhalt $ff bedeutet dass wieder am Anfang angefangen wird.

Der Zähler linecounter zählt von 0-3 durch. Je nach Zählerstellung wird 
die entsprechende Zeilenroutine aufgerufen. Das ist wichtig für die 
Bursts.

Hier noch das Foto. Im Code gab es ein noch ein kleines Problem mit der 
seriellen Schnittstelle. Die wird während Delays abgehandelt.

Das aussehen kann man über die Datei testimage.txt ändern.

Hier die aktuelle Version. Das Bild ist besser und man kann jetzt den 
Anfangstext in der generator.asm einstellen.

Was jetzt neu ist, ist dass das Farbsignal gefiltert ist, und auch ein 
Dithering das Quantisierungsrauschen versteckt. Das muss ich eventuell 
noch mal optimieren.

Hallo Christian,

Danke, werde ich mal testen.

Pascal ist lange bei mir her, wo gibts denn den Compiler ?

Ich nehme da den Freepascal Compiler für die Programme, die die Signale 
berechnen. Den gibts unter Freepascal.org
ggf. musst Du die Datei "macheinfach.sh" für Dein Betriebssystem 
abändern.

Der Rest ist ganz einfach AVR Assembler, kompiliert mit dem AVRA.

Ich sollte vielleicht wirklich mal einen Artikel darüber schreiben.

Ach ja, wenn Du das nur mal ausprobieren willst, es gibt da die Datei 
generator.hex. Oder Du assembelst einfach die generator.asm

Guten Morgen Christian,

ich hatte erst nach meiner Nachricht mir das ZIP File angesehen und dann 
auch die Compiler/ Assembler unter Linux/ Ubuntu ausgemacht.

Das System nutzte ich auch - danke.

Hier mal das ganze als Artikel

http://www.mikrocontroller.net/articles/PAL_Testbildgenerator

Danke. Ich habe jetzt den Artikel noch erweitert. Auch mit ein wenig 
Ausblick.

Man könnte beispielsweise noch mehr Bilder machen. Beispielsweise ein 
Gittertestbild, oder auch einen Konsolenmodus mit 40x25 Zeichen oder so.

Kreise sind im Fernsehen immer schwierig zu machen. Dadurch dass ich ja 
die Zeilen abspeichere könnte ich keine Zeilen neu verwenden.

Ich könnte aber hypothetisch die Zeilen in mehrere Teile unterteilen, so 
dass ich links und rechts jeweils einen unbunten Anteil habe in dem sich 
auch der Kreis befindet. Der sollte dann nicht so viel Platz im Flash 
brauchen.

Vielleicht wenn ich das mal neu implementiere. Muss ich mir mal 
überlegen.

Hallo,
ich habe das Projekt auch nachgebaut, jedoch keine passende Widerstände.
Deshalb bin ich hingegangen und habe z.B. für die 375 Ohm Widerstände 2 
Widerstände in Reihe geschaltet. In meinem Fall wären das 360 Ohm und 15 
Ohm, ergibt zusammen 375 Ohm.
Das habe ich mit allen so gemacht, bis außer R13 mit 10 kOhm.
Den Atmega32 hab ich mit der "gerator.hex" beschrieben und die 
entsprechende Fuse-Bits für das 16Mhz Quarz eingestellt. Das Quarz 
schwingt auch, da ich im Betrieb an XTAL1 ungefähr die Hälfte von den 5v 
Vcc habe.
Aber ich bekomme einfach kein Fernsehbild hin. Man kann lediglich ein 
Flimmern erkennen (im Anhang zu sehen).
Das seltsame ist, dass ich das nur an der TV-Karte sehe. Am Fernseher 
war das Bild Schwarz.
Weiß vllt jemand von euch woran das liegt?

Also an den Widerständen liegt es höchst wahrscheinlich nicht. So weit 
wie ich Dich verstanden habe hast Du kein Oszilloskop zur Verfügung.

Miss vielleicht mal an PA0-PA4, da solle überall so grob die halbe 
Versorgungsspannung herauskommen. Auf PB5 fast die volle 
Versorgungsspannung.

Ich vermute ja, dass Dein Quarz trotzdem nicht richtig schwingt.

Das das Bild unterschiedlich aussieht ist normal, da Du ja 
wahrscheinlich korrektes Videosignal hast.

In den letzten Satz bitte "kein" einfügen.

Wie du schon vermutet hast, besitze ich kein Oszilloskop. Könnte man 
damit nachmessen ob der µC schwingt?
Ich habe jetzt mal die Messungen durchgeführt und die stimmen gar nicht 
mit den von dir vorgegebenen Werten überein:

No  DC/AC  Value  Unit
PB.5  DC  0.8620  V
PA.0  DC  0.0430  V
PA.1  DC  0.0746  V
PA.2  DC  4.872  V
PA.3  DC  4.878  V
PA.4  DC  4.822  V
PA.5  DC  4.990  V
PA.6  DC  0.7600  V
PA.7  DC  4.995  V
AREF  DC  0.7344  V
GND  DC  0.0000  V
AVCC  DC  5.025  V
XTAL2  DC  2.559  V
XTAL1  DC  2.393  V

Ich habe auch hier im Board gelesen, dass der Quarz vllt mit einem 
Widerstand von OC2 nach +5V schwingt. Das hat bei mir jedoch auch keinen 
Erfolg gebracht. Ich habe einen 18 kOhm Widerstand verwendet. Es hieß 
man sollte einen Widerstand von 15 bis 22 kOhm verwenden.

Hmm, die Spannungen schauen alle sehr merkwürdig aus.


Leg mal /Reset mit einem Widerstand auf die positive 
Versorgungsspannung. Vielleicht ist er nur einfach ständig ge-resetet.

Hast Du eigentlich PB.5 getrennt als Du das Teil programmiert hast? Wenn 
das noch angeschlossen ist, kann der IC in der Regel nicht programmiert 
werden.

beim Programmieren verwende ich immer das myMultiProg MK1-Board. Ob da 
PB.5 anliegt, muss ich später mal schauen. Auch der Tipp mit Reset 
probiere ich heute Abend mal aus.

OK R6 hat bei mir glaube ich 185 Ohm oder so, der Wert ist unkritisch.

Der Widerstand hängt an MOSI, damit der SPI die Bits raus schieben kann. 
Das ist nur für die Texteinblendung notwendig. Wenn man keinen Text 
haben will, dann kann man den Widerstand auch raus lassen.

Ohne SPI würden die Zeichen breiter werden, da man dann manuell schieben 
müsste. Da man vor und nach dem Text nur bedingt Zeit hat, wird das 
relativ aufwändig.

Das Problem ließe sich übrigens sauber lösen, in dem man ein Logikgatter 
als Buffer verwendet.

Also um es noch mal deutlich zu sagen, R6 kann man auch raus lassen, das 
ist sinnvoll um die Schaltung programmieren zu können. Der einzige 
Unterschied ist, dass man dann keine Texteinblendung haben kann.

@Christian Berger:
Die Idee mit dem Reset hat nicht funktioniert. Ich habe einen 10 kOhm 
Widerstand verwendet. Beim Programmieren, nehme ich den µC aus der 
Schaltung heraus und setze ihn auf das oben genannte Programmier-Board. 
Ist dieser Vorgang richtig, oder muss ich in der Schaltung den µC 
Programmieren?

@Koi:
Den R6 habe ich nicht eingebaut. Wie Christian Berger meinte, ist dieser 
Widerstand nicht zwingend notwendig.
Als Software habe ich die ganze Zeit "Basecom-AVR" Software von MCS 
Electronics verwendet. Dort kann man auf "Manuell Programmieren" gehen 
und dann die hex datei in den Buffer laden gefolgt vom Beschreiben des 
µC.
Dann habe ich die Software "myAVR Workpad Plus" Demo verwendet. Dort 
wird nach dem Brennen angezeigt, dass alles Ok war.

Ja, den extern zu programmieren passt schon. Setzt doch mal die Fuses 
auf den internen RC-Oszillator. Dann läuft er zwar nur mit 8 MHz, das 
sollte aber mal zum probieren reichen. Auf dem Fernsehgerät solltest Du 
damit zumindest ein Geflimmer bekommen, vielleicht sogar schon ein 
kaputtes Bild.

Hast Du vielleicht ein Radio welches Du auf 16 MHz SSB einstellen 
kannst? Da solltest Du dann das Pfeifen des Oszillators hören, wenn Du 
ein Stück Draht an den Quarz machst.

Es ist noch hinzuzufügen, dass wenn ich die Spannung an die Schaltung 
anlege, der Bildschirm ganz kurz weiß aufleuchtet und dann direkt danach 
weiterhin schwarz ist.

Also das kurze Aufblitzen muss nichts bedeuten.

Ich habe die Fusebits auf 100100 gesetzt. Also Int.RC Osc. 8MHz; Startup 
time: 6CK + 64ms.
Ich sehe aber nach wie vor kein Fernsehbild.

OK was kommt dann, kommt Geflimmere? Kannst Du vielleicht einen 
Kopfhörer an den Ausgang schließen? Du solltest ein Brummen hören.

kein Flimmern zu sehen. Ich erkenne ledeglich schräge schmale Balken 
welche sich in unabhängigen Zeitabständen an die Linke 
Bildschirmoberkante bewegen, dann kurz stehenbleiben und sich dann 
schnell nach unten an die rechte Bildschirmunterkante bewegen. Dabei 
bleiben sie manchmal stehen. Manchmal werden sie so schnell, dass sie 
verschwinden und nach einer Zeit wieder auftauchen.
Wenn ich den Kopfhörer an die Anschlussklemmen halte, hört man beim 
anlegen ein lautes Klopfen und ganz leise ein leichtes Brummen.

Hmm, also ich bin am Ende meiner Weisheit angelangt. Ich vermute, dass 
das Programm mit dem Du das brennst irgendwas ungewöhnlich macht. Wie 
lange dauert denn das Flashen? Es sollte so grob eine halbe Minute 
dauern. Also länger als ein paar Sekunden.

Jo so lange dauert es bei mir auch.
Da sind ja 2 hex Dateien. Nämlich "generator.eep.hex" und die 
"generator.hex".
Ich verwende die "generator.hex". Das ist doch die richtige oder?
Ansonsten würde ich sagen, ist vllt der µC defekt.
Noch ne Frage:
Die eingezeichnete Widerstände, wo gibts die zu kaufen, da diese ja 
nicht unter die E-12 Reihe fallen? Ich habe mich im I-net schon dumm und 
dämlich gesucht.

Ja, die ohne eep ist richtig, die andere braucht man nicht.

Die genauen Werte der Widerstände sind egal, das ist halt ein R-2R 
D/A-Wandler. Da könnte man auch einen fertigen IC verwenden. Das Design 
ist eine simple Skizze.

Wenn die Werte ungenau wird, hat man halt mehr oder weniger 
Quantisierungsrauschen.

Es kann auch sein, dass der Mikrocontroller kaputt ist.

Wenn der kaputt wäre, wäre das ziemlich blöd, da ich das Teil extra für 
dieses Projekt (neu!) gekauft habe.
Wie kann man so ein Teil auf defekte überprüfen?
Ansonsten kaufe ich demnächst mal einen neuen und werde mal schauen, ob 
der funktioniert und werde mich dann noch mal melden.
Vielen Dank für eure superschnelle Mithilfe!

Bastian Urschel schrieb:
> Wenn der kaputt wäre, wäre das ziemlich blöd, da ich das Teil extra für
> dieses Projekt (neu!) gekauft habe.
> Wie kann man so ein Teil auf defekte überprüfen?

Probier mal so ein ganz simples Blink-Programm da drauf.

Ich werd verrückt! Der Atmega32 funktioniert beim Blinkprogramm. Warum 
funktioniert der bei dem andern net?!

Assemble die generator.asm-Datei mal selber.

Ich muss sagen, dass ich mich zugegeben mit Deiner etwas exotischen 
Software nicht auskenne. Ich nehme halt einfach avra als Assembler und 
avrdude als Flasher.

Bin momentan sehr im Stress. Deshalb werde ich den Vorschlag iergendwann 
mal durchführen. Vielen Dank!

So weit wie ich weiß ganz einfach auf externen Quarz 16 MHz, der Rest 
dürfte ziemlich egal sein. Natürlich sollte man den ISP nicht 
abschalten, sonst kann man das Teil nicht mehr neu flashen.

Da ist übrigens noch ein Fehler im Signal. Ich habe aber eh vor das mal 
neu zu machen. Vermutlich dann mit einem ATMega64 mit 20 MHz.

Naja, die neue Version wird nur noch in der ISR zeitkritisch sein. Das 
Hauptprogramm kann dann in jeder beliebigen Sprache geschrieben sein.

Durch die höhere Abtastrate von 20 MHz kann man dann auch besseres 
Dithering machen.

So bald ich mal gleichzeitig Zeit und Lust habe, und mir über die Detail 
im Klaren bin. :)

Hallo Doc,
darf ich fragen wie du bei der ganzen Sache vorgegangen bist?
Bei mir klappt das Projekt immer noch nicht.
Hab aber noch nicht alles ausprobiert.

gruß baschdi

Ahh, hast Du so einen seltsamen Assembler. Ich benutze ganz einfach den 
avra.

Hast Du da VMS? Davon habe ich quasi keine Ahnung. Ich bin eher der 
unixoide Typ.

Ich probiere das mal mit avra aus, dauert aber noch ein paar Stunden, 
weil die Linuxinstallation gerade läuft.
Das heißt also du rufst einfach das Shell Skript macheinfach.sh auf und 
dann läuft alles automatisch ab?

Ja, das kompiliert auch die Pascalprogramme mit dem Freepascal Compiler. 
Nur brennen tut es nicht.

Und die Fusebits müssen dann auch noch gesetzt werden oder?

Also die Fusebits wie schon gesagt so einstellen, das er vom externen 
Quarz mit 16MHz läuft.

Das Auskommentieren ist schon OK.

Also, ich wollte die macheinfach.sh ausführen aber dann kommt immer
"macheinfach.sh: 2: ppcx64: not found".
Woran kann das liegen? fpc und avra habe ich bereits installiert.

Gruß Baschdi

Ahh Du hast keine x64 Architektur, ersetze da einfach ppcx64 durch 
ppc386

Achso! Da hätte ich auch drauf kommen können ;)
Also es wurden keine Fehler zurrückgegeben.
Das bedeutet also, dass ich jetzt die Datei "generator.hex" auf den 
ATmega32 flashen kann?

Sollte eigentlich funktionieren.

Was muss ich eigentlich bei avrdude alles als Parameter angeben?
Ich verwende mittlerweile ein Pollin Atmel-Evalutions-Board Version 
2.0.1 welches am COM1 angeschlossen ist.

Boah, keine Ahnung.

Ich glaube, wenn meine Notizen richtig sind:

avrdude -p m32 -sponyser -P /dev/ttyS0 -U lfuse:w:0x7f:m -U 
hfuse:w:0x99:m

Ich habe den ATmega32 jetzt mal geflasht und es funktioniert trotzdem 
nicht.
Ich glaube es liegt jetzt definitiv am ATmega.
Ich werde demnächst dann mal einen neuen kaufen.
Vielen Dank nochmal für eure Mithilfe!

Doc schrieb:
> Immer beim Einschalten des Schaltung tritt das Problem auf, daß der Text
> nicht angezeigt wird. Bei einem erneuten aus und wieder einschalten wird
> der Text dann dargestellt. In einigen Fällen wird der Text aber nicht
> korrekt dargestellt, sondern durch Maschinencodezeichen ersetzt.

Im Schaltbild fehlen die Abblockkondensatoren und die RESET-Beschaltung. 
Das solltest Du nachrüsten.

Ahh das liegt dann noch am SPI. Ich glaube Du musst da noch einen Pin 
auf Masse legen damit der SPI funktioniert. Das steht im Datenblatt des 
Controllers.

Da solltest Du quasi jeden D/A-Wandler nehmen können, der einen 
parallelen Eingang hat.

http://www.mikrocontroller.net/articles/Standardbauelemente#DAC

Wenn Du es ganz gut haben willst, kannst Du auch noch einen Tiefpass 5 
MHz dahinter setzen.

Da ist eh noch ein Fehler drin, auf manchen Fernsehgeräten gibts kein 
Farbbild.

Bekanntes Problem (mit der Farbe). ich glaub die Zeilen sind zu lang 
oder zu kurz. Dass das vorher geklappt hat war mehr oder weniger Zufall.

Hast Du Deinen Terminmalemulator auf 9600 bps 8 bit eingestellt?

Hallo,
ich bin endlich nochmal dazu gekommen die Schaltung nachzubauen.
Das Resultat: sie funktioniert. Im Grunde habe ich nichts geändert. 
Später ist mir jedoch aufgefallen, dass ich statt der ersten Schaltung 
einen von der Bauform höheren Quarz und 2 Keramikkondensatoren von einer 
anderen Bestellung verwendet habe.

Es muss also an dem Quarz oder an den 22pf Kondensatoren gelegen haben.
Danke für die nette Hilfe und das tolle Projekt.

Ich liebe es wenn ein Plan funktioniert ;)

Gruß
Bastian Urschel

Die Synchronsignale werden genau so erzeugt wie das Bild. Sprich mit OUT 
PORTA,r0

Brauchst Du dafür ein komplettest "Blackburst" Signal, oder reicht es 
auch ohne Farbe?

Schau mal hier:
Beitrag "AVR ASCII Video Terminal  - 40 x 25  - BAS Signal"

Da kommt das Synchronsignal getrennt über einen anderen Pin als das 
Bildsignal.

Das Programm da drüben ist nicht von mir, und bei meinem kann man das 
nicht wirklich brauchbar trennen.

Das Problem ist, dass Du Dein Problem nicht verständlich formuliert 
hast. Du scheinst, wie so viele hier, Dein Problem nicht verstanden zu 
haben.

Wenn Du analoge Fernsehtechnik kennst, dann brauchst Du doch nur einen 
Synchrongenerator schreiben. Das geht mit den Timern im PWM-Modus ganz 
gut. Oder Du nimmst einen Zähler und ein paar Gatter.

Du hast das vermutlich mit Schleifen in Bascom gemacht. So funktioniert 
das nicht. Du müsstest das mit Timern machen. Wie schon gesagt der 
PWM-Modus eignet sich dafür. Zum Beispiel kannst Du zum Anfang jeder 
Zeile eine ISR aufrufen lassen, die dann den PWM für diese Zeile setzt, 
meistens muss der da nichts machen, nur bei der vertikalen 
Synchronisation muss sich die ISR um die Trabanten kümmern.

Aber ich glaube Du bist da besser aufgehoben in dem Du 2 Mikrocontroller 
nimmst.

Wenn Du aber ohne eigene Arbeit eine fertige Lösung haben willst, die 
genau Deinen Anforderungen entspricht, gibts hier bestimmt viele die so 
was machen. Das kostet halt dann Geld.

Mal eine ganz dumme Frage: Warum funktioniert das eigentlich mit einem 
16 Mhz Quarz? Die Frequenz des Farbträgersignals ist doch 4.43 MHz? Das 
passt irgendwie nicht zusammen.

Die Zeile wird schon vorher berechnet, da ist es relativ wurscht wie das 
genaue Verhältnis von Abtastrate zu Frequenz ist.

Christian Berger schrieb:
> Die Zeile wird schon vorher berechnet, da ist es relativ wurscht wie das
> genaue Verhältnis von Abtastrate zu Frequenz ist.

Bei 16Mhz schaffst Du doch selbst im besten Fall kein zweifaches 
Oversampling. Das Aliasing muss schrecklich sein. Ich finde es 
erstaunlich, dass es funktioniert.

Klar, das Alisasing ist schlimm, aber durch die krummen Frequenzen 
verteilt sich das schon. Das Quantisierungsrauschen durch die 5 Bit ist 
deutlich höher.

Das Quantisierungsrauschen sollte im Bezug auf das Bild aber stationär 
sein, während das Aliasing wahrscheinlich für Flackern sorgt? Ich muss 
es wohl selbst einmal ausprobieren.

Naja, ich dithere ja, somit flackert das ein wenig, das ist aber nicht 
wirklich schlimm. Die Frequenzanteile über 5MHz sieht man eh nicht, 
evtl. kann man da auch einen Tiefpass dran bauen.

Wofür ist denn dieses gewurschtel mit unterschiedlichen Burst-Frequenzen 
notwendig?

1

  mbburst(550,590,2e6);

2

  mbburst(600,640,3e6);

3

  mbburst(650,690,4e6);

4

  mbburst(700,740,4.443e6);

5

  mbburst(750,790,4.886e6);

Für die Multiburst Sequenz. 2 MHz, 3 MHz, 4 MHz, 4,443 MHz und 4,883 
MHz. Die 3 letzteren sind einmal 440 kHz unter der 
Farbunterträgerfrequenz, dann die Farbunterträgerfrequenz und dann 
darüber. Damit kann man gut feststellen ob der Kanal den Farbunterträger 
einseitig beschneidet.

Leider nicht, bin in letzter Zeit noch nicht dazu gekommen.

Christian, ein tolles Projekt, Respekt !

Hab mal die Schaltung aufgebaut, sie lief sofort.

Daraufhin untersuchte ich das PAL / FBAS Signal per Oszi und verglich es 
mit dem Ausgangssignal einer kleinen CMOS-CAM.

Der BURST sieht bei Dir etwas verwurschtelt aus, dennoch kommt mein
billig-Monitor gut damit zurecht.

Ich dachte immer, der BURST muss sehr sauber generiert werden, damit die 
TV-Geräte den Farbdecoder vernünftig synchronisieren können.

Kann es sein, dass die Qualtät des Burstes nicht von großer Bedeutung 
ist?

Bernhard


Anmerkung:


Das R2R Netzwerk bestückte ich mit 1k/2k Widerständen, desshalb stimmt 
der Pegel nicht ganz.

Nur der Anteil des Bursts bei der Farbunterträgerfrequenz ist relevant. 
Der kann durchaus ein wenig verzerrt sein, bzw auf anderen Frequenzen 
Rauschen haben. Es geht ja nur um die Phase.

Dieses kleine Assemblerprogramm testet das R2R Netzwerk für dieses 
Projekt.

Es entstehen treppenförmige Sägezahnimpulse (s.Bild 
"R2R_SAeGEZAHN.jpg").

Gemessen wurde am Netzwerk mit 100/200 Ohm Widerständen (R12=39 Ohm und 
angeschlossenem Monitor).

  .
Bernhard

Christian, ich bin untröstlich !

Dein BURST sieht doch relativ vernünftig aus (für einen 5-BIT 
DA-Wandler), Wie konnte mir dieser Fauxpas nur passieren?

Ganz einfach, ich hatte das FBAS Signal nicht am richtigen Punkt des R2R 
Netzwerkes abgegriffen.

Der R2R-Tester (s.oben) brachte die Wahrheit ans Licht, bzw. auf den 
Monitor.

Muss mich an dieser Stelle ganz offiziell und in aller Form bei Dir 
entschuldigen.


Bernhard

PS: Die beiden Bilder zeigen deutliche Farbunterschiede, es gibt eben 
billige und auch preiswerte Monitore.

Den weißabgleich habe ich versucht so optimal wie möglich an der CAM 
einzustellen.

Ja, da ist sogar noch ein Bug in der Software, die Zeilen haben die 
falsche Länge, somit gibt es PAL-Dekoder die das Signal nicht als 
Farbsignal erkennen.

In die 32 Kilobytes passt kein Bild. Deshalb funktioniert das Programm 
auch mit einzelnen gespeicherten Zeilen.

Hallo,

habe meine ersten Gehversuche in Atmel programmieren mit Christians 
Anleitung hinbekommen. Es funktioniert. Ich wollte nun den Text mal 
ändern im Testbild, nur das bekomme ich nicht hin. Ich habe das Hexfile 
in Bascom geöffnet und es in den AVR programmiert.
Um den Text zu ändern wollte ich die .asm laden..Text ändern und das 
erzeugte hex File wieder zurückspielen. Leider bringt Bascom 33 
Fehlermeldungen im Error Fenster unten.
Geht das überhaupt auf diesem Weg? Wie gesagt ich habe heute die ersten 
11 Stunden in der Materie verbracht und freue mich das überhaupt das 
Testbild schon da ist.

Evt kann  mir jemand paar Tips geben.

Danke Ronny

Also mit Bascom kenne ich mich nicht aus. Idealerweise einfach den Text 
über die serielle Schnittstelle eingeben. Einfach 9600 bits pro Sekunde.

Hallo Christian,

danke für deine schnelle Antwort. Also das mit Text ändern über die 
serielle Schnittstelle funktioniert. Aber ich möchte das Testbild nach 
Ausfall eines Videosignals (z.B. einer Überwachungskamera) automatisch 
(durch sync Dedector) einblenden lassen. Da der Atmega erst dann 
Spannung bekommt ist natürlich der alte Text wieder da.

Du benutzt feepascal, das Programm habe ich mal geladen, und werde heute 
Abend mal versuchen ob ich dort die .asm ändern kann.

MfG

Ronny

Hallo Ronny,

du kannst in der Hexfile mit einem Hex-Editor die Stelle suchen, an der 
die Zeichenkette "FuBK-Testbild" oder so ähnlich auftaucht.
Ich meine, dass das relativ am Anfang des Files war.
An dieser Stelle kannst du einen beliebigen Text eingeben (Zeichenanzahl 
beachten).

Ich hatte das damals auch so auf die Schnelle gemacht.

Viele Grüße
Basti

Bastian U. schrieb:
> ...An dieser Stelle kannst du einen beliebigen Text eingeben (Zeichenanzahl
> beachten).

Ja ganz genau so gehts.