RFM12b (keine Übertragung)

[Mateusz R. (mateusz224)]

Moin zusammen,
Also vorab das ist mein erster Beitrag hier und auch erst meine zweite 
Erfahrung mit einem uC. Für eine Uni-arbeit muss u.a. auch ein uC 
programmiert werden. Dabei soll von einem uC zu einem Raspberryn Pi die 
Daten übertragen werden. Zunächst versuch ich jetzt nun seit über 10 
Tagen tag täglich 8-10 Stunden eine Funkbrücke (mit einem RFM12b) vom 
PIC zum PIC zu realisieren, jedoch vergebens und bin schon verzweifelt. 
Ich habe so ziemlich alle Forenbeiträge gelesen und finde trotzdem den 
Fehler nicht.
Dabei benutz ich den CCS Compiler und die Hardware SPI.
Ich wäre unheimlich dankbar wenn mir jemand da weiter helfen könnte....

Zusatz Info:
868Mhz Modul

Was überprüft worden ist:
- Statuswort bei: power on reset 0x4000 | wird erhalten
- nIRQ wird ausgelöst beim Sender (Siehe Abbildungen)

Abbildung NewFile1:
Blau: nIRQ
Gelb: MISO

Abbildung NewFile2:
Blau: nIRQ
Gelb: nSEL

PS: Die Abbildungen NewFile0.bmp bitte ignorieren. Weiß leider nicht wie 
ich die wieder löschen kann.

#define nIRQ PIN_B1
#define nSEL PIN_B0

void rfm12_send_cmd(int16 cmd)
{
  #byte lobyte = cmd
  #byte hibyte = cmd + 1

  spi_write(hibyte);
  spi_write(lobyte);
}  

int16 rfm_get_status()
{
  int16 status;
  
  status = spi_read(0x00);
  status<<=8;
  status + spi_read(0x00);

  return status;
}
char rfm_read_cmd()
{
    char read;
    spi_read(0xB0);
    read=spi_read(0x00);
    return read;
}
  
void rfm12_init()
{
  output_high(nSEL);
  delay_ms(200);
  
  output_low(nSEL);
  
  int16 status;
  status = rfm_get_status();
  //

    rfm12_send_cmd(0x8067);   // Je nachdem ob Sender oder Empfänger
    //rfm12_send_cmd(0x80A7);  // Je nachdem ob Sender oder Empfänger
    rfm12_send_cmd(0x8208);
    rfm12_send_cmd(0xA680);
    rfm12_send_cmd(0xC647);
    rfm12_send_cmd(0x94A0);
    rfm12_send_cmd(0xC2AB);
    rfm12_send_cmd(0xCA81);
    //rfm12_send_cmd(0xCAF3);
    rfm12_send_cmd(0xCED4);
    rfm12_send_cmd(0xC4F7);
    rfm12_send_cmd(0x9850);
    rfm12_send_cmd(0xCC77);
    rfm12_send_cmd(0xE000);
    rfm12_send_cmd(0xC800);
    rfm12_send_cmd(0xC040); 

  output_high(nSEL);
}  

void rfm12_write(char data)
{
  output_low(nSEL);

    
  rfm_get_status();
  rfm12_send_cmd(0x8238);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB82D);
  rfm12_send_cmd(0xB8D4);
  rfm12_send_cmd(0xB845);
        rfm12_send_cmd(0xB8AA);
        rfm12_send_cmd(0xB8AA);
        rfm12_send_cmd(0xB8AA);
 
  rfm12_send_cmd(0x8208);
    
    

  output_high(nSEL);
    //printf("Status1: 0x%lX\r\n", status);
}  

void rfm12_read()
{
        char read;
        int16 status;
        output_low(nSEL);
  rfm_get_status();
  rfm12_send_cmd(0x82C8);
  rfm12_send_cmd(0xCA81);
  rfm12_send_cmd(0xCA83);
  read=rfm_read_cmd();
  //rfm12_send_cmd(0xCA83);
  rfm12_send_cmd(0x8208);
 
  output_high(nSEL);   
    
    printf("read: %u\r\n", read);
}

[Michael U. (amiga)]

Hallo,

C ist nicht so meine Spielwiese und PIC sowieso nicht, aber:

void rfm12_send_cmd(int16 cmd)
{
  #byte lobyte = cmd
  #byte hibyte = cmd + 1

  spi_write(hibyte);
  spi_write(lobyte);

Ich kenne den Compiler nicht, was macht #byte?

Sollte das nicht eher nur

  spi_write(cmd & 0xFF);
  spi_write((cmd >> 8) & 0xFF);

heißen?

Vermutlich muß auch noch ein cast auf byte oder char rein oder was 
spi_write() da erwartet.

Gruß aus Berlin
Michael

[Mateusz R. (mateusz224)]

Hej,
ja so könnte man das auch machen, ich hatte das jetzt so übernommen und 
es scheint auch zu funktionieren da ich die Register setzen kann. Also 
kann mir den Status des RFM12b auslesen lassen oder den RFM12b so 
konigurieren, dass er mir sein Clk ausgibt am PIN CLK. Von daher glaub 
ich weniger, dass es was mit der SPI Kommuniktion zu tun hat, sondern 
eher mit dem Fifo oder allgemein mit der richtigen Konfiguration des 
RFM12b (vielleicht auch timing probleme).... Ich habe nur die INFO: "PIC 
und C" mit rein genommen der vollständigkeit halber... aber glaube, dass 
das Problem bei der Konfiguration der (über SPI) zu sendenden Daten 
liegt.

[Michael U. (amiga)]

Hallo,

ok, dann geht Deine Version an dieser Stelle.
Ich habe einen RFM12 (den alten) hier noch als Empfänger laufen, 
allerdings an einem AVR.

void rfm12_init()
{

  RFM12_PORT |= (1<<RFM12_IRQ) | (1<<RFM12_CS) | (1<<RFM12_SDO);    // PullUp ein / Ausgang H
  RFM12_DDR  |= (1<<RFM12_CS) | (1<<RFM12_SDI) | (1<<RFM12_SCK);    // Ausgänge
  RFM12_DDR  &= ~((1<<RFM12_IRQ) | (1<<RFM12_SDO));                 // Eingang

  MCUCR |= (1<<ISC01);                          // INT0 fallende Flanke für RFM12 nIRQ
  GICR |= (1<<INT0);

  rfm12_send_cmd(0x0000);  // Status read

  rfm12_send_cmd(0xC080);  // CLK-Frequenz / Batterie-Level
  rfm12_send_cmd(0x80D7);  // FIFO ein, 433MHZ-Band, C = 12pF
  rfm12_send_cmd(0xC2AB);  // Clock Recovery Auto, Filter digital, DQD-Thresold 3
  rfm12_send_cmd(0xCA81);  // FIFO-Level 8 Bit, Sync Pattern ein, High senity Reset aus
  rfm12_send_cmd(0xE000);  // WakeUp aus
  rfm12_send_cmd(0xC800);  // Low Duty Cycle aus
  rfm12_send_cmd(0xC4F3);  // AFC immer, +7,5 / -10kHz, Add Freq-Offset zur PLL, Berechne Freq. Offset aus AFC                      // Status read
  rfm12_send_cmd(0xA620);  // Frequenz 433,92MHz  // Status read

  rfm12_send_cmd(0x948C);  // VDI Output, VDI Fast, Bandbreite 200kHz, LBA-Gain -6dB, RSSI-Thresold -79dB

  rfm12_send_cmd(0xC610);  // Baudrate 19200
  rfm12_send_cmd(0x8281);  // Empfänger ein, Clock Out aus
  rfm12_send_cmd(0xCA81);  // set FIFO mode
  rfm12_send_cmd(0xCA83);  // enable FIFO
}

Ist ein 433MHz RFM12 und die Baudrate stimmt auch nicht, die ist 21000 
oder so.

Vielleicht hilft Dir die Initialisierung etwas weiter.

Gruß aus Berlin
Michael

[Mateusz R. (mateusz224)]

könntest du vielleicht dein ganzen Code posten? Also ich habe mir schon 
zahlreiche Programme angeschaut und die sehen eigentlich identisch aus 
(außer, dass diese oft eine softawre spi haben) was mich ja extrem 
wundert...

Also den Sender/Empfänger Code, sowie wie du die Daten sendest und 
empfängst.

Beste Grüße aus Bremen

[Michael U. (amiga)]

Hallo,

Kann ich machen, hat aber ein Problem:
der Kram ist von 2009/2010 und heute noch in Betrieb.
http://www.avr.roehres-home.de/sensoren/index.html

Ursprünglich alls AVR-ASM, C dann als Übung für mich. Außerdem sende ich 
mit den alten RFM02, mit dem RFM12 habe ich nie gesendet...

Ich hänge die C-Sachen trotzdem mal hier ran, auf meiner Homepage sind 
nur die ASM-Projekte.
Vielleicht hilft es ja.

Ich könnte natürlich mal einen Sender mit RFM12 zusammenstecken und in C 
was senden, einen spielenden USB-Empfänger habe ich ja da.

Gruß aus Berlin
Michael

[Mateusz R. (mateusz224)]

Super schau ich mir gleich mal genauer an. Wie gesagt ich sitz da schon 
ca. 100 Stunden dran und weiß nicht mehr weiter, weiß ja nicht mal ob 
der Sender was Sendet oder das am Empfänger liegt. Und habe keine Ahnung 
wie ich das rausbekommen kann...

[Stefan (Gast)]

Hast du einen DVB-T Empfänger für deinen PC ?
Dann kannst du es testen, ob er sendet.
Habe ich auch so gemacht.

[Mateusz R. (mateusz224)]

Nop, weiß ehrlich gesagt nicht mal was das ist^^ Würde mir einen aber 
zulegen, wenn ich dadurch die Info erhalte. Also was ich weiß ist, dass 
der Sender angeschaltet ist und das die Trägerfräquenz an ist (Sendet). 
Aber ob auf dieser sich die Daten befinden die ich versuche zu Senden 
weiß ich nicht.

[Mateusz R. (mateusz224)]

Also was mich extrem wundert ist eigentlich die Abbildung. Gelb ist 
dabei der nSEL und Blau der nIRQ.
Was man erkennen kann ist der Aufruf der rfm12_write() funktion. Dabei 
wird mit der fallenden nSEL Flanke die Daten übertragen. Ich habe jetzt 
einmal 1ms dalay in der Funktion eingebaut (Abbildung NewFile4) um zu 
sehen was  dabei passieren wird. (Abbildung NewFile3 ist ohne delay).
Denn was mich verwirrt ist dass nIRQ bei einem high Pegel bedeutet, dass 
dieser sendebereit (bzw. das Fifo bereit ist diesen mit Daten zu 
füllen). Das bedeutet dass erst wenn die rfm12_write() Methode 
aufgerufen wird ist dieser soweit (wahrscheinlich durch setzen der -> 
0x8238). Hatte jedoch auch ebenfalls das so verstanden gehabt dass beim 
Senden das Fifo gefüllt wird und ebenfalls nIRQ dann auf low fallen 
würde, da das Fifo voll ist. Jedoch passiert da nichts.

Ist das der Fehler?

void rfm12_write(char data)
{
  output_low(nSEL);
  rfm_get_status();
  rfm12_send_cmd(0x8238);
    delay_ms(1);  //mit und ohne in der Abbildung
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB82D);
  rfm12_send_cmd(0xB8D4);
  rfm12_send_cmd(0xB845);
        rfm12_send_cmd(0xB8AA);
        rfm12_send_cmd(0xB8AA);
        rfm12_send_cmd(0xB8AA);    
  rfm12_send_cmd(0x8208);
  output_high(nSEL);
}

[Felix P. (fixxl)]

Bist du sicher, dass es funktioniert, wenn man den Chip Select auf low 
zieht und dann eine Serie von Befehlen schickt? Ich kenne es so, dass 
vor und nach jedem Befehl CS auf low bzw. high gezogen werden muss.

[Mateusz R. (mateusz224)]

Jein, also wie gesagt den RFM12b kann ich so konfigurieren. Also es 
scheint so zu funktionieren ich hatte trotzdem es versucht bei jedem 
befehl den chip select auf low zu ziehen... also:

void rfm12_write(char data)
{   output_high(nSEL);
  output_low(nSEL);
  rfm_get_status();
  rfm12_send_cmd(0x8238);
    output_high(nSEL);
  output_low(nSEL);

    rfm_get_status();
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB8AA);
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB8AA);
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB8AA);
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB82D);
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB8D4);
    output_high(nSEL);
  output_low(nSEL);
  rfm12_send_cmd(0xB845);
   output_high(nSEL);
  output_low(nSEL);
    rfm12_send_cmd(0xB8AA);
   output_high(nSEL);
  output_low(nSEL);
    rfm12_send_cmd(0xB8AA);
   output_high(nSEL);
  output_low(nSEL);
    rfm12_send_cmd(0xB8AA);
   output_high(nSEL);
  output_low(nSEL);

  rfm12_send_cmd(0x8208);
        output_high(nSEL);
}

Da ich nicht sicher war wegen dem entprellen hatte ich auch das versucht 
mit 1ms delay dazwischen... hat alles nicht geklappt. Mit 1ms delay war 
dann auch der nIRQ auf dauer high... keine Ahnung wieso.

Ich seh gerade (da ich zuvor das mit dem 434MHz modul probiert hatte) 
dass ocj eine 433MHz Antene immer noch rangelötet ist aber das dürft 
eigentlich nicht das Problem sein wenn die beiden Module nebeneinander 
liegen.

[Chris L. (kingkernel)]

Wie sieht denn dein Aufbau aus? Ich hatte mit den RFM12b-868 Modulen 
massive Probleme mit falschen Kondensatoren in der Spannungsversorgung. 
Alles lief, bis auf das senden. Dann klappte das Senden irgendwann aber 
ich hatte ständig fehler. Ein paar minuten später ging wieder nichts 
mehr

[Mateusz R. (mateusz224)]

Hej,
also ich habe ebend gerade irgendwelche Daten empfangen ohne dass der 
Sender an war... eine gewisse Zeit (1min) zumindest und dann wieder nur 
0  ganz komisches Verhalten... kann das Verhalten auch nicht mehr 
reproduzieren...

Also der Schaltplan sieht so aus, wie bei den meisten die ich im 
Internet gesehn...

[Felix P. (fixxl)]

Bin gerade noch einmal das Datenblatt durchgegangen, das Timing-Diagramm 
auf Seite 13 ist relativ eindeutig: Vor jedem SPI-Befehl muss der 
Chip-Select auf low gezogen, dann die 16 Bit übertragen und anschließend 
der Chip-Select wieder high gesetzt werden.

Bevor du deinen Code jetzt mit output_low und output_high flutest, würde 
ich einfach die Funktion rfm12_send_cmd entsprechend anpassen. Hast du 
mit dem Oszi mal SDI und SCK angeschaut, um zu vergleichen, ob deine 
Kommandos richtig rausgeschickt werden? Ich bin kein CCS-Experte, von 
daher kann ich nicht sagen, ob diese Konstruktion mit #byte so 
funktioniert.

Was mir auch seltsam vorkommt:

int16 rfm_get_status() {
  int16 status;
  status = spi_read(0x00);
  status<<=8;
  status + spi_read(0x00);
  return status;
}

Was passiert in der Zeile vor dem return? Muss das kein += sein?

[andy (Gast)]

Hier mal mein alter Source. Hat damals sehr gut funktioniert.

[Chris L. (kingkernel)]

Die 100nF am RFM12b reichen nicht! Da muss zwingend zusätzlich noch ein 
10µF-Elko dazu!

[Mateusz R. (mateusz224)]

So habe das jetzt mit nSEL angepasst bekomme jedoch wie schon vorher 
angesprochen jetzt kein Interupt auf nIRQ (ständig auf high).

Stimmt, da fehlte ein += ist auch korrigiert.

Habe noch einen 10uF Kondensator angelötet.


Alles bewirkte keine Änderung... Ja die Daten werden korrekt über die 
SPI übertragen, im Anhang nSEL und und das CLK Signal...

Kann das an der Hardware SPI liegen dass diese zu schnell ist und das 
RFM12b nicht hinterherkommt? eine CLK Periode dauert wie man in der 
Abbildung erkennen kann 500ns.

[Frank G. (frank_g53)]

Stefan schrieb:
> Hast du einen DVB-T Empfänger für deinen PC ?
> Dann kannst du es testen, ob er sendet.

Mateusz R. schrieb:
> Würde mir einen aber
> zulegen, wenn ich dadurch die Info erhalte.

http://www.stall.biz/project/868mhz-funksignal-ansehen-mit-dvb-t-stick

Stichworte: RTL2832 und SDR

[Stefan (Gast)]

Spendier der SEL Leitung noch einen
Widerstand zum Pluspol.

[Stefan (Gast)]

So ist eigentlich die Grundbeschaltung.

[Michael U. (amiga)]

Hallo,

Das wären dann 2MHz, SPI-Geschwindigkeit ist ok, das Datenblatt sagt 
Clock Low, Clock High jeweils Minimum 25ns, also theoretisch 50ns für 
die Periode.

Einschränkung ist beim Zugriff auf den FIFO, da sind nur maximal 1/4 vom 
Clock, also 10MHz/4 = 2,5MHz zulässig.

Richtig ist die Anmerkung irgendwo oben: nSEL geht vor Beginn einer 
Kommandosequenz auf Low und am Ende wieder auf High.

Das sagen auch alle Timingdiagramme im Datenblatt.
Vielleicht schaffe ich es morgen mal, einen RFM12 als Sender anzuwerfen.

Gruß aus Berlin
Michael.

[Mateusz R. (mateusz224)]

Jop stimmt das mit dem pull up Widerstand habe ich tatsächlich 
vergessen^^
Ist jetzt auch korrigiert... -> keine Änderung.

ich poste nochmal den aktuellen Code mit den vorgenommenen Änderungen:

#define nIRQ PIN_B1
#define nSEL PIN_B0
//#define  RFM12B_STATUS       RFM12B_spi(0x0000)
//#define  RFM12B_RGIT()       (RFM12B_STATUS & 0x8000)
//#define  RFM12B_WAIT_RGIT()  while(!RFM12B_RGIT()) {  }

void rfm12_send_cmd(int16 cmd)
{
  output_low(nSEL);
  #byte lobyte = cmd
  #byte hibyte = cmd + 1

  spi_write(hibyte);
  spi_write(lobyte);
    output_high(nSEL);
}

int16 rfm_get_status()
{
    output_low(nSEL);
  int16 status;
  
  status = spi_read(0x00);
  status<<=8;
  status += spi_read(0x00);
    output_high(nSEL);

  return status;
}
char rfm_read_cmd()
{
    output_low(nSEL);
    char read;
    spi_read(0xB0);
    read=spi_read(0x00);
    output_high(nSEL);
    return read;
}
  
void rfm12_init()
{
  output_high(nSEL);
  delay_ms(200);
  
  output_low(nSEL);
  
  int16 status;
  status = rfm_get_status();

    //rfm12_send_cmd(0x8067);
    rfm12_send_cmd(0x80A7);

    rfm12_send_cmd(0x8208);

    rfm12_send_cmd(0xA680);
    rfm12_send_cmd(0xC647);
    rfm12_send_cmd(0x94A0);
    rfm12_send_cmd(0xC2AB);
    rfm12_send_cmd(0xCA81);
    //rfm12_send_cmd(0xCAF3);
    rfm12_send_cmd(0xCED4);
    rfm12_send_cmd(0xC4F7);
    rfm12_send_cmd(0x9850);
    rfm12_send_cmd(0xCC77);
    rfm12_send_cmd(0xE000);
    rfm12_send_cmd(0xC800);
    rfm12_send_cmd(0xC040); 
    //rfm12_send_cmd(0x8057);
    

    //status = rfm_get_status();
   // printf("Status: 0x%lX\r\n", status);
}  

void rfm12_write(char data)
{   
  output_low(nSEL);
    
    
  rfm_get_status();

  rfm12_send_cmd(0x8238);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0xB82D);
  rfm12_send_cmd(0xB8D4);
  rfm12_send_cmd(0xB845);
    rfm12_send_cmd(0xB8AA);
    rfm12_send_cmd(0xB8AA);
    rfm12_send_cmd(0xB8AA);
  rfm12_send_cmd(0x8208);
  output_high(nSEL);
    //printf("Status1: 0x%lX\r\n", status);
}  

void rfm12_read()
{
    char read1, read2;
    int16 status;
    
    
  rfm_get_status();
  rfm12_send_cmd(0x82C8);
  rfm12_send_cmd(0xCA81);
  rfm12_send_cmd(0xCA83);
    delay_ms(4);
  read1=rfm_read_cmd();
  rfm12_send_cmd(0x8208);
    
    printf("read1: %u\r\n", read1);
    //printf("Status: 0x%1X\r\n", status);
}

Bzgl.:
  #byte lobyte = cmd
  #byte hibyte = cmd + 1
ist richtig, habe mich nochmal informiert, das ist wirklich ein CCS 
spezifischer optimierter Befehl, der mit einem Assembler Befehl (das 
nächste Register) defeniert. (int16) cmd zu schiften kostet mehrere 
Assembler Befehle.

[Felix P. (fixxl)]

Bei deiner Registerkonfiguration in der Init ist mir noch aufgefallen:

rfm12_send_cmd(0x80A7);

Damit hast du den FIFO-Modus nicht aktiviert, das Bit ef (Bit 6) ist 
nicht gesetzt und Daten- und Datentaktausgabe würden über die Pins 6 und 
7 ausgegeben. Für FIFO-Betrieb müsste der Befehl 0x80E7 lauten.

Das meiner Meinung nach größte Problem, das mir dummerweise erst jetzt 
aufgefallen ist, besteht aber wohl darin, dass du die Daten einfach 
unmittelbar nacheinander ins Datenregister schreibst, ohne darauf zu 
warten, dass sie verschickt werden und Platz für neue Daten ist. Beim 
RFM69CW, dem Nachfolger des RFM12b, würde das funktionieren, da der 
Puffer entsprechend groß ist, beim RFM12b passen da aber nur zwei Byte 
gleichzeitig hinein.

Vor jedem neuen Byte, welches ins Senderegister geschrieben wird, muss 
überprüft werden, ob das Senderegister aufnahmefähig ist (MSB des 
Statusregisters auf 1) oder nicht (MSB des Statusregisters auf 0). Deine 
write-Funktion sollte am Ende also ungefähr so aussehen:

void rfm12_write(char data) {   
   
  rfm_get_status();

  rfm12_send_cmd(0x8238);
  
  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8AA);
  
  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8AA);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8AA);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB82D);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8D4);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB845);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8AA);

  while(!(rfm_get_status() & (1<<15))); 
  rfm12_send_cmd(0xB8AA);

  while(!(rfm_get_status() & (1<<15)));
  rfm12_send_cmd(0xB8AA);

  rfm12_send_cmd(0x8208);
}

Selbstverständlich kannst du aber, um das nicht immer ausschreiben zu 
müssen, auch eine Funktion schreiben, die das Warten und den 
Schreibzugriff zusammenfasst.

Ganz alternativ würde natürlich auch die Auswertung des Interrupts 
funktionieren.

[Mateusz R. (mateusz224)]

Hmm also ich habe den nicht gesetzt, da das der Empfangs Fifo ist und 
das der Sender gewesen ist. Das Empfangs FiFo habe ich auf dem anderen 
Modul aktiviert (ist in dem geposteten Code kommentiert: 
rfm12_send_cmd(0x8067);)

bzgl.:
while(!(rfm_get_status() & (1<<15)));

sowas ähnliches hatte ich auch vorher (while(!(rfm_get_status() & 
0x8000));) jedoch MOSI bleibt dann auf dauer LOW und MISO verhält sich 
ebenfalls merkwürdig also geht auf high wenn nSEL low geht.

Ich geh davon aus, dass das Senderegister nie aufnahmefähig ist bzw. das 
FFIT Bit nie zurück gesetzt wird und dass das Programm deswegen in einer 
dauerschleife hängenbleibt und deswegen ist:

MISO: High bei nSEL
MOSI: (durch versenden von 0x0000) Low
nIRQ: dauer High

[Felix P. (fixxl)]

Mateusz R. schrieb:
> Hmm also ich habe den nicht gesetzt, da das der Empfangs Fifo ist und
> das der Sender gewesen ist. Das Empfangs FiFo habe ich auf dem anderen
> Modul aktiviert (ist in dem geposteten Code kommentiert:
> rfm12_send_cmd(0x8067);)
Ah, okay. Schaden tut es trotzdem nicht, wenn man beides aktiviert.

> bzgl.:
> while(!(rfm_get_status() & (1<<15)));
>
> sowas ähnliches hatte ich auch vorher (while(!(rfm_get_status() &
> 0x8000));) jedoch MOSI bleibt dann auf dauer LOW und MISO verhält sich
> ebenfalls merkwürdig also geht auf high wenn nSEL low geht.
>
> Ich geh davon aus, dass das Senderegister nie aufnahmefähig ist bzw. das
> FFIT Bit nie zurück gesetzt wird und dass das Programm deswegen in einer
> dauerschleife hängenbleibt und deswegen ist:
>
> MISO: high bei nSEL
> MOSI: (durch versenden von 0x0000) Low
Was MOSI tut, entscheidest du selbst: MOSI ist ein Ausgang deines 
Mikrocontrollers. Wenn MOSI dauerhaft auf low ist, obwohl du Daten 
sendest, ist das ein Problem der Software oder Hardware.

Dass MISO auf high geht, wenn du NSEL low ziehst (und gleichzeitig auch 
MOSI auf low ist), ist absolut in Ordnung. Dann gibt der Pegel nämlich 
den Zustand des MSB des Statusregisters wieder, im Sendemodus also RGIT. 
Und RGIT = 1 bedeutet, dass du den Wert xx per Befehl 0xB8xx ins 
Senderegister schreiben darfst. Wenn RGIT auf 1 ist, muss gleichzeitig 
auch nIRQ auf low sein und wird erst high, wenn du etwas ins 
Senderegister schreibst.

[Michael U. (amiga)]

Hallo,

ich weiß nicht, ob ich es heute noch schaffe, den RFM12 mal anzuwerfen.

Zur Abfrage des FIFO: SDO spiegelt immer den Zustand des FIFO-Status 
sobald nSEL auf L geht. Man muß beim Senden/Empfangen also nicht den 
Status lesen, man kann sofort den Zustand von SDO abfragen.

void RFM12_read_fifo(char *data_buf, char len)
  {

    unsigned char byte = 0, i, j;

    RFM12_send_cmd(0x82C8);            // Empfänger ein

    RFM12_send_cmd(0xCA81);            // set FIFO mode

    RFM12_send_cmd(0xCA83);            // enable FIFO

      RFM12_PORT &= ~(1<<RFM12_SCK);        // CLK auf L
      RFM12_PORT &= ~(1<<RFM12_SDI);        // DATA auf L

    for (i=0; i<len; i++)
      {
        RFM12_PORT &= ~(1<<RFM12_CS);      // CS auf L
        asm("nop");
        asm("nop");
      while (!(RFM12_PIN & (1<<RFM12_SDO)))  // warten bis SDO 1 -> FFIL 
        {
        }
                
      byte = 0xB0;              // Receive FIFO

      for (j=0; j<8; j++)
        { 
        if (byte & 0x80)
            {
            RFM12_PORT |= (1<<RFM12_SDI);  // DATA auf H
            }
        else
            {
            RFM12_PORT &= ~(1<<RFM12_SDI);  // DATA auf L
            }
        asm("nop");
        asm("nop");
        asm("nop");
          RFM12_PORT |= (1<<RFM12_SCK);    // CLK auf H
        asm("nop");
        asm("nop");
        asm("nop");
        asm("nop");
          RFM12_PORT &= ~(1<<RFM12_SCK);    // CLK auf L
        byte = (byte << 1);          // nächstes Bit nach oben
        }

      byte = 0;

      for (j=0; j<8; j++)
        {     
        byte = (byte << 1);          // eins höher schieben
        if ((RFM12_PIN & (1<<RFM12_SDO)) == (1<<RFM12_SDO))  // Bit 1?
            {
            byte = (byte | 0x01);        // ja
            }
        asm("nop");
          RFM12_PORT |= (1<<RFM12_SCK);    // CLK auf H
        asm("nop");
        asm("nop");
          RFM12_PORT &= ~(1<<RFM12_SCK);    // CLK auf L
        }
      *data_buf++ = byte;
      RFM12_PORT |= (1<<RFM12_CS);      // CS auf H
    }

    RFM12_send_cmd(0x8208);            // Empfänger aus

  }

Die Routine ist Software-SPI auf einem AVR, es geht ja nur um die 
Einleseschleife der Daten.
Ich lese eine feste Anzahl Bytes als Telegramm ein.

Gestartet wird im Interrupt, wenn derIRQ den Empfang der Magic-Pattern 
meldet.

Gruß aus Berlin
Michael

[Mateusz R. (mateusz224)]

@Felix:
Also ich bin mit nicht sicher ob du mcih richtig verstanden hast, bin 
aber auch furchtbar in erklären^^. Also MOSI ist deswegen die ganze Zeit 
auf LOW durch die hinzugefügte Zeile:

while(!(rfm_get_status() & (1<<15)));

beim lesen des Status Registers wird auf die MOSI Leitung 00000000 
00000000 gelegt. Da jedoch die oben genannte Aussage nie true wird 
(wieso auch immer!!?!?!?!!) bleibt das Programm da stecken. Und nIRQ 
verändert sich NIE es ist IMMER auf HIGH und ich glaub das ist das 
Problem. Das irgendwas mit dem FIFO nicht stimmt... aber es funktioniert 
bei beiden Modulen nicht also ist das auch kein Hardware schaden... habe 
das auch schon vorher bei einem 434MHz Modul versucht gleiches 
Problem...

nIRQ hat nur dann sich verändert wenn ich nicht für jeden befehl nSEL 
auf low gezogen habe...

@Miachel
 "SDO spiegelt immer den Zustand des FIFO-Status"

stimmt jedoch glaub ich nicht dass es den gewünschten Effekt mit sich 
bring... also ich werde das später testen, aber eigetlich würde ich den 
nIRQ schon funktionsfähig haben wollen damit das hauptprogramm weiter 
abeiten kann und nicht die ganze Zeit auf ankommende Daten warten muss 
bzw den Fifo überprüfen muss...

[Stefan (Gast)]

Also der SEL Pin muß auf Low, dann empfängt das Modul
Daten oder einen Befehl.
Beim Empfänger geht nur MISO auf high, wenn er 2DD4
empfangen hat. Dabei wird auch ein Datenbyte mit gesendet.
Dieses holt man mit B0000 ab.
Sendet der Sender kein 2DD4 so kann beim Empfänger auch der
MOSI Pin nicht auf high gehen.

[Mateusz R. (mateusz224)]

@Stefan
Das tut doch mein Programm ich Sende ja 0x8B2D und anschließend 0x8BD4 
oder meinst du etwas anderes?

[Michael U. (amiga)]

Hallo,

ich hatte nicht soviel Zeit, das alles durchzuschauen, meine 
Initialisierung als Empfänger ist ja schon in meinem Posting ziemlich 
weit oben.

Die läuft so mit diesen Werten, ist für 433MHz.
Wenn der RFM meldet, daß das MagicPattern empfängen wurde startet die 
zuletzt gepostete Routint und warte darauf, das SDO auf H geht, dann ist 
ein Byte im FIOF und das hole ich ab und warte auf das nächste.

Es gibt auch eine komplette IRQ-Lösung bei mir, die muß ich erst 
raussuchen.
Meine C-Sachen sind da leider etwas ungeordnet, das Original ist 
komplett in AVR-Assembler.

Das Einschalten des Empfängers ist bei mir mit:

    RFM12_send_cmd(0x82C8);            // Empfänger ein
    RFM12_send_cmd(0xCA81);            // set FIFO mode
    RFM12_send_cmd(0xCA83);            // enable FIFO

Am Ende eines Datenpaketes schalte ich wieder aus:

   RFM12_send_cmd(0x8208);            // Empfänger aus

Das stammt aus Testsourcen, die so laufen, aber nicht komplett sind.
Es ging mir ja nur um die Initialisierung des RFM12 als Empfänger und 
das auslesen des FIFO.

Jedesmal Status komplett holen kann je nach eingesteller Baudrate und 
SPI-Geschwindigkeit durchaus zum Überlauf des FIFO führen. Die haben das 
mit dem Bit auf SDO durchaus mit Absicht eingebaut.

Gruß aus Berlin
Michael

[Stefan (Gast)]

Wollte nur damit sagen, wenn der MOSI nicht
auf high geht, dann sendet der Sender nicht.
Deshalb habe ich das vorgeschlagen mit dem
DVB-T Stick. Damit du überhaupt mal siehst,
ob er sendet. So weist du nicht wo der Fehler liegt.
Beim Sender oder Empfänger.

[Michael U. (amiga)]

Hallo,

deshalb hatte ich mir vor Jahren dieses hochwertige Gerät gekauft:
http://www.ebay.de/itm/GY-560-Frequency-Counter-Frequenzzahler-fur-Transmitter-Funkgerat-Tragbar-Neu-/311368892559?hash=item487f08408f

Gibt es also immernoch...
Ist nicht wirklich zu gebrauchen, aber als Sendeindikator nutzbar, auch 
wenn man bei RFM12 o.ä. den RFM12-Antennendraht besser um die Antenne 
des Gerätches wickelt.

Gruß aus Berlin
Michael

[Felix P. (fixxl)]

Mateusz R. schrieb:
> beim lesen des Status Registers wird auf die MOSI Leitung 00000000
> 00000000 gelegt. Da jedoch die oben genannte Aussage nie true wird
> (wieso auch immer!!?!?!?!!) bleibt das Programm da stecken.
Wenn MISO beim Aktivieren des Chips auf high geht, muss das MSB des 
Statusregisters gesetzt sein und dementsprechend sollte die 
while-Schleife auch abbrechen. Sehr komisch!

Hast du mal mit dem Oszi die MISO-Leitung überwacht, ob das eingelesene 
Resultat dem tatsächlichen Pegel entspricht? Nicht dass der Fehler 
irgendwo in den spi-Routinen liegt.

[Mateusz R. (mateusz224)]

Also kurzzeitig hat die nIRQ Leitung funktioniert und nach einiger Zeit 
nicht mehr... ist aber auch nicht reproduzierbar gewesen... und jetzt 
habe ich es geschafft die Platine zu schrotten^^

Naja kann aber die Tests weiter auf dem Raspberry machen, da ist ja das 
gleiche Ergebnis und zwar dass nIRQ auf dauer HIGH ist.

Also ich versuch erstmal den Fifo interrupt stabil zu erhalten... wenn 
das funktioniert dann schau ich ob ich auch Daten erhalte.

Denke solange kein nIRQ interrupt ausgelöst wird bzw. dass FFIT bit auch 
gesetzt wird beim Sender, werde ich auch keine Daten beim Empfänger 
erhalten.

PS: Ja die spi-Routinen sind in Ordnung.