[OSy] Nestihajici zapsani CP0 compare registru

[Martin Decky]

Hezky den,

priste bych prosil psat podobne dotazy prednostne do konference ..

> Takze sa mi stane, ze nastavim compare na 43907 ale count uz je 44010
> napriklad. Tento delay v mojom kode som metodou try&fail odhadol na 200
> tickov a jednoduchy patch je samozrejme nastavit ten compare o 200
> tickov dalej v adekvatnych pripadoch.

Asi nezbyva nez cely ten algoritmus udelat robustne. Stejne se musite 
probouzet periodicky z duvodu planovani, takze v planovaci muzete 
otestovat, zda od posledniho pruchodu timery nejake nahodou nevyprsely, 
aniz by se provedly, a primo je provest nebo oznacit k provedeni (podle 
toho, v jakem kontextu obsluzne rutiny casovacu provadite).

> Otazka moja je (ktoru neviem z manualov vycitat), je moznost (a ako)
> priamo nastavit IP7 bit v kode (pri zakazanych interruptoch), takze by
> sa hned ako povolim interrupty vyvolal interrupt 7 a handlovanie
> timerov?

Ne, bit IP7 programove nastavit nelze, muze to udelat pouze procesor sam 
pri rovnosti Count a Compare registru. Uvedomte si ale, ze muzete 
nastavovat nejen hodnotu registru Compare, ale take hodnotu registru 
Count, takze vzdy, kdyz potrebujete naplanovat dalsi probuzeni, tak 
muzete zajistit, ze Count < Compare.

> Minimalne by som sa zbavil nejakeho 200 tick delayu, samozrejme timery
> by tam pretekali aj tak: ked raz niekto zavola timer_start(1 usec)
> tak sa moze aj na kolomaz rozliat a nestihnem ho zobudit za jednu
> mikrosekundu. Ale bolo by to aspon pekne.

Probuzeni presne za 1 usec neni rozhodne nutne, zadani to nepozaduje a 
pochopitelne to v non-RT systemu ani nemuzete nijak garantovat. Obsluzna 
rutina timeru by se nemela zavolat drive nez po vyprseni timeoutu, ale 
pokud se zavola v rozumne dobe po vyprseni, vse je OK.

Planovaci kvantum urcite odpovida definici "rozumne doby".


M.D.