Nevíte někdo, jak by se dal řešit následující problém :
Mám periferii, kterou musím (pokud je aktivní) obsluhovat v pravidelných poměrně krátkých intervalech (cca jednotky ms), přitom výpadek je nežádoucí.
Kdybych (čistě teoreticky - netvrdím že bych to uměl) napsal ovladač a zahrnul ho do kernelu, jak se dá zařídit, aby se tento můj ovladač dostal "k lizu" pokaždé včas ? Dejme tomu že přípustná tolerance intervalu je řádově desítky procent, ale pokud by obsluha přišla řekněme za dvoj- nebo troj-násobek obvyklé doby, mohlo by to dělat problémy.
Šlo by toto zařídit pomocí zmíněného low-latency patche ? Nebo až nastavením pre-emptivního kernelu v 2.6 ? A dalo by se (aspoň teoreticky) nastavit, že moje obsluha má vysokou prioritu a nikdo mě nemá rušit ? Samotné obsluhování je krátké a jednoduché (prakticky jen výstup 1 byte na port), alekdyby mi někdo "sebral pod rukama" CPU, docela by to vadilo.
S RTAI (http://www.aero.polimi.it/~rtai/) se daj
zaridit i mnohem kratsi intervaly, ale je to trochu slozitejsi :-) . Ale ty jednotky ms by mel s preempt patchem (+ mozna i lowlatency patch) zvladnout i
userspace proces (asi s realtime prioritou). Nekde na webu jsem videl nejaka mereni, ale ted nevim, kde.
Pokud chcete delat ovladac v userspace (nebo v kernelu jako kernel thread), pak je low-latency patch nebo preemptivni kernel potreba. Pokud je ovladac v kernelu na interruptu, tak tyto veci nemaji vliv.
Otazka je, jestli si zarizeni samo rekne o interrupt, nebo je treba pouzivat timer. V pripade timeru je problem, ze timery jde nastavovat minimalne po 10ms. Existuji i patche, ktere meni casovani po 1ms, niz to nejde, protoze by to moc zpomalovalo. Dalsi moznosti je pouziti ovladace "real-time clock", ten by mel umet i nizsi intervaly.
>Existuji i patche, ktere meni casovani po 1ms, niz to nejde, protoze by to moc zpomalovalo.
Cas 10ms je dany historii z dob i386. Podivate-li se do zdrojaku jadra, zjistite ze jsou platformy, kde je cas kratsi. Pri dnesnich vykonech i pro platformu x86 je cas mensi nes 1ms byl pouzitelny. Ja osobne jsem si ho predelal na 1ms (na jednom PPC 50Mhz) a zpomaleni bylo neznatelne.
Na mem pocitaci (Pentium 200) trva obsluha casovaciho interruptu na Linuxu asi 2500 tiku. Z cehoz 400 tiku je ACKnuti interruptu na PICu + overhead procesoru, 600 tiku je zamaskovani a odmaskovani na PICu, zbytek je overhead se softirq, ktere se pokazde vola kvuli moznym timerum (na FreeBSD je tento overhead vyrazne nizsi, nebot to zadne softirq nevola). Kdyz to budete volat kazdou 1ms, sezere to 1% casu (a to nemluve o neprimo zmeritelnem zpomaleni programu zpusobenem vyprazdneni cachi). I 1% je moc. Niz uz to opravdu nejde.
PIC je na sbernici ISA, proto je pristup k nemu pomoci instrukci in a out hodne pomaly a rozhodne se to na lepsich pocitacich nezlepsi --- ISA je porad stejne pomala. Pri pouziti APICu jsou doby trvani vyrazne nizsi.
Jeste v dobe 486tek se pro zpozdeni cca 1 microsec pouzivalo cteni portu 0x20 (PIC), ktery BYL na sbernici ISA. Ale kratce po objeveni 586 se tento PIC prestehoval do chipsetu a tam je k nemu rychlejsi pristup. Me proto prestal fungovat jeden program, ktery generoval presne casovane prubehy - presneji receno na me 486 fungoval, na firemni 586 taky, na zakaznikove 586 ne. Opravil jsem to ctenim registru karty, ktera byla zasunuta do ISY. Ale dnes uz pocitace casto ISU nemaji vubec a pokud ji maji, tak standardni periferie na ni stejne nejsou a mala zpozdeni se delaji upne jinak.
