Anti-Interrupt, oder so was in der Art.

[Andreas (Gast)]

Servus zusammen,

ich habe folgende Idee und bin mir gerade nicht sicher ob man das in C 
überhaut oder vielleicht sogar in schön verwirklichen kann. Gleich 
vorab:
Ich suche jetzt nicht unbedingt fertige Lösungen, nur Ansätze oder ggf. 
Alternativlösungen oder tips wie man sowas schön programmieren kann.

Also, es dreht sich alles darum, dass ich ein paar Codezeilen habe, die 
mit mittlerer Priorität abgearbeitet werden sollen, die aber sehr viel 
und lange auf unterschiedliche Hardware wartet. Ein anderer 
Codeabschnitt läuft ohne derartige Warteschleifen, soll aber auch mit 
niedrigerer Priorität abgearbeitet werden. Nun ist meine Idee, anstatt 
langen while(...); wartereien, eher eine Funktion wie 
"resumeOnInterrupt()" einzufügen, die solange einen anderen Prozess 
laufen lässt, bis eben ein bestimmter Interrupt auftritt. Dann soll der 
Code nach dem Resume wieder ausgeführt werden. Wahrscheinlich geht das 
ganze ein wenig in Richtung mini-Betriebssystem. Meint ihr, das ist 
sinnvoll? Und habt ihr ne idee wie man sowas machen könnte? Den 
Prozesscounter in C auslesen dürfte ja relativ schwierig sein, aber im 
Interrupt wird er ja soweit ich weiß auf den Stack geladen, man müsste 
also nur in einem "naked"-Interrupt (dass, man auch weiß, was wo am 
Stack liegt) den Stack lesen und dort eben den PC des anderen Prozessen 
rein schreiben. Nach einem reti sollte ja dann der andere Prozess 
laufen. Natürlich sollte man dabei auch das Status-Register noch 
speichern und wiederherstellen.
Nur wie kann dann z.B. in einer "resumeOnInterrupt()"-Funktion ebenfalls 
den PC modifizieren?!

Ich hoffe ihr versteht was ich meine.
Was haltet ihr davon und könnt ihr mir Tips, Anregungen oder auch gern 
gemachte Fehler sagen?

Vielen Dank
Gruß Andreas

[Ralf G. (ralg)]

Andreas schrieb:
> Ich hoffe ihr versteht was ich meine.

Nicht so richtig.
Das Programm geht doch sowieso an der Stelle weiter, an der es durch den 
Interrupt unterbrochen wurde. Die Interruptroutine hat sozusagen das 
"resumeOnInterrupt()" doch schon eingebaut!?

Andreas schrieb:
> Ein anderer
> Codeabschnitt läuft ohne derartige Warteschleifen, soll aber auch mit
> niedrigerer Priorität abgearbeitet werden.

Kommt jetzt darauf an, was dort gemacht wird. Evtl. lässt sich dieser 
Teil 'gelegentlich' als Funktion aufrufen.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Deine Grundidee ist schon nicht schlecht, aber die Art und Weise, wie Du 
sie umsetzen willst, etwas wirr formuliert.

Das Konzept, nach dem Du suchst, nennt sich Kooperatives Multitasking. 
Selbiges wurde bei M$ Windows vor Version 95 eingesetzt, ebenso bei 
MacOS bis einschließlich Version 9.x.

Bei kooperativem Multitasking kann ein Kontextwechsel entweder beim 
Aufruf einer Systemfunktion (Ein-/Ausgabe o.ä.) erfolgen oder wenn in 
einer langwierigen Rechenschleife explizit die Kontrolle abgegeben wird. 
Solch ein Aufruf heißt meist yield() o.ä..

[Falk B. (falk)]

@Andreas (Gast)

>Also, es dreht sich alles darum, dass ich ein paar Codezeilen habe, die
>mit mittlerer Priorität abgearbeitet werden sollen, die aber sehr viel
>und lange auf unterschiedliche Hardware wartet.

Schlecht.

>ganze ein wenig in Richtung mini-Betriebssystem. Meint ihr, das ist
>sinnvoll?

Siehe Multitasking.

> Und habt ihr ne idee wie man sowas machen könnte? Den
>Prozesscounter in C auslesen dürfte ja relativ schwierig sein,

Ist auch nicht sinnvoll.

>Nur wie kann dann z.B. in einer "resumeOnInterrupt()"-Funktion ebenfalls
>den PC modifizieren?!

Du denkst viel zu kompliziert. Dein Problem ist ganz normal mit C ohne 
jegliche Tricks lösbar. Siehe oben.

[Rolf Magnus (Gast)]

Andreas schrieb:
> Nun ist meine Idee, anstatt
> langen while(...); wartereien, eher eine Funktion wie
> "resumeOnInterrupt()" einzufügen, die solange einen anderen Prozess
> laufen lässt, bis eben ein bestimmter Interrupt auftritt. Dann soll der
> Code nach dem Resume wieder ausgeführt werden. Wahrscheinlich geht das
> ganze ein wenig in Richtung mini-Betriebssystem.

Ein RTOS macht sowas. Ein Beispiel dafür wäre FreeRTOS. Da wird das mit 
Semaphoren gelöst. Tasks können auf Semaphoren warten, und eine ISR 
setzt die Semaphore, wodurch die darauf wartende Task wieder 
ausführbereit wird und entpsrechend auch ausgeführt wird, wenn es nichts 
höherpriores mehr gibt.

> Meint ihr, das ist sinnvoll? Und habt ihr ne idee wie man sowas machen
> könnte? Den Prozesscounter in C auslesen dürfte ja relativ schwierig
>sein, aber im Interrupt wird er ja soweit ich weiß auf den Stack geladen,
> man müsste
> also nur in einem "naked"-Interrupt (dass, man auch weiß, was wo am
> Stack liegt) den Stack lesen und dort eben den PC des anderen Prozessen
> rein schreiben. Nach einem reti sollte ja dann der andere Prozess
> laufen. Natürlich sollte man dabei auch das Status-Register noch
> speichern und wiederherstellen.

Und alle normalen Register. Auch das macht ein RTOS.

> Nur wie kann dann z.B. in einer "resumeOnInterrupt()"-Funktion ebenfalls
> den PC modifizieren?!

Im Prinzip genauso wie du es oben bei der ISR beschrieben hast.

[Peter D. (peda)]

Bei der klassischen Mainloop schreibt man die einzelnen Funktionen 
einfach so, daß sie abweisend warten:

funktion_1()
{
  if( Bedingung == nix_zu_tun )
    return;
  mache_was_1();
}
// ...
funktion_n()
{
  if( Bedingung == nix_zu_tun )
    return;
  mache_was_n();
}

int main()
{
  init();
  for(;;){
    funktion_1();
    // ...
    funktion_n();
  }
}

[Uwe (Gast)]

Periodic Interupt timer und ne Statemachine mit Task managment