Forum: Compiler & IDEs Hilfe bei RFM12, Timing, SPI


von Gerald H. (elsuppus)


Angehängte Dateien:

Lesenswert?

Hallo alle zusammen,

Ich habe ein Problem mit meinem RFM Modulen.
Ich habe alles schön als Master Slave System mit 2 RFM Modulen 
implementiert und die Funkübertragung funktioniert bei kleinen 
Baudraten((0xC614) also etwas weniger als 19.2k) auch sehr stabil und 
zuverlässig. Der Master sendet kontinuierlich Daten an den Slave. Durch 
eine bestimmt Bitfolge kann der Master dem Slave erlauben ebenfalls 
Daten zu senden. Die Übertragung wird mit dem Rücksenden eines 
Acknowledge abgeschlossen immer abgeschlossen. Falls dies nicht 
geschieht (wenn z.B. die Checksumme beim Empfänger nicht übereingestimmt 
hat) werden im nächsten Zyklus die Daten einfach nochmal gesendet.

Jetzt bin ich dabei meine Sende- und Empfangsbaudrate langsam 
hochzustellen.
Sprich: (0xC611) oder (0xC605)
Hierbei lässt der Empfänger jedoch öfters Interrupts über den nIRQ 
einfach aus. Dadurch werden nicht alle Daten gelesen!

F0000TEK.JPG zeigt das normale Verhalten der Interrupte auf der Master 
(gelb) und der Slave (blau) Seite. Hier: Requestanfrage vom Master an 
den Slave welche vom Slave verneinend beantwortet wird (also Slave 
sendet keine "Nutzdaten" an den Master)

Master sendet: 3 Präambeln, Sync Hi, Sync Low, 5 Datenbytes, 3 Präambeln
2 ms warten
Slave antwortet mit: 3 Präambeln, Syc Hi, Sync Low, 5 Datenbytes, 3 
Präambeln

Bei der Erhöhung der Baudrate auf (0xC611) sieht es oft folgendermaßen 
aus.
Bild F0001TEK.JPG und F0002TEK.JPG
der Master empfängt nicht die vollständigen Datenbytes (Hier nur 4)

Auffällig ist, dass das Auslesen der Bytes beim Master und beim Slave 2 
Bytes immer zu spät erfolgt.
d.h. z.B. Master sendet 3 Präambeln, Sync Hi, Sync Low, 1. Datenbyte, 
2.Datenbyte, 3.Datenbyte
und erst jetzt beginnt der Salve das erste Datenbyte zu lesen. 
(dargestellt durch die Interrupt)

Kann es sein das ich durch das "zu späte" Auslesen bei hohen Baudraten 
ein Timing Problem bekomme und daher Interrupte vergessen werden? Welche 
Gründe kann es haben das der Empfänger (egal Master oder Slave) die 
Datenbytes erst 2 "Takte" später aus dem Fifo holt? Muss man den RFM 
FIFO Puffer bzw. die SPI dafür bestimmt konfigurieren?

meine Config sieht folgendermaßen aus:
  RF12_receive_WRT_CMD(0x80D7);
  RF12_receive_WRT_CMD(0x82D9);
  RF12_receive_WRT_CMD(0xA640);
  RF12_receive_WRT_CMD(0xC611);
  RF12_receive_WRT_CMD(0x94A0);
  RF12_receive_WRT_CMD(0xC2AC);
  RF12_receive_WRT_CMD(0xCA81);
  RF12_receive_WRT_CMD(0xC483);
  RF12_receive_WRT_CMD(0x9850);
  RF12_receive_WRT_CMD(0xE000);
  RF12_receive_WRT_CMD(0xC800);
  RF12_receive_WRT_CMD(0xC400);
  RF12_receive_WRT_CMD(0xCA83);

Standard config vom Pollin test Prog.

Für Hilfe und Anregungen bin ich sehr dankbar!

mfg Gerald

von Michael U. (amiga)


Lesenswert?

Hallo,

dann muß was grundsätzliches nicht stimmen. Ich empfange voll 
transparent im IRQ mit 19200 auf U. Radigs Webserver und habe außer bei 
Störungen noch nie ein Byte verloren. Nach der Syncword werden die Daten 
in den FIFO geschoben. Der steht auf 8 Bit, der IRQ kommt also, sobald 
ein Byte komplett ist.
Da die Verarbeitung bei mir in main() erst erfolgt, wenn die erwartete 
Anzahl Bytes im Buffer liegen, ist die IRQ auch kurz genug für höhere 
Raten, die brauch ich hier allerdings nicht.

Präambel nach den Daten ist nutzlos, die 0xAA davor sind nur, damit der 
Empfänger AFC und AGC einstellen kann.

http://www.avr.roehres-home.de/sensoren/index.html

Ist leider alles sehr unaufgeräumt, vielleicht findest da trotzdem was.

Gruß aus Berlin
Michael

von Gerald H. (elsuppus)


Lesenswert?

Danke für die schnell Antwort und den Link! Ich werde es mir mal 
anschauen. Vll finde ich was mir noch helfen könnte.

Also die angestrebte Baudrate soll min. die 57.6 kBaud sein! Ich sollte 
von der Anwendung aber schon besser auf die 115.2kBaud gehen!

Das der FIFO auf 8Bit steht habe ich auch im gesamten Programm 
durchgecheckt! nach jedem Senden mache ich:

RF12_receive_WRT_CMD(0x82D9);
RF12_receive_WRT_CMD(0xCA81);
RF12_receive_WRT_CMD(0xCA83);

von daher verstehe ich halt auch nicht wirklich warum der sich 2 Bytes 
mit dem Auslesen zeitlässt.

Übrigens das Problem mit den verlorenen Interrupten und damit Bytes 
scheint nur in die Richtung zu bestehen, wenn der Slave auf den Master 
sendet. Und das verwirrt mich mal richtig! Wenn der nIRQ LOW wird, 
springe ich in die ISR und lese dann den FIFO mit (0xB000) in der ISR 
aus. Ist beim Master und Slave genau gleich. Der Interrupt wird schnell 
genug abgearbeit! Das kann man auch in den Bildern oben erkennen! Habs 
auch nochmal mit anderen Ausgängen getestet gehabt ob er wirklich 
rausspringt und sich nicht im Interrupt verläuft! Das hat alles gepasst! 
Von daher für mich unerklärlich ...

Jiop danke zwecks der 3 Präambeln am Schluss! Die stammen noch vom 
Pollintest prog und werden sicherlich noch rausfliegen.

von Sauger (Gast)


Lesenswert?

Mahlzeit,

achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind. 
Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa) 
nachschieben.

MfG

von Michael U. (amiga)


Lesenswert?

Hallo,

Sauger schrieb:
> Mahlzeit,
>
> achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind.
Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig 
ausgelöst.

> Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa)
> nachschieben.

Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er 
mit Senden auch fertig ist, also den wieder leeren Buffer meldet.

von Michael U. (amiga)


Lesenswert?

Hallo,

Sauger schrieb:
> Mahlzeit,
>
> achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind.
Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig 
ausgelöst.

> Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa)
> nachschieben.

Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er 
mit Senden auch fertig ist, also den wieder leeren Buffer meldet.

@Gerald H. (elsuppus): 115kBaud sind zumindest ehrgeizig, die Reichweite 
dürfte merklich geringer werden bzw. die Empfangsbedingungen und die 
Einstellung vov Hub, Bandbreite usw. muß man wohl gut austesten. Man ist 
ja auch von den Störungen im Umfeld abhängig.

Gruß aus Berlin
Michael

von Sauger (Gast)


Lesenswert?

Michael U. schrieb:
> Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig
> ausgelöst.

nicht nur falsche Daten, das ganze RFM gerät außer Tritt.

> Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er
> mit Senden auch fertig ist, also den wieder leeren Buffer meldet.

dann hat der Sender beim nächsten einschalten schon mal was zum senden, 
wenn die 0xaa raus sind kommt der nächste Interrupt und verlangt nach 
mehr (sozusagen als Starthilfe).


MfG

von Michael U. (amiga)


Lesenswert?

Hallo,

Sauger schrieb:
> Michael U. schrieb:
>> Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig
>> ausgelöst.
>
> nicht nur falsche Daten, das ganze RFM gerät außer Tritt.
Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das 
Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon 
deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll.

>> Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er
>> mit Senden auch fertig ist, also den wieder leeren Buffer meldet.
>
> dann hat der Sender beim nächsten einschalten schon mal was zum senden,
> wenn die 0xaa raus sind kommt der nächste Interrupt und verlangt nach
> mehr (sozusagen als Starthilfe).

Merk ich mir mal fpr den RFM12. Habe auf den Sendemodulen RFM02 drauf, 
die wollen sowieso anders bedient werden.

Gruß aus Berlin
Michael

von Sauger (Gast)


Lesenswert?

Michael U. schrieb:
> Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das
> Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon
> deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll.

wenn der auf den RFM12 verbaute Chip (IA4420/1) auf Empfang geschaltet 
ist und das Empfangssignal abtastet, braucht er etwas Zeit, die nicht 
mehr zur Kommunikation auf der SPI-Schnittstelle zur Verfügung steht. 
Der IA4420 ist ein (mimosenhafter) Endlicher Automat (neudeutsch state 
machine) die entsprechend behandelt werden will.

MfG

von Michael U. (amiga)


Lesenswert?

Hallo,

Sauger schrieb:
> Michael U. schrieb:
>> Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das
>> Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon
>> deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll.
>
> wenn der auf den RFM12 verbaute Chip (IA4420/1) auf Empfang geschaltet
> ist und das Empfangssignal abtastet, braucht er etwas Zeit, die nicht
> mehr zur Kommunikation auf der SPI-Schnittstelle zur Verfügung steht.
> Der IA4420 ist ein (mimosenhafter) Endlicher Automat (neudeutsch state
> machine) die entsprechend behandelt werden will.
>
> MfG

habe ich die Stelle im Datenblatt übersehen? Ich kenne nur den Hinweis, 
daß das Lesen des FIFO nur mit max. 2MHz erfolgen darf. Jedes andere 
Kommando kann ich ihm mit voller Geschwindigkeit schicken und das 
versteht er auch.

Kann natürlich sein, daß ich da Glück hatte, weil mein SPI sowiso nur 
max. 4MHz schaffte.

Gruß aus Berlin
Michael

von Gerald H. (elsuppus)


Angehängte Dateien:

Lesenswert?

Hi,

Danke für die Antworten!

So, ich habe mittlerweile alles durchprobiert. Das Problem besteht noch 
immer. SPI-Takt liegt bei mir auf 1 MHz. Das kann nicht das Problem 
sein.

@Sauger
>Mahlzeit,

>achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind.
>Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa)
>nachschieben.

Habe es versucht eine B8AA nachgeschoben ... keine besserung!
Wie meinst du das genau mit Sender abschalten? et = 0 ? Das mache ich!



@Michael
>Präambel nach den Daten ist nutzlos, die 0xAA davor sind nur, damit der
>Empfänger AFC und AGC einstellen kann.

Habe die Präamblen versucht rauszuwerfen. Leider geht es nicht komplett!
Problem scheint meiner Meinung nach zu sein, dass er dann die letzten 
Bytes nicht mehr liest. Siehe Bild F0003TEK!
Er fängt einfach zu spät an die Bytes zu lesen!
Habe am ende es um ein Präambel reduziert (sprich nur noch 2)
D.h. der Empfänger bekommt das letzte Datenbye auf der 2. Präambel vom 
Sender mit. Sprich auf dem letzten gesendeten byte.


folgendes habe ebenfalls versucht:
anstelle von:
RF12_receive_WRT_CMD(0xCA81);
RF12_receive_WRT_CMD(0xCA83);

habe ich überall
RF12_receive_WRT_CMD(0xCA11);
RF12_receive_WRT_CMD(0xCA13);

konfiguriert.
der empfänger hat nach jeden bit eine nIRQ ausgelöst was auch passieren 
soll! Jedoch erst wieder nach dem 7. gesendeten Byte und nicht nach dem 
5.! also ebenfalls 2 zu spät.

Ich habe auf der Empfängerseite mir das Statusregister vor dem ersten 
empfangenbyte auslesen lassen. Wenn ich es richtig ausgelesen habe 
müsste FFOV = 0 gewesen sein!

lese das Statusregister wiefolgt aus.

teststatus = RF12_receive_WRT_CMD(0x0000);
itoa(teststatus,text,10);
uart_puts("\r\n teststatus:");
uart_puts(text);

Das ganze wird dann im Windows rechner weider binär dargestellt!
Wenn jeman eine besser variante weiß! immer her damit!

das RSSI Bit scheint bei mir die ganze Zeit auf 1 zu stehen! Kann das 
noch ein Problem sein? Gescheite Antennen habe ich!


Grüße Gerald

von Sauger (Gast)


Lesenswert?

Moin,

@ Gerald H.
stell doch einfach mal dein Projekt als Quellcode in Compilierbarer Form 
ein.

@ Michael U.
Bei den älteren (<3.0) durfte man bei geöffnetem Empfänger (Präambel 
empfangen) erst nach dem Auslesen des FIFOs wieder neue Kommandos 
absetzen. Abschalten oder Umschalten auf senden in dieser Phase führt in 
fast allen Fällen zum Absturz. Ob neuere (>=3.0) dieses Problem noch 
haben kann Ich nicht sagen, die Routinen sind für die Alten ausgelegt 
und arbeiten auch mit den neuen. Die Dinger werden übrigens kommerziell 
in „Funkbirnen“ eingesetzt und ersetzen Bedienpulte in Förderanlagen 
(Hand-/Einrichtbetrieb).

MfG

von Gerald H. (elsuppus)


Lesenswert?

Hoi,

>Bei den älteren (<3.0) durfte man bei geöffnetem Empfänger (Präambel
>empfangen) erst nach dem Auslesen des FIFOs wieder neue Kommandos
>absetzen.

Habe Präambel nun auch mal richtig im Interrupt ausgelesen. Leider keine 
Besserung.

>stell doch einfach mal dein Projekt als Quellcode in Compilierbarer Form
>ein.

Werde ich nun auch machen. Muss den Code noch ein bisschen aufbereiten 
sodass man den besser lesen kann.

Grüße Gerald

von Sauger (Gast)


Lesenswert?

Mahlzeit,

Die Präambel kannst du nicht auslesen. Damit rastet der Empfänger seine 
PLL ein, um dann nach Empfang des Synchronwords das FIFO bis zum 
Sankt-Nimmerleins-Tag zu füllen.

MfG

von Gerald H. (elsuppus)


Angehängte Dateien:

Lesenswert?

Moinsen,

Die "Präambel" sende ich nochmal zum Schluss!
Ich meine nicht die am Anfang zum einrasten.

Sprich z.B einer Requestanfrage welche durch einen Timer nach einer 
bestimmten zeit aufgerufen wird.
3 Präambeln, Syc Hi, Sync Low, 5 Datenbytes, 2
Präambeln

Die letzten Beiden Bytes lese ich beim Empfänger nicht mehr aus...
Aber selbst wenn ich sie beim Empfänger auslese macht es keinen 
Unterschied.
Wenn ich die nicht mitschicke funktioniert das ganze nicht mehr. Weil 
meiner Meinung nach halt die Interrupts zu spät kommen.
Aber wäre cool wenn du es dir mal anschauen könntest!

Danke
Grüße Gerald

von Sauger (Gast)


Lesenswert?

Mahlzeit,

ohne den ganzen Code angeschaut zu haben:

werfe alle "uart_puts" aus den ISRs raus, diese dauern zu lange und 
blockieren alles andere. Ein "FIFO voll" Interrupt vom RFM kann so 
verloren gehen.

MfG

von Gerald H. (elsuppus)


Lesenswert?

Hi,

Danke erstmal.
Das musste ich auch feststellen und vermeide dies schon.
Wenn ich den Sender an habe ('a' übers Terminal gesendet habe)
dann wird kein uart_puts aufgerufen ... es sei denn ich frage bewusst 
einen status über das terminal ab.

Grüße Gerald

von Sauger (Gast)


Lesenswert?

Nabend,

Deine Quellen sind mir umfangreich um diese zu zerlegen.
Du hast Post...

MfG

von Sauger (Gast)


Lesenswert?

Nachtrag,

da fehlt mittendrinn ein zu, dass Ich hiermit nachliefere.

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
Noch kein Account? Hier anmelden.