Hallo zusammen,
seit einigen Tagen beschäftige ich mich nun mit den RFM01 + RFM02
Modulen.
Etwas naiv dachte ich zuerst, nehme ich die Kombination aus den beiden,
weil die eine Seite nur Senden, die andere nur Empfangen soll
(Telemetrie für Modellbau), aber dann habe ich gemerkt, dass viele
Berichte nur das RFM12-Modul betreffen.
Deshalb habe ich mir die beiden Code-Stücke aus den hoperf.com-"Specs"
abgeschrieben (wieso machen die eigentlich PDFs, aus denen man nichts
kopieren kann? grrrr) und beim Abtippen gemerkt, dass das ziemlicher
Murks sein muss (sofern ich das als Anfänger jedenfalls beurteilen
kann/darf).
Schon leicht gefrustet habe ich dann die beiden zip-Dateien von Benedikt
gefunden und nach meinem Wissen (Vermuten) auf die 868MHz-Varianten
umgebaut.
Nun mein Problem: Ich habe mir zwei Pollin Funk-AVR-Evaluationsboards
besorgt (Version 1.2, also ohne die Probleme mit dem Optokoppler etc.
aus der Version 1.1, die hier wohl bisher ausschließlich besprochen
wurde).
Den Sender (AVR-Studio Projekt im Anhang) denke ich, habe ich soweit am
Laufen; eine der beiden LEDs habe ich im Sendetakt zum Blinken
programmiert und die blinkt auch schön. Außerdem sehe ich mit dem Oszi -
an der Antenne gemessen - die Trägerfreqzenz (grob geschätzt, mit meinem
40MHz-Oszi :-)) und 1x pro Sekunde einen kurzen Peak. Außerdem läuft der
CLK-Ausgang vom RFM-Modul auch mit 10MHz (ohne Jumper/Verbindung zum MC
mit 1MHz).
Der Empfänger streikt aber völlig. Auch den habe ich soweit umgebaut,
dass da eine LED blinken soll, wenn die Daten angekommen sind. Aber sie
blinkt nicht :-(
Auf meiner Fehlersuche bin ich dann auf ein ganz wirres Problem
gestoßen, dass ich mir auch nicht erklären kann: Zu Testzwecken habe ich
in der main() einfach mal nur die LED getoggelt (nachdem ich damit in
der
1
while(!(RF_PIN&(1<<SDO)));// wait until data in FIFO
-Schleife debug-toggeln wollte und sich da gar nichts gerührt hat!!)
Das Ergebnis ist "toggel.png".
Spinne ich jetzt? Wenn ich einen Prozessor (Atmega8) mit 12MHz takte
(siehe Fuses.jpg; Board hat 12MHz-Quarz), dann erwarte ich bei einem
reinen toggeln eines Pins auch 12MHz, oder? Zumindest aber keine 2MHz.
Bits invertieren ist doch nur ein Maschinenbefehl (oder irre ich mich
da?) Aber zumnindest würde ich doch erwarten, dass die HIGH-Zeit
identisch lang ist, wie die LOW-Zeit... Toggel.png zeigt hier aber ein
völlig asymmetrisches Verhalten!?!?! Kann mir bitte jemand erklären,
wieso?
Die main() sieht dabei so aus, wie im Anhang (oder wie hier):
1
...
2
// RFM-Initialisierungen
3
...
4
for(;;)
5
{
6
//rf01_rxdata(data, 32); // 32Bytes empfangen
7
// hier die Daten verarbeiten
8
//EVA_LED1_PORT ^= (1<<EVA_LED1);
9
PORTD&=~(1<<PD6);
10
PORTD|=(1<<PD6);
11
}
(Im "Empfängerbetrieb" sind halt die ersten drei Zeilen einkommentiert
und die beiden Zeilen mit dem Toggeln sind weg).
Noch kurz die Infos vom Anschluss:
Beim Sendeboard sind folgende Jumper gesteckt:
1) VCC
2) SDI
3) SCK
4) NSEL
5) NIRG
Beim Sendeboard sind folgende Jumper gesteckt:
1) VCC
2) SDI
3) SCK
4) NSEL
5) SDO
Außerdem beim 40pol. ein Pullup von Pin 12 (nFFS) an Pin 40 (VCC).
Kann mir bitte jemand verraten, was ich hier jetzt falsch mache? Wenn
sich jemand auch die Sourcen anschauen könnte, wäre ich zwar echt
überglücklich, aber ich bin jetzt schon so verzweifelt, dass ich mich
auch schon freuen würde, wenn mir wenigstens jemand dieses komische
Verhalten beim Toggeln erklären könnte (Frequenz und
Impuls/Pausen-Verhältnis)
Vielen Dank im voraus und viele Grüße,
Michael
A. K. (Gast) schrieb im Beitrag #1696235:
> Hast Du diesen Beitrag schon gesehen?
Ja, habe ich. Aus diesem Beitrag habe ich auch die beiden Dateien
rfm01.zip und rfm02.zip (von Benedikt), die ich hier verwendet habe.
Ich habe hier halt alle 4 Dateien in eine gepackt und auf 868MHz
umgeschrieben. Ohne die beiden ZIPs würde ich vermutlich jetzt noch
daran sitzen, die hoperf-Specs zu "verbessern".
Nur ist das alles mit 433 und nicht 868MHz; daher hoffe ich, dass ich
"nur" noch eine falsche Konfiguration habe.
Ach, noch vergessen zu erwähnen: Die Antennen sind jeweils 1,5mm
Kupferdraht mit 8,6cm Länge. Die Boards stehen ca.20cm voneinander
entfernt.
Aber wie erklärt sich das Toggelverhalten?
Michael B. schrieb:> Bits invertieren ist doch nur ein Maschinenbefehl
Setzen, löschen sind welche. Toggeln nur, indem man nach PINx schreibt,
und das auch nur bei neueren Typen (nicht mega8/16/32-Generation).
Beim Rest von deinem Toggle-Problem habe ich irgendwo den Faden
verloren.
Bei deinen Funkproblemen kann ich Dir leider nicht helfen, aber zum
Toggeln:
Ich weiß zwar nicht was der C-Compiler macht aber das ganze in ASM:
main:
OUT ... 1 Zyklus
OUT ... 1 Zyklus
RJMP main 2 Zyklen
= unsymmetrisch
frank
plup schrieb:> Toggeln, aber richtig:
Hallo plup,
danke für den Tipp; ich hätte geschworen, dass es bei diesem echten
Toggeln auch so unsymmetrisch war. Das hatte ich nämlich ursprünglich
auch so geschrieben. Aber ich habe es jetzt wieder nach Deinen Vorgaben
verbessert und es ist tatsächlich wieder symmetrisch :-)
Nur: Weiß jemand, warum das nur mit 1.2MHz toggelt, wenn doch ein 12MHz
Quarz dran ist?
>Nur: Weiß jemand, warum das nur mit 1.2MHz toggelt, wenn doch ein 12MHz>Quarz dran ist?
in port
xor wert
out port
rjmp anfang
Macht 5 Takte. Toggeln heisst dann ein Durchlauf
für an, einer für aus. Macht 10 Takte und passt perfekt
zu deiner Quarzfrequenz.
Oha, ist das echt so viel Aufwand, einen Pin zu toggeln? Muss da echt
gerechnet (geXORt) werden? Dachte, der ATmega8 kann das selbst. Jetzt
verstehe ich auch, warum viele sagen, man soll erst mit ASM, dann mit C
anfangen, wenn man in die MC-Welt einsteigt.
Danke Holger!
Michael B. schrieb:> Nur: Weiß jemand, warum das nur mit 1.2MHz toggelt, wenn doch ein 12MHz> Quarz dran ist?
Weil toggeln kein Maschinenbefehl ist. Geht nur schneller, wenn du den
richtigen Controller hast, z.B. Mega88:
PIND = 1<<PD6;
Dann 3 Takte / 2 MHz.
Es kommt auch auf Deine Optimierungen an. Compiliert mit -Os ergibt
sich folgender Code:
1
.L2:
2
cbi 50-32,6
3
sbi 50-32,6
4
rjmp .L2
was schon optimal ist (bis auf das Beschreiben von PIN bei neueren AVRs
geht's in Assembler auch nicht besser). Aber der Code macht auch
deutlich, warum Du so keine symmetrische Wellenform erhältst.
Zur Info:
1) Vielen Dank an alle, die mir das mit der Asymmetrie erklärt haben;
das Problem ist inzwischen auch gelöst. Es ist symmetrisch :-)
2) Zum "Hauptproblem" (empfängt nicht): Ich habe einen
Übersetzungsfehler von mir gefunden: In der Funktion:
habe ich ein sbi(...) ganz unten falsch in ein ClearBit(...)
umgewandelt.
1
//sbi(RF_PORT, CS);
2
ClearBit(RF01_NSEL_PORT,RF01_NSEL);
In meiner aktuellen Version steht jetzt richtig SetBit drin.
1
//sbi(RF_PORT, CS);
2
SetBit(RF01_NSEL_PORT,RF01_NSEL);
Leider noch mit gleichem Ergebnis: Es wird immer noch nichts empfangen.
Nachdem der Sourcecode ja eigentlich bei vielen mit den 433MHz-Modulen
läuft, vermute ich, dass ich in der Init oder so für die 868MHz noch
etwas falsch konfiguriert habe. Hat da noch jemand eine Idee?
Die LED2 toggelt in der Empfangsroutine im ca.1MHz-Takt
1
//while (!(RF_PIN&(1<<SDO))); // wait until data in FIFO
Update:
Noch einen Fehler entdeckt:
Der Pulllup für nFFS (10k) hing am falschen Pin. Ich hatte ihn an der
40pol. Buchse zwischen Pin 12 und Pin Pin 40 (VCC) gehängt. Nur doof,
dass die 40.pol Buchse gar nicht mit dem Modul verbunden ist, wenn der
entsprechende Jumper bei J8 gar nicht gesteckt ist. Peinlich.
3 Uhr nachts ist wohl keine gute Zeit zum arbeiten.
Ist jetzt auch berichtigt. Nur: Noch kein Empfang.
Ich habe aber jetzt festgestellt, dass der CLK-Ausgang vom RFM01 nur
noch sehr unmotiviert auf 10MHz umschaltet. Ich habe da jetzt fast immer
0 oder 5V; erst bei mehrfachem resetten kommt manchmal der 10MHz-Impuls
raus. Der Empfang geht dann aber auch noch nicht. (wenn das Modul gar
nicht am MC angeschlossen ist, kommt am CLK aber immer noch 1MHz raus;
dürfte also noch funktionieren)