Wenn sich das Programm in der Unteruptroutine INT1(hohe Priorität)
befindet kann dann innerhalb dieser Routine eine weiterer Interrupt
aufgerufen werden der eine niedrigere Priorität hat (Timer0 / bzw. Timer
1)
zum abspielen der Wave- Dateien, oder sind weitere Interrupts erst dann
möglich wenn INT1 abgearbeitet ist ?
ISR(INT1_vect)
{
if (!( PINC & (1<<PINC2))) // PINC2 LOW DIL 1
{
AMP_ON;
output=1; //WAVE
GELB_ON;
PlayWave("WAVE3.wav");
GELB_OFF;
AMP_OFF;
}
else
{
AMP_ON;
output=0; //DIN
ROT_ON;
PlayWave("WAVE3.wav");
ROT_OFF;
AMP_OFF;
}
}
Gast
#2250968
um welche CPU geht es überhaupt?
Ist PlayWave eine Routine, die das File abspielt? Interrupt-Handler sollten kurz sein. Aktionen auslösen, beispielsweise indem Flags gesetzt werden, nicht selbst längere Aktionen durchführen.
ohh sorry Mega32
Gast
#2250974
Ingo Laabs schrieb: > ohh sorry Mega32 seit wann soll denn der Mega32 irq Prioritäten haben?
PlayWave ist eine Routine die eine Wave-Datei abspielt in der die Int. der Timer benutzt werden. Ich benutze den INT-Eingang um eine laufende WAVE Datei zu unterbrechen um eine Ansage machen zu können die als Wave vorliegt.
irq Prioritäten hin oder her... Das Abspielen von wav-Dateien hat in einer ISR eigentlich nichts zu suchen.
Gast
#2250983
Servus Ingo, ich bin ja kein Profi, aber soweit ich gelernt habe, sollte man es grundsätzlich vermeiden, daß eine Interruptroutine von einem anderen Interrupt unterbrochen wird. Man kann sich da ziemlich verhaspeln. Wenn man sich an diese Voraussetzung halten will (Ich habe bis jetzt noch jede Aufgabe so lösen können), dann schaltet man am Beginn jeder Interruptroutine die Interrupts aus (cli) und am Ende wieder ein (sei). lg, Nino.
Gast
#2250984
Hi
>seit wann soll denn der Mega32 irq Prioritäten haben?
Selbstverstänlich gibt es Interruptprioritäten. Die haben aber nichts
mit 'Unterbrechbarkeit' von Interrupts zu tun, sondern mit der
Reihenfolge der Abarbeitung gleichzeitig anstehender
Interruptanforderungen.
MfG Spess
Nino K.L. schrieb: > ich bin ja kein Profi, aber soweit ich gelernt habe, sollte man es > grundsätzlich vermeiden, daß eine Interruptroutine von einem anderen > Interrupt unterbrochen wird. Man kann sich da ziemlich verhaspeln. Nicht grundsätzlich. Aber bei AVRs, die von Haus aus keine über Priorisierung verschachtelbaren Interrupts unterstützen, ist das nicht ratsam. Bei andere Controller mit aufwendigeren Interrupt-Systemen sind priorisiert verschachtelte Interrupts völlig normal. > Wenn man sich an diese Voraussetzung halten will (Ich habe bis jetzt > noch jede Aufgabe so lösen können), dann schaltet man am Beginn jeder > Interruptroutine die Interrupts aus (cli) und am Ende wieder ein (sei). Genau das sollte man nicht tun, denn das macht der Controller sowieso schon selbst. Und insbesondere ein abschliessendes sei() kann die exakt gegenteilige Wirkung entfalten, weil zwischen dem SEI und dem Return noch etliche Befehle stehen, die eben dann unterbrochen werden können und dann exakt diese unerwünschte Verschachtelung bewirken.
spess53 schrieb: > Hi > >>seit wann soll denn der Mega32 irq Prioritäten haben? > > Selbstverstänlich gibt es Interruptprioritäten. Die haben aber nichts > mit 'Unterbrechbarkeit' von Interrupts zu tun, sondern mit der > Reihenfolge der Abarbeitung gleichzeitig anstehender > Interruptanforderungen. > > MfG Spess also kann ich den laufenden Int1 unterbrechen ..oder ?
Ingo Laabs schrieb: > also kann ich den laufenden Int1 unterbrechen ..oder ? Man kann, aber man sollte nicht. Und schon gleich garnicht bei deinem Interrupt-Modell, denn das ist schon im Ansatz verkehrt.
Gast
#2250995
Hi
>also kann ich den laufenden Int1 unterbrechen ..oder ?
Man kann, sollte es aber vermeiden. Besonders wenn man so etwas, wie du,
erst erfragen muss. Und wie schon gesagt, ist das Abspielen von Waves in
einer Interruptroutine das Dümmste, was man machen kann.
Such dir einen anderen Weg.
MfG Spess
spess53 schrieb: > Hi > >>also kann ich den laufenden Int1 unterbrechen ..oder ? > > Man kann, sollte es aber vermeiden. Besonders wenn man so etwas, wie du, > erst erfragen muss. Und wie schon gesagt, ist das Abspielen von Waves in > einer Interruptroutine das Dümmste, was man machen kann. > > Such dir einen anderen Weg. > > MfG Spess da wäre ja nur noch die Möglichkeit innerhabl des Abspielens der WAVE-Datei ständig den PIN von Int1 abzufragen (Int natürlich dann lahm gelegt)
Nino K.L. schrieb: > dann schaltet man am Beginn jeder > Interruptroutine die Interrupts aus (cli) und am Ende wieder ein (sei). Super Tip und dadurch gibts nen Stacküberlauf. CLI/SEI im Interrupt ist Pfusch! In einem Interrupthandler macht man nur das, was explizit im Datenblatt steht. Ansonsten gilt: Hände weg von der Interruptlogik! Peter
Ingo Laabs schrieb: > da wäre ja nur noch die Möglichkeit innerhabl des Abspielens der > WAVE-Datei ständig den PIN von Int1 abzufragen (Int natürlich dann lahm > gelegt) Entweder dies, oder der Interrupt-Handler setzt ein Flag, welches in der Routine gelegentlich abgefragt wird. Spielt der AVR die WAVs selber ab, oder spricht er dazu einen externes IC an? In letzterem Fall könnte die Unterbrechung der Abspielroutine ohnehin recht problematisch sein.
spess53 schrieb: > Selbstverstänlich gibt es Interruptprioritäten. Die haben aber nichts > mit 'Unterbrechbarkeit' von Interrupts zu tun, sondern mit der > Reihenfolge der Abarbeitung gleichzeitig anstehender > Interruptanforderungen. Das nennt sich dann aber bei MCs, die wirklich Prioritätslevel haben, nicht Priorität, sondern Polling-Sequenz. Z.B. 8051-Datenblatt: "A low-priority interrupt can be interrupted by a high-priority interrupt but not by another low-priority interrupt. A high-priority interrupt can not be interrupted by any other interrupt source. If two requests of different priority levels are received simultaneously, the request of higher priority level is serviced. If requests of the same priority level are received simultaneously, an internal polling sequence determines which request is serviced." Peter
spess53 schrieb: > Hi > >>also kann ich den laufenden Int1 unterbrechen ..oder ? > > Man kann, sollte es aber vermeiden. Besonders wenn man so etwas, wie du, > erst erfragen muss. Und wie schon gesagt, ist das Abspielen von Waves in > einer Interruptroutine das Dümmste, was man machen kann. > > Such dir einen anderen Weg. > > MfG Spess da wäre ja nur noch die Möglichkeit innerhabl des Abspielens der WAVE-Datei ständig den PIN von Int1 abzufragen (Int natürlich dann lahm gelegt) A. K. schrieb: > Ingo Laabs schrieb: > >> da wäre ja nur noch die Möglichkeit innerhabl des Abspielens der >> WAVE-Datei ständig den PIN von Int1 abzufragen (Int natürlich dann lahm >> gelegt) > > Entweder dies, oder der Interrupt-Handler setzt ein Flag, welches in der > Routine gelegentlich abgefragt wird. > > Spielt der AVR die WAVs selber ab, oder spricht er dazu einen externes > IC an? In letzterem Fall könnte die Unterbrechung der Abspielroutine > ohnehin recht problematisch sein. der AVR spielt die WAVE von einer SD-Card ab
Gast
#2251011
Peter Dannegger schrieb: > In einem Interrupthandler macht man nur das, was explizit im Datenblatt > steht. Wo steht denn im Datenblatt was ich im Interrupthandler machen darf? Ich darf doch wohl jeden ASM befehl ausführen den es gibt. Und PlayWave ist auch nur eine Sammlung von ASM befehlen. Wenn man weiss was man macht, muss man sich an überhaupt nichts halten. In diesen Fall macht es wirklich keinen sinn die Wave Datei im Interrupthandler abzuspielen aber als Begründung das Datenblatt zu erwähnen finde ich ein wenig merkwürdig.
Ingo Laabs schrieb: > der AVR spielt die WAVE von einer SD-Card ab Was bedeutet, dass du dann ab und zu mitten drin im SPI Interface Protocoll der SD-Card per Interrupt wiederum neu die SD-Card ansprichst und das ganze Protokoll völlig durcheinander bringst. Es sei denn du sicherst alle solche Aktivitäten in der Routine wiederum mit einer save-interrupt-flag + disable-interrupt - restore-interrupt-flag Klammer ab. Kurz: Vergiss es, der Ansatz ist Unfug.
A. K. schrieb: > Ingo Laabs schrieb: > >> der AVR spielt die WAVE von einer SD-Card ab > > Was bedeutet, dass du dann ab und zu mitten drin im SPI Interface > Protocoll der SD-Card per Interrupt wiederum neu die SD-Card ansprichst > und das ganze Protokoll völlig durcheinander bringst. Es sei denn du > sicherst alle solche Aktivitäten in der Routine wiederum mit einer > save-interrupt-flag + disable-interrupt - restore-interrupt-flag Klammer > ab. Kurz: Vergiss es, der Ansatz ist Unfug. also den PIN ständig abfragen ohne Interrupt
Ingo Laabs schrieb: > also den PIN ständig abfragen ohne Interrupt Wdh: "Entweder dies, oder der Interrupt-Handler setzt ein Flag, welches in der Routine gelegentlich abgefragt wird."
Peter II schrieb: > Wo steht denn im Datenblatt was ich im Interrupthandler machen darf? Ich > darf doch wohl jeden ASM befehl ausführen den es gibt. Und PlayWave ist > auch nur eine Sammlung von ASM befehlen. Einfach mal den ganzen Text lesen. Es ging um Manipulation der Interruptlogik (CLI/SEI) und die macht man nicht nach Gefühl, sondern exakt so, wie es im Datenblatt steht. Insbesondere bei größeren MCs (ARM) mit 32 Interruptlevel kommt man mit Gefühl nicht weiter. Da ist ganz genau einzuhalten, wann und in welcher Reihenfolge man welche Bits und Register anfassen darf. Beim ARM7 von ST ist die Interruptbeschreibung nur schlappe 35 Seiten lang. Peter
Gast
#2251591
> dann schaltet man am Beginn jeder Interruptroutine die Interrupts aus
Oh Schreck, die Echtzeit ist weg.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.