Hallo zusammen, ich komme gerade mit einen Code nicht weiter und brauche etwas Unterstützung. Folgenede Situation: Ich habe eine Platine (HAA_Basis) die ein paar Daten 3x per RFM12 sendet und dann auf Empfang schaltet. Wenn der RFM12 auf Empfang geschaltet wird, messe ich mit dem Ossi an Pin nINT des RFM12 erstmal ein High-Pegel und bei JEDEM empfangenen Byte ein Low-Pegel der nach jedem Byte wieder zurück auf High springt. Nach ings. 10Bytes Nutzdaten ist der Empfang abgeschlossen und die Daten werden ausgewertet. Jetzt gibt es noch eine zweite Platine (HAA_Reed) die vorerst nur zum senden verwendet wurde und die ich jetzt so umschreiben will, dass sie vor dem Senden erstmal auf Empfang gehen soll (Daten der Basis). Im Grunde ist das der erste Schritt zur bidirektionalen Kommunikation. Ich habe den Code "Daten senden" aus dem Code der Basis entnommen und alle Header und andere Dateien die damit zusammenhängen abgeglichen. Problem 1: Wenn ich den Code in den Controller lade, sehe ich am Ossi den Pegel von, RFM12 nINT der Reedplatine, der sich von low auf high ändert. Übertrage ich den gleich Code noch einmal, ändert sich der Pegel von high auf low und bei der nächsten Übertragung wieder umgekehrt usw. Im Code selber steckt ein SW-Reset des RFM12 der eigentlich alle eingestelleten Werte löschen sollte. Schalte ich jetzt die Spannung der Platine ab und wieder an, ist der Pegel IMMER auf high, so wie er sein soll. Kann mir das jemand erklären ? Problem 2: Ist der Pegel nINT auf high und die Basis sendet Daten, dann fällt er auf low und die ISR der Reed-Platine löst damit aus, aber nicht so wie bei der Basis sondern nur einmal und bleibt dann dort. Wenn ich den FIFO resete und RFM-Interrups lösche (auskommentiert) setzt er zwar den nINT wieder auf high, jedoch sehe ich am Ossi, dass dieser nicht bei jedem empfangenen Byte reagiert wie bei der Basis. Ausserdem soll er die Daten erst nach 10Bytes aufwerten und nicht nachdem ersten aufgeben. Ich hoffe das war verständlich ausgedrückt. Hat jemand Rat, ich komme da nicht weiter !??
Peter F. schrieb: > ich komme gerade mit einen Code nicht weiter und brauche etwas > Unterstützung. Dann wirst du den Code zeigen müssen... > Ich hoffe das war verständlich ausgedrückt. Nein, war es nicht. Das war Dummlall-Lyrik. Prosa (Quelltext) ist viel leichter zu lesen und unmißverständlicher.
Hallo, ich jetzt nur flüchtig in Deinen Code geschaut. Meine Erfahrung mit den RFM-Modulen: als erstes bei Init immer Status lesen, das Verhalten der RFM01/02/12 ist sonst manchmal unberechenbar. Das gilt speziell, wenn Du Reset des RFM nicht ansteuerst, der wird beim Flashen des AVR ja dann nicht zurückgesetzt. Du schreibst was von Softwarereset des RFm, habe ich nicht gefunden auf die Schnelle. Deine IRQ-Routine sieht eigentlich ok aus. Noch was: wo kommt die Unart her, den RFM über einen Portpin zu versorgen? Die RFM brauchen zwar nicht viel, sind aber recht sensibel was die Spannung angeht. Bei mir ist generell ein 10-20µ-Elko dicht am RFM weil ich teilweise aus recht kleinen Batterien versorge (CR2032 z.B.). Die RFM verbrauchen wenige µA im Sleep mit aktivem Sleeptimer, wozu also Strom abschalten? Gruß aus Berlin Michael
:
Bearbeitet durch User
c-hater schrieb: > Dann wirst du den Code zeigen müssen... Siehe Anhang. c-hater schrieb: > Nein, war es nicht. Das war Dummlall-Lyrik. Prosa (Quelltext) ist viel > leichter zu lesen und unmißverständlicher. Sowas geht auch höflicher, lenk mal deine schlechte Laune in eine andere Richtung und bleibt konstukrtivtiv ! Was genau hast Du denn nicht verstanden, dann versuche ich es anders auszudrücken ? Michael U. schrieb: > als erstes bei Init immer Status > lesen, das Verhalten der RFM01/02/12 ist sonst manchmal unberechenbar. > Das gilt speziell, wenn Du Reset des RFM nicht ansteuerst, der wird beim > Flashen des AVR ja dann nicht zurückgesetzt. Der Software-Reset und den Status auszulesen stehen in der Main-Funktion direkt nach "initInterrupt();". Das wäre doch eigentlich genau das, um dem RFM12 beim Start in ein definierten Zustand zu versetzten, oder irre ich mich da ? Michael U. schrieb: > Noch was: wo kommt die Unart her, den RFM über einen Portpin zu > versorgen? Was meinst Du mit Unart ? Wenn Du die Spannung meinst für den RFM12, liegt direkt an der Platinenversorgung. Michael U. schrieb: > Die RFM brauchen zwar nicht viel, sind aber recht sensibel was die > Spannung angeht. Bei mir ist generell ein 10-20µ-Elko dicht am RFM weil > ich teilweise aus recht kleinen Batterien versorge (CR2032 z.B.). > Die RFM verbrauchen wenige µA im Sleep mit aktivem Sleeptimer, wozu also > Strom abschalten? Den Elko werde ich mal mit einfügen, aber ich denke das beantwortet nicht meine Fragen dazu. Den RFM12 schalte ich gar nicht ab und hab vorerst in dem Code die Sleepfunktionen gelöscht. Hat jemand weitere Ideen ? Schöne Feiertage noch.
Peter F. schrieb: > Michael U. schrieb: >> als erstes bei Init immer Status >> lesen, das Verhalten der RFM01/02/12 ist sonst manchmal unberechenbar. >> Das gilt speziell, wenn Du Reset des RFM nicht ansteuerst, der wird beim >> Flashen des AVR ja dann nicht zurückgesetzt. > > Der Software-Reset und den Status auszulesen stehen in der Main-Funktion > direkt nach "initInterrupt();". Das wäre doch eigentlich genau das, um > dem RFM12 beim Start in ein definierten Zustand zu versetzten, oder irre > ich mich da ? Wo hast Du 0xFE00 her? Das setzt den WakeUp-Timer auf irgendeine ZEit. > > Michael U. schrieb: >> Noch was: wo kommt die Unart her, den RFM über einen Portpin zu >> versorgen? > > Was meinst Du mit Unart ? Wenn Du die Spannung meinst für den RFM12, > liegt direkt an der Platinenversorgung. Aus ports.h der Software der Basis: #define RFM_POWER 4 //Spannungversorgung für RFM Ich habe auch nur anmerken wollen. Außerdem; wenn ich als erstes Lesen des Staus empfehle, dann meine ich das auch so. Nicht als Zweites nach dem ominösen Senden von 0xFE00. Die Code ist zumindest etwas schwer lesbar. Warum passieren obige Sachen nicht in der initRFM()? Zusammensuchen ist für einen Anderen etwas mühsam, für Dich in ein paar Jahren aber auch... Genauso sind bei mir die Portzuordnungen in der RFM12.h drin und die Aktivierung in der initRFM(). Wenn ich sowas in einem anderen Projekt weiter verwenden will, will ich RFM.h und RFM.c einfügen können und anpassen, nichts weiter. Das mag mit Deinem Problem im Moment nichts zu tun haben, es ist aber schwierig durch die Abhängigkeiten durchzusteigen. Hier gibt es einen alten Beitrag von mir dazu: Beitrag "RFM12 Empfang von Sensordaten im IRQ" Ich habe aktuell den Kram mit einem RFM01 auf einen ESP8266 portiert und es lief nahezu auf Anhieb, ist natürlich auf meinen Sensorkram von damals zugeschnitten was Paketlänge usw. angeht. War eine meiner ersten Übungen in C... Gruß aus Berlin Michael
Michael U. schrieb: > Wo hast Du 0xFE00 her? Das setzt den WakeUp-Timer auf irgendeine ZEit. Steht hier im Forum: https://www.mikrocontroller.net/articles/RFM12#Software-Reset_.280xFE00.29 Michael U. schrieb: > Aus ports.h der Software der Basis: > #define RFM_POWER 4 //Spannungversorgung für RFM Ach ja richtig. Ich hab das jetzt mal bei der Reed-Platine nachgeholt. Bei der Portinitialisierung schaltet er den RFM12 ab und mit der Funktion Power_On(), also nach 1s, wieder ein. Michael U. schrieb: > Ich habe auch nur anmerken wollen. > Außerdem; wenn ich als erstes Lesen des Staus empfehle, dann meine ich > das auch so. > Nicht als Zweites nach dem ominösen Senden von 0xFE00. Status auslesen hab ich jetzt auch direkt an erster Stelle. Michael U. schrieb: > Die Code ist zumindest etwas schwer lesbar. Warum passieren obige Sachen > nicht in der initRFM()? Da gebe ich dir recht. Sobald das Problem gelöst ist, pack ich die Sacken dort rein. Manchmal sieht man den Wald vor lauter Bäumen nicht mehr. Mein Problem kann ich damit aber nicht lösen. Bitte um weitere Unterstützung. Michael U. schrieb: > Hier gibt es einen alten Beitrag von mir dazu: > Beitrag "RFM12 Empfang von Sensordaten im IRQ" Werde ich mir mal durchlesen, danke.
Jetzt läuft es. Ich weiß nicht genau wo das Problem war, aber ich hab mir das zu Herzen genommen... Michael U. schrieb: > Die Code ist zumindest etwas schwer lesbar. Warum passieren obige Sachen > nicht in der initRFM()? ...und habe alles schön koordiniert in die rfm12.c gepackt und alles was mit Ansteuerung der RFM12 zu tun hat per Funktionsaufruf realisiert. Ich vermute, dass ich damit Anweisungen mit ausführe die ich wahrscheinlich übersehen habe. Danke für den Tipp.
Hallo, schön, daß es jetzt läuft und Danke für die Rückmeldung. Den Effekt kenne ich selber, bei mir ist dann auch erstmal aufräumen in den Sourcen angesagt... Und meist auch gleich aufräumen auf dem Basteltisch. Gruß aus Berlin Michael
Hallo, Dafür hab ich jetzt ein neues Problem. Am Ossi sehe ich bei jedem gesendeten Byte ein Low-Impuls. Im dem Fall sind das insg. 16 Bytes davon 10 Bytes Nutzdaten. Beim Empfänger sehe ich ab dem 7ten Bytes ein Impuls, was auch stimmt weil er mir dann zusätzlich die Daten per Uart anzeigt. Doch wenn ich vorher etwas sende und wieder auf Empfang stelle, sehe ich am Ossi das er nur ein Teil der gesendeten Nutzdaten erkennt. Die Uart-Ausgabe zeigt auch nur Quatsch an. Ich hab mal genauer geguckt und sehe ich im Code, dass ich beim Umschalten auf Empfang immer den Status auslese und den Fifo zurücksetze. Hast du da eine spontane Idee? Wenn ich Zuhause bin kann ich noch zusätzlich den überarbeiten Code und ein paar Bilder vom Ossi anhängen.
Angehängte Dateien:
-
nur_empfangen.png
24 KB -
nur_empfangen.bmp
1,2 MB -
senden_und_empfangen.bmp
1,2 MB -
senden_und_empfangen.png
30 KB
Anbei die Bilder der Basis wenn sie NUR empfängt und wenn sie einmal nach dem Senden wieder zurück auf Empfang schaltet. Der Aufbau der Bytes die gesendet werden, sieht so aus: - PREABLE - PREABLE - SYNC0 - SYNC1 0 ADR 1 FKT 2 STA 3 UBAT 4 URGL 5 RFSTATH 6 RFSTATL 7 LF 8 SW 9 CHKSUM - SUFFIX - SUFFIX siehe auch haa_bus.h Die Bilder zeigen immer 16 Impulse. Jedoch verstehe ich die Reihenfolge nicht so ganz. Laut Ossi, reagiert die Basis (gelb) auf die letzten 10 Bytes, was ja eigentlich nicht genau die Nutzdaten darstellen kann, weil diese nach meinen Aufbau schon nach 4 Bytes kommen. Jedenfalls sieht man an den anderen Bild, dass nicht alle Daten erkannt werden und die Basis bei der UART-Ausgabe nur Nullwerte anzeigt. Kommentiere ich "Status senden" in der Main-Funktion aus, funktioniert es tadellos. Durch rumprobieren, bin ich an der Stelle "rfm12.c -> Daten_senden -> Byte_senden(xxxxx)" stehen geblieben. Sobald dort die Funkionsausrufe "Byte_senden(xxxx)" ausgeführt werden, und ich später wieder auf Empfang schalte, kommt beim Empfäger nur Blödsinn an. Weiter komme ich momentan nicht. Eine Idee?
Ich muss wirklich sagen, dass ich etwas enttäuscht bin. Ich dachte das Thema RFM12 wurde schon oft durchgekaut, da musst doch jemand eine Idde parat haben.
Peter F. schrieb: > Am Ossi sehe ich bei jedem gesendeten Byte ein Low-Impuls. Wo gibt's den zu kaufen? :-) Peter F. schrieb: > Jetzt läuft es. Ich weiß nicht genau wo das Problem war, aber ich hab > mir das zu Herzen genommen... Peter F. schrieb: > Ich dachte das > Thema RFM12 wurde schon oft durchgekaut, da musst doch jemand eine Idde > parat haben. Was machst Du da eigentlich? Peter F. schrieb: > Kommentiere ich "Status senden" in der Main-Funktion aus, funktioniert > es tadellos. Durch rumprobieren, bin ich an der Stelle "rfm12.c -> > Daten_senden -> Byte_senden(xxxxx)" stehen geblieben. Sobald dort die > Funkionsausrufe "Byte_senden(xxxx)" ausgeführt werden, und ich später > wieder auf Empfang schalte, kommt beim Empfäger nur Blödsinn an. Weiter > komme ich momentan nicht. Da scheint wohl in "Staus senden" ein Problem zu sein. Wenn es ohne "tadellos funktioniert" - prima ... dann lass es einfach weg und alles ist O.K. :-) Was unkst Du denn dann noch rum?
Dieter F. schrieb: > Was unkst Du denn dann noch rum? Häh ? Ist nicht gerade die Hilfe die ich erwartet habe.
Peter F. schrieb: > Häh ? > Ist nicht gerade die Hilfe die ich erwartet habe Peter F. schrieb: > Jetzt läuft es. Ich weiß nicht genau wo das Problem war, aber ich hab > mir das zu Herzen genommen... Häh, ist nicht gerade die Frage, die ich erwarte habe ...
Dieter F. schrieb: > Häh, ist nicht gerade die Frage, die ich erwarte habe ... Hast du denn kompletten Thread gelesen, oder hast du die letzten 3 Einträge kurz überflogen ?
Peter F. schrieb: > Hast du denn kompletten Thread gelesen, oder hast du die letzten 3 > Einträge kurz überflogen ? Nun, wenn ich korrekt zähle, beziehen sich meine Kommentare auf mehr als 3 Einträge zurück ... oder? Außerdem hast Du mir Deinen Ossi noch nicht vorgestellt :-)
Dieter F. schrieb: > Nun, wenn ich korrekt zähle, beziehen sich meine Kommentare auf mehr als > 3 Einträge zurück ... oder? Außerdem hast Du mir Deinen Ossi noch nicht > vorgestellt :-) Dann frag ich mich warum du mir rätst "Status_senden" einfach auszukommentieren. Owon DS7102V.
Peter F. schrieb: > Kommentiere ich "Status senden" in der Main-Funktion aus, funktioniert > es tadellos. Peter F. schrieb: > Dann frag ich mich warum du mir rätst "Status_senden" einfach > auszukommentieren. Noch Fragen? Weißt Du eigentlich, was Du so schreibst :-)
Wie soll ich denn einen Status senden wenn ich den Funktionisaufruf dazu auskommentiere soll, weil dieser Teil als Kombi zum Empfangen Probleme macht ???
Peter F. schrieb: > Wie soll ich denn einen Status senden wenn ich den Funktionisaufruf dazu > auskommentiere soll, weil dieser Teil als Kombi zum Empfangen Probleme > macht ??? Nochmal: Weißt Du eigentlich, was Du so schreibst :-) Peter F. schrieb: > Jetzt läuft es. Ich weiß nicht genau wo das Problem war, aber ich hab > mir das zu Herzen genommen... Peter F. schrieb: > Kommentiere ich "Status senden" in der Main-Funktion aus, funktioniert > es tadellos.
Peter F. schrieb: > Kommentiere ich "Status senden" in der Main-Funktion aus, funktioniert > es tadellos. Durch rumprobieren, bin ich an der Stelle "rfm12.c -> > Daten_senden -> Byte_senden(xxxxx)" stehen geblieben. Sobald dort die > Funkionsausrufe "Byte_senden(xxxx)" ausgeführt werden, und ich später > wieder auf Empfang schalte, kommt beim Empfäger nur Blödsinn an. Weiter > komme ich momentan nicht. > > Eine Idee? ....ich hab keine Lust mehr mich mit Dir im Kreis zu drehen.
Peter F. schrieb: > ....ich hab keine Lust mehr mich mit Dir im Kreis zu drehen. Prima, da sind wir mindestens schon 2 ... :-) gute Nacht
Thread beobachten
Seitenaufteilung abschalten
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.