Autor: Gregorio Kus (Grego_at_RMnet.IT)
Data: Sat 01 Jun 1996 - 21:21:40 MET DST
On Fri, 31 May 1996 15:56:25 +0200 PAyMoN wrote:
>majes_at_loiv.torun.pl (Piotr Majewski) wrote:
>
>>Interesuje mnie podlaczenie do PC urzadzen technicznych i sterowanie nimi.
[...]
>A najczesciej bierzesz takie cudo jak interfejs RS i z pomoca tego
>mozna podlaczyc prawie wszystko....a jak nie to projektujesz sobie
>wlasna karte....proste,nie? :)
ten, jak i kilka innych maili z propozycja uzycia "RS jako uznanego
standardu" zmuszony jestem uznac za nie tyle moze bledne w ogolnosci,
co blednie skierowujace pytajacego na sciezke, ktora jest tylko jedna
z mozliwych i w dodatku, w wiekszosci przypadkow daleka od optymalnosci.
W skrocie (bo temat ten to rzeka), do najprostszych systemow sterowania
(pod wzgledem sygnalow, nie pod wzgledem aplikacji - te moga byc naprawde zlozone) najlepiej uzyc portu rownoleglego (zwlaszcza jesli to ECP czy EPP
- powszechne dzisiaj). W ogromnej wiekszosci przypadkow (nawet do sterowania
skomplikowanymi urzadzeniami) wystarcza kilka sygnalow binarnych - uzycie
portu szeregowego to tylko niepotrzebna komplikacja po stronie sterowanej.
Jezeli sygnalow nie wystarcza - moznna kupic karte z 8255 (ten sam chip
co w PC [dzis zaszyty w chipset'cie]) aby miec mozliwosc uzycia 24 sygnalow.
Nawet z przerwaniem generowanym na kazda zmiane stanu na ktorejkolwiek
linii. Przy uzyciu jednego z trzech portow 8255 do adresowania mozna miec
np 256 portow we i 256 portow wy. itd itp.
Jesli natomiast naprawde musimy wymieniac DANE z urzadzeniem sterowanym -
na bliskie odleglosci i jesli nam nie przeszkadza grubosc kabla - znow
latwiej to zrobic uzywajac portu rownoleglego. Natomiast jesli powyzsze
warunki nie sa spelnione i zaczynamy rozwazac polaczenie szeregowe wcale
wybor RS nie musi byc "automatyczny" - jest uznany standard w aparaturze
pomiarowej (GPiB), a jesli zalezy nam na czyms powszechnie znanym i uzywanym
w swiecie PECET'a - wcale nie glupim jest wykorzystanie transmisji przez
port MIDI obecny na kazdej, najtanszej nawet karcie dzwiekowej (jest
masa tanich [bo projektowanych z mysla o amatorach zajmujacych sie
muzyka] "gotowcow" do tego standardu).
Z kolei, gdy nie obejdziemy sie bez sygnalow analogowych - za grosze
mozemy kupic taniutki 12bitowy przetwornik AD/DA (popularne w konfiguracji:
1 wyjscie analogowe/16 wejsc analogowych). Daje wystarczajaca dokladnosc
i czestotliwosc probkowania dla masy zastosowan (choc oczywiscie nie dla
probkowania dzwieku - do tego lepszy kazdy glupi Soundblaster).
Dalej: w przypadku sterowania czesto moze nas interesowac dlugosc trwania
jakiegos sygnalu lub ilosc impulsow z jakiegos wejscia impulsowego. W obu
tych przypadkach uzycie karty z 8253/8254 (znow kosci znane z IBM PC) moze
dac nieocenione uslugi. Zreszta przy pewnym wysilku - mozna wykorzystac do
tego celu te same kosci zawarte na plycie matce.
(Mala ciekawostka: mam wlasnie przed soba niezle napisany artykul
z "Computer Programming", pt "Performance monitoring in Win32",
w ktorej autor opisuje m.in. uzycie dwoch funkcji z Win32 library -
QueryPerformanceFrequency i QueryPerformanceCounter, zaznaczajac ze na jego
komputerze DX4/100MHz ta "performace frequency" wynosi 1,193,180Hz wyraznie
oczekujac ze np. na 286/10MHz moglaby byc inna. Tymczasem moze ona byc inna
ale np. na WinNT zapuszczonym na DECu z Alpha~, ale nie na pececie.
Bo w pececie jest to po prostu czestotliwosc taktowania ukladu 8253,
ktory ustawiony jest "na max" czyli generowanie przerwania co "pelny obrot"
16to bitowego licznika czyli co 65536 impulsow - jedno przerwanie.
To wyjasnia dlaczego we wszystkich pecetach [przynajmniej znamionowo -
bo mozna to zmienic, sam uzywalem tego przerwania 1000 razy na sekunde
w spirometrze komputerowym opartym na PC] mamy 18.2 przerwania na sekunde.
Idiotyczna wartosc, nieprawdaz? Na slad rozumowania tego palanta, ktory nas
obdarzyl tym rozwiazaniem, moze nas naprowadzic inne dzialanie:
65536/18.2=3600! tzn. co pelny obrot kolejnego licznika 16to bitowego
mamy 1na~ godzine! Inaczej mowiac - ten przyglup skazal nas na te wszystkie
kretynskie wyliczenia, jakie kazdy z nas musi robic mierzac "czas realny" -
tylko po to by latwo mierzyc godziny! W dodatku nawet tych elementarnych
rachunkow nie wykonal dokladnie, przez co w kazdym BIOSie jest taki fragment
ktory dodaje do licznika co pelna dobe pewna poprawke. Jaka? Pozostawiam
jako zagadke do wyliczenia. Za prawidlowa odpowiedz na pytanie jaka powinna
byc (z dokladnoscia do 1Hz) czestotliwosc taktowania tego cholernego zegara
w IBM PC aby powyzsze zalozenia sie zgodzily - stawiam piwo. W Rzymie.
[dojazd na koszt wlasny :-) ]
W kazdym razie - bez uzycia dodatkowej elektroniki mozna pecetem
mierzyc czas z rozdzielczoscia circa 0.0008ms. Niezle, nieprawdaz?
Cholera, ale sie rozpisalem...
moze lepiej tu zakoncze...
ale ostrzegalem przeciez ze to temat-rzeka.
Reasumujac: podkreslilem jedynie kilka wyjsc do ewentualnej dyskusji.
Najpierw trzeba sprecyzowac czym i w jakim celu ma sie zamiar sterowac.
Grego
P.S. Pisalem juz oprogramowanie i projektowalem elektronike do calej
masy przeroznych sterownikow. Nigdy nie uzylem do tego celu RSa.
RSa uzywalem (i uzywam) - owszem, ale do symulatorow, te jednak raczej
uznalbym za kilka komputerow polaczonych prymitywna siecia (RS byl
wystarczajacy - zbedne bylo stosowanie kart sieciowych), a nie
system sterowania, choc oczywiscie podzial nie jest scisly.
RS jest niezly (choc przestarzaly) do tego do czego zostal zaprojektowany
tzn. do komunikacji czyli wymiany DANYCH, podczas gdy do sterowania na ogol
wystarcza wymiana SYGNALOW. Zdaje sobie w calej pelni, jak nieostre
(i nakladajace) sie sa te pojecia (oczywiscie ze nie da sie wymieniac
danych nie wymieniajac sygnalow, a kazda wymiana sygnalow niesie w sobie
zawarte jakies dane) ale jednak mysle ze kazdy mniej wiecej zrozumial
o co mi chodzi w tym rozroznieniu.
-- /------------------------------------------------------------------ Gregorio Kus Grego_at_RMnet.it Grego_at_cyberspace.org ROMA, Italy http://www.RMnet.it/~grego Grego_at_FreeNet.hut.fi
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:44:54 MET DST