ja, streckenweise rechne ich sogar fest mit dieser reaktion! es bleibt aber genügend zeit um die verschachtelung abzubauen ... problematischer ist es wenn zwischen den operationen in der ISR ne unterbrechung entstehen würde!

die ISR für den Komparator werd ich demnächst reduzieren, ich werd einen externen komoparator einsetzen, der die funktion meiner makros "START" und "STOP" übernimmt und den controller quasi nurnoch über das ereignis informieren, der dann die notwendigen schritte einleitet

ausserdem es müssten wirklich ziemlich genau 256 takte sein die ins land ziehen um diesen effekt auszulösen ... da der effekt IMMER dieselbe größe hat(und auch nur negativ ist) statt einer 100S pause warte ich 84µS .. ein "mehr" oder "weniger" ist nicht, es sind nur diese beiden ergebnisse .. 100µS sollen es sein, 84µS sind es wenn der timer mal wieder spinnt

vielleicht hat ja jemand noch nen gedanklichen beitrag, wie ich eine µS genaue verzögerung einbauen kann, die in der summe aber bis 500mS (eventuell mehr) dehnbar ist und parallel die abarbeitung eines datenbus erlaubt

und noch einmal, sehr viele testläufe haben erwiesen, dass die menge der ISR und die verwendung von cli() und sei() darin auf das gesamte timing keinen einfluss haben, nur eben dieser eine effekt stört gewaltig und bleibt mir ein rätsel .. der code den ich oben geschrieben habe beinhaltet eigentlich alles was mit den timern zu tun hat und auch alle ISR die größer sind als 2 zeilen

in de rmain werden nur diverse variablen abgefragt um auf kommunikation und probleme reagieren zu können

leider kann cih hier nicht alles posten

PS: für die simulation fehlen mir die externen ereignisse und ne handeingabe fällt flach, wegen der zufälligkeit (was mich auch an dem simulationsergebnis zweifeln lässt) ^^