1. Home
  2. Electronics (German)
  3. Ich werd' noch wahnsinnig: RFM12

Ich werd' noch wahnsinnig: RFM12

Also bei mir funktioniert es ganz zuverlaessig, und da dein Empfaenger ja auch die beiden SyncBytes empfaengt muss es bei dir auch schon klappen. Daher kann es wohl nur am auslesen der Fifo liegen. Bei mir sieht das so aus:

/*********************************************************************/ /* Liefert TRUE wenn Fifo leer ist! */ /*********************************************************************/ int rf12_RGIT(void) {

RF12_DATA_low(); /* Wir geben immer nur 0 aus. Das ist der Statusreadbefehl

*/ RF12_CS1_low(); if (RF12_DATA_in() == TRUE ) { /* Ja wir koennen etwas Zuwendung gebrauchen */ RF12_CS1_high(); RF12_DATA_high(); return(TRUE); } else { /* Nein, wir sind voll bis zum abwinken */ RF12_CS1_high(); RF12_DATA_high(); return(FALSE);

} }

Dein Problem kommt mir irgendwie bekannt vor. Ich meine ich hatte dieselben oder jedenfalls aehnliche Probleme. Lag bei mir an irgend einem Pegel beim lesen. Kann ich aber leider nicht mehr genau sagen. Aber obiger Code funktioniert. Ich hab ihn identisch in einem Palmpiloten und in einem M16C laufen.

/*********************************************************************/ /* Ein Byte empfangen */ /*********************************************************************/ unsigned char rf12_rxbyte(void) { unsigned char data; volatile unsigned short i;

/* Warten bis wieder Platz im Puffer ist */ i=RXWAIT; do { i--; } while ( (rf12_RGIT() ==FALSE) && (i!=0) );

/* Wenn es zu lange dauert dann stimmt hier etwas nicht! */ if (i==0) { RF12Err.bit.RxErr = 1; RF12Err.bit.Timeout = 1; return(0x00); }

data = spi_word(0xB000) ;

return (data); }

Olaf

Reply to
Olaf Kaluza
Loading thread data ...

Hallo,

Nachdem ich jetzt schon das dritte WE damit vertrödelt habe, mich mit diesem Mistmodul auseinanderzusetzen und die Sache immer noch nicht läuft, hier dieser Hilfeschrei.

Also, die AVR-Software zur Ansteuerung des Teils habe ich selber geschrieben (interruptgesteuert und mit Hardware-SPI), sie entspricht aber funktional wohl weitestgehend den bekannten Bitbang/Polling-Lösungen aus den einschlägigen Foren. Was man daran sehen kann, daß diese exakt dieselben Ergebnisse liefern...

Das Problem ist, daß dieses vermaledeite Teil nur Mülldaten aus dem FIFO rausrückt. (Wohlgemerkt: _nicht_ "nur Mülldaten empfängt")

Die Sache stellt sich so dar:

Der Sender sendet im Sekundenrythmus folgenden String:

.DB $aa,$aa,$aa,$aa,$2d,$d4,"Hallo World! ",$aa,$aa

Also insgesamt 21 Bytes, wovon die ersten 6 eine üppige Präambel und das Syncpattern darstellen.

Frequenz und Bitrate sind für Sender und empfänger natürlich gleich eingestellt, sonstige Parameter sinnvoll aufeinander angepaßt. Scheint auch alles ganz nett, denn der Empfänger verhält sich wie erwartet. Er wartet ordentlich darauf, daß das Syncpattern erscheint und beginnt bei Erscheinen Daten zu liefern. Testweises Entfernen des Syncpatterns aus dem Sendestring führte erwartungsgemäß dazu, daß der Empfang nicht startete, ein alternatives Sync-Pattern verhielt sich genau wie der Standard.

Das Teil empfängt also definitiv die gesendeten Daten und reagiert intern korrekt darauf, wie man weiter unten in den Logs noch detaillierter sehen kann. Zu den Logs noch als Erklärung: Der zweistellige Hexstring stellt das vom FIFO rausgerückte, angeblich empfangene Byte dar, der einstellige Hexstring in den eckigen Klammern einen Auszug aus den Statusbits des RFM12, nämlich die Bits für RSSI(MSB),DQD,CRL und ATGL(LSB).

Nachdem also der Empfänger mit $CC83 "scharf" gemacht wurde, passiert als erstes folgendes:

00[E]80[E]40[E]40[E]70[E]40[E]30[E]70[E]80[E]40[E]00[E]00[E]00[E]

Was die Statusbits betrifft, sieht das sehr gut aus, denn alles, was einen kompletten VDI ausmacht, ist gesetzt. Weiter geht es mit einer Menge Daten á la:

00[0]00[0]00[0]04[0]00[0]00[0]80[0]00[0]00[0]00[2]00[2]00[2]00[0] ...

Sieht auch gut aus. Ab und an meint die CR-Unit zwar mal, gelockt zu sein, obwohl nur Rauschen empfangen wird, aber das stört keinen. Interessanter ist schon, warum von den 15 ab Sync gesendeten Byte nur 13 zu sehen waren. Das ist dadurch erklärlich, daß ich den Sender ziemlich hart abwürge, wenn das letzte Byte der Zeichenkette gesendet ist. Die beiden $aa nach dem eigentlichen Nutzstring dienen also nur als Dummy. Das ist so geplant und funktioniert offensichtlich auch wie geplant.

Nach rund einer Sekunde kommt dann das nächste Sendeevent. Erwartungsgemäß wird die empfangene Zeichenkette jetzt länger, da Präambel und Sync mit empfangen werden. Das ganze sieht dann so aus (gleich mal vier Inkarnationen, zwischen denen liegen im Original natürlich den Sendepausen entsprechende Phasen von Rauschen):

00[E]20[E]40[E]00[E]00[E]70[E]00[E]10[E]10[E]10[E]10[E]80[E]00[E]D0[E]B0[E]10[E]10[E]08[E]00[E]00[E] ... 00[E]40[E]20[E]40[E]00[E]60[E]20[E]00[E]00[E]40[E]A0[E]70[E]00[E]30[E]B8[E]90[E]40[E]00[E]00[E]00[E] ... 00[E]00[E]20[E]40[E]00[E]60[E]00[E]00[E]00[E]00[E]00[E]C0[E]00[E]60[E]C0[E]00[E]80[E]00[E]00[E]00[E] ... 00[E]00[E]00[E]00[E]20[E]50[E]00[E]00[E]00[E]40[E]40[E]70[E]00[E]60[E]70[E]00[E]40[E]00[E]00[E]00[E] usw.

Also, soweit alles sehr schön. Der springende Punkt ist eben nur, daß die angeblich empfangenen Daten rein garnix mit den gesendeten zu schaffen haben. Meiner Meinung nach ist nichtmal irgendeine Korrelation zu erkennen. Tatsächlich empfängt das Teil aber nachweislich zumindest das Sync-Pattern korrekt. Man sollte also erwarten können, daß in den Wiederholungen zumindest diese Sync-Pattern herauskommen müßten, ggf. mit verschobenen Bits. Tuen sie aber offensichtlich nicht.

Irgendwelche Ideen, Tips, Hinweise?

Die in den einschlägigen Foren geposteten Hinweise zum Rumspielen mit diversen Parametern des RFM12 (AFC, PLL, RXCONTROL usw.) sind nicht hilfreich. Das oben gepostetete stellt nämlich das Beste dar, was mit sämtlichen verfügbaren Bitkombinationen erreichbar war. Letztes WE hatte ich nämlich schon aus Verzweiflung ein Programm gebastelt, was die alle automatisiert durchprobiert hat.

Das Problem ist meiner Meinung nach irgendein Firmware-Bug beim Auslesen des FIFO. Denn: mit dem automatisiert gefundenen Optimum der Einstellungen ist es sehr wohl problemlos möglich, eine ordentliche Übertragung der Daten zu realisieren. Nämlich ohne den RX-FIFO...

Das nützt mir aber nix. Ich brauche die Rechenzeit im AVR für andere Sachen.

Reply to
Heiko Nocon

Heiko Nocon schrieb:

Dann wäre doch der Code mal interessant, mit dem Du den FIFO ausliest. Bei anderen (so auch bei mir) funktioniert er ja, d.h. er kann nicht komplett defekt sein.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Ich hatte zu begin ja auch ein Problem, habe es dann aber hinbekommen. Bloss weiss ich jetzt leider nicht mehr was es war. Aber es war irgendeine Fehlannahme mit dem Statusregister. Liess doch mal im Archiv dieser Newsgroup nach. Wir hatten das damals hier laenger besprochen. Ich kann mich noch entsinnen das ich der Sache auf die Schliche gekommen bin als ich die Automatische Erkennung der Syncbytes mal testweise abgeschaltet habe. Danach muessen die ja auch aus dem Empfaenger kommen da es ja nun normale Nutzdaten sind, kamen sie aber nicht. Aber immerhin habe ich jetzt meinen Source identisch auf zwei doch sehr unterschiedliche Prozessoren laufen. Ich habe da ein relativ kompliziertes Busprotokoll mit Pruefsummen und bestimmten Timinganforderungen drauf laufen. Die Abfrage so wie ich sie gepostet habe muss funktionieren sonst wuerde das nicht klappen.

Das muss nichts heissen. Es gibt da nur wenig Leute die selber was auf die Beine stellen, der grosse Rest ist nur Abschreiber die bei Problemen sowieso nicht weiterkommen.

Olaf

Reply to
Olaf Kaluza

Heiko Nocon schrieb: ...

...

Das geht doch bei AVRs mit "loop_until_bit_is_set(UCSRA, TXC)": Warte darauf, daß der der Tx alle Übertragungen beendet hat. Eine mögliche Fehlerquelle weniger.

...

00[E]20[E]40[E]00[E]00[E]70[E]00[E]10[E]10[E]10[E]10[E]80[E]00[E]D0[E]B0[E]10[E]10[E]08[E]00[E]00[E]
00[E]40[E]20[E]40[E]00[E]60[E]20[E]00[E]00[E]40[E]A0[E]70[E]00[E]30[E]B8[E]90[E]40[E]00[E]00[E]00[E]
00[E]00[E]20[E]40[E]00[E]60[E]00[E]00[E]00[E]00[E]00[E]C0[E]00[E]60[E]C0[E]00[E]80[E]00[E]00[E]00[E]
00[E]00[E]00[E]00[E]20[E]50[E]00[E]00[E]00[E]40[E]40[E]70[E]00[E]60[E]70[E]00[E]40[E]00[E]00[E]00[E]

Wenn ich solche Muster sehe, bei denen meistens nur ein bit/Byte gesetzt ist, denke ich automatisch an unpassende Baudraten oder das Samplen auf der falschen Flanke von CLK (oder wie das bei den Teilen heißt)...

Falk

Reply to
Falk Willberg

Wie gesagt: per eigener HardwareSPI-Routine und per Bitbang-Routine aus microcontroller.net kommt exakt derselbe Müll raus. Die Routinen selber müssen auch jeweils korrekt sein, denn es ist ja bei jedem anderen Kommando als $b0xx das erwartete Verhalten zu beobachten.

Es ist mir bewußt, daß die veröffentlichten Routinen bei vielen Leuten funktionieren, bei einigen aber offensichtlich auch nicht, die haben dann exakt die Probleme, die auch ich habe. Es gibt mehrere (leider jeweils nur kurze) Threads bei microcontroller.net dazu. Die Threads verliefen jeweils im Sande, keine abschließende Erfolgsmeldung wie sonst dort üblich.

Reply to
Heiko Nocon

/* Dateneingang vom RFM12 Modul */ int RF12_DATA_in(void) { return( read_PM7() ); };

/*********************************************************************/ /* Liesst und schreibt gleichzeitig ein Word auf den SPI-Bus

*/ /*********************************************************************/ unsigned short spi_word(unsigned short data) { int i; unsigned short dummy;

dummy=data;

RF12_CS1_low(); for (i=0;i

Reply to
Olaf Kaluza

Das hat mit der RS232-Kommunikation rein garnix zu schaffen. Es ging um die Bytes, die der AVR per SPI an das RFM12 schickt. Die bezieht er im Testaufbau als Stringkonstante aus seinem eigenen PM. RS232 spielt nur beim Empfänger überhaupt eine Rolle und dort im Wesentlichen auch nur zur Ausgabe des Logs der Kommunikation zwischen AVR und RFM12.

Reply to
Heiko Nocon

00[E]20[E]40[E]00[E]00[E]70[E]00[E]10[E]10[E]10[E]10[E]80[E]00[E]D0[E]B0[E]10[E]10[E]08[E]00[E]00[E]
00[E]40[E]20[E]40[E]00[E]60[E]20[E]00[E]00[E]40[E]A0[E]70[E]00[E]30[E]B8[E]90[E]40[E]00[E]00[E]00[E]
00[E]00[E]20[E]40[E]00[E]60[E]00[E]00[E]00[E]00[E]00[E]C0[E]00[E]60[E]C0[E]00[E]80[E]00[E]00[E]00[E]
00[E]00[E]00[E]00[E]20[E]50[E]00[E]00[E]00[E]40[E]40[E]70[E]00[E]60[E]70[E]00[E]40[E]00[E]00[E]00[E]

Ok, das Modul kenne ich nicht, hatte aber bei Kunden ab und zu aehnliche Uebertragungsprobleme gesehen. Hast Du mit dem Scope nachgesehen, was aus dem FIFO bei dranhaengendem AVR rauskommt? Am besten am AVR messen. SPI Timings sind leider nicht bei allen Bauteilen so wie sie nach Datenblatt sein sollten.

Verstaendlich.

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

[...] Das sind wahrscheinlich die wohlbekannten Polling-Routinen . Nein, die funktionieren mit den Modulen hier genausowenig wie meine eigenen.

Interessant wäre allenfalls die Implementierung von spi_word und RF12_DATA_in. Vermutlich steckt da aber letztlich auch nur das wohlbekannte Bitbang-Geraffel drin.

Reply to
Heiko Nocon

Heiko Nocon schrieb:

Was mir gerade noch auffiel: Du meinst sicherlich $CA83.

Du wirst wohl um einen Blick mit dem Scope auf die Datenleitungen nicht herumkommen, wenn Du Code und Hardwaredesign nicht postest.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Ja. Exakt das, was auch der AVR einliest. Auch die Flanken sehen ordentlich aus und zwar auf allen vier beteiligten Leitungen.

Ich glaube auch nicht, daß es am SPI an sich liegt. Sonst würde es auch bei der sonstigen Kommunikation Probleme geben, denn die läuft ja ebenfalls komplett über SPI. Ich tippe eher auf ein Problem bei dem Multiplexer des RFM12, der dafür zuständig ist, den FIFO-Ausgang nach Empfang des $b0-Kommandos auf SDO zu legen. Leider ist den Datenblättern nicht zu entnehmen, wie das im Detail gelöst ist. Ich vermute, daß es da zum Mux ein Latch für den FIFO-Inhalt gibt und daß da irgendwas nicht richtig funktioniert oder falsch/unvollständig dokumentiert ist.

Das Datenblatt hält sich bezüglich des Auslesens des FIFO über das $b0-Kommando des SPI-Interface auch verdächtig bedeckt, räumt demgegenüber der (ja tatsächlich funktionierenden) bitweisen Polling-Variante über SPI erstaunlich viel Raum ein und deutet eine weitere Möglichkeit über ein erweitertes STATUSREAD-Kommando an, ohne sich allerdings diesbezüglich allzusehr in nützliche Details zu verlieren...

Ein typischer Chinakracher halt.

Reply to
Heiko Nocon

Heiko Nocon schrieb:

Eigentlich ist das ja dokumentiert: Wenn man den Clock weiterlaufen lässt, kommen beim "Status Read"-Kommando hinter den 16 Statusbits die FIFO-Daten.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Ja, natürlich. Tippfehler.

Hardwaredesign entspricht weitgehend dem "Standard". D.h.:

MISOSDI SCK ->SCK INT2

Reply to
Heiko Nocon

angesichts deiner fehlerbeschreibung seh ich eigentlich nur zwei möglichkeiten: entweder das modul ist kaputt (hast du schon mal das sendende und das empfangende gegeneinander getauscht?), oder der fehler stammt von dir und ist dann erfahrungsgemäß nicht zu finden, weil sich mit dem verbissenen suchen ein blinder fleck bildet (don't ask me how I know...) -- außer jemand anderer schaut sich das an oder du läßt die sache einmal ein paar wochenden liegen und schaust sie dir dann nochmal an...

funktionierender code findet sich u.a. auf

formatting link

ciao,

cm.

--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
> Konzept Kunde/König?
Ist deren Internet kaputt oder meines? Kann ich das wieder hinbiegen
oder die? -- Ralph Angenendt in dasr
Reply to
christian mock

Das will bei manchen SPI Bausteinen sehr genau eingehalten werden. Ein SCLK zuviel, einer zuwenig oder zuviel Pause und die Dinger legen entweder einen Abort hin oder es kommt Datenmuell heraus. Was ich bei AD schon einmal hatte war besonders interessant. Es wollte ums Verplatzen nicht auf den fallenden Flanken funktionieren, obwohl das so im Datenblatt stand. Auf der steigenden fluppte alles wie am Schnuerchen. Der Application Engineer meinte dann laessig "Well, if it works then just take the rising edge".

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Genau das gepostete. Das entspricht den vielfach veröffentlichten Codevarianten.

Nein, man muß eben nicht warten, sondern kann in der Zeit nützlicheres machen. Für sowas gibt's nämlich Interrupts.

Ich brauche ein interruptgesteuertes System, weil die Kommunikation via RFM12 nicht Selbstzweck ist, sondern letztlich nur die Ergebnisse der eigentlichen Arbeit des Systems transportieren soll.

Aber wie schon mehrfach erwähnt: Auch mit dem "bewährten" Code kommt effektiv genau dasselbe Verhalten raus. Es liegt also nicht an der Implementierung.

Reply to
Heiko Nocon

Genau das meinte ich. Da sind aber nur drei Bits eingezeichnet und keine zeichnerische Andeutung, daß es auch weiter gehen könnte. Im Text wird's garnicht erwähnt und in der Tabelle ebenfalls nicht. Es steht auch nirgendwo was davon, daß diese FIFO-Bits "gültig" oder wieviele der 16 FIFO-Bits man auf diese Weise auslesen kann. Sowas würde ich nicht unbedingt als "dokumentiert" bezeichnen.

Trotzdem werde ich wohl oder übel, falls nicht noch andere nützliche Tips kommen, mich nächstes WE daransetzen, die Unterstützung dafür in meinen Code einzubauen.

Reply to
Heiko Nocon

Da ist mir ein interessantes Detail aufgefallen:

Wozu das nop? Oder anders ausgedrückt: Mit welchem Takt läuft das Teil?

Die Zeit entspricht der im Datenblatt mit tOD (data delay time) bezeichneten. Die ist dort mit 10ns Minimum angegeben. D.h.: Erst bei

100MHz Systemtakt müßte man anfangen, an dieser Stelle nops einzufügen.

Allenfalls wäre noch die Einhaltung von tCL als Grund denkbar (25ns). Aber auch das wäre erst ab 40MHz Takt relevant.

Reply to
Heiko Nocon

Heiko Nocon schrieb:

Man kann so viele Datenbits auslesen wie im FIFO sind, also maximal 16. Es gibt keinen Weg, den genauen Füllstand des FIFOs zu erfahren, aber FFIT teilt Dir mit, das der eingestellte Level überschritten wurde. Ist der Level auf 8 Bits gestellt, kannst Du mit dem Kommando also mind. 8 Bits auslesen.

Aber was anderes: Wenn Du nFFS schon mit Deinem AVR verbunden hast, hast Du dann mal probiert, nach Erhalt des Interrupts nicht das Kommando $B000 zu senden, sondern stattdessen nFFS auf Low zu setzen und die Bits direkt aus dem FIFO herauszutakten?

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.