Forum: Mikrocontroller und Digitale Elektronik Zerstört Pollin-Board den RFM02?


von Robert K. (mr_insanity)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe ein Problem mit dem RFM02 auf dem Pollin-Board. Hatte dazu auch 
schon mal hier: Beitrag "Problem mit RFM02" und 
hier: Beitrag "Endlosschleife?" etwas dazu 
gepostet.

Hier nochmal das Programm:
1
#include <avr/io.h>
2
#include <avr/interrupt.h>
3
#include <avr/pgmspace.h>
4
#include <avr/eeprom.h>
5
#include <stdlib.h>
6
#include <util/delay.h>
7
#include "global.h"
8
#include "rf02.h"
9
10
#define Taster_PORT PORTB
11
#define Taster_DDR   DDRB
12
#define Taster_PIN   PINB
13
#define Taster 1
14
15
#define LED_PORT  PORTD
16
#define LED_DDR   DDRD
17
#define LED_PIN   PIND
18
#define LED 5
19
20
21
unsigned char test[2]="01";
22
23
int main(void)
24
{
25
  Taster_DDR &= ~(1<<Taster);
26
  LED_DDR |= (1<<LED);
27
  
28
  rf02_init();          // ein paar Register setzen (z.B. CLK auf 10MHz)
29
  rf02_setfreq(RF02FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
30
  rf02_setpower(0);        // -0dBm Ausgangangsleistung
31
  rf02_setmodfreq(3);        // 120kHz Frequenzshift
32
  rf02_setbaud(19200);      // 19200 Baud
33
  SREG &= ~(1<<7);
34
  
35
  
36
  while(1)
37
  {
38
    if (Taster_PIN & (1<<Taster))
39
    {
40
      rf02_txdata(test,2);
41
      LED_PORT |= (1<<LED);      
42
      _delay_ms(1000);
43
      LED_PORT &= ~(1<<LED);
44
    }
45
  }
46
}

Nun habe ich mal versucht das auf einem Mega32 zu debuggen und habe 
dabei festgestellt, dass das Programm immer an einer bestimmten Stelle 
hängen bleibt. Ich lasse es einfach laufen, drücke den Taster und 
pausiere es dann. Dabei bleibt es jedesmal an folgender Stelle hängen:
1
void rf02_shiftout(unsigned char wert)
2
{  unsigned char j;
3
  for (j=0; j<8; j++)
4
  {  
5
    while(IRQ_PIN&(1<<IRQ));
6
    while(!(IRQ_PIN&(1<<IRQ))); <---- Hier bleibt es hängen
7
    if (wert&128)
8
        sbi(SDI_PORT, SDI);
9
      else
10
        cbi(SDI_PORT, SDI);
11
      wert<<=1;
12
    }
13
}
Es kommt also wohl kein IRQ-Request vom RFM02.

Diese Funktion stammt aus der angehängten Library.

Ich dachte mir dann, vielleicht ist ja das RFM02 defekt und habe es 
durch ein nagelneues getauscht. Nachdem Einschalten des Boards 
funktionierte es genau einmal. Also die LED leuchtete nach dem Betätigen 
des Tasters einmal, so wie es sein sollte. Ein weiteres Mal 
funktionierte es aber nicht. Auch ein Reset oder Trennen von der 
Stromversorgung half nichts.
Könntes es nun sein, dass das RFM02 aus irgendeinem Grund gekillt wird? 
Oder hängt es sich vielleicht irgendwie auf?
Kann ich irgendwie testen, ob das Modul noch funktioniert?
Ich weiß wirklich nicht mehr weiter!

MfG
Robert Knipp

von Robert K. (mr_insanity)


Lesenswert?

Hat denn keiner eine Idee, woran das liegen könnte?

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Vom RF12 Datenblatt her (s. Artikelsammlung) macht die 2. while-Schleife 
IMHO keinen Sinn. Der Empfänger (das RF02 Modul) zeigt ja durch ein LOW 
auf der nIRQ Leitung, dass er vom µC neue Daten empfangen mag. Dann 
sollte man die vom µC aus auch liefern und nicht in einem while trödeln. 
Das rf02 kann dann den IRQ-Request schicken wie es will, durch die 
while-Falle kommt der nie durch! Wenn der Code beim ersten Mal 
funktioniert, hat das andere Gründe.

ADD: Wo kommt denn die Library her? Hast du die geschrieben oder 
umgeschrieben?

von Robert K. (mr_insanity)


Lesenswert?

Vielen Dank für den Tip!
Habe die Schleife mal auskommentiert und es läuft nun durch. Aber der 
Benedikt hat sich doch sicher etwas bei dieser Schleife gedacht. Naja, 
werde mal das RFM01, welches übrigens der Empfänger ist (RFM02 ist 
Sender), in Betrieb nehmen. Vielleicht empfängt es ja was.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Mit "Empfänger" meine ich das Ding, das hier vom µC ("Sender") 
angesprochen wird. Nicht die Funktion bzw. den Funkteil. Ich sollte 
vielleicht besser Master (µC)/Slave (RFxx Modul) benutzen und 
Sender/Empfänger nur bei der Funktion der RFxx Module.

von Benedikt K. (benedikt)


Lesenswert?

Stefan "stefb" B. wrote:
> Vom RF12 Datenblatt her (s. Artikelsammlung) macht die 2. while-Schleife
> IMHO keinen Sinn. Der Empfänger (das RF02 Modul) zeigt ja durch ein LOW
> auf der nIRQ Leitung, dass er vom µC neue Daten empfangen mag.

RF12 und RF02 darf man nicht vergleichen! Der RF02 hat keinen FIFO, er 
zeigt mit einem kurzen Impuls an, wann er neue Daten haben möchte. Daher 
muss man beide Flanken abfragen. Ohne die zweite abfrage, wird der RF02 
mit Daten zugemüllt. Wenn der µC zu langsam läuft, oder irgendein 
Interrupt dazwischen kommt, dann verpasst er den Impuls. Es gibt zwar 
auch einen undokumentierten Befehl mit dem man den RF02 in eine andere 
Betriebsart versetzen kann (in der dann ein Rechteck mit 50% duty 
rauskommt), aber irgendeinen Grund wird es haben, warum dieser Modus 
nicht in der Dokumentation auftaucht. Der Hersteller gibt dazu keine 
weiteren Infos raus, außer dessen Existenz zu bestätigen.
Da die RFM12 beim Hersteller genausoviel kosten wie die RF02 bin ich 
seitdem auf die RF02 übergewechselt. Die sind sehr viel schöner 
anzusteuern, RF02 ist echt eine Qual.

von Robert K. (mr_insanity)


Lesenswert?

>...bin ich seitdem auf die RF02 übergewechselt.

Du meinst wohl auf RFM12?

Ich habe die RFM02 genommen, da ich damit eine Fernbedienung realisieren 
möchte und ich mir dachte, Senden reicht ja, nehme ich die RFM02.

Die Schleife muss also drin bleiben? Aber warum hängt er denn da immer?

von Benedikt K. (benedikt)


Lesenswert?

Ja, RFM12.
Es gibt 2 Möglichkeiten wieso er hängen bleibt:
- Der AVR ist zu langsam (ich glaube mindestens 4-5MHz braucht die 
Software um den Impuls sicher zu erkennen)
- aus irgendeinem Grund gibt der RF02 keine Impulse aus (da er 
vermutlich nicht richtig initialisiert wurde).

von (prx) A. K. (prx)


Lesenswert?

Nachteil des RFM12 ist, dass es nicht als 866MHz 5V-Version verfügbar 
ist, sondern nur als RFM12B für 3,3V. Die RFM01/02 hingegen schon.

von Benedikt K. (benedikt)


Lesenswert?

A. K. wrote:
> Nachteil der RFM12 ist, dass es sie nicht als 866MHz 5V-Version gibt,
> sondern nur als RFM12B für 3,3V. Die RFM01/02 hingegen schon.

Nein, da bist du falsch informiert. Ich habe genau diese Version im 
Einsatz (RFM12 868). Siehe auch hier:
http://www.hoperf.com/pro/RFM12.html

von (prx) A. K. (prx)


Lesenswert?

Ok, also wo gibt es das, ohne direkt bei Hope kaufen zu müssen?

von Robert K. (mr_insanity)


Lesenswert?

>- Der AVR ist zu langsam (ich glaube mindestens 4-5MHz braucht die
>Software um den Impuls sicher zu erkennen)

Der läuft mit 16MHz


>- aus irgendeinem Grund gibt der RF02 keine Impulse aus (da er
>vermutlich nicht richtig initialisiert wurde).

Habe die Initialisierungsroutine eigentlich nicht verändert. Habe auch 
mal das Delay in der Routine vergrößert und sie auch mal mehrmals 
ausführen lassen am Anfang. Hat alles nichts geholfen.

von Stefan B. (stefan) Benutzerseite


Angehängte Dateien:

Lesenswert?

@ Benedikt

Danke für den Hinweis, dass RF02 anders als der RF12 ist. Den 
Sachverhalt an sich verstehe ich noch nicht.

Sehen die Impulse so aus wie im Bild oben? Das ist das einzige, dass ich 
mit nIRQ Wechseln beim RF02 (http://www.hoperf.com/pdf/rf02.pdf) finde. 
nach dem Bild würde ich die 2. while Schleife (Warten auf nIRQ HIGH) 
hinter die if/else-Anweisung setzen.

von Benedikt K. (benedikt)


Lesenswert?

Stefan "stefb" B. wrote:

> Sehen die Impulse so aus wie im Bild oben? Das ist das einzige, dass ich
> mit nIRQ Wechseln beim RF02 (http://www.hoperf.com/pdf/rf02.pdf) finde.

Ja. Das sind die Impulse.

> nach dem Bild würde ich die 2. while Schleife (Warten auf nIRQ HIGH)
> hinter die if/else-Anweisung setzen.

Meine Idee war, dass mit der steigenden Flanke neue Daten ausgegeben 
werden, da das Modul die Daten mit der fallenden Flanke speichert.
Andersrum sollte es aber genauso funktionieren. Wichtig ist nur, beide 
Flanken abzufragen.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Ich meine, so könnte es besser gehen, weil das Modul so mehr als 1,6 µs 
Zeit hat, das richtige Bit zu sehen.

Müsste man aber im Oszi anschauen, ob die Spur im Bild oben realistisch 
ist (nIRQ LOW länger als nIRQ HIGH) und wieviel Zeit das Erhöhen und das 
Prüfen von j brauchen (muss <1,6 µs sein!).

ADD: Die Zeit für Beginn der nächsten Schleife sollte sogar egal sein, 
wenn das >1,6 µs dauert, rauscht der Programmablauf einfach durch das 
erste while durch und macht legal mit dem nächsten Bit weiter.
1
void rf02_shiftout(unsigned char wert)
2
{  
3
  unsigned char j;
4
  for (j = 0; j < 8; j++)
5
  {  
6
    while(IRQ_PIN & (1 << IRQ));   // auf fallende Flanke nIRQ warten
7
    if (wert & 128)                // Bit anlegen
8
        sbi(SDI_PORT, SDI);
9
      else
10
        cbi(SDI_PORT, SDI);
11
    wert <<= 1;
12
    while(!(IRQ_PIN & (1 << IRQ))); // auf steigende Flanke nIRQ warten
13
  }
14
}

von Robert K. (mr_insanity)


Lesenswert?

Habe das mal entsprechend geändert. Der bleibt trotzdem immer beim 
Warten auf die steigende Flanke hängen.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Hast du mal nachgesehen, ob die Versorgungsspannung noch reicht, wenn 
das erste Bit auf die Reise soll (s. bei Bug #1 Optokoppler bei 
http://www.controller-designs.de/index.php?lang=de&cat=internal&cont=info_pollinfunkboard&sub=)

Bzw. ich sehe in deinem main() nirgends, dass du über PORTD PD4 den 
Optokoppler OK1 auf dem Pollin-Funkboard einschaltest. Wenn du dieses 
Board hast, fehlt dem Modul die Versorgungsspannung und es grabscht sich 
"zuwenig zum Leben und zuviel zum Sterben" aus den Datenleitungen. 
Vielleicht fehlt ihm beim Senden des ersten Bits dann endgültig der Saft 
um nIRQ kurz hochzuziehen.

von Robert K. (mr_insanity)


Lesenswert?

Mein Board hat keinen Optokoppler.

von Robert K. (mr_insanity)


Angehängte Dateien:

Lesenswert?

Das sieht so aus.

Da steckt man alles über Jumper.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Ah v1.2, sieht besser aus. Mir gehen aber jetzt die Ideen aus und zwei 
falsche Mutmaßungen heute reichen.

von Robert K. (mr_insanity)


Lesenswert?

@Benedikt

Also ich habe mit Hilfe des Beispielprogrammes von Pollin, was Deinem ja 
auchsehr ähnlich ist, und dem Datenblatt vom rf02 nochmal etwas 
herumprobiert. Das Programm bleibt aber immer noch an der selben Stelle 
hängen, wobei es auch egal ob man das zweite while vor oder nach dem 
Anlegen des SDI Signals einfügt.

Witzigerweise hat es einmal nach dem Aufspielen auf den Controller 
einmal funktioniert.

Hast Du das Programm denn mal mit einem RFM02 zum laufen bekommen?

von Benedikt K. (benedikt)


Lesenswert?

Ja, ich hatte mit der Software die ich im Forum gepostet habe (also 
RFM01 + RFM02) Daten übertragen. Allerdings nur Testweise, danach habe 
ich die RFM01+02 beseite gelegt und mich mehr mit dem RFM12 beschäftigt.

Hast du ein Oszilloskop? Falls ja, dann mess mal am IRQ Ausgang, da 
müssten mit der Baudrate Impulse erkennbar sein.

von Robert K. (mr_insanity)


Lesenswert?

Ich habe leider keins.
Aber ich denke mal da wird auch nicht viel kommen. Sonst würde doch auch 
der Controller nicht immer an der selben Stelle hängen bleiben, oder?

von Benedikt K. (benedikt)


Lesenswert?

Ich kontrolliere sowas gerne mal nach, um Verdrahtungsfehler usw. 
auszuschließen. Man kann aber davon ausgehen, dass beim AVR nichts 
ankommt. Wieso nichts ankommt, da kann ich leider auch nur raten, das 
könnte alles mögliche sein.

von Robert K. (mr_insanity)


Lesenswert?

hmm.... vielleicht bestelle ich mir einfach mal ein paar RFM12 und 
versuche es damit mal.

von Jens K. (studone)


Lesenswert?

Hab grad eben nen post zu diesem Problem gemacht.

Siehe hier..

Beitrag "Re: Problem mit RFM02"

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.