|
Anzeige
|
Seltsames SPI Verhalten (Mega88, RFM12)
Gast
#1981997
Hallo, ich betreibe ein RFM12 Funkmodul interruptbasierend an einem Mega88 mit Hardware-SPI. Das SPI scheint innerhalb des IRQ-Handlers nicht mehr zu funktionieren; es wird das erste Byte der (zwei Byte langen) Statusabfrage gesendet, dann ist laut Logikanalysator Feierabend. Ist es prinzipiell ein Problem in einem IRQ Handler das SPI zu verwenden? Schönen Adventssonntag noch Reinhold
Gast
#1982021
Hi Wie ist das SS-Pin konfiguriert/beschaltet? Datenblatt: If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. MfG Spess
Gast
#1982094
SS ist als Ausgang konfiguriert, der Pin wird als ChipSelect (nSEL) für das RFM12 verwendet. Wenn ich den IRQ deaktiviere und alles in der Main-Funktion veranstalte gibt es keine Probleme (warten bis die IRQ Leitung low ist, dann die Statusabfrage). Das Problem mit dem SS kenne ich schon, da bin ich auch schon mal drauf rein gefallen ;-( Reinhold Hmm, ich hatte mal das Problem mit einem AT168 und der SPI als Master wo nur sporadisch gesendet wurde. Die SPI Konfiguration wurde einmal beim init vorgenommen. Ich habe das so gelöst, dass ich die SPI vor dem Senden als Master konfiguriert habe und nach dem Empfang in der ISR zurück auf Slave. Also ein ständiges Neukonfigurieren vor jedem Byte, war eher ein Zufallstreffer. Gruss Bernd Bernd M. schrieb: > Ich habe das so gelöst, dass ich die SPI vor dem Senden als Master > konfiguriert habe und nach dem Empfang in der ISR zurück auf Slave. Wozu denn das? Der Master kann doch statisch bleiben und trotzdem empfangen. Nunja, das mit dem "sporadischem Senden" war das Problem. Es sollte immer eine Message mit 20 Bytes gesendet werden, es kam aber nur ein Byte sofort raus und der Reset dann irgendwann. Hab mich nicht weiter mit der Fehleranalyse beschäftigt, weil meine eigentliche Aufgabe war die Gegenseite. Mit der beschriebenen Vorgehensweise macht er es so wie ich es will.
Gast
#1984309
Ungünstig für die Performance in deinem Programm scheint mir die Warteschleife in der ISR zu sein (wait for ...),das ist unüblich in ISRs. Schau da mal nach,was dort eigentlich passiert und ob das nötig ist. Hier könnte sich ein Fehler verstecken. Ein älteres Beispiel von mir mit SPI-IRQ. Es hängen hier bei mir externe Schieberegister am SPI-Port. Das erste Byte wird vom Hauptprogramm geschrieben, und alle restlichen werden über den Interrupt bedient. Just heute hatte ich mir den RFM12 auch angesehen und überlegt, damit mal was zu machen, wenn Du Erfolg hast, dann berichte doch mal über die Resultate, würde mich interessieren. Roland.
Gast
#1984310
Wenn Reset kommt, dann vielleicht mal den Watchdog bedienen? Roland schrieb: > Wenn Reset kommt War sicher ein Schreibfehler und sollte Rest heissen? Bernd M. schrieb: > es kam aber nur ein > Byte sofort raus und der Reset dann irgendwann. Knut Ballhause schrieb: > War sicher ein Schreibfehler und sollte Rest heissen? > > Bernd M. schrieb: >> es kam aber nur ein >> Byte sofort raus und der Reset dann irgendwann. Jepp, man sollte um viertel nach zwei nix mehr posten ;-) Reinhold schrieb: > Das SPI scheint innerhalb des IRQ-Handlers nicht mehr zu > funktionieren Versuchst du eventuell, innerhalb eines SPI-Zugriffs einen weiteren zu starten? Das ist 'ne Falle. Wenn man sowas macht, sollte man einfach während der SPI-Zugriffe (so lange dauern die bei voller Geschwindigkeit ja nicht) die Interrupts blockieren, zumindest die vom Funkmodul. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
