|
Anzeige
|
RFM12: Welche Interruptquelle auswerten?
Gast
#4257523
Ich versuche mich gerade an den RFM12-Funkmodulen (an einem STM32). Was ist die beste Lösung, das ganze Interruptgesteuert zu machen? Bei nIRQ wird ja alles mögliche als Interrupt gesendet. Ich hab im Moment z.B. das Problem, dass ATS gesetzt ist, weiß aber nicht genau warum, bzw. wie man das behebt dass der nicht mehr auslöst. Ich könnte für den Empfang nFFT auswerten, nur was werte ich dann beim senden aus? ATS ist laut Datenblatt keine Interruptquelle: ----- The receiver will generate an interrupt request (IT) for the microcontroller - by pulling the nIRQ pin low - on the following events: - The TX register is ready to receive the next byte (RGIT) - The FIFO has received the preprogrammed amount of bits (FFIT) - Power-on reset (POR) - FIFO overflow (FFOV) / TX register underrun (RGUR) - Wake-up timer timeout (WKUP) - Negative pulse on the interrupt input pin nINT (EXT) - Supply voltage below the preprogrammed value is detected (LBD) FFIT and FFOV are applicable when the FIFO is enabled. RGIT and RGUR are applicable only when the TX register is enabled. To identify the source of the IT, the status bits should be read out. ----- Die Lösung steht im letzten Satz. Man muss, wenn ein Interrupt kommt, das Statusregister lesen und kann dann aus den obersten fünf Bits die Ursache für den Interrupt herauslesen und entsprechend reagieren.
Gast
#4257752
Vielen Dank für die Antwort! Stimmt, da hab ich dann das mit ATS als IRQ falsch verstanden... Aber das Flag von ATS beim Auslesen ist dennoch gesetzt. Was bedeutet ATS genau? Im Artikel hier im Forum zu RFM12 steht etwas von Fehlanpassung... Wenn ich die Sendeleistung verringer ist es nicht gesetzt.
Gast
#4258164
mh schrieb: > Ich versuche mich gerade an den RFM12-Funkmodulen (an einem STM32). > Was ist die beste Lösung, das ganze Interruptgesteuert zu machen? > Bei nIRQ wird ja alles mögliche als Interrupt gesendet. Natürlich, denn nIRQ ist ja die einzige Interruptquelle eines RFM12, bezogen auf die Außenwelt. Man liest also als Reaktion auf den Interrupt das RFM12-Statusregister aus (und tut das tunlichst, ohne eine ggf. gerade laufende SPI-Kommunikation mit dem RFM12 zu einem anderen Thema zu unterbrechen, sondern erst DANACH). Aber anderererseits auch: ASAP. D.h.: man braucht einen sinnvoll organisierten Protokollstack, der das Einschieben hochpriorisierter Status-Abfragen und ggf. der Reaktionen darauf ermöglicht. Dann schaut man im ausgelesenen Statusregister-Inhalt, was eigentlich die Quelle des Interrupts war und behandelt diese entsprechend. So sehr viele gibt es ja nicht, insgesamt nur fünf. Und nur auf zwei davon (das erste und das dritte) muß man bezüglich des RFM2 irgendwie aktiv reagieren, für die restlichen drei genügt bereits das schiere Auslesen des Statusregisters, um die Interruptanforderung des RFM12 zurückzusetzen. > Ich hab im Moment z.B. das Problem, dass ATS gesetzt ist, weiß aber > nicht genau warum, bzw. wie man das behebt dass der nicht mehr auslöst. > Ich könnte für den Empfang nFFT auswerten, nur was werte ich dann beim > senden aus? "ATS" kommt in meinem DB überhaupt nicht als mögliche Interruptquelle vor, sondern nur als eins der unter "ferner liefen" zu subsummierenden Statusbits. Hast du ein anderes DB? Dann ist es ganz sicher nicht das Richtige!
Gast
#4258807
Alles klar. Ja, das mit ATS hab ich falsch verstanden. Der Interrupt hat immer ausgelöst, da ich die Daten zu langsam zum Modul gesendet hab (Senderegister underrun). Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
