Forum: HF, Funk und Felder Nochmal zum RFM12


von Christoph H. (webturtle)


Lesenswert?

Wie mir hier Beitrag "RFM12 Ich scheine echt zu blöd zu sein" geraten 
wurde sollte ich ja mit den RFM12 Modulen anders beginnen.

Ich habe nun mal ein Platinchen gemacht um vom Steckbrett wegzukommen 
und mir dieses Datenblatt vorgenommen: 
http://www.octamex.de/shop/datasheet/65eb60c317f2276781a6b6007a20d268.pdf
Darin ist auch der Schaltplan zur Platine.
nFFS ist über 10K an VCC was wohl notwendig ist um das TX Register zu 
nutzen.

Das Beispielprogramm in dem Datenblatt ist auch gut kommentiert und ich 
glaube ich erreiche eine sauber SPI Kommunikation.

Wenn ich an das Modul ein 0x0000 sende bekomme ich den Inhalt des 
Statusregisters. Da geht es dann aber schon los. Im Datenblatt ist nicht 
beschrieben was das Statusregister enthält. Ich kann nur die Infos aus 
dem Artikel auf Mokrocontroller.net heranziehen und die verstehe ich 
nicht wirklich. Vor allem hat dort das Statusregister 18 bit....

Wenn ich nun die Beispielanwendung senden lasse und nach jedem Send das 
Statusregister lese bekomme ich als antwort immer 0xD080. Aber ich kann 
diese Antwort nicht interpretieren.
Nach dem Init des Moduls bekomme ich C000 und nach dem senden des 
gesamten Pakets bekomme ich D0000. Auch hier kann ich den Status aber 
nicht interpretieren.

Auf Empfängerseite bleibt die Sache in der RECV Schleife hängen an der 
Stelle wo gewartet wird dass der nIRQ was macht.
Aber so lange ich nicht weiss ob das Modul korrekt sendet ist es wohl 
sinnlos dort zu forschen.

Wie würdet ihr weitermachen?

: Verschoben durch Moderator
von rfm12 (Gast)


Lesenswert?

Hallo,
guck mal in eines dieser Datenblätter. Da steht deutlich mehr dazu drin:
http://www.silabs.com/products/wireless/EZRadio/Pages/Si442021.aspx

Handelt sich dabei um die Chips, die in den RFM12 Modulen sind.

Viel Erfolg!

von R. W. (quakeman)


Lesenswert?

Ich würde dir auch raten erst mal die RFM12 im Polling und nicht im 
Interrupt Betrieb anzusteuern. Das funktioniert deutlich zuverlässiger, 
wie du etlichen Posts hier im Forum entnehmen kannst. Für einen 
funktionierenden Interrupt Betrieb musst du diverse Register korrekt 
beschreiben, wohingegen der Polling Betrieb per SDO Pin ohne spezielle 
Initialisierung funktioniert. Somit fällt schon mal eine Fehlerquelle 
weg in deinem Programm. Wenn das dann problemlos funktioniert kannst du 
dich ja an den Interrupt Betrieb dranmachen, falls du den wirklich 
benötigst.

Ciao,
     Rainer

von Christoph H. (webturtle)


Lesenswert?

Danke für den Link aber in dem Datenblatt steht auch nicht wirklich mehr 
zum statusregister. Außerdem hat es dort auch 18 Bit.

Zum Polling betrieb: bin mir nicht ganz sicher ob ich das richtig 
verstehe, aber ist der beispiellose nicht eigentlich polling betrieb? Es 
wird jedenfalls kein Interrupt im atmega genutzt.
Der Empfang wartet bis die eine Leitung löw wird. Kann man das ändern?

Koennt ihr was zu den werten sagen die das statusregister mir antwortet?

Sorry dass ich nur von dem beispiellose im Datenblatt Rede. Ich kann 
meinen exakten Code erst heute Abend Posten.

von R. W. (quakeman)


Lesenswert?

Ja, das mit dem Prüfen auf Low-Pegel von SDO ist Polling Betrieb.

Das bei dem Statusregister mehr als 16 Bits angegeben sind kommt daher, 
weil direkt nach dem Statusregister auch gleich der Fifo mit ausgelesen 
wird. Dies ist aber nur ein Beispiel und muss nicht so gemacht werden. 
Es reicht also völlig, wenn du 16 Bits aus dem Statusregister ausliest 
und danach aufhörst. Die Bedeutung dieser 16 Bits sind im Datenblatt zu 
dem IA4420 Controller auf Seite 22 erklärt.
Direkt nach dem Einschalten sollte beim ersten Auslesen des 
Statusregisters das POR Bit gesetzt sein. Dieses wird beim Auslesen dann 
automatisch wieder zurückgesetzt.

Ciao,
     Rainer

von Christoph H. (webturtle)


Lesenswert?

Danke für ide Geduld.
Will kurz meine Fortschritte berichten:
Der Tip wie man das Statusregister liest war Klasse.
Ich wusste nun, dass ich nach dem Power On des Moduls eine 4000 
empfangen muss. Das war aber nicht der Fall.
Also war die SPI Kommunikation nicht okay. Woran konnte es liegen.
Ettliches lesen und der Code von Benedikt brachten mich auf die Idee. Da 
ich in den Beispielen ja nicht das SPI Interface des AVR genutzt habe 
sonder quasi ein Bit Banging konnte es ja vielleicht sein, dass ich zu 
schnell war.
Im Code von Benedikt fand ich in der SPI Senderoutine ein Deley von 0.3 
us.
Das versuchte ich auch und siehe da, ich hatte die 0x4000.
Dann ging es recht schnell. Ich arbeitete dann direkt mit dem Code von 
Benedikt weiter und kann jetzt sauber senden und auf einem anderen Modul 
empfangen. Dort werde ich aus und sende dann was an den UART.
Geht. Ich kann sauber 6 Fälle unterscheiden, was mir momentan ausreicht.
Ich denke ab jetzt gehts einfach und schnell weiter.

Vielleicht sehe ich mir jetzt sogar noch die ASK Routine aus der Lib an.

Danke allen, Chris

von R. W. (quakeman)


Lesenswert?

Christoph Hoell schrieb:
> Der Tip wie man das Statusregister liest war Klasse.
> Ich wusste nun, dass ich nach dem Power On des Moduls eine 4000
> empfangen muss. Das war aber nicht der Fall.

Das ist nicht ganz das, was ich meinte. Ich sagte, dass das Bit POR 
gesetzt sein muß, aber das bedeutet nicht, daß eventuell auch andere 
Bits gesetzt sein könnten. Somit muss der empfangene Wert nicht 
unbedingt 0x4000 sein sondern irgend etwas >= 0x4000. Also beim Prüfen 
auf POR nicht die Zahl mit 0x4000 vergleichen sondern testen ob das Bit 
gesetzt ist.

Aber wenn die Kommunikation jetzt endlich funktioniert dann freut mich 
das für dich. :)

Ciao,
     Rainer

von Christoph H. (webturtle)


Lesenswert?

Ja stimmt.
Die Annahme meinerseits kam daher, dass ich mit dem Pollin Funkboard 
gearbeitet habe.
Da muss ich zum programmieren des µC immer das RFM12 abstecken per 
Jumper.
Ich nehme dass dadurch dass es stromlos einfach auch immer die 4000 kam. 
Ich hab aber keinen Vergleich damit gemacht, sondern es mir auf den UART 
geben lassen. In Binär- und Hexadezimaldarstellung.

Eine Sache noch, wo ich gestern nicht mehr ganz schlau draus wurde.
Ich habe jetzt einen Sender. Der sendet mir im Testbertrieb permant: 
"Dies ist Befehl A"
Auf dem Empfanger empfange ich diesen Text und kann auch ne Checksumme 
bilden, indem ich einfach mal die einzelnen Zeichen aufaddiere.
Das sind beides Atmega48.
Im fertigen Projekt soll der Empfänger ein Atmega32 sein. Nun empfängt 
der zwar auch, aber nur Blödsinnige Zeichen. (@'¿¿≠¿... und so)
Aber die Ckecksumme istbei jedem Empfang gleich.

Es ist der gleiche Code. Nur andere IO Pins wegen dem Mega 32.

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.