Hallo zusammen, ich versuche jetzt schon seit längerer Zeit ein RFM12 Modul zur Ansteuerung von Funksteckdosen zu verwenden, leider scheitert es schon an der Konfiguration über SPI. Verwendet wird ein Kinetis K60 ARM-Prozessor mit dem Betriebssystem uTasker, deswegen kann ich mit den AVR-Codebeispielen nur bedingt etwas anfangen. Zum Problem: Ich habe die SPI im Mode 0 konfiguriert (CPOL = 0, CPHA = 0) und auf 1,5Mhz getaktet. Gesendet werden 16Bit Worte, also die erwarteten 2 Bytes. Nach Anschalten des Funkmoduls bekomme ich als Status 0x4000 gesendet, danach kann ich senden was ich will, der Status bleibt 0x0000. Die Frequenz des CLK-Pins lässt sich auch nicht ändern, was ja auf eine fehlerhafte Kommunikation zurückzuführen wäre. Ich habe alle vier Pins (nSEL,SDI,SDO,SCK) an einem Oszilloskop angeschlossen und dort sieht die Kommunikation meiner Meinung nach richtig aus (bis auf die falsche/fehlende Antwort...). Antworten tut das Modul auf manche Anfragen, allerdings ist dabei immer nur das letzte Byte gesetzt. z.B.: Anfrage: 0x000A Antwort: 0x0008 Anfrage: 0x000F Antwort: 0x000D Anfrage: 0x0000 Antwort: 0x0000 Hat vielleicht irgendjemand eine Idee was ich noch versuchen könnte bzw. was ich vergessen habe? Ich verzweifle echt langsam an dem Kram, kann es aber auch nicht sein lassen :) Mit freundlichen Grüßen P.B.
PS: Habe gefühlt 10000 Artikel und Forenbeiträge gelesen also bitte nicht von wegen Suchfunktion oder Google antworten. Danke
Das RFM12 antwortet nur auf 2 Kommandos mit nicht-0-Bytes, die Statusabfrage, und das FIFO Read Command. Wenn du das RFM12 nicht dazu konfiguriert hast, etwas zu empfangen o.ä. ist der Status eben immer 0 (außer direkt nach dem Reset, da ist das Power On Reset Flag gesetzt => Status = 0x4000). Und wenn es eben nichts empfangen hat, zB wegen falscher Konfiguration, ist im FIFO eben auch nur eine 0. Anfrage: 0x000A Antwort: 0x0008 Anfrage: 0x000F Antwort: 0x000D Anfrage: 0x0000 Antwort: 0x0000 Die ersten beiden sind keine gültigen Anfragen - das höchste Bit ist '0', also eine Status-Wort-Abfrage, aber der Reest des Kommandos enthält nicht-0-Bits - also doch keine Status-Wort-Abfrage, aber was dann?
Habe auch mal alle Kommandos von Hand nach und nach gesendet um auszuschließen das sie zu schnell kommen, danach sollte die Statusabfrage doch etwas anderes als 0 liefern oder nicht? Was auch sehr merkwürdig ist und eigentlich auf eine funktionierende Kommunkation hindeutet, dass wenn ich 0xfe00 (Soft-Reset) schicke und danach die Statusabfrage, das Modul wieder mit 0x4000 antwortet. Wie groß sollte die Verzögerung zwischen zwei Kommandos sein? Gruß P.B.
P. B. schrieb: > Habe auch mal alle Kommandos von Hand nach und nach gesendet um > auszuschließen das sie zu schnell kommen, danach sollte die > Statusabfrage doch etwas anderes als 0 liefern oder nicht? Wieso? Wenn du einfach irgendwas sinnloses sendest, muss das Modul doch nicht irgendwas sinnvolles machen... Du müsstest schon sinnvolle Befehle senden, zB Empfänger einschalten, Empfängerfrequenz setzen etc., dann von einem anderen Modul aus was senden, DANN könnte im Status-Byte stehen dass die Senderfrequenz erkannt wurde und evtl. etwas im FIFO steht. P. B. schrieb: > Was auch sehr merkwürdig ist und eigentlich auf eine funktionierende > Kommunkation hindeutet, dass wenn ich 0xfe00 (Soft-Reset) schicke und > danach die Statusabfrage, das Modul wieder mit 0x4000 antwortet. Laut Datenblatt stellt 0xFE00 den Wakeup-Timer ein. Wo hast du das mit dem Soft-Reset her?
P. B. schrieb: > Wie groß sollte die Verzögerung zwischen zwei Kommandos sein? Laut Datenblatt min. 25ns.
RFM12: Software-Reset Punkt 3.15 Software-Reset (0xFE00), kann leider nicht direkt darauf linken. Das Statusregister habe ich wohl falsch verstanden, nachdem ich jetzt nochmal den Teil des Artikels gelesen habe verstehe ich was du meinst sry. Wenn der "Reset" ja funktioniert, sollte dann nicht auch das ändern der CLK Frequenz klappen?
P. B. schrieb: > RFM12: Software-Reset Punkt 3.15 Software-Reset (0xFE00), kann leider > nicht direkt darauf linken. Ach da, okay, damit hab ich mich noch nicht auseinander gesetzt. P. B. schrieb: > Wenn der "Reset" ja funktioniert, sollte dann nicht auch das ändern der > CLK Frequenz klappen? Ja sollte... Wenn du mit dem CLK Ausgang deinen µC betreibst solltest du aber sicherstellen dass der solche Änderungen in der Frequenz verträgt, ein AVR zB tut das nämlich nicht...
Strickwettbewerbgewinner schrieb: > Ja sollte... Wenn du mit dem CLK Ausgang deinen µC betreibst solltest du > aber sicherstellen dass der solche Änderungen in der Frequenz verträgt, > ein AVR zB tut das nämlich nicht... Wollte das nur testweise mal ändern und auf dem Oszi gucken ob es klappt. Tut es... Vielen vielen Dank hast mich echt weitergebracht und vom Rand der Verzweiflung geholt :) Gruß P.B.
> Tut es... Na wunderbar... > Vielen vielen Dank hast mich echt weitergebracht und vom Rand der > Verzweiflung geholt :) Jo büdde, das können die RFM12 gut ...
Der RFM12 bzw. RFM12B haben scheinbar keine Schieberegister im SPI. Ich habe festgestellt, dass das Modul schon vor dem nSEL-Impuls den Befehl ausführt. Das kann es ja nur, wenn es die Bits mitzählt bzw. die einzelnen Bits im Eingangsregister nicht durchschiebt sondern durchadressiert. Möglicherweise setzt das nSEL-Signal nicht in jedem Fall den Bitzähler zurück? Wer wird denn mal den Chip aufschleifen und reinschauen, was da drin tatsächlich passiert?
Stefan Helmert schrieb: > Das kann es ja nur, wenn es die Bits mitzählt bzw. die > einzelnen Bits im Eingangsregister nicht durchschiebt sondern > durchadressiert. Na und? Stefan Helmert schrieb: > Wer wird denn mal den Chip aufschleifen und reinschauen, was da drin > tatsächlich passiert? Was wäre der Nutzen dieser Erkenntnis?
Strickwettbewerbgewinner schrieb: > Stefan Helmert schrieb: >> Das kann es ja nur, wenn es die Bits mitzählt bzw. die >> einzelnen Bits im Eingangsregister nicht durchschiebt sondern >> durchadressiert. > Na und? Das hat eine Auswirkung auf das Verhalten, wenn man nicht genau 16 Bit überträgt. Wenn man mehr überträgt und es ein Schieberegsiter ist, dann werden die letzte 16 Bit beim nSEL-Impuls ausgewertet. Bei einem adressierten Register beginnt der Zeiger evtl. wieder von vorn oder bleibt am Ende stehen. nSEL setzt evtl. nur den Pointer zurück, aber der Befehl wird schon ausgeführt, wenn alle 16 Bit übertragen sind.
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.