Hallo Hat jemand schon versucht einen LC Kreis an Xtal1/Xtal2 eines AVRs zu klemmen? Ich wollte fuer OSD Zwecke den AVR als PLL seinen eigenen Schwingkreis ziehen lassen mittels Varicap. Den Comparator als Sync Detect und via Interrupt und einen internen Timer eine Software PLL machen. OSD chips sind oft nicht viel anders. Mit Quarz wackelt mein OSD mir zuviel und ich dachte es sei ein Versuch wert. Wie kritisch reagiert ein AVR auf verschiedene Fuse Bits (Und wieso gibt es fuer verschiedene Quarz Frequenzen andere Fuses z.b. im Mega8 ?) und was muss mann beim DC path zwichen Xtal1 und 2 achten oder kann man eine Spule direkt anklemmen (DC Kurzschluss)? Viele Fragen und viel Spielraum! Edward
Wenn man den Quarz einfach durch eine Spule ersetzt funktioniert das ganze wunderbar. Zusammen mit den beiden Kondensatoren nach Masse ergibt sich ein sauber schwingender Schwingkreis. Das habe ich auch mal gemacht, als ich keinen 13,1072MHz Quarz gefunden haben.
Hi Benedikt, Welche Werte fuer C und L, welcher Processor und die Fuses wie fuer ein Xtal? Ed
Das war glaube ich ein mega8515. Wichtig ist, das die CKOPT Fuse gesetzt ist, wenn der mega8515 mit der XTAL EInstellung läuft. Die Kondensatoren hatten so um die 10-30pF, die Spule irgendwas im Bereich um die 30-70uH. Falls der Schwingkreis nicht schwingen will, kann man das Verhältnis der beiden Kondensatoren etwas verändern, dann sollte alles sicher schwingen. Wichtig ist, dass die Spannung sich nicht auf >5Vss aufschaukelt und verzerrt wird. Dadurch wird die Frequenz nämlich etwas verstimmt.
<< Mit Quarz wackelt mein OSD mir zuviel ... Dann hast Du woanders ein Problem ! Wenn Du sowieso eine PLL brauchst, wäre ein 74HC4046 angesagt. Varicap hat den Nachteil, höhere Versorgungsspannung zu brauchen; Spulen sind empfindlicher gegenüber äußeren Einflüssen, es sei denn, sie sind geschirmt.
Ich könnte mir auch vorstellen, daß die Absturzgefahr recht hoch ist, wenn der Prozi seinen eigenen Takt regeln soll. Oder aber das Ganze muß sooo langsam gehen, daß man innerhalb der Grenzen für den maximal zulässigen Takt-Jitter bleibt.
@Edward: Quote: "" << Mit Quarz wackelt mein OSD mir zuviel ... Dann hast Du woanders ein Problem ! "" Würde ich auch sagen. Evtl. ein konzeptuelles? Normalerweise sollte man Horizontal- und Vertikalsync feststellen und dann einen festen Zeitbezug herstellen. So macht es der Ersteller dieses Projekts: http://www.knology.net/~gdion/videoverlay.html Wenn du dir den Schaltplan ansiehst, siehst du, dass beide Synchronimpulse vom LM1881 auf die Interrupteingänge gehen, in der Source sieht man dann, dass darüber der Zeilenzähler und der Zeilentimer jeweils zurückgesetzt werden. Auf diese Weise wird ein konstanter Abstand zum linken Bildrand erreicht. Wenn es dann wackelt, ist entweder das Bild verrauscht oder der Horizontalimpuls instabil, z.B. weil die Quelle ein alter Videorecorder ist. ( Der LM1881 enthält keine Geheimnisse, der extrahiert nur die Synchronimpulse aus dem Videosignal) Gruss Jadeclaw.
Die kleine Zappelei um plus/minus ein Pixel ist am schwierigsten abzustellen. Irgendwo muß die Quantisierung mit der Taktfrequenz des Controllers stattfinden. Als Varicap sollte man einen Mittelwellentyp (BB113) benutzen, keinen für UHF oder UKW. VHF könnte noch gehen (BB109 und folgende)
von www.funkamateur.de -> Online-Shop - Spezialteile - Dioden gibts noch ein paar Varicaps, die sind in den letzten Jahren selten geworden: z.B. BB409 (Art.-Nr. 6555) C-Diode (C1V/12V) = 44/10 pF Preis: EUR 1,20 Reichelt hat nur noch die BB833, für Sat-Empfang über 1 GHz, die hat zu wenig Kapazität. Von http://www.giga-tech.de/dioden.htm gibts noch einiges http://www.eisch-electronic.de/katalog/index.html?rub=7 hat noch drei Typen.
@Egon: Das Problem ist der Xtal ist nicht mit dem Video gelockt. Die Schrift wird deshalb schief, zackig oder "schwingt" da der AVR die Sync abtasted. Wenn der Abtastpunkt um ein MachineCycle gerutscht ist sprint das ganze um ein Pixel. @Dinosaur: Gido hat das gleiche Problem, seine Schrift ist nicht sauber an den Raendern. Schau mal der rechte Strich vom rechten "N" oben rechts. @Christoph Kessler: Du hast es gerafft. Ich glaube ich kanns hinkriegen, das Wochenende ist lang ... Ich schau mal wie es weiter geht. Der LC schwingt zwichen 13.5 und 14.5 MHz am Mega8 mit einer UHF Varicap, danke Benedikt fuer die Fuses, jetzt geht es 100%. Edward
Ich meinte eine Varicap am Quarz, wenn die einigermaßen weit ziehen soll, darf kein C parallel liegen, und unterhalb von 5 oder 10 pF in Serie schwingt der Quarz nicht mehr. Maximal kann man Quarze um etwa ein Promille ziehen. Zum Thema Quarzoszillator und Ziehen von Quarzen gibts das Buch vom Experten: http://www.qsl.net/dk1ag/
Edward, mich würde interessieren, wie Deine Software-PLL funktioniert. Um sicher zu synchronisieren, muß man die Trabanten unterdrücken und exakt auf 0° Phasenlage einstellen, damit nichts zittert. Das geht meiner Meinung nach nur per Hardware-PLL hinreichend gut.
Egon Die Trabanten leiten einen Bildwechsel ein und sollen eigentlich nur den Versatz durch das Zeilensprungverfahren ausgleichen. Das eingetastete OSD ist ohne. Wenn da etwas im Timing nicht stimmen sollte würde das OSD vertikal 'zittern', nicht horizontal wie es jetzt auftritt. Edward Ob Software-PLL realisierbar ist bin ich eher skeptisch. PLL bedeutet ja Frequenz UND Phase sind 'eingerastet' und starr gekoppelt. Angenommen, es gelingt Dir über das Varicap die (ich denke Du möchtest auf den Farbträger) Frequenz nachzuführen kannst Du aufgrund der sehr kurzen Zeit einer Zeile (64us) einen Phasenwinkel-Fehler nicht zuverlässig erkennen. Der Atmega braucht ja etwas Zeit zum rechnen. Und unterschiedliche Ausführungs-Zeit, die evtl. mit NOP's abgeglichen werden müßte. Ich lasse mich gerne vom Gegenteil überzeugen. ;-)
Hallo Edward Cardew, Dein OSD-Projekt ist sehr interessant, könntest Du es vielleicht veröffentlichen? Danke Bernhard
@T.S. Den Pixeltakt synchronisiert man zweckmäßigerweise mit Hsync. Und da stören sie 32µs Trabbis den 64µs Hsync. Vsync synchron zu bekommen ist dagegen wesentlich leichter. Bleiben wir weiter gespannt auf die softe PLL :-)
>Und da stören sie 32µs Trabbis den 64µs Hsync. Stimmt. Das mit den Trabbi's ist nicht so einfach; und so einen zu fahren auch nicht. ;) Die Vor- und Nach-Trabanten sollten aber aufgrund ihrer unterschiedlichen Dauer vom eigentlichen Zeilenwechsel (VSync) ohne Probleme erkennbar sein wie Du bereits erwähnt hast. Das ist ja das eigentliche Problem an dem ich Zweifel an der Machbarkeit habe. Um das auszuwerten braucht man etwas Code in einer ISR dessen Ausführungszeit je nach Situation unterschiedlich ist. >Den Pixeltakt synchronisiert man zweckmäßigerweise mit Hsync. Ja, denke ich auch. Am besten auf ein ganzzahliges Vielfaches. Edward erwähnte etwas von 13.5 - 14.5 MHz. Das kommt mir irgendwie bekannt vor. 14 komma dingsbums, ist das nicht ein Farbträger.. Moment mal, da war doch was. Mein alter Commodore brauchte einen Quarz 14,x MHz für Ntsc und einen 17,x MHz für Pal.. >Bleiben wir weiter gespannt auf die softe PLL :-) Auf jeden Fall. :-)
> "... und einen 17,x MHz für Pal.."
Habe hier einen alten Amstrad Satreceiver liegen, dessen OSD läuft mit
17.734 MHz. (Farbträger mal 4)
Gruss
Jadeclaw.
Also 14 MHz da 64usec mal 896 = 14e6. Farbe will ich nicht locken. Nur was besseres als http://www.knology.net/~gdion/videoverlay.html Was ich bisjetzt habe versucht zu locken. Jetzt geht es an die Details warum es noch nicht ganz so will: 1er Punkt: Hat ein ATmega8 immer die gleiche Zeit um zur INT0 service zu kommen wenn mein hauptloop: rjmp hauptlooped und sonst nix? 2er Punkt: Ich benutze ein Prescaler am Timer, villeicht ein Fehler da beim Neuladen des Timers der Prescaler nicht geresetted wird? Konnte zu diesen 2 Punkten keine Antwort im Datenblatt finden. Gruss Edward
>>1er Punkt: Hat ein ATmega8 immer die gleiche Zeit um zur INT0 service zu kommen wenn mein hauptloop: rjmp hauptlooped und sonst nix? Natürlich nicht :-) der aktuelle Befehl muß zunächst beendet werden, um die INT-Routine anzuspringen. Befehle können 1 - 3 Taktzyklen brauchen und unter Umständen durch waits bei externem Speicherzugriff noch länger dauern. RJMP braucht zwei Takte. Darum zweifel auch ich an der soften Lösung und sage wiederholt ..4046. Die Trabbis kann man durch nicht nachtriggerbare Monoflops unterdrücken z.B. ..221. Dabei gehe ich davon aus, das ein LM1881 zuvor die Hsyncs aufbereitet hat.
Das heisst 1er Punkt ist OK da ich immer rjmp mache. INT0 ansprung Zeit muesste also immer gleich sein. Ich habe gerade gelesen den Prescaler kann man einen Reset verpassen...
Wenn der aktuelle Befehl immer ein rjmp auf sich selbst ist dann ist die Entry in INT0 doch immer gleich oder bin ich da im Wald? Der AVR wird doch nur alle 2 Cyclen in INT0 springen (Da gibt es doch keine Moeglichkeit auf "Gehopse"). Wenn alles einrastet dann wird er auch auf seinen 2 Cyclen gelockt sein (oder?). Das mit dem Prescaler auf Null hat schon viel gebracht. Jetzt sind aber 3 Commandos in Reihe (Timer lesen, Prescaler reset und Timer reset) und diese Drei sind eindeutig zu viel PPM fuer einen Xtal. Mit dem LC sieht es gut aus, guck mals weiter ... Edward
>>Der AVR wird doch nur alle 2 Cyclen in INT0 springen
Schon, aber mal im 1. Takt, mal im 2. Takt abhängig davon, ob die
INT-Routine eine gerade oder ungerade Anzahl an Takten braucht.
Zudem mußt Du ja zwei Signale vergleichen, um zu regeln. Die
Gleichzeitigkeit hat aber einen Fehler, da während ein INT auftritt,
sich das 2. Signal ändern kann. Die Unsicherheit beträgt dadurch
mehrere Taktzyklen. Verhindern könnte man dies meiner Meinung nach nur
mit einem Timer mit zwei Capture-Eingängen, woraus sich die Phasenlage
ableiten ließe.
Vergleiche einmal, was eine Kapazitätsdiode+Spule kosten, und was ein
HC4046 kostet :-)
Wenn ein AVR selbst die Sync Signale ereugt, und man nach der Ausgabe von x Pixeln einfach mit warte: sbrs flags, hsync rjmp warte auf den Interrup wartet, dann wackelte das Bild je nach Dauer um 0, 1, 2 Pixeln, da je nach empfangen Daten (werde im HSync Interrupt verarbeitet) der Interrupt irgenwann währen des sbrs auftrat. Mit entsprechenden nops musste ich alle Wege die das Programm i Interrupt nehmen konnte um 0, 1, 2 Takte verlängern. Der Jitter lag dann am Ende bei exakt 0 Takten. Wartet man auf einen externen Takt, dann kann der Jitter ebenso 0,1 oder 2 Takte betragen, selbst wenn der Takt synchron läuft. Man bekommt es nur stabil hin, wenn man sowohl den Takt (per PLL) synchronisiert, und die Interruptroutine von der Länge her so abgeglichen ist, dass diese keinen Jitter gegenüber dem Timer verursacht.
Wenn eine H Zeile zB genau 1024 Cycles braucht und der rjmp 2 dann past von da her schon alles. Dass der Int0 dann auch immer gleich sein muss (oder minimum eine gerade Zahl Cycles) hat ich nicht bedacht, das ist es Wert zu untersuchen. Der RETI ist documentiert doch wieviele Cycles gehen drauf um zum ersten Befehl im Int0 zu kommen und wo steht das, im Mega8 Datenblatt oder steht das in einem AppNote? Ich finde die Interrupts bei AVR nicht so gut documentiert wie bei der alten MCS51, vieleicht nur nicht an der richtigen Stelle gekuckt. Der LC schwingt schon ein und zappelt nur sehr wenig (ca 1 pix). Warte auf ein AM Varicap um das ganze mal mit Xtal anzugehen. Bei diesem schoenen Wetter gibt es auch andere Sachen als AVR intellektuelle Stimulation ;-) Edward
OK, das mit den Interrupts hab ich: Interrupt Response Time sagt 4 cycles push PC and clear I, 3 cycles for jump (Komisch, ich denk rjmp und ijmp braucht nur 2 ???) Interrupt Leave ist 4 cycles pop PC and restore I mit RETI. Weiss einer wieso hier der jump 1 Takt mehr brauch? (Reine Neugier) Edward
... und zappelt nur sehr wenig (ca 1 pix). Na ja, ich glaube hier haben wir unterschiedliche Vorstellungen. Was für Dich "sehr wenig" ist, ist für andere zu viel. Unter "Interrupt Response Time" steht doch alles im Datenblatt.
@Egon: Er zappelt ganausoviel, wennicht etwas weniger als http://www.knology.net/~gdion/videoverlay.html der mit einem Xtal faehrt. Ist doch nicht schlecht fuer ein einfaches LC. Das Ziel fuer mich war doch "Was besseres" als das vom Gdion. Weiss einer warum 4(push)+ *3*(jmp) Takte beim Mega8 draufgehen um ins INT0 zu springen, auf English: This sounds strange ... ? Edward
I don't think it's strange. ;) Ich denke mal bei einer Int-Anforderung kommt jeder uC kurzzeitig in's schwitzen: PC auf Stack retten, neuen PC lesen, neuen PC laden, I-Flag setzen, Sonderfälle nicht vergessen (z.B. ADC neu starten) usw. Ohne die Taktktzyklen aus dem DS abschreiben zu wollen.. Egon's Empfehlung es mit dem 4046 einmal zu versuchen ist meiner Meinung nach wirklich die beste Lösung; "Better safe than sorry". Dieses Standard-IC kostet kein Vermögen. Torsten
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.