PCINT Attiny Flankenerkennung

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • tschoeatsch schrieb:

      @Mitch64 und wie wird das erkannt, dass sich das Programm in der isr befindet? Wozu bräuchte es dann das reti, dass ja int-flags zurück setzt? Und warum wird dann nicht immer die isr durch andere interrupts unterbrochen? Fragen über Fragen a_27_b277ca12
      Jetzt steinigt mich doch nicht gleich!

      Der Opcode von Ret und Reti unterscheidet sich. Da gebe ich dir recht. Einen Unterschied macht das wohl.
      Ansonsten kann ich dir die Frage nicht beantworten was nun stimmt.

      Ich weiß, dass im Controller ein Microcode abläuft (und vielleicht ist da der Atmel auch eine Ausnahme) und der Controller weiß, dass ein Interrupt anhängig ist (PCIFn = 1), also hat er die Möglichkeit das Flag beim Einsprung zu löschen. Schließlich prüft er ja das Globale Interruptflag im Statusregister ja auch, bevor er springt.

      Ich habe nur eine Vermutung aufgestellt, dass das Flag schon mein Einsprung gelöscht werden könnte.
      Und die Passage aus dem Datenblatt auf Deutsch und Englisch angegeben.

      Mehr weiß ich auch nicht.

      Ein Test-Ccode kann Aufschluss darüber geben, ob das Flag erst beim IRET gelöscht wird oder nicht.
    • Du hast ja recht @Mitch, beim Schachteln würde ich aber explizit den betroffenen Interrupt deaktivieren, dann Interrupts wieder erlauben... um am Ende der ISR die Interrups wieder zu verbieten, den betroffenen Interrupt wieder zulassen - den Rest macht das RETI beim Rücksprung.

      Denn echte „nested“ Interrupts können die Atmegas/ATTinys nicht.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Zitat aus dem Mikrocontoller.net:

      "Einige Mikrocontroller, wie z. B. der AVR kennen nur zwei CPU-Zustände. Normale Programmausführung und Interruptausführung, gesteuert durch das I-Bit der CPU. Die normale Programmausführung kann jederzeit durch Interrupts unterbrochen werden. Die Interruptausführung kann nicht durch neue Interrupts unterbrochen werden. Die ISR wird erst zu Ende bearbeitet, zurück in die normale Programmausführung gesprungen und erst dann werden neue, wartende (engl. pending) Interrupts bearbeitet.
      Etwas komplexere Mikrocontroller oder große Prozessoren bieten verschiedene Interruptlevel (Stufen) an . Dabei gilt meist je niedriger die Zahl des Levels, um so höher die Priorität. Ein Interrupt mit höherer Priorität kann einen Interrupt mit niedriger Priorität unterbrechen. Ein Interrupt mit gleicher Priorität wie der gerade bearbeitete Interrupt kann das im allgemeinen nicht. Das nennt man verschachtelte Interrupts (engl. nested interrupts). Klassische Vertreter hierfür sind PIC18, 8051, PowerPC, X86 und Motorola 68000.
      Auf dem AVR kann man verschachtelte Interrupts sowohl in Assembler als auch in C nachbilden, allerdings mit einigen Einschränkungen und Tücken. Das ist jedoch Leuten vorbehalten, die schon viel Erfahrung auf diesem Gebiet haben. Zu 99,9% braucht man sie nicht."
    • Mitch64 schrieb:

      Es geht hier nicht um verschachtelte Interrupts. Bitte nicht verwechseln.
      Natürlich wird der Interrupt zuerst abgearbeitet. Aber währenddessen kann ja wohl das Flag neu gesetzt werden.
      Dein verlinkten Lexikon Beitrag behandelt aber genau dieses Thema. Dass ein weiterer (während der ISR aufgetretener) PCINT direkt nach dem RETI wieder in die ISR führt ist klar. Der Zeipunkt des Flag Löschens, vor Eintritt in die ISR, hast Du korrigiert - Danke für den Hinweis.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Ich habe ein kleines Programm geschrieben, um die Frage zu klären.
      Vielleicht möchte jemand das Programm ausprobieren.

      Ich habe keinen Tiny da.

      Hier das Programm

      BASCOM-Quellcode

      1. ' Testcode PinChange-Interrupt
      2. ' LED1 (PortB.7) zeigt aktiven PinChange-Interrupt an
      3. ' Interruptdauer mit Wait auf 1 Sekunden gesetzt
      4. ' Mit Taster (an PinB.0 gegen GND) wird eine Pegeländerung verursacht.
      5. ' Versuch
      6. ' Taste wird gedrückt und ISR wird aufgerufen (LED ist an).
      7. ' Jetzt Taste loslassen, solange LED an ist.
      8. ' Wenn die 2. Flanke während der aktiven ISR erkannt wird,
      9. ' muss lie LED insgesamt 2 Sekunden leuchten.
      10. ' Die ISR wird nach beenden sofort noch einmal aufgerufen.
      11. ' Die LED geht unsichtbar fürs Auge kurz aus und wieder an.
      12. ' Daher Leuchtdauer 2 Sekunden.
      13. ' Wird die 2. Flanke während die ISR aktiv ist nicht erkannt,
      14. ' wird die LED insgesamt nur 1 Sekunden leuchten.
      15. $regfile = "attiny4313.dat"
      16. $crystal = 8000000
      17. $hwstack = 40
      18. $swstack = 16
      19. $framesize = 40
      20. ' LED zeigt aktive ISR an
      21. Led1 Alias PortB.7
      22. Config Led1 = Output
      23. ' Taster löst Interrupt aus
      24. Set PortB.0 ' PullUp an
      25. Enable Pcint0 ' PortB.0
      26. On Pcint0 ISR_PCINT
      27. Pcmsk = &B00000001
      28. Enable Interrupts
      29. Do
      30. Loop
      31. ISR_PCINT:
      32. Set Led1
      33. Waitms 1000
      34. Reset Led1
      35. Return
      Alles anzeigen
    • Hallo Tschoeatsch,
      das Reti setzt nicht die Flags des Interrupts zurück, sondern erlaubt wieder global die Interrupts.
      Diese werden beim Sprung in die ISR von der HW disabled.
      Das eigene Interrupt Flag wird vor dem Aufruf der ISR gelöscht, wenn in der Vektortabelle nach der Adresse der ISR geschaut wird.

      Wenn er gerade so lange in der ISR bleiben will wie nötig, kann er ja ein Bitwait auf das Setzen des GIFR.PCIF0 machen und es dann löschen. So ist sichergestellt, dass immer der ganze Impuls in der ISR stattfindet, aber nur so wenig wie möglich gewartet wird.

      Nosave macht hier doch keinen Sinn, da das Flag eh vor dem ersten Befehl, der ISR, also auch vor den Pushs gelöscht wird.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Guenther ()

    • Was hab ich getan a_51_b30e0498
      War nur froh das es endlich läuft und ihr macht da jetzt son langen Thread draus.
      Fakt ist ( wie es ja im Datenblat steht) das das ISR Flag beim Einstieg rückgesetzt wird, brauch ich nicht weiter testen, hatte ich ja auch schon bewiesen. Und selbst in der ISR können weitere (neue) ISR Flags gesetzt werden welche dann nach Reihe der Priorisierung (Datenblatt ;) ) jeweils nach rücksprung abgearbeitet werden. In ne ISR reinspringen während eine andere läuft geht ja anscheinend irgendwie, so hab ich das aber nie gelernt und daher ist das schon ganz gut das Bascom das per Standard nicht tut.
      Der Impuls muss nur ne mindestlänge haben damit er auch die ISR auslöst, sind ein paar takte glaub ich....steht im Datenblatt :)

      In meinem fall total egal, selbst nen bitwait am PIN funktioniert im meinem fall ganz ohne das ich irgendeine ISR anspringe. Mir gings hauptsächlich darum das ich wusste das man das Flag rücksetzen kann, nur wie das Register heisst und das rücksetzen ne 1 sein muss hab ich im Datenblatt nicht gefunden gehabt.

      Tobias
    • Also @tschoeatsch da hast du die Erklärung.
      RETI bewirkt, dass das I-Flag wieder gesetzt wird, sofern es vor der ISR war.

      Daher der Unterschied RET und RETI.

      Und @Guenther sagt auch, dass das Flag (PCIF0) gelöscht wird, wenn in der Vektortabelle nach der Adresse der ISR geschaut wird.
      Also kann das PinChange Interrupt Flag wieder per Flanke gesetzt werden, obwohl die ISR noch ausgeführt wird.
      Das bewirkt nach Abarbeitung von RETI einen erneuten Sprung in die ISR.

      Danke Guenther!
    • Mitch64 schrieb:

      monkye schrieb:

      Dein verlinkten Lexikon Beitrag behandelt aber genau dieses Thema.
      Du hast ja auch behauptet, dass Interrupts nicht unterbrechbar wären.Das hängt davon ab, on man in der ISR Interrupts wieder zulässt oder nicht.
      Standard bei Bascom ist nicht zulassen.
      Richtig, es ist im Interrupt Konzept der AVR nicht vorgesehen. Die Beschränkung gilt nicht wegen BASCOM (auch mit C oder Pascal), sondern dem Design.
      Und hier hast Du schon von mir die Zustimmung erhalten, dass es trotzdem geht. Dann sind es aber „Nested Interrupts“ - ein Interrupt wird durch einen weiteren Interrupt unterbrochen.
      Du musst es mit Software lösen, dabei obliegt es Dir als Entwickler, dass eben keine Systemhänger entstehen. Genauso wie es keine Software-Interrupts gibt - aber programmatisch möglich sind.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.