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
Hat denn keiner eine Idee, woran das liegen könnte?
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?
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.
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.
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.
>...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?
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).
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.
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
Ok, also wo gibt es das, ohne direkt bei Hope kaufen zu müssen?
>- 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.
@ 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.
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.
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 | }
|
Habe das mal entsprechend geändert. Der bleibt trotzdem immer beim
Warten auf die steigende Flanke hängen.
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.
Mein Board hat keinen Optokoppler.
Das sieht so aus.
Da steckt man alles über Jumper.
Ah v1.2, sieht besser aus. Mir gehen aber jetzt die Ideen aus und zwei
falsche Mutmaßungen heute reichen.
@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?
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.
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?
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.
hmm.... vielleicht bestelle ich mir einfach mal ein paar RFM12 und
versuche es damit mal.
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.
|
Thread beobachten
Seitenaufteilung abschalten