Interrupt probleme!!

[asuroer]

das geht doch nich, oder? man kann doch in einer isr nicht noch ein interrupt auslösen

[izaseba]

man kann doch in einer isr nicht noch ein interrupt auslösen

Wozu braucht man einen Interrupt, wenn man den Asuro im Kreis fahrenlassen will ?

[asuroer]

ich meinte, dass man sleep() nicht benutzenkann, da man ja kein interruot in einer isr auslösen kann. im Kreis fahren geht zwar, aber nicht eine bestimmte zeit lang, oder?

[izaseba]

Klar geht das, hat doch damaltor oben geschrieben.
Oder willst Du, daß er erst nach einem Tastendruck in Verbundung mit INT1 losfährt ?
Das kannst Du z.B. so lösen:

...
...
volatile uint8_t fahrlos = 0;
SIGNAL(SIG_INTERRUPT1){
fahrlos = 1;
}

int main(void) {
for(;;){
   while(!fahrlos);
   fahre();
   sleep(250);
   haltan();
   fahrlos = 0;
 }
return 0;
}

fahre() und haltan() mußt Du entsprechend ändern

Gruß Sebastian

[damaltor]

du benötigst überhaupt keine interrupts zum kreise fahren... nicht im allergeringsten. für die ersten 50-60 auch komplexen prorgamme wirst du dich mit den interrupts nicht beschäftigen müssen.

--- du schaltest die motoren ein. mit motordir und motorspeed.
--- du machst eine dreisekündige warteschleife. mit sleep oder msleep.
--- du hältst die motoren wieder an. mit motordir und motorspeed.

das wars. beispiel:

MotorDir(FWD,FWD);
MotorSpeed(255,150);
Msleep(3000);
MotorDir(BREAK,BREAK);
MotorSpeed(0,0);

ohne interrupts...

[asuroer]

hi damaltor,

Sleep funktioniert doch auch mit nem Interrupt, dem SIG_OUTPUT_COMPARE2, also doch wieder n Interrupt

[damaltor]

naja aber um den musst du dich doch gar nicht kümmern... du musst nur den quelltext nutzen, die interrupts sind bereis eingestellt...

[Sternthaler]

Hallo zusammen,
das hat ja mal Seltenheitswert. Alle haben Recht.
izaseba erklärt die Prios von Interrupts und unterbrochene Funktionen.
damaltor liefert Kreisprogramme für 3 Sekunden und weitere Erklärungen.
asuroer stellt fest, das Sleep() in einem anderen Interrupt nicht sinnvoll ist, da es nicht geht.

Warum das nicht geht liegt allerdings nicht am SIG_OUTPUT_COMPARE2, sondern am SIG_OVERFLOW2. In der dazu gehörenden Interrupt-Funktion wird ja die Variable count36kHz hochgezählt. Und wenn die Sleep()-Funktion diesen Wert nun innerhalb einer gerade laufenden Interruptfunktion abfragt, bleibt der Wert in count36kHz ja tatsächlich auf immer und ewig stehen, da eine begonnene Interruptfunktion ja nicht unterbrochen werden kann (ausser man will es wie izaseba schon sagte). Somit kann Sleep() also nie verlassen werden. Und damit steht das System.

[izaseba]

Hallo Sternthaler,
das ist natürlich eine gute Möglichkeit den Programmierer davon abzuhalten Warteschleifen in der ISR zu machen
Ein Hoch auf dei asurolib =D>

Gruß Sebastian

[Sternthaler]

Hallo izaseba,
klar ist die Möglichkeit nicht schlecht. Genau das habe ich ja beabsichtigt.
Warum also soll man asuroer nicht eine sinnvolle Erklärung zu seinem ja schon selbst gefundenen Sachverhalt geben? Man kann ja wohl recht zufrieden sein, dass ein 14-jähriger hier schon weiterdenkt und solche 'verzwickten' Dinge bemerkt. Und da er mit Nachdruck bzw. mit Traute auch ein 2.tes mal fragt, ob seine Vermutung nun stimmt oder nicht, hat er meiner Meinung nach auch eine Antwort verdient. (Ich gehe nicht davon aus, das dies der gesperrte Küchenbrett-User ist.)
Natürlich ist die Asuro-LIB nicht das nonplusultra. Aber genau darum geht es ja, jeder darf sie nutzen und ändern, oder er läßt es eben.

Gruß Sternthaler

P.S.: Ich wäre total an deiner LIB interressiert. Wenn du Spaß daran hättest, würde ich die mal gegen meine tauschen wollen. Ich stehe auf interruptbetriebene Sensorabfragen. (Soll neugierig machen.) PN?