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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.