Interrupt-Abfrage >>> Routine vereinfachen

[frabe]

Erst ein mal vielen Dank für deine Gedanken und Anregungen!

Ich finde den Code relativ unübersichtlich.

Ich weis was du meinst. Ich habe schon für Massenabfragen vorbereitet. Bei mir werden alle PAx überwacht.
Tatsächlich benutze ich aber nur 2 - daher werde ich mal in mich gehen und die "EierLegendeWollmilchSau" hinterfragen.

Ist es nicht wesentlich Recorcenschohnender, das gesamte Register auf Veränderungen abzufragen, als jede 1ms (oder 10ms) jeden Eingang einzelnd abzufragen? Was ist wenn ich 4 Eingänge pro Register nutze, ist das dann anders?

Ich würde alle Funktionen direkt in der ISR machen. Was mir auch auffällt ist, das du in der Auswertung zuerst eine Zahl einer Variable zuweißt und anschließend diese Variable abfrägst. Ich würde z.B. "Ledxx_ein", Ledxx_aus,... direkt in die "If"-Abfrage schreiben.

LedXX_ein, LedXX_aus ist nur ein Test-Platzhalter für aufwendigere Anweisungen.
Aber auch hier sehe ich die "Kanone die auf Spatzen zielt".

Solltest du das Programm nicht ganz verstehen, einfach melden.

Wieso nicht? Ist dein Code doch viel leichter lesbar und einfacher.

Man sollte, wenn es geht, auf >, >=, < oder <= Abfragen und nicht auf == wie du es bei dem 10ms Takt gemacht hast. Der Grund ist das du theoretisch den Wert auf z.B. 11 stellen kannst und dann wird weitergezählt bis der Zähler überläuft und zählt dann wieder bis 10. Wenn du eine Bytevariable hast zählt er 255ms zu lange.

Gute Idee.
Bei >= bringt ein "Verschlucken" nur eine minimale Unsauberkeit, aber kein Durchlaufen mit sich.

Ich habe bei dem 10ms Takt "5" genommen, weil bei diesem Programm ca. alle 2ms ein INT ausgelöst wird, bei dir muss "10" stehen.

Alle 10ms wird bei mir ausserhalb des ISR der EIngangszustand abgefragt. Sollte sich dieser 3 mal nicht ändern (30ms) wird der neue Zustand gesetzt.
Der 1ms-Takt "OverflowZaehler" wird später im main() noch anderweitig als Stopuhr verwendet.

[021aet04]

Deine Variante ist, vermutlich (nicht getestet), so Resourcenschonend wie meine. Ich habe z.B. nur Variablen die ich unbedingt benötige, Das ist die Freigabe und der alte Zustand der Eingänge. Du hast noch viel mehr. Du hast viel mehr Variablen (auch wenn diese nur temporär sind), das ist Speicher (Ram) und zusätzlich gibt es mehr Code, das ist auch Speicher (Flash).

Bei meiner Variante ist es gleich wie bei deiner. Zuerst wird auf Veränderung geachtet. Erst wenn 3x hintereinander der Zustand gleich bleibt wird der Eingang abgefragt (dafür ist "Prellzeit" zuständig). Was man eventuell noch ändern könnte ist, den Zustand des Pinregisters 1x in eine temporäre Variable schreiben und mit dieser dann weiterarbeiten. Ich frage das PIN-Register 2x ab (einmal bei der Abfrage und einmal wenn ich den Zustand in die Variable "Eingang_alt"). In dieser Zeit könnte sich der Wert allerdings ändern.

Du fragst auch jeden Pin einzeln ab, du fragst sogar 2x ab und ich nur einmal. Du schaust ob es High ist und dann ob es low ist. Das kannst du dir eigentlich sparen, denn es gibt keinen 3ten Zustand und somit ist es automatisch low wenn es nicht high ist.

Wenn du auf bestimmte Muster von den Eingängen abfragst, kannst du mit switch arbeiten. Als Beispiel du willst etwas ausführen wenn am PortB nur PB0 und PB2 high sind und alle anderen low kannst du auf 0x03 abfragen.

Also in etwa so:

switch (Eingangsbyte)
{
     case 0x03:
          ........
          ........
          Mach was
          ........
          ........
     break;
}

Bild hier   Zitat von 021aet04 Bild hier  
Man sollte, wenn es geht, auf >, >=, < oder <= Abfragen und nicht auf == wie du es bei dem 10ms Takt gemacht hast. Der Grund ist das du theoretisch den Wert auf z.B. 11 stellen kannst und dann wird weitergezählt bis der Zähler überläuft und zählt dann wieder bis 10. Wenn du eine Bytevariable hast zählt er 255ms zu lange.



Gute Idee.
Bei >= bringt ein "Verschlucken" nur eine minimale Unsauberkeit, aber kein Durchlaufen mit sich.

"Verschlucken" wird er sich nicht, solltest du aber irgendwie auf diese Variable von "Außen" zugreifen können, kann man diesen Wert ändern. Bei deiner Anwendung wird es aber nicht sein (außer dein Speicher sollte kaputtgehen, was aber eher unwahrscheinlich ist). Bei einer SPS, wäre es aber möglich (somit sollte man immer so arbeiten).




Ich habe nur die ISR gemacht (und die Konfiguration des Timers nur über Prescaler), mit einem Attiny2313 mit 8MHz, dadurch stimmt das ganze Timing nicht exakt mit deinem Programm überein.

MfG Hannes

[frabe]

Danke, Hannes.
Deine Ausführungen sind für mich sehr hilfreich!

[frabe]

Frage:
Wie "legetim" ist es, aus einem ISR mit longjmp in das main() zurück zu springen, sollten bestimmte Bedingungen innerhalb des ISR erfüllt sein?
Hintergrund:
Mehrfache Tastenabfrage+Entprellung via Timer-ISR. Je nach Ablaufposition innerhalb des main() sollen unterschiedliche Befehle ausgeführt werden. Einfaches Bsp: ein delay() abbrechen/überspringen.

[Klebwax]

Frage:
Wie "legetim" ist es, aus einem ISR mit longjmp in das main() zurück zu springen, sollten bestimmte Bedingungen innerhalb des ISR erfüllt sein?

Was bedeuted legitim hier? Die Frage ist: darf man es benutzen? Wenn es zulässig ist, dann darf man es auch. Eine zweite Frage wäre, ist es sinnvoll?

Einige aber sicher nicht alle Antworten, die mir so einfallen.

Ich benutze C schon ziemlich lange, hatte aber noch nie das Bedürfnis, longjmp zu benutzen. Ich hab es also noch nie für sinnvoll gehalten.

Setjmp/longjmp ist ein Minenfeld. In MISRA ist es IMHO verboten. Wer sich sehr gut in C auskennt, mag vielleicht in diesem Minenfeld navigieren können, warum Anfänger das tun wollen, erschließt sich mir nicht.

Ein Interrupthandler verhält sich zwar wie eine normale C-Funktion, ist aber keine normale Funktion. Das sieht man an den Atributen, die sie hat. Der Code den der Compiler erzeugt und der vor der ersten Zeile C-Code der Funktion läuft ist ebenso wie der Code, der bei einem return erzeugt wird, ein anderer. Verlässt man eine solche Funktion, wird das, was sonst beim return gemacht wird, ausgelassen. Die Konsequenzen hab ich jetzt nicht untersucht.

Ob das ganze Konzept

Je nach Ablaufposition innerhalb des main() sollen unterschiedliche Befehle ausgeführt werden.

Sinn macht, hab ich jetzt nicht angesehen.

MfG Klebwax

[Sisor]

Frage:
Wie "legetim" ist es, aus einem ISR mit longjmp in das main() zurück zu springen, sollten bestimmte Bedingungen innerhalb des ISR erfüllt sein?
Hintergrund:
Mehrfache Tastenabfrage+Entprellung via Timer-ISR. Je nach Ablaufposition innerhalb des main() sollen unterschiedliche Befehle ausgeführt werden. Einfaches Bsp: ein delay() abbrechen/überspringen.

Wie legitim? Auf einer Skala von 0 bis 100 eine solide 0,001. Mit anderen Worten: Ohne sehr gute Gründe überhaupt nicht.
In C mit normalen Sprachfeatures nur die Möglichkeit über ein return eine Funktion ( und ja: ISR ist streng genommen ein Makro, wird aber vom Kompiler zu einer void ISR_Name (void)-Funktion reduziert) zu verlassen (In void()-Funktionen trägt der Kompiler das return nachträglich ein, falls es nicht ausdrücklich dort steht.) Das hat hauptsächlich den Grund eine korrekte Funktion des Aufrufstapels zu gewährleisten. Mit Sprüngen aus einer Funktion ist das Verhalten des Programms daher undefiniert.

Dein Problem kann man anders lösen, z.B. mit einer abbrechbaren warte-Funktion wie dieser:

volatile bool abbrechen = false;
void warte(uint ms) {
 while(--ms>0 && !abbrechen) delay(1);
 abbrechen = false;
}