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
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...
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
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
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
