RFM12b 868MHz

[Marco R. (Gast)]

Hallo,
Seit einigen Tagen versuche ich ein Programm für das RFM12b Modul 
(868Mhz) zu schreiben (Programm im Anhang), leider bis jetzt ohne 
Erfolg. Ich habe etliche Programmierguids durchgelesen und mich an diese 
gehalten... kann mir deshalb auch keinen Fehler mehr erklähren. Leider 
finde ich auch keine wirklich verständliche library im Internet.

Details zum Projekt:

µController: Atmega8
Sender/Empfänger: RFM12b 868Mhz

Beschaltung:

Atmega --> RFM12b

Vcc --> Vcc
GND --> GND
SCK --> SCK
MOSI --> SDI
MISO --> SDO
PD7 --> nIRQ
SS --> nSEL

CLK,nRes, DCLK, nINT --> nicht belegt
FSK mit 10k pullup auf Vcc


Ich wäre würklich froh über Programme, Fehlerkorekturen oder 
Anleitungen.

mfg. Marco R.

[Christian S. (roehrenvorheizer)]

Hallo,

es gab dazu früher schon etwas:
Beitrag "bidirektionale RS232 Funkbrücke mit RFM12"

MfG

[c-hater (Gast)]

Marco R. schrieb:

> Beschaltung:
>
> Atmega --> RFM12b
>
> Vcc --> Vcc
> GND --> GND
> SCK --> SCK
> MOSI --> SDI
> MISO --> SDO
> PD7 --> nIRQ
> SS --> nSEL
>
> CLK,nRes, DCLK, nINT --> nicht belegt

OK soweit.

> FSK mit 10k pullup auf Vcc

Nicht nötig für RFM12b (für RFM12 hingegen schon), schadet aber auch 
nicht.

> Ich wäre würklich froh über Programme, Fehlerkorekturen oder
> Anleitungen.

Tja, du hast leider alles entscheidende NICHT gesagt:

Was GENAU willst du erreichen? Wie hast du den RFM12b für diesen Zweck 
initialisiert?

Diese RFM12(b) sind funk- und protokollmäßig relativ mächtige Teile, man 
kann sie für viele Anwendungsfälle einsetzen. Dementsprechend komplex 
ist die korrekte Initialisierung. Man muss einfach wissen, was man 
erreichen will und sie dafür passend initialisieren.

Allerdings: bevor man sich damit abgibt, kann man auf jeden Fall erstmal 
etwas anderes testen: nämlich, ob die Kommunikation zwischen lokalem µC 
und RFM12 überhaupt korrekt funktioniert und damit auch die 
grundlegenden zwei Softwareschichten: SPI und Statusabfrage.

Wenn (wie in deiner Hardwarekonfig) nRes nicht mit dem µC verbunden ist, 
aber beide Teile an einer Versorgung hängen, fängt das erstmal damit an, 
dass man nach einem PowerOn dem RFM12 erst einmal 100ms genehmigt, bevor 
man überhaupt das erste Mal an seinen Beinchen wackelt...

Dann sollte man nIRQ checken. Wenn nicht Low, ist irgendwas mit der 
Hardware im Argen. Wenn Low: Statusregister des RFM12 das erste Mal 
lesen. Da sollte (mindestens) eins der IRQ-Bits gesetzt sein, nämlich 
POR. Logisch, oder?! Wenn nicht: Irgendwas ist mit der Hardware oder der 
SPI-Implementierung im Argen.

Dann liest man zur Sicherheit das Statusregister noch einmal, POR sollte 
jetzt aus sein (weil das Lesen des Statusregisters das POR-Flag des 
RFM12 löscht). Nicht? Hardware oder SPI-Software funktioniert nicht 
korrekt.

OK? Ab diesem Moment kannst du davon ausgehen, dass der RFM12 bereit 
ist, alles das zu tun, was du ihm aufträgst und du kannst in die normale 
Behandlung der Kommunikation mit ihm eintreten.

Was dann genau zu machen ist, hängt, wie schon gesagt, davon ab, was du 
mit dem Teil eigentlich machen willst...

[Marco R. (Gast)]

Ersteinmal danke für die schnelle Antwort.
Ich will in weiterer folge das RFM12 Modul zur übertragung von Sensor 
Daten verwenden. Es sollte möglich sein Daten von Gyro Modulen und GPS 
Modulen bidirektional zu senden.

[grundschüler (Gast)]

funk ist ja im Prinzip onewire. Die Übertragung hat Ähnlickeit mit IR. 
Dazu gibt es jede Menge code. Also schauen, dass man einen Eingangspin 
per Funk getoggelt bekommt und dann ein IR-Protokoll implementieren.

[Felix P. (fixxl)]

Dein Datentransfer funktioniert nicht, weil du dem Modul keine Zeit 
gibst, die Daten zu versenden. Das Modul kann intern lediglich zwei 
Bytes speichern und du darfst das nächste Bit immer erst per SPI 
nachschieben, nachdem eins versendet worden ist.

Du musst daher immer kontrollieren, ob ein Speicherplatz frei ist, bevor 
du die Daten schickst. Das geht am besten, indem man, während SDI low 
ist, einfach nur den Chip-Select auf low zieht, anschließend den Zustand 
der SDO-Leitung abfragt und danach den Chip-Select wieder auf high 
zieht. War SDO high, kann man das Byte übertragen, ansonsten muss man 
noch warten.

Am Ende der Übertragung bieten sich zudem zwei Dummy-Bytes an, damit 
auch sicher ist, dass wirklich alle Daten, die man übertragen wollte, 
rausgeschickt worden sind.