Se opravicujem za prejsnji (prazen) mail.
Hotel sem dodati tole:
PC-ji oz. njihova ura in ostali timerji (razlicni na razlicnih osnovnih
ploscah) so *zelo* tocni. Problem je v operacisjkem sistemu, torej
software-u, ki je grajen za t.i. "average case performance" in ne za
"worst case performance". To velja za non-Rel_time operacijske sisteme,
med katerimi je tudi Linux, Win*...
Nek linux program oz. proces v user-space, ki ima eno neskoncno zanko in
nekaj posilja na LPT port se res casovno zelo netocno izvaja. Ampak to
zaradi milti OS, ki dela se marsikaj drugega...
Obstojajo pa Real-Time OS (Hard-Real-Time OS), tudi za PC platformo.
Eden izmed njih je tudi Rel-time-Linux (RTL).
http://www.rtlinux.org/
http://www.aero.polimi.it/projects/rtai/
RTL temelji na tem, da je Linus-ov Kernel malenkostno spremenjen in tece
kot neka naloga (task) z najnizjo prioriteto. Te naloge pa krmili nek RT
kernel, ki je torej hierarhicno visje kot Linux OS.
Zato lahko izvaja recimo periodicne naloge z max. 8 mikrosekund (mikro,
ne mili) zakasnitvijo, oz. napako. In to precej neodvisno od
obremenitve, ki ga povzrocajo Linux (user-space) procesi. Taka je tudi
max. zakasnitev zacetka izvajanja prekinitvene rutine pri neperiodicnih
nalogah (interrupt-driven). Resolucija timerja, je razlicna, tipicno pa
na neki PII osnovni plosci znasa 32 nano sekund. Seveda pa se s tako
natancnostjo ne da izvajati nalog... ni pa (obicajno) niti kaksne
potrebe po tem.
Za prehod na RTL je torej potrebno prevesti le (popatchan) kernel. Neko
nalogo pa se sprozi z nalozitvijo modula v kernel, . Ta modul zna
komunicirati tudi z user-space preko cevi, deljenega (skupnega)
pomnilnika...
S stalisca user-space programja je to torej isto kot gonilnik. Pisanje
teh modulov, oz. svojih nalog, pa je malenkostno tezje, ker gre za
programiranje v kernel space. Prepovedanih oz. nedostopnih je tudi
precej funkcij, predvsem vsi sistemski klici, dinamicno alociranje
pomnilnika... Je pa itak filozofija RTL-ja v tem, da se nalogo razstavi
na real-time in non-real-time del, ki se jih implementira loceno v
modulu in enim interface programom/skripto, ki komunicira z modulom.
Recimo za nastavljanje frekvence impulzov, vklop izklop nekih vnaprej
definiranih sekvenc...
Naceloma bi lahko preko Apache/cgi-bin/java ali cesa podobnega tudi
krmilil pozicijo robota preko www.
Skratka za posiljanje impulzov na LPT port za krmiljenje koracnih
motorjev, vec kot dovolj dobra, oz. predobra zadeva.
Edino koracni motorji se mi zdijo neuzstrezni za pogon robota, ker so
energijsko zelo neucinkoviti, je pa res, da so zelo enostavni za
krmiljenje.
Se pa strinjam z Ivanom, da je DOS, se najbolj real-time med M$
prokukti, ker tam tece samo en proces, in imas takorekoc cel procesor
zase. Edino kaksno pisanje v datoteko na disk te lahko zelo zmoti, ampak
to je pac problem tvojega programa.
Mikrokrmilnik pa je seveda najboljsa izbira, ker nimas OS-a, ki bi ti
delal probleme :-)))
Enako bi lahko dosegel tudi z i*86, torej PC arhitekturo, ce bi napisal
program v asemblerju za svojo nalogo. Seveda brez OS-a. Je pa to
nesmiselno in precej tezje kot programirati en mikrokontroler.
Upam, da nisem bil predolg.
lp,
Ales
Ivan Zilic wrote:
> PCji so casovno zelo netocni (tu smo v razredu milisekund) in pri direktnem
> krmiljenju koracnih motorjev s PCjem, je kakrsnokoli resno casovno spreminjanje
> intervalov nemogoce. Zato (tudi zaradi tega) uporabo mikrokrmilnika kot 'low
> level' sefa koracnih motorjev zelo toplo priporocam.
>
> Po drugi strani pa je uporaba multi* OSov /da priblizno ostanemo v okvirju
> liste ;-)/ najmanj primerna za taka neposredna krmiljenja.
> Moja izbira je vsekakor mikrokrmilnik. Nato (ce bi na vsak nacin ze moral biti
> PC HW) bi uporabil DOS. Linux je dobra zadeva, a ne na tem podrocju...
