mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LC Oscillator am AVR


Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Benedikt,

Welche Werte fuer C und L, welcher Processor und die Fuses wie fuer ein
Xtal?

Ed

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<< 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.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: T.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Edward Cardew,

Dein OSD-Projekt ist sehr interessant, könntest Du es vielleicht
veröffentlichen?

Danke

Bernhard

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: T.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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. :-)

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "... 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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, der 1. Punkt ist eben nicht ok !!!

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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 :-)

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Edward Cardew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: T.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.