Voor dit geval hoeft dat ook niet, als de totale tijd van de isr routines maar binnen je kritische window valt. En dat is zeer goed voorspelbaar.
Hoe dan? 3 encoders die (in deze context) at random interrupts genereren... Dat gaat alleen goed als het 'snel' is. Als het 'snel' is, is die hele interrupted interrupts ongein niet nodig...
Dat wordt (vaak) bepaald door de architectuur van de gebruikte CPU.
Sommige ondersteunen dat, andere niet, soms is het een feit dat het zo is. Normaal laat ik de interrupts op dezelfde prioriteit lopen, dan wordt er niks genest. Per CPU type zoek ik dat uit hoe het precies in elkaar zit.
Dat is onzin. Als je de boel gaat nesten, moet je oppassen dat het niet te diep genest wordt. Daar doe je niks aan. Je kunt wat met priorities doen - als de interrupt controller dat kan - maar dan nog is het oppassen geblazen. En tot op heden heb ik nog niet meegemaakt dat het noodzakelijk is - wel dat een programmeur wilde laten zien 'hoe goed hij de controller begreep'. En feitelijk dus liet zien dat-ie niet in staat is om efficiënte code te schrijven / er net iets langer over na te denken zodat dat niet nodig is.
Zonder context is dit een gevaarlijke uitspraak.
De context is er: hardware counters die de boel bijhouden. Jij vraagt de status op op het moment dat je er interesse in hebt. That's is. Komt geen interrupt aan te pas.
[...]Kijk, nu haal je de context er wel bij: Laat de hardware het doen, net beweerde je nog dat je alles in de main-loop moet doen en dat werkt hier nu juist net niet.
Eh... Dat beweerde ik niet. Dat beweerde Jochem. Wel in de juiste context blijven hoor.
Mijn enige reactie was dat het technisch wel(licht) kan, met de retorische vraag of je het moet willen. Stack ontploft?? 