Hallo,
ich habe mir kürzlich den seriell programmierbaren Quarzoszillator von AK Modul-Bus zuegelegt. Meine Frage: hat jemand Erfahrung mit der Programmierung des CY27EE16 über die serielle Schnittstelle?
Mit der exzellenten Software von G8JCF (G8JCFSDR) funktioniert die Programmierung einwandfrei. Ich möchte den Oszillator aber später mit eigener Software steuern.
Hallo Reinhard,
Du müßtest mit der seriellen Schnittstelle ein I²C Bus nachbilden, d.h. es wären 2 Leitungen nötig die bitweise von der entsprechenden Software geschrieben und gelesen werden müssen. Das Protokoll, die zu schreibenden Bytes / Adressen und wie der gesamte Datenrahmen auszusehen hat werden u.a. im CY27EE16 Datenblatt erläutert. Für eine PC-Software wäre eine DLL von Vorteil die die einzelnen Leitungen der RS232 Schnittstelle einzeln adressieren kann, bei einem µC geht das, besonders in einer Hochsprache mit extra "I²C Befehl", etwas einfacher.
Lieber OM Reinhard,
der geniale Bastler B. Kainka hat hierzu super Beispiele und Programme
Auf seiner WEB-Site zeigt er wie man über Visual Basic einfach auf die serielle Schnittstelle zugreifen kann und zum Beispiel den I2C Bus programmiert.
http://www.b-kainka.de/portnt.htm
Visual Basic kann man mittlerweile als EXPRESS Vollversion von microsoft für den Privatgebrauch kostenlos herunterladen.
viele Grüße
Markus, DB7MK
Hallo Reinhold und Markus,
danke für eure Antworten. Das Problem konnte ich gestern lösen, die Programmierung klappt jetz auch mit meiner Software. Dazu musste ich aber erst etwas "Reverse Engineering" betreiben, d. h. ich habe die serielle Schnittstelle belauscht und den Datenverkehr aufgezeichnet, während das schon erwähnte Programm G8JCFSDR auf die Schnittstelle zugegriffen hat. Daraus konnte ich erkennen, dass nach jedem Byte noch ein "1"-Bit gesendet wurde. Als ich das in mein Progrämmchen eingefügt habe, klappte es auch bei mir. Aus dem Timing-Diagramm im Datenblatt war das so nicht zu erkennen.
Als Programmiersprache verwende ich PureBasic.
Hallo Reinhard,
ZitatOriginal von dk1io
Hallo Reinhold und Markus,
Daraus konnte ich erkennen, dass nach jedem Byte noch ein "1"-Bit gesendet wurde. Als ich das in mein Progrämmchen eingefügt habe, klappte es auch bei mir. Aus dem Timing-Diagramm im Datenblatt war das so nicht zu erkennen.
Als Programmiersprache verwende ich PureBasic.
das zusätzliche Bit nach jedem Datenbyte ist das ACK (Acknowledge) und wird zur Bestätigung einer geglückten Datenübetragung vom Baustein gesendet, nicht vom PC. Im Datenblatt ist es auch vermerkt.
Hallo Miteinander
ich beabsichtige, den CY27EE16 mit einem ATMEL MOP seriell zu steuern. Wenn ich mich recht erinnere, enthält BASCOM die für den I2C Verkehr benötigten Routinen.
Interessant wäre in diesem Zusammenhang auch der Algoritmus zur Umwandlung
einer gewünschten Frequenz in die entsprechende Byte Sequenz -hat sich jemand von
Euch schon damit befasst?
Eine weitere Frage: Gibt es Messungen über den Rauschpegel in der Nähe (300 bis
3000 Hz Offset) des Trägers?. Meine Anwendung ist ein DC-TX/RX mit dem miniPro
und T2 von Rick Campbell.
Grüsse
Andreas
Hallo,
@ KubiK
Laut Datenblatt wird die Datenleitung vom CY27EE16 während des neunten Clockpulses auf LOW gezogen.
Wie auch immer, mein PC sendet jetzt als neuntes Bit eine "1" und damit klappt die Programmierung.
@ HB9EHI
Da ich nur Festfrequenzen benötige, lasse ich Cyberclocks die benötigten Bytes ausrechnen, übernehme diese dann von Hand aus dem PLL-Block und schreibe sie per Programm in das SRAM.
Bezüglich des Rauschpegels wurde in einem anderen Thread mal etwas erwähnt (Hard- und Software Defined Radio).
Hallo Reinhard,
das Ausgangsspektrum des CY27EE16 findest Du unter folgendem Link:
http://groups.yahoo.com/group/soft_radio/files/DJ9CS/
Du musst Dich allerdings beim Forum anmelden, es lohnt sich aber.
73 Gerd DM2CDB
Hallo Andreas,
ZitatOriginal von HB9EHI
Hallo Miteinander
ich beabsichtige, den CY27EE16 mit einem ATMEL MOP seriell zu steuern. Wenn ich mich recht erinnere, enthält BASCOM die für den I2C Verkehr benötigten Routinen.
ja, da mußt du dir keine Gedanken über das I²C Protokoll machen, nur die Datenbytes korrekt zusammenstellen und an der richtigen Adresse bzw. Register senden.
ZitatInteressant wäre in diesem Zusammenhang auch der Algoritmus zur Umwandlung
einer gewünschten Frequenz in die entsprechende Byte Sequenz -hat sich jemand von
Euch schon damit befasst?
Das ist tatsächlich nicht so einfach wie bei einem DDS Chip, durch die vielfältigen Teiler-Kombinationen muss man sich schon vorher Gedanken machen was erreichbar ist, z.B.:
REF=16.384MHz
Q=64 gibt eine PLL referezfrequenz von 256kHz (es müssen min. 250kHz sein)
mit CLK = ((REF/Q) x P) / N
Der interne VCO muß sich zwischen ca. 100 und 400MHz bewegen, es ergeben sich z.B. folgende relevante CLK Bereiche im HF Bereich:
1. 1,564 - 6,248MHz bei N=64, Q=64, P=391...1562
2. 6,256MHz - 24.992MHz bei N=16, Q=64, P=391...1562
Um zwischen den recht großen Schrittweiten zu interpolieren kann Q ein Schritt nach unten verändert werden, die PLL Referenz steigt dabei an und der Ausgangsteiler N ein Schritt nach oben bei gleichbleibendem P. Um noch weiter, beim selben P Wert, zu interpolieren ließe sich zusätzlich die VCXO Funktion (+/- 150ppm) des Bausteins aktivieren.
ZitatEine weitere Frage: Gibt es Messungen über den Rauschpegel in der Nähe (300 bis
3000 Hz Offset) des Trägers?. Meine Anwendung ist ein DC-TX/RX mit dem miniPro
und T2 von Rick Campbell.
Naja, die Qualität des integrierten VCO ist nicht besonders, vielleicht -60dBc @ 1kHz Abstand, durch die Teilung am Ausgang kommen noch 20log(N) dazu ... also im Endergebnis bescheiden, für einen einfachen RX bei kleinen Frequenzen aber durchaus noch brauchbar.
Hallo Reinhard,
ZitatOriginal von dk1io
Laut Datenblatt wird die Datenleitung vom CY27EE16 während des neunten Clockpulses auf LOW gezogen. Wie auch immer, mein PC sendet jetzt als neuntes Bit eine "1" und damit klappt die Programmierung.
Ganz genau, der CY Baustein zieht SDAT beim neunten Bit auf Low, somit könnte der PC erfahren ob die Übetragung des Datenbytes auch geklappt hat. Passiert das nämlich nicht sendet der PC schon das neue / nächste Datenbyte obwohl das vorherige nicht korrekt angekommen ist.
Hallo Reinhold,
Deine Skepsis bezüglich des neunten Bits war begründet. Habe das "1"-Bit gegen "0" getauscht, das hat auch funktioniert. Habe dann das neunte Bit ganz weggelassen und dafür außerhalb der Schleife, die die Bits eines Bytes ausgibt, den neunten Clockpuls angehängt, und damit läuft es auch. Entscheidend ist allein, dass nach den 8 Bits eines Bytes noch ein neunter Clockpuls folgt, und das war in allen Fällen so.
Freut mich, dass unsere Diskussion zu einem guten Ergebnis geführt hat.
Untenstehend seht Ihr den Code, der für die Ausgabe der Datenbytes verantwortlich ist.
DTR gibt die Daten aus, RTS die Clockimpulse.
For lSI2 = 1 To 8
If Mid(sDat, lSI2, 1) = "0"
EscapeCommFunction_(hComm, #CLRDTR)
Else
EscapeCommFunction_(hComm, #SETDTR)
EndIf
EscapeCommFunction_(hComm, #SETRTS)
EscapeCommFunction_(hComm, #CLRRTS)
Next
EscapeCommFunction_(hComm, #SETRTS)
EscapeCommFunction_(hComm, #CLRRTS)
