Hallo auch, vielleicht ist mein Problem kein neues, aber in über 1000 RF12-Beiträgen ist mir das evt. entgangen... Ich verwende einen ATtiny45 an einem RFM12B-868 Modul zum Senden von 16 Bytes (zB 0123456789ABCDEF). Der Empfänger (ATmega8 mit RFM12) empfängt aber die 16 Bytes verstümmelt (zB 01.456..AB.F....) - so als kämen die Bytes schneller als der Empfänger sie auswerten könnte, ich verliere mittendrin einzelne Bytes. Ich benutze Software-SPI bei 4800 bps, beide verwenden FIFO. Über einen anderen Thread kam ich auf die Idee, dass ich die Datenbits evt. genau mit 4800 bps in den RFM12 hineintakten muss, damit der Empfänger das auch versteht - also schnell ein paar NOPs in den Code geschummelt, mit dem Oszi kontrolliert und siehe da, der Empfänger sieht plötzlich (fast immer) den richtigen Bytestrom. Dann hab ich im Datenblatt gelesen, dass o.g. Vorgehen aber nur den RF01 betrifft, nicht aber den RF12, weil dieser ein TX-Senderegister hat. Nur scheint das bei mir nicht zu funktionieren. Inzwischen habe ich eine ganze Menge an verschiedenen Einstellungen probiert, aber ohne Erfolg. Kann mit jemand dabei weiterhelfen ? Beachtet der RF12 beim Senden die programmerte Datenrate, oder nicht ? Aus dem Datenblatt von Hope werde ich nicht schlau, schon mal Danke vorab Matthias
Hallo Matthias, ich habe längere Zeit mit dem RFM01 und RFM02 gekämpft und dabei auch viel in den Datenblättern des RFM12 gewälzt. Du hast es im Grunde schon selbst gesagt: Die RFM12 haben einen FiFo, wenn du den benutzt solltest du normalerweise keinen abreißenden Datenstrom bekommen. Auf welchen Wert hast du den FiFo-Level eingestellt? Typischerweise stellt man den auf 8 Bits und schiebt dann immer ein Byte nach dem anderen zum Funkmodul. Falls du keine extremen Timing-Probleme hast, würde ich darauf Tippen, dass du evtl. Probleme bekommst weil dein Mustersignal zu wenig 01 bzw 10 Flanken aufweist - wobei 4800 Bit/s da eher unproblematisch sind. Ach ja, darüber stolpere ich gerade: Dein SPI läuft auch auf 4800 Bit/s? Dann könntest du unter Umständen Aussetzer durch einen leichten Zeitversatz bekommen. Warum drosselst du dein Soft-SPI so stark? Laut Timing-Spezifikation für die SPI-Schnittstelle könnte dein SPI-Takt theoretisch bis zu 20 MHz betragen. Inwiefern sich das mit der Spezifikation "FiFo-Zugriffe mit max. f_res/4, also 2,5 MHz" verträgt, ist mir schleierhaft, aber selbst mit 2,5 MHz bist du weit jenseits von 4800 Bit/s mfG Markus
Matthias du solltest dir das Leben einfacher machen und nicht versuchen vom Controller genau mit 4800 Bps die Daten an den RFM12 zu schicken. Der RFM12 besitzt für soetwas eine busy Abfrage, welche du nach jedem gesendeten 16Bit Wert einfach abfragen kannst. Sobald er nicht mehr beschäftigt ist kannst du den nächsten Wert schicken. Denn sobald dein Timing auch nur im geringsten schneller ist kommen solche Fehler zustande wie du sie beschrieben hast. Ich verwende mit busy Abfrage als SPI Takt zum RFM12 460kBps ohne Probleme und ohne Datenverlust. Die einfachste Methode ist direkt auf SDO (MISO) zu prüfen. Der Ablauf ist recht simpel: 1. NSEL = 0 zum aktivieren des RFM12 2. 16Bit Wert an RFM12 senden 3. Warten bis SDO=1 (Solange SDO=0 ist der RFM12 beschäftigt) 4. wieder bei 2. anfangen 5. Sobald fertig NSEL = 1 zum deaktivieren des RFM12 Ciao, Rainer
Hallo Rainer: danke für den Hinweis, das hat mir geholfen. Im Prinzip war mein Code ok, aber der Compiler hatte eine while(..)-Anweisung wegoptimiert, weil ich ein _volatile vergessen hatte ... Ich habe mir nochmal das RF12-Datenblatt durchgelesen (das 'neue', das weniger Fehler hat) und anstelle nach dem Senden auf SDO zu warten, prüfe ich vor dem Senden nIRQ und warte ggf - das funktioniert erst mal. Matthias
Matthias D. schrieb: > Hallo Rainer: danke für den Hinweis, das hat mir geholfen. Im Prinzip > war mein Code ok, aber der Compiler hatte eine while(..)-Anweisung > wegoptimiert, weil ich ein _volatile vergessen hatte ... Das ist dann natürlich ärgerlich. :) > Ich habe mir nochmal das RF12-Datenblatt durchgelesen (das 'neue', das > weniger Fehler hat) und anstelle nach dem Senden auf SDO zu warten, > prüfe ich vor dem Senden nIRQ und warte ggf - das funktioniert erst mal. Gibt es von dem Datenblatt mal wieder eine neue Version? Also ich habe mir immer gleich das Datenblatt von dem IA4420DS angeschaut, da dies der verbaute Chip ist. Die Datenbläter von HopeRF fand ich nie sehr gut. Aber wenn es da mal wieder ein neues gibt würde ich da auch mal reinschauen. Ciao, Rainer
Bitte 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.