"Apropó, több helyen olvasom hogy az interruptot nem ISR szolgálja ki hanem callback? Vagyis kilép a védett üzemmódból és mókol valahol?"
Ez egy dizajn dontes. Egyreszt nem szeretjuk a hosszu megszakitasokat, mert nehezen kontrollalhato keslelteteseket okoznak, ugyanakkor nem szeretjuk kesleltetve kiszolgalni a periferiat, mert ez lassit, illetve adatvesztest okozhat (pl UART elhagyja a karaktereket). Hogy melyik periferiahoz mi lesz a megfelelo egyensuly a 2 kozott, az alkalmazas es periferia fuggo. Pl. hogy az UART -nal maradjunk, ha az UART -nak van FIFO -ja, vagy DMA -val hasznalod, akkor jobb ha az ISR -bol csak kuldesz egy event -et az UART kiszolgalo processnek, es az majd feldolgozza az esemenyt amikor a rendszer raer. Ha az UART -nak sem FIFO-ja, sem DMA -ja nincs, akkor az ISR leteheti a karaktert egy FIFO -ba (ez gyors) majd az ISR event -et kuld, es a process majd feldolgozza a FIFO tartalmat kesobb. Ha az UART -ot figyelo processz idokritikus dolgot csinal (real-time protokoll -t futtat, es idoben kell tudjon valaszolni), akkor a feldolgozast vegzo teljes allapotgep futhat ISR kontextusban.
A "call-back" mint programozasi technika a fentiekkel nem feltetlenul van összefüggésben, amennyiben call-back hivhato ISR contextusbol, illetve azon kivulrol is. A call-back inkabb egyfajta "runtime dependency injection", vagy runtime szoftverkonfiguracios megoldas. Ez inkabb arrol szol, hogy a hivo kod csak a hivott kod elvart viselkedeset illetve az interfeszt hatarozza meg, de a konkret mukodest az imlementaciora bizza.