interrupt ohne rücksprung

> Das heißt, das Programm soll nach
> dem Interrupt einfach weiter laufen.

Wo soll er denn weiterlaufen?
Wenn die Interruptfunktion zu Ende ist, muss es ja irgendwo weitergehen. 
Nur wo soll das denn sein, wenn nicht an der Stelle an der das 
Hauptprogramm unterbrochen wurde?

thomas wrote:
> Interrupt ausgelöst wurde. Kann man auch einen Interrupt auslösen, ohne
> das er sich merkt wo er gewesen ist?

Nein.

> Das heißt, das Programm soll nach
> dem Interrupt einfach weiter laufen.

Das nennt sich dann Chaos-Programmierung.
Du wirst mit diesem Ansatz nicht glücklich, sobald das Projekt etwas 
größer wird.

Wenn jeden Augenblich jede mögliche Task abgeschossen wird, kann man 
keine vernünftige Funktion erreichen.

Versuch mal mit Word einen Brief zu schreiben und ein anderer drückt 
ständig Alt-F4. Dann weißt Du wie sich die CPU bei Deinem Ansatz fühlt.


Peter

Ich werd zwar aus deiner Beschriebung nicht wirklich schlau, aber eines 
ist sicher: Deine Software-Architektur stimmt nicht. Mit deinem 
Interrupt-Return verbiegen löst du das eigentliche Problem nicht.
Ein Haus, das auf Sand gebaut ist, kann man zwar mit Holzbalken 
abstützen.  Das wird aber immer Stückwerk bleiben. Besser ist es das 
Haus abzureissen und zuallererst mal ein vernünftiges Fundament bauen.

In deinem Fall klingt das für mich:
Du hast dir nicht richtg überlegt, wie man einen µC dazu bringen kann, 
einzelne Tasks geordnet nacheinander abzuarbeiten. Das Stichwort dazu 
lautet: Job-Flags.
Ein Interrupt macht so gut wie keine Arbeit selber, sondern er setzt ein 
Jobflag, welches der Hauptschleife mitteilt, dass es wieder mal Zeit 
wäre die Signalqualität zu überprüfen.
Die Hauptschleife registriert dieses Ansinnen anhand des Jobflags und 
entscheidet, dass genau das zum jetzigen Zeitpunkt nicht machbar ist, 
weil da noch ein Anruf in der Bearbeitung steckt. Oder umgekehrt: Das 
ein Anruf reinkommt, der aber momentan nicht bearbeitet werden kann, 
weil gerade eine Signalqualitätsprüfung läuft.

Dein Problem ist ganz einfach, dass die linke Hand nichts davon weiß was 
die rechte Hand gerade macht. Die Lösung kann aber nicht lauten: Dann 
hauen wir halt mal auf die Finger. Die Lösung kann nur lauten: Es 
braucht eine Einrichtung, die die beiden Aktivitäten koordiniert.

(Oder so ähnlich. Wie gesagt, ich werde aus dem Zeugs da oben nicht 
wirklich schlau)

thomas wrote:
> ISR(USART0_RXC_vect)
> {
>   flag=1;
> }
> ISR(USART1_RXC_vect){}
Das ist tödlich! Die Interrupt Flags RXC0/1 werden erst dann gelöscht, 
wenn das UDR ausgelesen wird. Im Interrupt Handler muss deshalb UDR0 
bzw. 1 ausgelesen werden, sonst wird er immer wieder aufgerufen.

Dass das Programm / der µC sich aufhängen, wenn zwei Interrupt Handler 
ständig wieder aufgerufen werden und zwischen ihnen nur jeweils ein 
einzelner Befehl im Hauptprogramm bearbeitet wird, ist hoffentlich 
klar...

thomas wrote:
> Hallo Johannes, heißt das, dass der Interrupt sozusagen zu lange
> ausgeführt wird? Bezw. zu oft? Wie müsste den dann der Händler aussehen?
> Danke im voraus!
Schreib ich chinesisch? Ich habe oben geschrieben, dass in den beiden 
Inerrupt Handlern das dazugehörige Datenregister ausgelesen werden muss, 
damit das jeweilige Interrupt Flag gelöscht wird. Das kann doch nicht so 
schwer zu verstehen sein...

Noch mal: Wenn einer der beiden Interrupts auftritt, wird das 
dazugeörige Flag gesetzt und der Handler ausgeführt. Wenn der Handler 
beendet wird, ohne dass das Datenregister gelesen wurde, ist das Flag 
nach dem Rücksprung noch gesetzt und der Handler wird praktisch sofort 
wieder aufgerufen, und zwar so lange, bis das Programm irgendwann mal an 
einer Stelle anlangt, wo das UDR ausgelesen und damit das Flag gelöscht 
wird!

Johannes M. wrote:
> thomas wrote:
>> ISR(USART0_RXC_vect)
>> {
>>   flag=1;
>> }
>> ISR(USART1_RXC_vect){}
> Das ist tödlich! Die Interrupt Flags RXC0/1 werden erst dann gelöscht,
> wenn das UDR ausgelesen wird. Im Interrupt Handler muss deshalb UDR0
> bzw. 1 ausgelesen werden, sonst wird er immer wieder aufgerufen.

Ich denke mal, dass hier thomas aus 'Geheimhaltungsgründen' wieder mal 
einiges nicht gezeigt hat.


Daher wieder mal der Appell: zeig deinen richtigen Code, nicht etwas was 
so aussieht oder so ähnlich ist oder fast dem entspricht was du hast. 
Abspecken auf das Notwendigste macht Sinn, aber die relevanten Sachen 
genau so präsentieren wie sie wirklich im Code sind.

Und Freunde: Kommt nicht immer mit diesem Geheimhaltungsquatsch. 
Entweder ihr dürft in der Öffentlichkeit nach Hilfe fragen oder ihr 
dürft es nicht. Kein Mensch wird aus diesem Forum ein kommerzielles 
Projekt, das noch in der Entwicklungsphase steckt, klauen.

thomas wrote:
> Es ist doch so, dass in den Interrupt Routinen so wenig wie möglich
> stehen soll, damit die Zeit so kurz wie möglich gehalten wird, oder?
Aber das UDR muss trotzdem im Interrupt Handler gelesen werden. Und 
wenn Du das nicht tust, wird es nicht funktionieren! Ansonsten muss ich 
Karl heinz zustimmen...