( asch | 2019. 09. 09., h – 11:34 )

Itt a probléma az, hogy IT rutinból kell továbbterelni a busz állapotát, különben nem követi a valóságot, viszont a szerző által írt rutin nem elég gyors ahhoz, hogy időben lekezelje az állapotátmenetet. Ha kellően gyors volna az IT rutinja, az megoldás lenne.

16-20MHz csip órajelet feltételezve kb 2000 órajele van lekezelni az interruptot. (Jól számoltam? A busz és a csip órajelének függvénye is ez!) Le is írja a cikkben, hogy nem csak annyi van az IT rutinban, hogy beteszi a kapott bájtot egy pufferbe, hanem konkrétan csinál is vele valamit. Illetve nem tudja a regiszter mentéseket kispórolni az IT rutinból, mert túl sok változót használ, vagy van belül függvény továbbhívása.

Szerintem ezt a problémát meg lehet oldani ASM-ben írt IT rutinnal, vagy "NAKED" ISR rutinnal, ami az állapotátbillentést megcsinálja regiszter mentés nélkül, majd újraengedélyezi az IT-t, és a hosszú idejű feldolgozást már IT engedélyezés mellett hajtja végre. (Vagy csak beteszi az adatot egy round-robin pufferbe, és a fő szálról dolgozza fel, nem IT alól.) Szerk.: Emiatt számomra nem egyértelmű, hogy ezt hardware bugnak kell tekinteni, vehetjük úgy is, hogy egy nagyon szigorú IT sebesség korlátozás.

Ez egy piszkos trükk, hogy az IT rutin kontextusából, de engedélyezett IT mellett dolgozzuk fel a bejövő adatot. Lehetővé teszi az egymásba ágyazott IT-ket, ezért különösen észnél kell lenni az időzítésekkel, nehogy stack overflow legyen a vége, de jól csinálva működik.

Plusz arra is figyelni kell, hogy nem csak ez az egy IT rutin van a rendszerben, és worst case is benne kell maradni az időkeretben. Ez a többi IT rutin, plusz az IT disable blokkok kényszerű lerövidítését is jelenti. És még jó sokat kell számolgatni is. Szóval végsősoron tényleg sokkal jobb lenne, ha a hardver másképpen lenne megvalósítva, ahogy a cikk szerzője javasolja.