Konzept: Schnittstellen API an Interrupt Routine

Du musst die Laufzeit deiner Callback Funktionen in den Griff kriegen 
und aufwändige Teile asxmchron laufen lassen. Im Callback also nur Daten 
wegspeichern und ein Flag setzen, dadas du im Hauptprogramm sporadisch 
prüfst.

@Tom: Das Problem ist ja, dass ich an das Hauptprogramm (main()) nicht 
heran komme. Sonst würde ich natürlich nur ein Flag setzen.

@Peter: Das ganze läuft auf einem TI TMS320F28335 DSP.

Ich weiß, dass das ganze etwas unlogisch klingt, aber was mich daran 
stört ist, dass ich eine API (wie gesagt nicht quelloffen) habe, mit der 
das ganze einwandfrei funktioniert.

@Florian: Genau die Idee hatte ich auch schon, allerdings hat der 
Controller nur 3 Timer. Einer wird standardmäßig schon für die 
Schnittstelle benötigt. Wenn ich jetzt noch einen nehme, hab ich schon 
2/3 nur für die Schnittstellen verbraucht. Als Notlösung geht das 
natürlich.

Dazu kommt aber noch, dass das fertige API ja auch ohne den zweiten 
Timer auskommt. Ich würde es ja gerne genauso elegant lösen.

Habt ihr noch andere Ideen?

Grüße Eike

Erwartet denn der API-Aufruf einen Rückgabewert? Könnte es sein, dass 
der API-Call so oft wiederholt wird, bis "fertig" zurückgemeldet wird?

Also der API-Call gibt teilweise einen Rückgabewert zurück. Aber alle 
Calls werden pro ISR nur einmal aufgerufen.

Als Beispiel:

ISR_xy{

//alle anderen Interrupts disablen

res = fkt();

//alle anderen Interrupts enablen

}


int fkt(){

//do action

return res;

}

Und ich habe wie gesagt nur die Möglichkeit fkt() zu gestalten. Auf 
alles andere habe ich keinen Zugriff, kann es aber lesen. Und die 
Laufzeit von fkt() ist bei deaktivierten Interrupts definitiv zu lang.