[LUGOS-PROG] senzor

[Ales Bardorfer]

Ales Kosir wrote:

> S tem se ne strinjam: RTAI Linux (Real-time) smo na letosnji poletni soli
> racunalnistva v Hermes Softlabu uporabljali za kontroliranje serijskega
> vmesnika in branje signala na prav enak nacin, kot se zdaj pogovarjate. Pri
> priblizno 30 Hz signalu nismo opazili tezav pri njegovi obdelavi in
> kontroli. Menda seze tocnost merjenja casov na RTAI tja pod 10 ms.

Tudi jaz se ne strinjam, da PC-ji niso primerni za merjenje casa. Prej
bi rekel, da vecina OS-ov ni primerna za to.
Vsi CPU-ju od Pentiuma in njegovih klonov naprej imajo vgrajen t.i.
Pentium internal counter (TSC register), 64 bitni, katerega vrednost se
monotono povecuje s taktom. Pri danasnjih CPU-jih (1 GHz) je teoreticno
razlocljivost merjenja casa 1 ns (nano sekunda). Res pa je, da tudi
zgradba Real-Time operacijskih sistemov (prekinitve...) to razlocljivost
nekoliko pokvari, tako da je dejanska razlocljivost nekje v rangu 50 ns.
Izvajanje dolocene kode pa lahko odstopa od zeljenega casa (periodic
scheduler latency, jitter) max. 8 us (mikro sekund).

Poleg RTAI, je druga veja Real-Time Linux-a (no, zgodovinsko gledano je
prva) se RTL (Real-Time Linux) <http://www.rtlinux.org/>. Vsi casi o
katerih sem govoril veljajo za RTL in sicer za kernel-mode, torej kodo,
ki se izvaja kot modul v kernel space-u.
Za RTAI bi morali biti casi podobni, je pa res, da RTAI omogoca
izvajanje aplikacij v user space-u v t.i. "Soft Real-time". Tu so
razumljivo casovna odstopanja (jitter) precej vecja in verjetno res
padejo v razred 10 ms, kot kometira Ales Kosir. Ales, se motim?


> Na navadnem Linuxu pa je zanesljivost merjenja casa dogodkov odvisna
> predvsem od obremenjenenosti sistema, kar pa vsi prav dobro vemo; po
> izkusnjah pa je to narejeno bolje kot v primerljivem sistemu pod MS Windows.

Tocno tako!

Za tvoj laserski senzor predlagam, da ga prikljucis na paralelni port,
tako da sprozi prekinitev (obicajno IRQ7). Nato lahko uporabis RTL in
napises kernel space modul (driver) ki bo vseboval prekinitveno rutino,
ki bo merila cas nastopa recimo pozitivne fronte signala na pinu. Ta cas
lahko potem elegantno preneses v user-space (FIFO ali shared memeory),
lahko pa tudi napises svoj driver interface. Neka user space aplikacija
lahko potem po standardnem read/write postopku bere/pise na dek
/dev/laser, oz. ce uporabis FIFO,  na /dev/rtf??.
Za konstrukcijo svojega driver interface-a priporocam branje Alessandro
Rubini et al.: Writing Linux device drivers 2nd edition, ki dostopna (v
celoti) tudi online na <http://www.oreilly.com/catalog/linuxdrive2/>.

Ce potrebujes case samo v merile namene bo to vse, v primeru da moras na
dolocen signal laserja takoj odreagirati z neko akcijo (vklop/izklop
neke naprave), pa bos moral to funkcionalnost dodati kar v kernel-space
modul, sicer se zadeva casovno ne bo nic bolje obnasala kot user-space
proces na non real-time OS-u.

Ni pa nujno, da uporabis prekinitve, lahko tudi neprestalno spremljas
nivo na dolocenem pinu LPT-ja. Vseeno pa priporocam uporabo prekinitev,
je pa res, da bos moral pametno izbrati pin LPT-ja, ker vsi ne morejo
sproziti prekinitve.

lp,
Ales