www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM12 - ein bisschen mehr als spielen.


Autor: Thomas Maier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag :-),

ich habe mir vor einiger Zeit ein paar RFM12-Module und zwei zugehörige 
Funk-Evaluation-Boards von Pollin gekauft. Jetzt habe ich mich ein 
paarmal rangesetzt...und siehe da...es funkt :-).So weit, so gut! Aber 
ich brauch mehr. Ich bekomme es nicht so wirklich gebacken mehr als 
Testprogramme zu bauen. Nachdem das aber alles ernsthaft verwendet 
werden soll, wäre es toll - wenn das ginge ;-). Und bevor ich mir da 
jetzt selber ein riesen Gerüst aufbaue...dachte ich mir...lobe die 
Abstraktion - es muss ein Protokoll her. Und da wären wir beim Thema:

Ich habe mich für das S.N.A.P.-Protokoll entschieden (war das ein 
Fehler?). Jetzt habe ich aber nicht wirklich einen Ansatz wie ich das 
implementieren soll. Zu Bascom-Projekten gibt es jede Menge Hilfe, bei 
GCC siehts da ja eher schlecht aus. Hat denn jemand von euch zufälig ein 
Projekt rumliegen in dem S.N.A.P für nen ATmega8 (o.Ä) an einem 
RFM12-Modul implementuert ist, vielleicht sogar noch für die Pinbelegung 
des Pollin-Evaluation-Boards? Prinzipiell kanns auch jedes andere 
Protokoll sein..ich habe mich da nicht festgesetzt. Es sollte möglichst 
"flach" sein. Ich brauche eigentlich nur "Geräte-ID's", auf 
Fehlerkorrektur kann verzichtet werden, quasi ein UDP in klein...

BTW: Falls mir jemand aus Stuggi hilft, gibts gern n Bier ;-)

Viele Grüße,
Thomas

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du dir das schon mal angesehen?
http://www.ethersex.de

Gruß
Roland

Autor: Thomas Maier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,
Danke für die schnelle Antwort. Ich hab mir das Projekt gerade mal 
angeschaut - colle Sache! ich habe allerdings das Gefühl, dass das ein 
bisschen zu viel für mich kann. Ich denke das wäre einfach 
überdimensioniert. Das einzige was ich übertragen will, ist 
bidirektional AN oder AUS zwischen drei RFM12's...

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

mit fertigen Lösungen sieht das wirklich schlecht aus, das habe ich auch 
festgestellt. Es sieht so aus, als würde ich meine eigene Lösung bauen 
müssen. SNAP halte auch ich für eine gute Wahl.

Meine Planungen sehen so aus

1.) Datenübertragung mit Hilfe einer Interrupt-Routine (INT1), analog zu 
den RS232-Lösungen. Die Module sind wohl ein wenig biestig, weswegen 
einige sie nur pollen. Das nützt mir aber nichts. Die ISR-Routine soll 
etwa so aussehen: Status des RFM auslesen, je nach Modus:
Empfangen: Byte abholen, SNAP-Sync-Byte erkennen bzw. wenn schon vorher 
erkannt, neues Byte in Empfangspuffer schreiben. Wenn Puffer schon voll: 
Verwerfen.
Senden: Wenn noch Daten im Sendepuffer sind: neues Byte senden. Sonst 
Sender abschalten.

Beim Senden stellt eine Routine des Hauptprogrammes den SNAP-Frame 
inklusive der Füllbytes vor UND nach dem Frame zusammen, schaltet das 
RFM12 auf Senden und schreibt ggf. das erste Byte. Zurückschalten auf 
Empfang übernimmt wie gesagt die ISR.

Die Auswertung, ob ein gültiger Frame empfangen wurde, übernimmt nicht 
die ISR, sondern eine Routine des Hauptprogrammes. Die löscht auch ggf 
den Empfangspuffer.

Implementieren werde ich nur eine Untermenge des SNAP-Protokolls. 
Maximal 32 Byte Payload (vielleicht auch nur 16) sind erlaubt. Dann 
beschreibt der Wert des SNAP-Protokolls exakt die Bytes, was bei 
größeren Frames nicht der Fall ist. Ggf. könnte daher die ISR schnell 
und einfach bestimmen, ob schon genug Bytes empfangen wurden.

Es gibt nur Ein-Byte-Adressen und es wird nur CRC8 als Absicherung 
verwendet (Routinen zur Berechnung findet man beim DS1820-Sensor)

Zur Entprellung der Tasten habe ich eine ISR-Routine (hier aus dem 
Forum), die den TIMER0 verwendet und die alle 4ms aufgerufen wird. In 
dieser wird jetzt zusätzlich ein uint8_t hochgezählt, wenn er nicht 
schon 0xFF ist. Die RFM12-Empfangsroutine soll diesen Wert zurücksetzen, 
wenn ein Byte empfangen wurde (timeout).

So kann das Hauptprogramm feststellen, ob gerade jemand sendet oder 
nicht. Setzt man den Wert nicht auf 0 zurück, sondern auf (TCNT0 & 
0x7F), so ergibt sich ein relativ zufälliger Time-Out-Wert von 0.5 bis 
1s, so dass sich die verschiedenen Sender nicht so leicht in die Quere 
kommen.

ACK/NAK habe ich (noch) nicht eingeplant. Eine mögliche Lösung aus 
meiner Sicht: Die Entprellroutine bekommt eine zusätzliche uint16_t 
Variable, die bis auf null runtergezählt wird (Time-Out für Antwort). 
Die Zahl der Adressen wird auf 128 (0x00-0x7F) begrenzt. Das oberste Bit 
wird bei jedem neuen(!) Paket getoggelt, bei einer Wiederholung also 
gerade nicht. (Das habe ich mir von den IR-Fernbedienungen abgeguckt) 
Der Empfänger braucht ein maximal 16-Byte großes Bit-feld, wo diese Bits 
gespeichert werden um zu erkennen, ob es sich bei diesem speziellen 
Sender um ein neues Paket handelt.

So weit meine Ideen.

Gruß, DetlevT

Autor: Thomas Maier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hört sich interessant an :-). Ist das bisher "nur" eine Idee? Ich schaue 
mir gerade noch die RFM12-lib 
http://www.das-labor.org/wiki/RFM12_library an...schaut auch nicht 
schlecht aus.

Viele Grüße,
Thomas

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

diese Library kannte ich noch nicht. Die Interruptbehandlung werde ich 
mir wohl abgucken. Ansonsten gefällt mir das Ganze nicht so, die 
ISR-Routine ist mir viel zu lang und macht zu viel.

Noch ist alles in der Planung, Code gibt es noch nicht. Ich arbeite an 
einer gcc-avr-Library, die für einen ATMEGA328p die typische Hardware 
abdecken soll (Tastenentprellung, LCD, RC-5/NEC Remote Control, 
EM4095-RFID, DS1820, RTC, UART, SPI, I2C, ADC, PWM, externes EEPROM 
(24C512) mit einem einfachen Datei-System, SD-Card mit 
FAT16-Unterstützung, eine interne Uhr, SHT-11 Feuchtesensor, 
BMP08-Drucksensor und halt auch RFM12 mit SNAP-Protokoll)

Das soll alles in einer einbindbaren Library (.a) enden, wo der Linker 
sich automatisch herauspickt, was er gerade braucht. Da muss man ein 
bisschen im Voraus planen. :D

Gruß, DetlevT

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.