EDV-Dompteur/Forum

Zitat von »Machtwas«

Gut, eine PCINT kann ich an jedem beliebigen Portpin haben und die INT0 ist an PB1 gebunden, aber das kann doch nicht der Grund für die Existenz der PCINT sein?

Es gibt halt nur einen INT0.
Aber manchmal möchte man mehrere Interrupt-Quellen zur Vefügung haben.

INT0 hat die höchste Priorität. Wenn der auftritt, dann cancelt es automatisch die möglicherweise zeitgleich (oder unmittelbar nachfolgenden) anderen Interrupts, sofern man keine Maßnahme dagegen ergreift. Siehe die Seiten 10 und 11 im Datenblatt.

Man kann bei INT0 festlegen, ob auf einen Low-Zustand, oder explizit auf eine steigende Flanke, oder explizit eine fallende Flanke reagiert werden soll, oder auf ein Toggeln in beliebige Richtung.
Im Gegensatz dazu, detektieren die sechs PCINT(0.5) Eingänge lediglich das Toggeln eines Pins (egal in welche Richtung).

An dem Datenblatt kann man in Bezug auf Interrupts echt verzweifeln, wenn man kein gestandener Fachmann für Bit-Schubserei in Mikrocontrollern ist. Mein Verständnis bleibt hier ziemlich vage, denn weder aus dem von Dir geposteten Schema, noch aus dem im Datenblatt darunter befindlichen Timing-Diagramm, geht für mich vollständig klar hervor, was es mit diesen drei Flipflops auf sich hat. Aber ich VERMUTE, dass es erstens damit zu tun hat, die Unterscheidung der Flanken weg zu kriegen, um letztendlich auf das bloße Toggeln des Pin-Zustands zu reagieren. Zweitens mag es damit zu tun haben, dass INT0 eine höhere Priorität hat, als PCINT(n). Darum eine Verzögerung um drei Takte.

Man sieht im Timing-Diagramm, dass der auf PCINT(n) folgende Takt zunächst pcint_in_(n) wieder auf low setzt. - Dieses Signal wurde zuvor unverzüglich (asynchron) high, als PCINT(n) high wurde.
Es braucht dann, wegen der Flipflops, noch genau zwei weitere Takte, um am Ende das PCIF auszuspucken.
Bevor das passiert, fallen zwischen den Flipflops noch die Signale pcint_syn und pcint_seflag an. Diese Signale sind per Suchfunkion im Datenblatt sonst nicht aufzufinden, aber ich gehe davon aus, dass der Controller sie intern verwurstet ... und dass der Controller sein finales PCIF erst dann erzeugt, wenn wenn diese beiden internen Signale ihren Dienst getan haben.

Das Datenblatt stellt im Timing-Diagramm leider nur den Fall dar, wenn der PCINT(n) von Low auf High toggelt.
Was aber passiert, wenn von High auf Low getoggelt wird, bleibt für mich nebulös. Allerdings habe ich auch Schwierigkeiten bei der Interpretation der im Plan verwendeten, amerikanischen Gatter-Schaltzeichen.


Ich würde sagen: Lebe einfach damit, dass es so ist, wie es ist!
Die Entwickler werden sich bestimmt ganz schlaue Dinge dabei gedacht haben, dass sie es genau so umgesetzt haben.

Ergänzend sei noch gesagt, dass Du zumindest von mir nicht gar zu viel Hilfe erwarten solltest, bei Deinen Assembler-Problemchen.
Ich selbst habe immer nur in BASCOM programmiert und (wenn ich nicht irre) überhaupt nur zweimal je eine Assembler-Routine eingefrickelt, als es mal wirklich zeitkritisch wurde.

Zwischenzeitliche Versuche mit dem Arduino-C (das ja sooo viel schnelleren Code erzeugen soll, als BASCOM) endeten bei mir in einer Mischung aus Frust und nochmal Frust und Ehrfurcht und dann wieder Frust. Ich werde einfach nicht froh mit der Sprache C.

Für mein nächstes Projekt spiele ich mit dem Gedanken, auf MicroPython zu wechseln.
Davon abgesehen, haben für mich die AVR-Controller echt an Bedeutung verloren, seit es den ESP32 gibt.
AVR hat zwar noch immer seine Daseinsberechtigung, wenn es mal besonders klein/billig/stromsparend werden muss, aber als Arbeitstier hat der ESP32 einfach so entschieden mehr Power und mehr Fähigkeiten, dass AVR IMHO keinen Sinn mehr macht, wenn man mehr als eine Computermaus etc. realisieren will.

Nehmen wir das Ansteuern von LED-Pixeln. WS28xx und so.
Für einen AVR absolut grenzwertig! Geht mit Assembler zwar noch, wenn man nur vorgekaute Lichtmuster ausgeben will, aber einen zweiten Task nebenbei kann man knicken.
Ich habe auch mal einen Farbconverter von HSV auf RGB in BASCOM programmiert, für ein LED-Smoothlight. Da hat man es mit Fließkommazahlen zu tun. Damit war der AVR dann aber auch kräftig ausgelastet.
In 8-Bit Arithmetik gestaucht und in Assembler realisiert, hätte man zwar noch etwas Luft gewinnen können, aber trotzdem geht da nicht mehr sooo viel.

Ein ESP32 kann selbst in einer Hochsprache programmiert recht locker - per Multitasking - acht unabhängige LED-Pixel-Stripes ansteuern. Und noch andere Dinge nebenher erledigen. Und Kommandos per WLAN (also per Smartphone!) entgegen nehmen. Und so weiter.
Da besteht für mich kein Bedarf mehr, für Assembler-Frickeleien auf AVR-Controllern.