www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM01+02 und der sichere Weg in den Wahnsinn


Autor: Michael B. (planlessmichi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
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):
  ...
  // RFM-Initialisierungen
  ...
  for (;;)
  {  
    //rf01_rxdata(data, 32);    // 32Bytes empfangen
    // hier die Daten verarbeiten
    //EVA_LED1_PORT ^= (1<<EVA_LED1);
    PORTD &= ~(1<<PD6);
    PORTD |= (1<<PD6);
  }

(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

Autor: Michael B. (planlessmichi)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu Anschluss siehe auch 
Beitrag "Re: RFM02 Pinbelgung beim ATMEGA8"

Inbesondere die vom RFM02 ist nur eine Möglichkeit, geht auch anders.

Autor: A. K. (prx)
Datum:

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

Autor: plup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Toggeln, aber richtig:

for (;;)
  {
    //rf01_rxdata(data, 32);    // 32Bytes empfangen
    // hier die Daten verarbeiten
    //EVA_LED1_PORT ^= (1<<EVA_LED1);
    PORTD ^= (1<<PD6);
  }

Autor: frank (Gast)
Datum:

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

Autor: Michael B. (planlessmichi)
Datum:
Angehängte Dateien:

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

Autor: frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schrieb Blödsinn. Ist noch zu früh, sorry.
frank

Autor: Michael B. (planlessmichi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-) Wollte mich trotzdem gerade bedanken :-) Für mich klang das sogar 
logisch :-)

Autor: holger (Gast)
Datum:

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

Autor: Michael B. (planlessmichi)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt auch auf Deine Optimierungen an.  Compiliert mit -Os ergibt 
sich folgender Code:
.L2:
        cbi 50-32,6
        sbi 50-32,6
        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.

Autor: Michael B. (planlessmichi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  void rf01_rxdata(unsigned char *data, unsigned char number) {...}

habe ich ein sbi(...) ganz unten falsch in ein ClearBit(...) 
umgewandelt.
  //sbi(RF_PORT, CS);
  ClearBit(RF01_NSEL_PORT, RF01_NSEL);

In meiner aktuellen Version steht jetzt richtig SetBit drin.
  //sbi(RF_PORT, CS);
  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
  //while (!(RF_PIN&(1<<SDO))); // wait until data in FIFO
  while (!(RF01_SDO_PIN&(1<<RF01_SDO)))
  {
    // wait until data in FIFO
    EVA_LED2_PORT ^= (1<<EVA_LED2);
  }

Autor: Michael B. (planlessmichi)
Datum:

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

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.