Ansprechen eines PLLs (LM7001)

[dg2ygq]

Hallooooooooooo,

Ich habe da vielleicht ein PLL-IC, vielleicht kann es ja das was ich brauche :

- 12 bis 18 Mhz in 2,5kHz Schritten
- "schnelles" Umspringen zwischen 12 und 18 Mhz
- Über einen AVR steuerbar

Es handelt sich um das LM7001
http://pdf1.alldatasheet.com/datasheet-pdf/view/41210/SANYO/LM7001.html

Lassen sich mit diesem IC die gebrauchten Frequenzen erzeugen?

Wie lässt sich dieses PLL mit einem AVR ansprechen?
Es werden ja nur 2 Datenleitungen gebraucht, aber welche "Daten" müssen übertragen werden? Übertragungsrate, usw usw, es fehlt mir jeglicher Überblick
Hier wäre ein Erklärung und evtl. ein Programmbeispiel sehr hilfreich.

Vielen Dank
Michael

 

[Dirk]

Hallo Michael!

Wie lässt sich dieses PLL mit einem AVR ansprechen?
Es werden ja nur 2 Datenleitungen gebraucht, aber welche "Daten" müssen übertragen werden? Übertragungsrate, usw usw, es fehlt mir jeglicher Überblick

Man benötigt zur Übertragung der Daten CE (ChipEnable), Data und CL (Takt). Mit dem AVR kann man das entweder über die SPI-Schnittstelle machen oder man programmiert das manuell. Im Datenblatt steht, dass bei 7,2MHz Quarz-Frequenz der Takt > 3us (2 x 1,5us) sein soll. Übertragen werden insgesamt 24bit, die setzen sich zusammen aus dem Teiler (14bit), Band und Zeitbasis, sowie der Referenzfrequenz. Beispiele sind im Datenblatt vorhanden. Bezüglich der Übertragung der Daten ist das eigentlich einfach zu lösen.

Ob deine Forderungen ...

- 12 bis 18 Mhz in 2,5kHz Schritten
- "schnelles" Umspringen zwischen 12 und 18 Mhz

erfüllt werden, kann ich leider so auf Anhieb nicht sagen. Vielleicht kann ja hier jemand anderes etwas weiterhelfen.

Hast du denn schon mal geprüft, ob du an den PLL dran kommst?

Grüße,
Dirk

 

[dg2ygq]

Hallo Dirk,

verfügbar ist das IC, bei einem großen Versandhaus für weniger als 1€

Wenn das gute Ding nicht die 2,5kHz Schritte bei bis 18 Mhz macht, werde ich mir wohl doch was mit Frequenzmischung überlegen müssen

Aber im allgemeinen meinst du dass es sich recht "einfach" programmieren ließe, ja ?

 

[Dirk]

Hallo Michael!

Aber im allgemeinen meinst du dass es sich recht "einfach" programmieren ließe, ja ?

Ja, das scheint recht einfach zu sein. Du solltest dir vielleicht bevor du das IC bestellst einmal die Beispiele im Datenblatt ansehen, dort wird zum Beispiel beschrieben, wie der Teiler berechnet wird. Normalerweise müsste man mit den angegebenen Daten ermitteln können, ob Deine Forderungen erreicht werden.

Gruß,
Dirk

 

[dg2ygq]

Ich werde aus dem Datenblatt noch nicht wirklich schlau :

seven reference frequencies: 1,5,9,10,25,50 and 100kHz

Auch gut, im 5kHz Raster geht ja auch, ich muss nur die Grundfrequenz dann um 2,5Khz anheben, also zB mit 10,0025 MHz mischen ?! Notfalls würd es der 1kHz Schritt tun, wäre dann nach der Frequenzverdoppelung auch "nur" 1kHz neben der erwünschten Frequenz.

Ja, ich denke ich sollte das mal probieren, falls dieses Vorhaben damit nicht klappt, lässt sch das IC sicher noch für andere Projekte nutzen.

Du hast 7,2Mhz Quarz angesprochen, wenn ich das Datenblatt richtig durchschaut habe, ist die Quarzfequenz nur für die Programmierung ausschlaggebend, nicht aber für die tatsächliche Frequenzaufbereitung / Teilung des PLL`s ?


Michael

 

[Dirk]

Hallo Michael!

Durch den 7,2MHz Quarz wird die Referenzfrequenz erzeugt, die Teilung stellt man mit den Bits R0 bis R2 ein (8 Frequenzen von 1kHz bis 100kHz). Im Datenblatt sind minimale Zeiten für die Übertragung der Daten in Abhängigkeit der Frequenz am Pin XIN angegeben, die nicht unterschritten werden dürfen. Warum es da eine Abhängigkeit gibt, weiß ich nicht, es handelt sich ja eigentlich nur um ein Shift-Register, in das man die Daten schiebt. Man muss da eben den AVR ein bisschen "bremsen"

Gruß,
Dirk

 

[dg2ygq]

Na klasse, nun hapert es am Quarz mit 7,2 Mhz. 7,368 (oä) ist drann zukommen, aber die knappen 200Khz lassen sich wohl auch nicht "ziehen"

Wenn ich jetzt 7,2Mhz durch 2,5 teile, müsste doch der 1kHz Schritt zu 2,5kHz werden? Aber dann muss der AVR noch mehr gebremst werden ?!
Zumal ich wieder nicht weiß nob der LM noch mit 2,88MHz arbeitet oder ob dieser Quarz verfügbar ist ???

Die 5kHz Schritte mit einem 14,4Mhz Quarz auf 2,5Khz umstellen ... das geht wohl nicht mehr, weil in Datenblatt was von bis 8 MHz steht ?

Ist das nun überhaupt der richtige Gedankenweg ?

 

[dg2ygq]

Hallo zusammen!

Ich habe nun eine kleine Änderung gemacht !

Statt dem LM7001 möchte ich nun den SAA1057 nutzen.

http://www.peter-geisler.de/datasheet_SAA1057.pdf


Wie kann ich nun eine Verbindung zum AT-Mega8 herstellen?
Muss ich spezielle Port-Pins für die Datenübertragung nutzen?
Wie setzt sich die Bitfolge für dieses IC zusammen?

 

[Dirk]

Hallo Michael

Wie kann ich nun eine Verbindung zum AT-Mega8 herstellen?
Muss ich spezielle Port-Pins für die Datenübertragung nutzen?

du verwendest einfach drei freie IO-Pins, die du als Output schaltest.

Wie setzt sich die Bitfolge für dieses IC zusammen?

Im Datenblatt steht, dass man die Einstellung über zwei 15Bit Latches vornimmt. In LatchA befindet sich die Frequenzinformation, mit den Bits in LatchB stellt man den PLL Synthesizer ein.

Wichtig ist hier die Seite 4 "Control information".

Das Übertragungsprotokoll ist nicht so schwer, das kann ich dir als Routine schreiben. Es wäre aber vorteilhaft, wenn man sich über die Bedeutung der Bits von LatchB vorher im Klaren ist. Konntest du denn hier auch mit einem PC-Programm simulieren?

Gruß
Dirk

 

[dg2ygq]

Hallo Dirk,

ja, mit dem Programm lässt sich das IC so ansprechen, wie ich es mir wünsche

Wenn ich das richtig sehe, bleibt ja LatchB immer gleich, nur LatchA verändert die Frequenz?!

Richtig durchschaut habe ich auch noch nicht wie die Bitfolge aussehen muss, um zB 16,00125 Mhz daraus zu bekommen. Aber ich denke ich werde mich da noch reinwurschteln können...
Andernfalls frag ich Euch

Wäre super wenn du mir eine kleine Routine dazu schreiben würdest, denn ich habe noch garkeine Idee wo ich überhaupt anfangen soll.

Michael

 

[Dirk]

Hallo Michael,

hier ist mal eine Routine zum Testen.


Definiere zuerst zwei 16Bit Variablen im Datensegment (nach .dseg)

;****************************************
;*** SAA1057 ****************************
PLL_LatchA:                   .byte 2
PLL_LatchB:                   .byte 2

Den folgenden Code in dein Programm einfügen. Eventuell in ein Include-File schreiben/kopieren und im MainProgramm mit .include "meinincludefile.asm" einbinden.

Eine Einschränkung gibt es: Alle drei Signale müssen Signale eines Ports sein. Wenn das nicht geht, kann man das noch ändern, ich fand es so aber erst einmal übersichtlicher.

Als Beispiel wurde hier der PortB mit den entsprechenden Pins verwendet (siehe bei .equ), das kann man ändern.

Zuerst muss einmalig die Routine PLL_InitPort aufgerufen werden.
Du musst etwas in die beiden 16Bit Register im SRAM PLL_LatchA und PLL_LatchB hineinschreiben. LatchA ist für Frequenz und LatchB für Konfiguration. Das jeweils höchstwertige Bit wird ignoriert.

Die eigentliche Routine, die die Daten überträgt ist PLL_SendData. Ich konnte den Code ja leider nicht testen, kann also nicht versprechen, dass alles richtig funktioniert. Am besten wäre, wenn du bekannte Daten für LatchA/B einfach mal überträgst und dann überprüfst, ob alles funktioniert.

Grüße
Dirk

.equ PORT_PLL   = PORTB
.equ DDR_PLL    = DDRB
.equ PIN_DLEN   = PB0
.equ PIN_CLB    = PB1
.equ PIN_DATA   = PB2

PLL_InitPort:

   cbi PORT_PLL, PIN_DLEN  ; alle drei Signale low
   cbi PORT_PLL, PIN_CLB
   cbi PORT_PLL, PIN_DATA

   sbi DDR_PLL, PIN_DLEN   ; alle drei Portpins sind Ausgänge
   sbi DDR_PLL, PIN_CLB
   sbi DDR_PLL, PIN_DATA

ret
 
;*********************************************************************************
;* PLL_SendData
;*
;* Description: Überträgt 2 x 16Bit zum SAA1057
;* Arguments  : PLL_LatchA (2Byte SRAM), PLL_LatchB (2Byte SRAM)
;* Results    : -
;*
;*********************************************************************************

PLL_SendData:
 

   sbi PORT_PLL, PIN_DLEN    ; DLEN = 1
   rcall wait5us

   ;*************************************************
   ;*** Daten LatchA ********************************
 
   lds RegA, PLL_LatchA+0    ; Bit7 bis Bit0
   lds RegB, PLL_LatchA+1    ; Bit15 bis Bit8
   
   andi RegB, 0b01111111     ; Bit15 = 0 (identifiziert LatchA)


   ldi RegC, 16              ; 16 Bits werden übertragen
pll_sd_loop1: dec RegC
   tst RegC
   breq pll_sd_latch_b

   rol RegA
   rol RegB
   brcs pll_sd_set1

   cbi PORT_PLL, PIN_DATA   ; Data = 0
   rcall wait5us
   sbi PORT_PLL, PIN_CLB
   rcall wait5us
   cbi PORT_PLL, PIN_CLB
   rjmp pll_sd_loop1

pll_sd_set1:
   sbi PORT_PLL, PIN_DATA    ; Data = 1
   rcall wait5us
   sbi PORT_PLL, PIN_CLB
   rcall wait5us
   cbi PORT_PLL, PIN_CLB
   rjmp pll_sd_loop1
 
 
   ;*************************************************
   ;*** Daten LatchB ********************************
pll_sd_latch_b:

   lds RegA, PLL_LatchB+0    ; Bit7 bis Bit0
   lds RegB, PLL_LatchB+1    ; Bit15 bis Bit8
   
   ori RegB, 0b10000000      ; Bit15 = 1 (identifiziert LatchB)

   ldi RegC, 16              ; 16 Bits werden übertragen
pll_sd_loop2: dec RegC
   tst RegC
   breq pll_sd_end

   rol RegA
   rol RegB
   brcs pll_sd_set2

   cbi PORT_PLL, PIN_DATA    ; Data = 0
   rcall wait5us
   sbi PORT_PLL, PIN_CLB
   rcall wait5us
   cbi PORT_PLL, PIN_CLB
   rjmp pll_sd_loop2

pll_sd_set2:
   sbi PORT_PLL, PIN_DATA    ; Data = 1
   rcall wait5us
   sbi PORT_PLL, PIN_CLB
   rcall wait5us
   cbi PORT_PLL, PIN_CLB
   rjmp pll_sd_loop2
 

pll_sd_end:
   cbi PORT_PLL, PIN_DLEN    ; DLEN = 0

ret



wait5us:

   ldi RegD, 8
wait5us_loop: dec RegD
   tst RegD
   breq wait5us_end

   nop
   nop
   nop
   nop
   nop
   nop
   rjmp wait5us_loop

wait5us_end:
ret

 

[dg2ygq]

Hallo Dirk!

Mit soviel Code hatte ich nicht gerechnet

Wo schreibe ich denn die Werte in die beiden Register? Ich habe es mal fix überflogen, ist mir aber nicht ins Auge gestochen.

Ich melde mich sobald ich es aus getestet habe.

Vielen Dank dafür.

Später muss doch für jeden Kanal eine .db erstellt werden, oder ?

Michael

 

[Dirk]

Hallo Michael!

Wo schreibe ich denn die Werte in die beiden Register?

Da gibts mehrere Möglichkeiten wie man das machen kann. Ich würde erst einmal überhaupt austesten, ob die Datenübertragung bzw. die Konfiguration funktioniert.

Zu Testzwecken kannst du folgendermaßen vorgehen:

SystemInit:
   ...
   rcall PLL_InitPort

   ldi RegA, low([COLOR=RoyalBlue]Frequenz[/COLOR])
   sts PLL_LatchA+0, RegA  ; niederwertiges Byte
   ldi RegA, high([COLOR=RoyalBlue]Frequenz[/COLOR])
   sts PLL_LatchA+1, RegA  ; höherwertiges Byte


   ldi RegA, low([COLOR=RoyalBlue]Konfiguration[/COLOR])
   sts PLL_LatchB+0, RegA  ; niederwertiges Byte
   ldi RegA, high([COLOR=RoyalBlue]Konfiguration[/COLOR])
   sts PLL_LatchB+1, RegA  ; höherwertiges Byte

   rcall PLL_SendData

warte: 
   wdr                     ; Watchdog Reset, falls der aktiviert ist
   rjmp warte            ; Endlosschleife

Für Frequenz und Konfiguration musst du entsprechende Werte eintragen. Bei der Konfiguration ist hier Binärform vorteilhaft (0b100110 ...). Jeweils 15 Bits.

Später muss doch für jeden Kanal eine .db erstellt werden, oder ?

Ja, aber erst einmal würde ich prüfen, ob es mit einem bestimmten Kanal (Frequenz) funktioniert. Wenn die Konfiguration richtig ist kann man hier auch eventuell die richtige Frequenz aus der Kanalanzeige errechnen, also ohne Tabelle ermitteln.

Grüße
Dirk

 

[dg2ygq]

Hallo Dirk
So, ich glaube das ist ein wenig durcheinander ?!

Die m8def.inc macht auch wieder Probleme, wie ich es bei der m8515def.inc auch schon hatte ! (go) ?!

Höheres Byte und niedrigeres Byte? Ist richtig dass ich die Bits von "links nach rechts geschrieben habe? (Konfiguration)

Schau doch mal durch ob dir noch etwas ins Auge fällt


Michael

 

[Dirk]

Hallo Michael,

ich habe mir dein Programm mal schnell angesehen. Folgende Programmteile habe ich ergänzt bzw. geändert:

.include "m8def.inc"

.org 0   ;*** Reset ***
   rjmp SystemInit

das richtige Definitionsfile findet AVR Studio in seinem Programmverzeichnis, hier musst du keinen Pfad angeben. Reset-Adresse ist 0x0000, danach direkt zur Routine "SystemInit" springen. Die Interrupteinsprungadressen nach 0x0000 sind hier noch nicht definiert, das kann man später machen, wenn man Interrupts nutzt.

   ;************************************************
   ;*** Stack Pointer ******************************
  [COLOR=DarkRed] ldi RegA, low(RAMEND) ; StackPointer initialisieren
   out SPL, RegA
   ldi RegA, high(RAMEND)
   out SPH, RegA[/COLOR]
                
   ;************************************************
   ;*** Hier noch allg. Funktionen *****************
   ;rcall InitPorts          ; Ports initialisieren
   ;rcall InitRegisters      ; Register initialisieren

Ganz wichtig: StackPointer SPL/SPH initialisieren, sonst kannst du keine Routinen nutzen, oder die Befehle Push/Pop nutzen. InitPorts und InitRegisters benötigt man hier noch nicht, ist aber sinnvoll, kann man später noch machen, wenn feststeht, wo du was an den AVR anschließen möchtest. Den Watchdog aktivieren wir hier noch nicht.

Die Wartezeit in der Routine wait5us ist für eine Taktfrequenz von 16MHz (1/62,5ns) berechnet.

Im Anhang ist das geänderte Programm.


Grüße
Dirk

 

[dg2ygq]

Puhhhh, das will alles noch nicht

Das IC macht einfach nicht was ich will.
Ich habe zu letzt mit dem Test-Ausgang experimentiert, der sollte ja was machen, auch wenn die Frequenz (Latch A) nicht zu meinem VFO passt.

; Latch B:
ldi RegA, low(0b1000000111010010)
sts PLL_LatchB+0, RegA ; niederwertiges Byte
ldi RegA, high(0b1000000111010010)
sts PLL_LatchB+1, RegA ; höherwertiges Byte

Bit bedeut. Wert (von links nach rechts / high bit nach low bit)
_______________
01 --- 1
02 fm 0
03 refh 0
04 cp3 0
05 cp2 0
06 cp1 0
07 cp0 0
08 sb2 1
09 sla 1
10 pdm1 1
11 pdm0 0
12 brm 1
13 T3 0
14 t2 0
15 t1 1
16 t0 0

Somit sollte doch am Test-ausgang was zu messen sein? (ich habe mehrere Kombinationen bei T0-T3 getestet, keine Änderung)

Die Port-Pin`s PB0 bis PB2 habe ich nun direkt ohne Widerstand an den SAA angeschlossen.
Der SAA sitzt samt Schaltung auf einer Platine, der AVR auf dem STK500, verbindung über 15cm Flachbandkabel an Pfostenstecker, Masse natürlich auch verbunden.

Wo könnte der Fehler denn noch liegen?

 

[Dirk]

Hallo Michael,

der Fehler könnte an mehreren Stellen liegen. Zuerst solltest du überprüfen, ob die Datenübertragung richtig funktioniert. Um erst einmal zu überprüfen, ob überhaupt eine Datenübertragung erfolgt, könntest du die Routine PLL_SendData in die Endlosschleife einbauen, so dass ständig übertragen wird. Dann könntest du mit dem Oszilloskop die einzelnen Signale prüfen. DLEN ist am niederfrequentesten, DATA ist höherfrequent und CLB hat die höchste Frequenz. Wenn das nicht so ist, liegt der Fehler bei der Datenübertragung.

Im Moment ist es auch so, dass der AVR nach RESET direkt die Daten überträgt, dies ist vielleicht für den PLL zu schnell. Man sollte hier nach der Initialisierung des StackPointers eine Pause von 100ms einbauen.

Zusätzlich könnte man die 5us-Pause, die von der Routine PLL_SendData aufgerufen wird, erhöhen.

Ich würde erst nochmal mit Oszilloskop wie oben beschrieben prüfen.

Melde dich dann nochmal, was du rausgefunden hast. Ich schreibe dir dann die Software bezüglich der Pausen nochmal ein bisschen um.

Gruss
Dirk

 

[dg2ygq]

CLB = 81kHz
Data = 13Khz
DLEn = 3 kHz
(Werte nur ca.)



Die Konfig-Bits habe ich soweit richtig eingestellt (1khz schritte, am usw) ?

Hier habe ich die Pause eingefügt:

SystemInit:
;************************************************
;*** Stack Pointer ******************************
ldi RegA, low(RAMEND) ; StackPointer initialisieren
out SPL, RegA
ldi RegA, high(RAMEND)
out SPH, RegA
rcall Pause100ms

Mit 100mS Pause auch keine Änderung, der SAA bleibt von allen Versuchen unbeeindruckt ?!

 

[Dirk]

Hallo Michael,

ich habe auch noch einmal Pausen eingebaut und die Routine PLL_SendData überarbeitet. Es werden nun LatchA und LatchB einzeln in jeweis einer DLEN-Phase übertragen.

In der Endlosschleife wird die Routine PLL_SendData alle 500ms aufgerufen (nur für Testzwecke).

Kannst du das Programm im Anhang nocheinmal laufen lassen.

Grüße
Dirk

 

[dg2ygq]

So, den neuen Code auch mal ausprobiert, leider wieder nichts

Ich hab mit dem PC-Proggy mal experimentiert .... auch darüber bekomme ich den Test-Ausgang nicht hin, aber dafür passt dort immer noch die Frequenz.

Ich habe auch versucht den Code auf einem 8515 zu schreiben, mit dem gleichen Misserfolg.
Beim AtMega8 liegt der Quarz ja an PB6 und PB7, nicht dass der Port deswegen Komplikationen macht.

Auch den SAA1057 habe ich gewechselt, am Ergebnis ändert das alles nichts.

Wäre interessant WAS das PC-Proggy ausspuckt, um genau diese Daten dem AVR geben zu können !


Hier nochmal der Link zu dem PC-Programm:
www.peter-geisler.de/SAAPLL01_XP_VO1_2006.exe
und der Link zum Datenblatt vom SAA1057
http://www.peter-geisler.de/datasheet_SAA1057.pdf