www.mikrocontroller.net

Forum: Compiler & IDEs RFM 01 empfängt nicht


Autor: Maikel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute ich weiß es gibt unzählige Beiträge zum RFM aber ich komm 
trozdem nicht hinter mein Problem.

Also wie schon gesagt empfange ich nichts, mein Sender klappt auf jeden 
fall das weiß ich.

Im Anhang ist der Schaltplan

/********************************************************************
Bobycar-Empfänger
RFM01-Funkmodul (Empfangen)
Maikel Rehl

Prozessor: ATMEGA8
Frequenz: 434MHz
Datenrate: 4.8kbps

----------------------------------------------------------------------
ATMEGA8           RFM01            ISP 10-Pin
----------------------------------------------------------------------
PD6               SCK
PD5               SDI
PD7               nSEL
PD4               SDO
PC4               LED2
PC5               LED1 (Power)

PB3 (MOSI)                  MOSI
PB4 (MISO)                  MISO
PB5 (SCK)                  SCK
PC6 (RESET)                  RESET

// nFFS: 1-10k Pullup an Vcc !!!
*********************************************************************/

#include <avr/io.h>
#include "defines.h"
#include "uart.h"
#include "rfm01.h"

void Delay_ms(unsigned char amS){
  unsigned char i;
  unsigned int j;
  for(i=0;i<amS;i++)for(j=0;j<914;j++);
}

int main(void)
{
  unsigned char i,j,ChkSum;
  uart_init(51);
  LED_OUTPUT();
  LED1_ON();
  for(i = 0;i<5;i++)
  {
    LED1_TRG();
    Delay_ms(200);
  uart_putc(i);
  }
  uart_puts("huhu");

  RFXX_PORT_INIT();
  RFXX_WRT_CMD(0x0000);
  RFXX_WRT_CMD(0x898A);//134kHz
  uart_puts("898A\r\n");
  RFXX_WRT_CMD(0xA640);//434MHz
  uart_puts("A640\r\n");
  RFXX_WRT_CMD(0xC847);//4.8kbps
  uart_puts("C847\r\n");
  RFXX_WRT_CMD(0xC69B);//AFC setting
  uart_puts("C69B\r\n");
  RFXX_WRT_CMD(0xC42A);//Clock recovery manual control,Digital filter,DQD=4
  uart_puts("C42A\r\n");
  RFXX_WRT_CMD(0xC240);//output 1.66MHz
  uart_puts("C240\r\n");
  RFXX_WRT_CMD(0xC080);
  uart_puts("C080\r\n");
  RFXX_WRT_CMD(0xCE88);//Aktiviere FIFO
  uart_puts("CE88\r\n");
  RFXX_WRT_CMD(0xCE8B);
  uart_puts("CE8B\r\n");
  RFXX_WRT_CMD(0xC081);//Start RX
  uart_puts("C081\r\n");
  DDRD |= (1<<RFXX_DATA);
  DDRD &= ~(1<<RFXX_NIRQ);
  while(1)
  {
    while(!(PIND&(1<<RFXX_NIRQ)))//wartet darauf das RFXX_NIRQ gelöscht ist
  {
      RF_RXBUF[i++]=RF01_RDFIFO();//lese FIFO Daten
     uart_putc(RF01_RDFIFO());
     uart_puts("\r\n");
      if(i==18){
        RFXX_WRT_CMD(0xCE88); //Resetet FIFO um den nächsten Frame zu empfangen
        RFXX_WRT_CMD(0xCE8B);
        i=0;
        ChkSum=0;
        for(j=0;j<16;j++){
          ChkSum+=RF_RXBUF[j]; //berechnete checksumme
        }
        if(ChkSum==RF_RXBUF[16]){//frame check
          LED1_TRG();
        }
      }
    }
  }
}


//rfm01.c die rfm01.h gibt es natürlich auch hab ich nur nicht aufgelistet

//-------------RFM01---------//
#include <avr/io.h>
#include "defines.h"
#include "rfm01.h"
#include "uart.h"

void RFXX_PORT_INIT(void)
{
  uart_puts("Initialisiere \r\n");
  HI_SEL();
  HI_SDI();
  LOW_SCK();
  SEL_OUTPUT();
  SDI_OUTPUT();
  SDO_INPUT();
  SCK_OUTPUT();
}

unsigned int RFXX_WRT_CMD(unsigned int aCmd){
  unsigned char i;
  unsigned int temp;
  LOW_SCK();
  LOW_SEL();
  for(i=0;i<16;i++){
    temp<<=1;
    if(SDO_HI()){
      temp|=0x0001;
    }
    LOW_SCK();
    if(aCmd&0x8000){
      HI_SDI();
      }else{
      LOW_SDI();
    }
    HI_SCK();
    aCmd<<=1;
  };
  LOW_SCK();
  HI_SEL();
  return(temp);
}

unsigned char RF01_RDFIFO(void){
  unsigned char i,Result;
  LOW_SCK();
  LOW_SDI();
  LOW_SEL();
  for(i=0;i<16;i++){//skip status bits
    HI_SCK();
    HI_SCK();
    LOW_SCK();
    LOW_SCK();
  }
  Result=0;
  for(i=0;i<8;i++){//read fifo data byte
    Result<<=1;
    if(SDO_HI()){
      Result|=1;
    }
    HI_SCK();
    HI_SCK();
    LOW_SCK();
    LOW_SCK();
  };
  HI_SEL();
  return(Result);
}

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also wie schon gesagt empfange ich nichts
Was hast du denn schon versucht um doch etwas zu empfangen?

> mein Sender klappt auf jeden fall das weiß ich.
Woher weist du das?

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab mir von einem freund eine fernbedinung ausgeliehen die mit dem 
RFM12 läuft, und die funktioniert bei ihm, daher weiß ich das, und den 
code davon hab ich auch.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommst du dann darauf dass der Fehler im Code liegt, wenn dieser bei 
deinem Freund funktioniert?

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab gesagt der fehler liegt an meinem EMPFÄNGER, von meinem freund 
ist der sender.

der code oben ist auch von EMPFÄNGER

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann versuch doch einfach mal den Code deines Freundes...
Selbstverständlich den des EMPFÄNGERS.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest mal den Code aufräumen..:

>   DDRD |= (1<<RFXX_DATA);
>   DDRD &= ~(1<<RFXX_NIRQ);
^- das ist in der init() besser aufgehoben, wobei sich mir der Sinn von 
DATA noch nicht recht erschliesst. Laut Schaltplan (und wenn ich mich 
recht erinnere, dann auch laut Erinnerung) ist das dauerhaft auf High 
gezogen.

>   while(1)
>   {
>     while(!(PIND&(1<<RFXX_NIRQ)))//wartet darauf das RFXX_NIRQ gelöscht ist
              ^- das schreit geradezu nach einem aussagekräftigen Makro 
:-)
>     {
>         RF_RXBUF[i++]=RF01_RDFIFO();//lese FIFO Daten
>         uart_putc(RF01_RDFIFO());
                    ^- ?? sollte da nicht "RF_RXBUF[i-1]" (Achtung 
Array-Grenzen!!!!) stehen?

Deklaration und Definition von RF_RXBUF hab ich nicht gefunden, kann Dir 
also nicht sagen, ob die while-Bedingung im Kontext sinnvoll ist. Das i 
wird auch nicht zurückgesetzt, das hat am Anfang obiger while-Schleife 
noch den Wert 5 - ist das beabsichtigt??

HTH

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der code ist der beispiel code von pollin an dem ich eigentlich nur die 
pins geändert habe, mit RFXX_DATA geb ich dir recht mir auch nicht 
schlüssig wozu das da sein soll, denn der ist nicht angeschlossen oder 
sonst was.

RF_RXBUF ist in der define.h daklariert.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab mir mal den Code von Pollin [1] angesehen, da gibts 
tatsächlich ein Beispielprogramm..

> mit RFXX_DATA geb ich dir recht mir auch nicht schlüssig wozu das da
> sein soll, denn der ist nicht angeschlossen oder sonst was.

Laut deren Pinout ist er angeschossen.. Bei Dir nicht. Hab eben mein 
Modul rausgekramt (868MHz), dort ist er (so wie bei Dir) per Pullup auf 
+Vcc (und es funktioniert) -> im Code entfernen.

>> Das i wird auch nicht zurückgesetzt, das hat am Anfang obiger while-
>> Schleife noch den Wert 5 - ist das beabsichtigt??

Ich mach mal die Ingrid nachdem Du nicht drauf eingegangen bist: Nein, 
es ist nicht sinnvoll </WinkMitDemZaunpfahl> ;-)

In Deinem Code sind Sender und Empfänger (etwa.. siehe weiter unten) 5 
Bytes Phasenverschoben. Wär schon ein großer Zufall, wenn die Checksumme 
dann trotzdem mal passen würde..

Achja nochmal die Ingrid: Das mit dem doppelten FiFo-Lesen ist natürlich 
auch Mist. Dein Code bewirkt etwa folgendes:

1. Die Phase um 5 Bytes verschieben (am Anfang)
2. Das erste Byte aus dem FiFo lesen und an der sechsten(!) Stelle 
Speichern
3. Müll aus dem wahrscheinlich noch nicht wieder vollständig gefüllten 
FiFo lesen und über uart verschicken.
4. Warten auf neue Daten
5. Das zweite Byte (respektive Müll - gerne bitweise Phasenverschoben, 
falls bei 3. schon wieder ein paar 'echte' Bits im FiFo waren) aus dem 
FiFo lesen und an siebter(!) Stelle speichern.
6. Wieder Müll über uart schicken..
7. D.C.ad.lib.

HTH

[1] http://www.pollin.de/shop/ds/MjU5OTgxOTk-.html - Downloads zu 
RFM01-433

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ist der Code eigentlich völliger müll wenn ich das richtig verstehe

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also ist der Code eigentlich völliger müll wenn ich das richtig verstehe

Depends. Der von Reichelt funktioniert afair. Abgesehen von der geräte- 
und anwendungsspezifischen Initialisierung kann man den schon nehmen zum 
Testen. Nur hast Du ein paar Copy/Paste-Fehler reingebaut, die das 
Erfolgserlebnis erstmal erfolgreich verhindern. Aber nicht aufgeben, der 
hardwarenahe Teil sollte ja klappern, der Rest wird schon noch.

Achja eine etwas ausführlichere Doku zu den Chips gibts beim Hersteller 
[1] s.v. RF01 und RF02 (ohne 'M'), hat mir damals doch weiter geholfen 
:-)

HTH

[1] http://hoperf.com/

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja danke die hab ich auch schon gefunden :)

aber ich wollte erst mal den von pollin nehmen weil da alles in c ist 
und in dem anderen ist aich asm drin das hätet mich verwirrt.

Ich werds mal weiter versuchen, aber angeschlossen hab ich doch alles 
richtig oder also liegt der fehler auf jeden fall im programm.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Rest sieht gut aus so weit. Bau mal die angesprochenen Fehler aus, 
dann sollte zumindest schon mal was ankommen.

Ich seh bei mir gerade im Code, dass ich bei den Kommandos 'fifo_off' 
und 'fifo_on' die Werte 0xCE84 und 0xCE87 schicke (bei Dir: 0xCE88 und 
0xCE8B). Schau nochmal ins Datenblatt, ob du wirklich 'reserved' haben 
willst als fifo-fill-start-condition (★Zaunpfahlwinker★). Bei mir steht 
das auf 'sync word' und es funktioniert einwandfrei :-) (Hint: Das 
Syncword ist 0x2DD4). Kannst je nach Anforderung natürlich auch 'VDI' 
oder 'always' nehmen. Nur 'reserved' würde ich mir für später aufheben.. 
;-)

HTH

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank schonmal ich werds mal versuchen

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also bei mir im daten blatt steht 0xCE88 und
0xCE8B. aber könnten wir vielleicht mal über icq oder so schreiben ich 
denke das geht schneller schick mir wenn möglich einfach ne nummer oder 
was weiß ich an (r e f l e x _ n o . 1 @ w e b . d e) natürlich alles 
zusammen.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> also bei mir im daten blatt steht 0xCE88 und 0xCE8B.

In der Tat, es gibt eine neuere Version des Datenblatts.. und dort steht 
geschrieben zum LSNibble:
  1 0 x x fifo-fill-start-condition 'VDI & sync-word'

..gabs bei mir damals(tm) (Anfang April diesen Jahres) noch nicht.. Aber 
man lernt ja nie aus :-)

HF beim Debuggen

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich habe in meinem code jetzt mal RFXX_DATA gelöscht, und 
uart_putc(RF_RXBUF[i-1]); benutzt, aber es tut sich nix, denn der müsste 
mir doch eigentlich auch den "müll" anzeigen können, allso es sollte ja 
wenigstens irgendwas kommen.
leider kommt aber nix

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, jetzt wirds langsam eng.. ein paar Kleinigkeiten hätt ich noch, 
wenn das nicht hilft, dann heissts klassisch debuggen - mit dem Oszi 
(auf SCK, SDI, SDO - ob sich da was tut) so anwesend, behelfsweise 
'led-blinken in den Schleifen', 'uart-flooding bei Aktivität', ..

Was käme noch in Frage:

- startup zu schnell. Der Compiler könnte - abhängig vom 
Optimierungsgrad - deine Delay_ms() wegoptimieren. Ich verwende 
stattdessen die _delay_ms() aus <util/delay.h> (zzgl. F_CPU).

Zwischenfrage: Die uart-Nachrichten aus der Initialisierungsphase kommen 
aber schon an, oder?

- erst 'Output' setzten, dann 'hi/lo'? ..bei mir immer in dieser 
Reihenfolge, im Datenblatt zu $avr hab ich mal was dazu gelesen.. 
irgendwo.. in weiter Ferne.. könnte signifikant sein, kann mich aber 
auch täuschen.. da müsste im Datenblatt zu Deinem AVR auch was drin 
stehen..

- ich ziehe SDI regelmäßig auf low (am Anfang und am Ende von 
write_command()), weiss aber nicht mehr genau, ob ich das wegen 
Stromsparen eingebaut hab oder wegen der Kommunikation.

- achja wäre es denkbar, dass Sender und Empfänger auf unterschiedliche 
Funkparameter eingestellt sind? Ich erinnere mich vage, dass sich die 
Kommandos damals(tm) erheblich unterschieden haben für RFM01 und RFM02..

Viel Erfolg!

P.S.: Antennen sind schon eingesteckt, oder? ;-)

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja normal uart senden geht, aber antenne hab ich im empfänger nicht 
drin, nur im sender, hab gelesen das es auch so geht

Autor: Ralph Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Da fummeln ja noch andere an dem RFM01/02_Pärchen rum... :-)

[quote]In der Tat, es gibt eine neuere Version des Datenblatts.. und 
dort steht
geschrieben zum LSNibble:
  1 0 x x fifo-fill-start-condition 'VDI & sync-word'[/quote]

Beim Hersteller der Chips (Silicon Labs) steht das schon ziemlich lange 
so drin.

Hope kauft die Chips bei Silabs und bastelt die auf ihre Module. Beim 
Kopieren der  Datenblätter schaffen es die Jungs tatsächlich, Fehler 
einzubauen...also besser die Originale nehmen (TX = Si4020, RX = 
Si4320).

Bei Silabs gibt es einiges an Literatur zu den Chips, z.B. ein recht 
gutes Tutorial zum Ermitteln der geeigneten HF-Parameter. Ich finde es 
sinniger, das zu lesen und die Datenblätter zu studieren (und 
verstehen), als irgendwelche Konfig-Parameter aus dem Netz zu nehmen. Da 
ist eine Menge Unfug unterwegs.

An den OP: versuche doch erstmal, den Fifo wegzulassen und zu sehen, ob 
der VDI "schnackelt".

So weit habe ich meinen RFM01 jetzt.

Das Mistding wird bald aufgeben... :-)

Viel Glück!

Ralph

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soo ich hab jetzt was anderes versucht
von hoperf gibt es ja auch codes die hat mein freund auch benutzt
ich hab den auch mal benutzt der code sieht auf jeden fall besser aus 
aber leider passiert immer noch nicht so viel, kann es denn vielleicht 
echt daran liegen das ich keine antenne habe ?
ich zeig mal den code.
// main.c
/********************************************************************
Bobycar-Empfänger
RFM01-Funkmodul (Empfangen)
Maikel Rehl

Prozessor: ATMEGA8
Frequenz: 434MHz
Datenrate: 4.8kbps

----------------------------------------------------------------------
ATMEGA8           RFM01            ISP 10-Pin
----------------------------------------------------------------------
PD6               SCK
PD5               SDI
PD7               nSEL
PD4               SDO
PC4               LED2
PC5               LED1 (Power)

PB3 (MOSI)                  MOSI
PB4 (MISO)                  MISO
PB5 (SCK)                  SCK
PC6 (RESET)                  RESET

// nFFS: 1-10k Pullup an Vcc !!!
*********************************************************************/

#include <avr/io.h>
#include "defines.h"
#include "uart.h"
#include "rf01.h"
#include <util/delay.h>

int main(void)
{
  uart_init(51);
  LED_OUTPUT();
  LED1_ON();
  for(int i = 0;i<5;i++)
  {
    LED1_TRG();
    _delay_ms(500);
  }
  uart_puts("los");

  rf01_init();          
  rf01_setfreq(RF01FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf01_setbandwidth(4);      // -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf01_setbaud(9600);        // 200kHz Bandbreite
  rf01_setreceiver(2,4);      // 9600 Baud

  for (;;)
  {  rf01_rxdata(RF_RXBUF, 3);    // 3Bytes empfangen
    uart_putc(RF_RXBUF[0]);
    uart_putc(RF_RXBUF[1]);
    uart_putc(RF_RXBUF[2]);
    uart_puts("\r\n");
    _delay_ms(500);
  }
}



//rf01.c

//-------------RFM01---------//
#include <avr/io.h>
#include "defines.h"
#include "rf01.h"
#include "uart.h"

#ifndef F_CPU
  #define F_CPU 8000000UL
#endif

#ifndef cbi
#define cbi(sfr, bit)     (_SFR_BYTE(sfr) &= ~_BV(bit)) 
#endif
#ifndef sbi
#define sbi(sfr, bit)     (_SFR_BYTE(sfr) |= _BV(bit))  
#endif

#include <util/delay.h>

static unsigned char sdrssi, sgain;

void rf01_trans(unsigned short wert)
{  unsigned char i;

  cbi(RF_PORT, CS);
  for (i=0; i<16; i++)
  {  if (wert&32768)
      sbi(RF_PORT, SDI);
    else
      cbi(RF_PORT, SDI);
    sbi(RF_PORT, SCK);
    wert<<=1;
    _delay_us(0.2);
    cbi(RF_PORT, SCK);
  }
  sbi(RF_PORT, CS);
}

void rf01_init(void)
{  unsigned char i;
  RF_PORT=(1<<CS);
  RF_DDR=(1<<SDI)|(1<<SCK)|(1<<CS);

  for (i=0; i<11; i++)
    _delay_ms(10);      // wait until POR done

  rf01_trans(0xC2E0);      // AVR CLK: 10MHz
  rf01_trans(0xC42B);      // Data Filter: internal
  rf01_trans(0xCE88);      // FIFO mode
  rf01_trans(0xC6F7);      // AFC settings: autotuning: -10kHz...+7,5kHz
  rf01_trans(0xE000);      // disable wakeuptimer
  rf01_trans(0xCC00);      // disable low duty cycle
}

void rf01_setbandwidth(unsigned char bandwidth)
{
  rf01_trans(0x8970|((bandwidth&7)<<1));
}

void rf01_setreceiver(unsigned char gain, unsigned char drssi)
{
  sdrssi=drssi;
  sgain=gain;
}

void rf01_setfreq(unsigned short freq)
{  if (freq<96)        // 430,2400MHz
    freq=96;
  else if (freq>3903)      // 439,7575MHz
    freq=3903;
  rf01_trans(0xA000|freq);
}

void rf01_setbaud(unsigned short baud)
{
  if (baud<336)
    return;
  if (baud<5400)        // Baudrate= 344827,58621/(R+1)/(1+CS*7)
    rf01_trans(0xC880|((43104/baud)-1));
  else
    rf01_trans(0xC800|((344828UL/baud)-1));
}

void rf01_rxdata(unsigned char *data, unsigned char number)
{  unsigned char i,j,c;
  uint8_t TimeOut;
  rf01_trans(0xC0C1|((sgain&3)<<4)|((sdrssi&7)<<1));  // RX on
  rf01_trans(0xCE89);      // set FIFO mode
  rf01_trans(0xCE8B);      // enable FIFO
  cbi(RF_PORT, SDI);
  for (i=0; i<number; i++)
  {  cbi(RF_PORT, CS);
    
    while (!(RF_PIN&(1<<SDO)))
    {
      TimeOut++;
      _delay_us(1);
      if (TimeOut == 250)
      return;
    } // wait until data in FIFO
    
    for (j=0; j<16; j++)  // read and discard status register
    {  sbi(RF_PORT, SCK);
      asm("nop");
      cbi(RF_PORT, SCK);
    }
    c=0;
    for (j=0; j<8; j++)
    {  c<<=1;
      if (RF_PIN&(1<<SDO))
        c|=1;
      sbi(RF_PORT, SCK);
      _delay_us(0.2);
      cbi(RF_PORT, SCK);
    }
    *data++=c;
    sbi(RF_PORT, CS);
  }
  rf01_trans(0xC0C0|((sgain&3)<<4)|((sdrssi&7)<<1));  // RX off
}



//define.h

//Hier stehen alle Defines für den Sender

#define RF_PORT  PORTD
#define RF_DDR  DDRD
#define RF_PIN  PIND

#define SDI    5  // SDI,  -> RF02
#define SCK    6  // SCK,  -> RF02
#define CS    7  // nSEL, -> RF02
#define SDO    4  // SDO,  <- RF02

#define DDR_IN 0
#define DDR_OUT 1
#define DDR_LED DDRC
#define PORT_LED PORTC
#define LED_OUTPUT() DDR_LED = 0x30
#define LED1_ON() PORT_LED|=(1<<4)
#define LED1_OFF() PORT_LED&=~(1<<4)
#define MODULE_ON() PORT_LED|=(1<<5)
#define MODULE_OFF() PORT_LED&=~(1<<5)
#define LED1_TRG() PORT_LED^=(1<<4)
unsigned char RF_RXBUF[3];


Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ad Drahtstummel: Ich hab meine noch nie mit ohne Antenne betrieben. Aber 
ein guter Grund, dass es nicht geht wäre es auf jeden Fall :-)

Ad Silabs: Ui krass, endlich anständige Datenblätter :-) Das hat mich 
damals(tm) vielleicht Nerven gekostet.. aber zum Laufen hab ich sie dann 
doch noch hingeprügelt.. mit viel Trial and Error..

Ich bin dann mal Literatur wälzen :-)))) Besten Dank für den Hinweis 
:-))

Autor: User (Ingrid..) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal ad Antenne: Ich hab (für 868MHz) sehr gute Erfahrungen gemacht 
mit einem einfachen Stück Litze, 8.6cm lang direkt an das PCB gelötet. 
Ein einfachster ƛ/4-Strahler halt :-) Und zum Testen sollte es sowieso 
langen. (Bei 433MHz wären das dann etwa 17.3cm, nur der Vollständigkeit 
halber)

So, jetzt aber zurück in den Datenblattstapel :-))

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab das datenblatt auch mal überflogen und gesehen das die in 
der mindestbeschaltung nirq angeschlossen haben, was ich bei mir ja auch 
habe.
jedoch wird es im code überhaupt nicht benutzt.
aber der muss doch immer auf low stehen wenn er etwas empfäng also muss 
ich doch vor jedem empfangen den stauts low abwarten oder ?

Autor: User (Ingrid..) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[ nIRQ ]

Im ursprünglichen Code hast Du das benutzt (und ich habs angemosert ob 
da nicht ein Makro hüpscher wär), in der neueren Version steht 
stattdessen 'return falls SDO zu lange low '.. das sollte wohl auch eher 
'warten auf nIRQ low' sein.

Eine Anmerkung möchte ich noch loswerden: Das Warten war in ersterem 
Fall erfolgreicher gelöst. Genau genommen gehts aber noch etwas besser, 
zumindest wenn man nicht realtime-artig auf eine 'Antwort' wartet:

- RX initialisieren
- RX FiFo zurücksetzen (z.B. mit Länge 8 Bit)
:warten_und_teetrinken
- irgendwann geht nIRQ auf low
- eine FiFo-Füllung abholen (z.B. 8 Bit)
- ein Datenpakt vollständig ? { selbiges verarbeiten; FiFo 
zurücksetzen(!) } : nop
- goto warten_und_teetrinken

Das Warten kann man per busy-waiting totschlagen oder per IRQ (letzteres 
hab ich an einem attiny2313 per PCINT nicht zum laufen bekommen.. aus 
einem mir bisher nicht bekannten Grund hat der tiny den PCINT nicht 
aufgezeichnet.. obwohl das Oszi die Pegeländerung sauber(tm) 
protokolliert hat.. und falls er ihn doch mal mitbekommen hat, dann zu 
langsam, da war die Millisekunde dann schon vorbei..)

HTH

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab gesehen das in dem code darauf gewartet wird das SDO auf low 
geht, aber ich habs auch mal mit nIQR versucht leider klappt es nicht. 
ich werde wohl echt mal versuchen ne antenne anzuschließen

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ich hab mal ne antenne angeschlossen
leider tut sich noch nichts, könnt ihr euch vielleicht noch mal den code 
genau angucken und mir sagen was daran falsch ist, ich verzweifel 
langsam echt.
wäre echt super

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du mal deinen vollständigen Code anhängen(!)? Wenn möglich 
inklusive build-Skripten/Makefile/.. Ansonsten kann ich Dir anbieten, 
dass Du mal meinen (alten) Code ausprobierst, der ist allerdings an ein 
paar (wenigen, hier unwesentlichen) Stellen tiny2313-spezifisch.

Aber erstmal noch eine wichtige Frage zum Hardwaredebuggen: Hast Du ein 
Oszi zur Hand? Schau mal auf SCK, SDI und SDO, ob sich da irgendwas tut. 
Mit einem Multimeter kannst auch auf nIRQ schauen, ob das (bei zu 
erwartendem Empfang) auf low geht. Falls sich am nIRQ nix rührt, dann 
hast Du ein Problem mit dem Empfang (falsch konfiguriert, 
Stromversorgung, ..aaah, da fällt mir grad was ein: Ich hab dem 
RFM0[1,2] einen extra Elko (100u-universal-totschlag-Elko) spendiert, 
obwohl (oder gerade weil?) die Stromversorgung aus einer Batterie 
stammt. Und immer wenn was gekommen ist (über Funk), dann hat das RFM* 
einen reset gemacht.. da bin ich aber erst mit dem Oszi draufgekommen..)

Wo war ich.. genau, also wenn sich an SDO was rührt, dann wär das schon 
mal was. Wenn sich nIRQ bewegt und es tut sich nix an SCK (und SDI), 
dann liegts sicher an der Software.

Viel Spaß beim messen :-)

Autor: Maikel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
zur hand hab ich leider keins, nur in der schule kann ich morgen aber 
mal nach gucken (ja morgen ^^ tag der offenen tür) aber erstmal muss ja 
der code stimmen :)
wegen dem resetproblem hab ich den reset pin über 10k an vcc, genau 
damit der nicht fröhlich vor sich hin resetet.
den code kann mal anhängen ja.

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der erste böse Schnitzer war zwar schon mal angesprochen, ist aber 
immernoch drin:
void rf01_rxdata( [..] )
    [..]
    while (!(RF_PIN&(1<<SDO)))
    {
      TimeOut++;
      _delay_us(1);
      if (TimeOut == 250)
      return;
    } // wait until data in FIFO
    [..]
Du wartest als allererstes auf SDO, da kann aber nix kommen, solange du 
kein SCK ausgibst. Korrekt müsste das etwa so heissen:
#define RFNIRQ_IS_HIGH() ( RF_PIN & (1 << IRQ) )
[..]
    // busy-wait for nIRQ low
    while (RFNIRQ_IS_HIGH())
    { [.. Timeout zählen oder auch nicht ..] }
Falls Du den timeout wirklich brauchst, dann kannst ihn natürlich auch 
da in die Schleife reinpacken. Wobei 250µs schon recht kurz sind bei so 
niedrigen Übertragungsraten: Wenn der Code 'richtig'(TM) ist und Du 9600 
baud setzt, dann dauert die Übertragung eines einzelnen Bytes immerhin 
(mindestens) 1/9600*8 Sekunden, da wären in Zahlen etwa 833µs(!). Bei 
einem so kurzen Timeout würdest Du also höchstens immer das erste Byte 
erwischen, der Rest wär noch nicht mal im Äther..

Das mit dem Elko(!) bei mir hatte übrigens keinen Zusammenhang mit einem 
eventuell nicht vorhandenen Reset-Pullup (der ist sowieso obligat). Bei 
mir hat das Funkmodul(!) resettet (und das hat als Folge gelegentlich 
auch den tiny mitgezogen). Also einfach mal einen Elko dazustecken falls 
Du alle anderen Fehlerquelle ausschließen kannst..

Noch zwei Verbesserungsvorschläge: In uart.c:
#include <avr/io.h>
#include <avr/iom8.h>
Das ist böse, korrekterweise steht da nur das Include für io.h, das muss 
langen. Der Rest kommt automagisch via -mmcu=$typ.

Und in die Header-Dateien (*.h) macht man üblicherweise ein
#ifndef include_eindeutiger_dateiname_h
#define include_eindeutiger_dateiname_h

[.. Inhalt ..]

#endif // include_eindeutiger_dateiname_h
aussen rum, das spart versehentliche doppelte Includes mit u.U. 
unverhersehbaren Nebeneffekten.

Viel Spaß mit dem Oszi morgen, aber korrigiere vorher noch obigen Bug!

HTH

Autor: Maikel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so vielen danke erstmal das du dir überhaupt die zeit für das alles 
nimmst :)

ich hab jetzt mal soweit ausgebessert, sieht bei mir jetzt so aus
#define RFNIRQ_IS_HIGH() ( RF_PIN & (1 << IRQ) )
[...]
while (RFNIRQ_IS_HIGH())
{
  return;
}

das include iom8.h hab ich jetzt rausgekommen, ich hatte das nur drin 
weil ich mit den UART probleme hatte aber naja jetzt ging das auf jeden 
fall auch noch.

so aber da hatte sich nix getan

dann hab ich einfach mal verscuht hier bei dem if auch RFNIRQ_IS_HIGH() 
reinzusetzten weil der da auch auf SDO=high gewartet hat, das ging aber 
auch nicht dann hab ich diese sache wieder rückgängig gemacht.
for (j=0; j<8; j++)
{  c<<=1;
  if (RFNIRQ_IS_HIGH())
  c|=1;
  sbi(RF_PORT, SCK);
  _delay_us(0.2);
  cbi(RF_PORT, SCK);
}

naja auf jeden fall klappt es nocht nicht :(

Autor: User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim 'zweiten' ist das RFNIRQ natürlich fehl am Platze, schließlich 
liesst Du da den SDO aus - der RFNIRQ ist nur der Anzeiger, dass was im 
FIFO steht. Also wenn RFNIRQ low, dann ist was im FIFO, also SCK 
rausschicken und FIFO reinlesen..

Was sagt das Oszi zum RFNIRQ? Bekommst Du da was? Bleibt er dauerhaft 
high (dann hast Du keinen Empfang (Hardwarefehler, falsche 
Konfiguration, ..))? Geht er auf low und bleibt dort (dann bekommt der 
µC den Wechsel nicht richtig(tm) mit oder er setzt den FIFO nicht 
korrekt zurück)? Was Du sehen willst (bei Dauersenden/-empfang) ist ein 
schönes Rechtecksignal auf dem RFNIRQ. Alles andere ist (bei Verwendung 
des FIFO) ein guter Indikator für die Fehlerstelle.

HTH und viel Spaß beim Debugg0rn :-)

Autor: Ralph Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

User schrieb:
> Was sagt das Oszi zum RFNIRQ? Bekommst Du da was? Bleibt er dauerhaft
> high (dann hast Du keinen Empfang (Hardwarefehler, falsche
> Konfiguration, ..))?

Hm, jein, man kann noch eine Stufe tiefer ansetzen und nur den VDI 
begucken. Wenn der im Rythmus des Senders zappelt, wird schon mal etwas 
empfangen. Der Nirq muß dann noch nicht klappen...in dem Stadium bin ich 
jetzt (wieder).

Vor einiger Zeit war ich schon so weit, bis dann ploetzlich nichts mehr 
ging. Heute fand ich die Ursache: ein Flachbandkabel vom Steckbrett zum 
RFM-Adapter (beide Seiten ordentlich mit Steckern kontaktiert) hatte ne 
Unterbrechung...grmpff&%&$§$&%&%§$!!

Was ich neulich vergessen hatte: bei http://www.controller-designs.de
gibt es ein paar nette Java-Tools (unter "Projekte") zum Umrechnen der 
Parameter in Hex.
Inzwischen habe ich mir aber angewöhnt, die Parameter binär in den 
Quelltext zu schreiben; finde ich übersichtlicher.

Viel Erfolg bei der Fehlersuche!

Ralph

Autor: G. 457 (g457)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
</User>*Account anleg*<g457>

> [ ..] bis dann ploetzlich nichts mehr ging [..] hatte ne
> Unterbrechung...grmpff&%&$§$&%&%§$!!

★eg★, das kenne ich.. ..Und Du wirst es kaum glauben, aber genau das 
selbe ist mir jetzt auch passiert, als ich mein 
RFM01-Labor-Testplattform-Platinen-Lochrasterkarten-Dings wieder in 
Betrieb nehmen wollte - es ging genau garnichts. Muss sich wohl eine 
kalte Lötstelle schlussendlich doch noch durchgesetzt haben. Zum Zwecke 
des Schonens der eigenen Nerven hab ichs jetzt stattdessen auf einem 
Brotbrett aufgebaut (und hey, es läuft bei 18.432MHz µC-Takt und 
868kommairgendwas MHz Empfangsfrequenz einwandfrei). Vielleicht komm ich 
die Tage mal dazu, des Delinquenten Quellcode auf meinen hiesigen Aufbau 
zu portieren. Vielleicht hilfts ja.

Ad VDI: note to self: VDI verkabeln :-)

Autor: Hannes (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da dieser Thread ganz brandaktuell ist und genau mein Problem ist, 
möchte ich mich kurz nach Eurer Erfahrung bekunden:

Aufbau RFM01 <-> RFM02 von Pollin
Ich nutze PIC-µC, aber trotzdem sollten die Teile ja laufen :-)

Mein Problem ist folgendes:
Sender sendet, Empfänger bekommt auf dem analogen Pin 
(Filter-Kondensator RSSI (?)) auch ein Signal.
Aber er synct überhaupt nicht, das heißt der Empfänger stellt sich 
eifnach tot: keine Daten am Fifo. Meine Einstellungen habe ich von 
Benedikt in asm übertragen. SPI am Empfänger geht auch, habe 10Mhz am 
CLK-pin.

Meine Frage: Woran könnte es liegen, wenn ich an besagtem Kondensator 
nur die An-und Abschaltvorgänge des Senders, aber nicht die Daten des 
Senders sehen kann?

Die Amplitude an dem Pin beträgt etwa 0,5V. ich sehe exakt die An-und 
abschaltvorgänge, die ich am Sender vornehme...
Funktioniert auch wenn der Sender im Nebenraum ist. Verbindung scheint 
also irgendwie zu stehen.

Bild: Low= Sender aus, High=Sender an und sendet

Habt Ihr Vorschläge / Ideen?

Gruß Hannes

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.