Jak osi±gn±ć 115200bps na AT89C2051 i jak± częstotliwo¶ć kwarcu zastosować?
AT89C2051 i 115200bps
From: "Filip R. Zawadiak" <philz_at_nospam_wasko.gliwice.pl>
Subject: AT89C2051 i 115200bps
Date: Mon, 16 Nov 1998 10:28:48 +0100
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
Filip R. Zawadiak (Philz) http://vyx.net/~philz
Isaac is alive ! mailto:philz_at_nospam_vyx.net
From: "Tomasz Gumny" <gumny_at_nospam_ikp.atm.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Mon, 16 Nov 1998 11:28:49 GMT
Filip R. Zawadiak napisał(a) w wiadomo¶ci:
<364FF050.A8CFD0EC_at_nospam_wasko.gliwice.pl>...
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
>Filip R. Zawadiak (Philz) http://vyx.net/~philz
>Isaac is alive ! mailto:philz_at_nospam_vyx.net
Witam
W Mode2 (9bit UART) przy kwarcu 3.6864MHz
lub 7.3728MHz.
W Mode1 lub 3 (8 lub 9bit UART) przy kwarcu 22MHz
(tylko AT89C2051-24 i skad wziac taki kwarc).
TG
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Tue, 17 Nov 1998 01:07:43 +0100
Marek Michalkiewicz napisał(a) w wiadomości:
skad wziac taki kwarc
Cześć wszystkim!
Po przeczytaniu twojej wiadomości przypomniało mi się autentyczne zdarzenie:
Stoję drugi w kolejce w sklepie elektronicznym. Facet przede mną pyta
sprzedawcę:
- Czy otrzymam rezonator kwarcowy 24MHz.
- Nie, nie ma.
- To poproszę dwa 12MHz, połączę szeregowo.
Prawie się osikałem.
Jeżeli chodzi o pytanie Filipa to można rozwinąć zawrotną prędkość 115200
stosując zewnętrzny generator na kwarcu 11,0592MHz z powielaczem
częstotliwości x2 na wyjściu (parę bramek). Oczywiście można się przyczepić,
że uC powiększył się dwukrotnie, ale problem zostanie rozwiązany. Znacznie
bogatsze możliwości daje AT89C52, w któwy licznik T2 może być taktowany
zegarem fxtal/2. Wchodzi wówczas w rachubę kwarc 18,432MHz, do nabycia np. w
Maritexie za magiczną sumę 1,25zł netto (T2 dzieli w tym przypadku przez 5).
Nara
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: marekm_at_nospam_piast.t19.ml.org (Marek Michalkiewicz)
Subject: Re: AT89C2051 i 115200bps
Date: Mon, 16 Nov 1998 18:15:37 GMT
Tomasz Gumny <gumny_at_nospam_ikp.atm.com.pl> wrote:
W Mode1 lub 3 (8 lub 9bit UART) przy kwarcu 22MHz
(tylko AT89C2051-24 i skad wziac taki kwarc).
Projektowałem kiedy¶ co¶ na AMD 188ES z kwarcem 22.1184MHz (z tego samego
powodu - 115200bps). Kwarc dało się kupić (MS Elektronik w Gdyni), choć
chyba z powodu "rzadkiej" częstotliwo¶ci cena niestety ok. 4 PLN + VAT.
Czy przy 115200bps procesorek się wyrobi z przetworzeniem odebranych
danych to inna sprawa (188ES się wyrabia ale tylko dzięki DMA, bo na
obsługę przerwań po każdym odebranym znaku byłoby zbyt mało czasu).
Na '51 może być to do¶ć trudne.
Uwaga na kwarce o dużych częstotliwo¶ciach - można trafić na takie,
które pracuj± na trzeciej harmonicznej - wtedy (według AMD) trzeba dać
szeregowo 10uH i 200pF między XTAL1 i GND. Nie wiem jednak czy to
zadziała na AT89C2051...
Pozdrawiam
--
Marek Michałkiewicz <marekm_at_nospam_piast.t19.ml.org>
AM ELEKTRONIK s. c., ul. Biała 7, 80-435 Gdańsk, tel./fax 058 3440061
From: "Tomasz Gumny" <gumny_at_nospam_ikp.atm.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Mon, 16 Nov 1998 20:30:01 GMT
Marek Michalkiewicz napisał(a) w wiadomo¶ci: <2ppp27.up.ln_at_nospam_marekm.home>...
Tomasz Gumny <gumny_at_nospam_ikp.atm.com.pl> wrote:
W Mode1 lub 3 (8 lub 9bit UART) przy kwarcu 22MHz
(tylko AT89C2051-24 i skad wziac taki kwarc).
Projektowałem kiedy¶ co¶ na AMD 188ES z kwarcem 22.1184MHz (z tego samego
powodu - 115200bps). Kwarc dało się kupić (MS Elektronik w Gdyni), choć
chyba z powodu "rzadkiej" częstotliwo¶ci cena niestety ok. 4 PLN + VAT.
Pozdrawiam
--
>Marek Michałkiewicz <marekm_at_nospam_piast.t19.ml.org>
Mozna tez wziac kwarc 11.0592MHz, zbudowac
na nim prosty generator i powielic razy 2.
Nigdy tego nie robilem, ale tak na oko wystarczy
jedna kosc z czterema bramkami XOR: dwie-trzy
na generator i jedna na powielacz.
TG
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Tue, 17 Nov 1998 02:13:46 GMT
Filip R. Zawadiak napisał(a) w wiadomo¶ci:
<364FF050.A8CFD0EC_at_nospam_wasko.gliwice.pl>...
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
>Filip R. Zawadiak (Philz) http://vyx.net/~philz
>Isaac is alive ! mailto:philz_at_nospam_vyx.net
Owszem da sie ale na kwarcu 11,0592 razy 2 - ciezko z nimi co prawda ale sa
programowane generatorki z PLL Cypressa. Jest problem w UARCIE tylko taki,
ze Atmelek ma buforowany RXD a TXD niestety nie. Co prawda przerwanie
wyskakuje zaraz po 8-mym bicie danych jak zaczyna sie bit stopu ale to tylko
jeden bit czasu na reakcje :((( kiepsko.
Reasumujac - odbierac nim sie jakos da ale nadawac niebardzo !
Do takich predkosci to cos 16-bitowego niestety trzeba wziac lub
mocniejszego.
Juliusz
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Wed, 18 Nov 1998 01:58:15 +0100
Juliusz napisał(a) w wiadomości: ...
Filip R. Zawadiak napisał(a) w wiadomo¶ci:
<364FF050.A8CFD0EC_at_nospam_wasko.gliwice.pl>...
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
>>Filip R. Zawadiak (Philz) http://vyx.net/~philz
>>Isaac is alive ! mailto:philz_at_nospam_vyx.net
>
>Owszem da sie ale na kwarcu 11,0592 razy 2 - ciezko z nimi co prawda ale sa
>programowane generatorki z PLL Cypressa. Jest problem w UARCIE tylko taki,
>ze Atmelek ma buforowany RXD a TXD niestety nie. Co prawda przerwanie
>wyskakuje zaraz po 8-mym bicie danych jak zaczyna sie bit stopu ale to
tylko
>jeden bit czasu na reakcje :((( kiepsko.
>Reasumujac - odbierac nim sie jakos da ale nadawac niebardzo !
>
>Do takich predkosci to cos 16-bitowego niestety trzeba wziac lub
>mocniejszego.
>
>Juliusz
Nie chcę cię martwić, ale 1 bit to aż 16 cykli zegarowych(przy fxtal
22,1184MHz oczywiście) dzięki którym można zachować ciągłość transmisji.
Podczas wysyłania bitu startu i 8 bitów danych (+ opcjonalna parzystość)
mamy min. 8x16 = 128 cykli maszynowych, podczas których można przygotować
następny bajt do wysłania np. odczytując go nawet z wybitnie flegmatycznej
pamięci zewnętrznej. Obsługa przerwania od portu szeregowego może wygladać
następująco:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ; razem
7 cykli ( w tym momencie zostało zainicjowane nadawanie, które defakto
rozpocznie się za 9 cykli maszynowych)
PUSH PSW
MOV C,WcześniejPrzygotowanyBitParzystości
MOV RB8,C
POP PSW
RETI
W ten magiczny sposób załapujesz się ( z palcem w d...) na najbliższy cykl
sygnału TXC (sygnał taktujący nadajnika) i nadawanie przebiega bez żadnych
przerw.
Wbrew pozorom te małe mikrokomputerki mogą więcej niż się powszechnie
sądzi. Trzeba tylko trochę pokombinować, a można zaoszczędzić kilkadziesiąt
złotych na szybkich maszynach 16-bitowych. Jeżeli chodzi o kwarc 11,0592MHz
to można go dostać np. w Maritexie za 1,25zł netto bez żadnego problemu, a
zwnętrzny generator z podwajaczem częstotliwości można wykonać na czterech
bramkach EXNOR plus kilka elementów biernych.
Pozdrawiam
Maciej Adamski
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Sat, 21 Nov 1998 02:43:13 GMT
Maciej Adamski napisał(a) w wiadomo¶ci:
<733ucb$d02$1_at_nospam_gemini.webcorp.com.pl>...
Juliusz napisał(a) w wiadomo¶ci: ...
Maciej Adamski napisał(a) w wiadomo¶ci:
<732in2$r0r$1_at_nospam_gemini.webcorp.com.pl>...
Nie potrafię zrozumiec jak z powyższego tekstu wyci±gn±łe¶ wniosek, że
zamierzam robić przerwy między bajtami. Napisałem o 15% spadku mocy
obliczeniowej a nie prędko¶ci transmisji. Przerw nie ma! A nawet jeżeli
wprowadziłbym specjalnie jeden bit przerwy to i tak prędko¶ć spadłaby o
10%.
Natomiast gdyby¶ chciał wysył±ć to wolniej to następna prędko¶ć w szeregu
to
57600 a to już 50% wolniej. Różnica jest, co?
He, prowadzimy szkolna dyskusje w koncu, bez nerwow :)) Zastanawiam si co by
bylo gdyby.... A wina chyba jest w tym braku buforowania TXD i w tym
parszywym dzieleniu kwarcu przez 12 :)) Inaczej nie byloby problemu. Zreszta
ktos kto zaczyna i tak sobie sprawy nie zdaje z tych problemow :(
I tutaj zgadzam się z tob± kolego całkowicie. Jest okazja, aby
zaapelować do wszystkich pytaj±cych aby na¶wietlali w swoich listach trochę
więcej szczegółów. Pozwoli to rozwi±zywać problemy w znacznie szerszy
kontek¶cie. Nie będzie podobnych nieporozumień.
A to jest inna kwestia :)) Wrecz komedia jak ludzie pytaja o cos, ze
wlasciwie chyba nawet sami nie wiedza o co zapytac. Zwykle takie posty
ignoruje, bo nawet trudno na nie udzielic odpowiedzi. Jak ktos pyta o
schemat do 51-ki czy o wykresy jakies blizej nie okreslone.
Pamietacie CZESIA ? Co wycieraczki sterowac chcial ? Pewnie nawet nie ma
czym zaprogramowac kostek do dzisiaj :)) A co dopiero mowic o problemach z
programowaniem. %1-ka to nie samo programowanie i trzeba czuc, ze jeszcze
dochodzi tutaj wiedza z elektroniki cyfrowej. Trudno jest tlumaczyc
cokolwiek ludziom nie majacym nawet podstaw. To nie pecet i qbasic :))
Juliusz
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Sat, 21 Nov 1998 12:39:20 +0100
Juliusz napisał(a) w wiadomo¶ci: <5Np52.7724$BD6.1360733_at_nospam_news.tpnet.pl>...
Zreszta ktos kto zaczyna i tak sobie sprawy nie zdaje z tych problemow :(
Jeżeli masz mnie na my¶li to po czę¶ci prawda. Obecnie pracuję nad
zrobieniem Juliusza na AT89C1051 (RS nigdy nie był jego mocn± stron±). A to
przecież zadanie dla pocz±tkuj±cych.
Pozdrawiam
Maciej
Bez odbioru szszszszszszszszszszszszszszszszszszszszsz...
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Sat, 21 Nov 1998 02:51:10 GMT
Maciej Adamski napisał(a) w wiadomo¶ci:
<734220$id9$1_at_nospam_gemini.webcorp.com.pl>...
Na dodatek program jest napisany w konwencji wielozadaniowej (dochodzi
przeĹÄczanie zadaĹ, zarzÄdzanie pamiÄciÄ i dostÄpem do portĂłw). Juliusz to
by pewnie zastosowaĹ Pentium MMX 200 (albo dwa) (bez obrazy ;)
Nie, no bez przesady, ze 200MMX :)) Ale mam urzadzenie, ktore musialem
zrobic na 2 Atmelach AT89C51 taktowanych z 20MHz. Procki pracuja
rownoczesnie i jeden wstepnie cos obrabia, a inny to lyka portem dalej i
obrabia koncowke tego co pierwszy juz zrobil. Procki sa polaczone jednym
portem ze soba - 8-ma liniami :)
W samych Katowicach pracuje tego juz kilkadziesiat sztuk i to w miejscach
poblicznych :)) Pewnie wielu z katowic to widzialo a nie wiedza, ze Juliusz
w tym palce maczal :)))))))))))))))))
Juliusz
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Sat, 21 Nov 1998 03:07:38 GMT
J.F. napisał(a) w wiadomo¶ci: ...
On Fri, 20 Nov 1998 15:01:56 GMT, Juliusz <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
wrote:
[..]
Niby tak ALE: co sie stanie jezeli dane rownolegle beda pompowane do portu
co 160 (16 cykli x 8N1) cykli maszynowych a ty bedziesz opuszczal bit co
ramke ? Ha ? Na jak dlugo starczy ci RAMu na FIFO az zaczniesz dane tracic
?
Mowiac szczerze jak dane sa rownolegle, to zwykle jest jakis mechanizm
wstrzymywania ich doplywu ...
Dobra, juz dobra, nie lapmy sie za slowka :)) Zakladamy, ze chodzi nam o
okstremalne warunki przepompowywania danych w obu kierunkach. Nawet wyobraz
sobie prosty 2-kierunkowy konwerter parallel to serial i serial to parallel
w czasie rzeczywistym i do tego konwersja asynchroniczna na synchroniczna i
odwrotnie :)) Nie zawsze da sie powstrzymywac dane w koncu :)
Nikt mi nie powie, ze okienko z 16-ma cyklami maszynowymi wystarczy aby
nie
opuscic bitow po drodze.
Na oko jakies 32 cykle przy tym kwarcu ...
Jestes w bledzie. Przerwanie od nadania znaku w 51 wyskakuje natychmiast po
nadaniu 8-go bitu danych. Czyli 9-go w kolejnosci: START bit_____8xDANE_
PRZERWANIE _ STOP. Czyli aby dokarmic UART musisz w trakcie bitu stopu
wpisac do SBUF kolejny BAJT. jeszcze raz to przypominam:
115200 - predkosc
8,68056E-06 - tyle trwa 1 bit
5,42535E-07 - tyle trwa 1 cykl maszynowy (zegar 22118400/12)
16 - to wychodzi jak podzielisz bit przez cykl maszynowy
Czyli masz 16 cykli
W przerwaniu najpierw skaczesz pod wektor, testujesz flage, kasujesz ja i
dopiero mozesz cos wpisac do bufora. A z powodu tego, ze musisz jeszcze
robic byfor programowy (powinienes) to jeszcze wskazniki bufora
modyfikujesz. Wiec juz na 100% wyskakujesz ponad 16 cykli niestety.
Dostajesz predkosc 115200 posiekana przerwami pomiedzy. To jest idealny
przyklad, ale zwykle robisz wiecej niz takie proste operacje. Pamietaj, ze w
przeciwna strone leci osobny podprzerwaniowy proces dla odbierania znaku i
jeszcze kilka innych drobnych rzeczy.
Nawet jakbys robil konwersje asynchro na synchro dla wylacznie szeregowej
transmisji to juz zupelnie sie zamotasz, bo fifo robisz duze i juz
kompletnie brakuje czasu. Dane doplywaja w full duplexie na 115200 a ty je
chcesz wysylac 115200 z przerwami. Wiec co sie dzieje ? Wysylasz do czasu
kiedy ci wystarcza bufora, a pozniej tracisz dane...
Juliusz
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Tue, 17 Nov 1998 21:04:26 +0100
Juliusz napisał(a) w wiadomości: ...
Filip R. Zawadiak napisał(a) w wiadomo¶ci:
<364FF050.A8CFD0EC_at_nospam_wasko.gliwice.pl>...
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
>>Filip R. Zawadiak (Philz) http://vyx.net/~philz
>>Isaac is alive ! mailto:philz_at_nospam_vyx.net
>
>Owszem da sie ale na kwarcu 11,0592 razy 2 - ciezko z nimi co prawda ale sa
>programowane generatorki z PLL Cypressa. Jest problem w UARCIE tylko taki,
>ze Atmelek ma buforowany RXD a TXD niestety nie. Co prawda przerwanie
>wyskakuje zaraz po 8-mym bicie danych jak zaczyna sie bit stopu ale to
tylko
>jeden bit czasu na reakcje :((( kiepsko.
>Reasumujac - odbierac nim sie jakos da ale nadawac niebardzo !
>
>Do takich predkosci to cos 16-bitowego niestety trzeba wziac lub
>mocniejszego.
>
>Juliusz
Nie chcę cię martwić, ale 1 bit to aż 16 cykli zegarowych(przy fxtal
22,1184MHz oczywiście) dzięki którym można zachować ciągłość transmisji.
Podczas wysyłania bitu startu i 8 bitów danych (+ opcjonalna parzystość)
mamy min. 8x16 = 128 cykli maszynowych, podczas których można przygotować
następny bajt do wysłania np. odczytując go nawet z wybitnie flegmatycznej
pamięci zewnętrznej. Obsługa przerwania od portu szeregowego może wygladać
następująco:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ; razem
7 cykli ( w tym momencie zostało zainicjowane nadawanie, które defakto
rozpocznie się za 9 cykli maszynowych)
PUSH PSW
MOV C,WcześniejPrzygotowanyBitParzystości
MOV RB8,C
POP PSW
RETI
W ten magiczny sposób załapujesz się ( z palcem w d...) na najbliższy cykl
sygnału TXC (sygnał taktujący nadajnika) i nadawanie przebiega bez żadnych
przerw.
Wbrew pozorom te małe mikrokomputerki mogą więcej niż się powszechnie
sądzi. Trzeba tylko trochę pokombinować, a można zaoszczędzić kilkadziesiąt
złotych na szybkich maszynach 16-bitowych. Jeżeli chodzi o kwarc 11,0592MHz
to można go dostać np. w Maritexie za 1,25zł netto bez żadnego problemu, a
zwnętrzny generator z podwajaczem częstotliwości można wykonać na czterech
bramkach EXNOR plus kilka elementów biernych.
Pozdrawiam
Maciej Adamski
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Thu, 19 Nov 1998 19:06:23 GMT
Maciej Adamski napisał(a) w wiadomo¶ci:
<72sogj$tbo$1_at_nospam_gemini.webcorp.com.pl>...
Nie chcę cię martwić, ale 1 bit to aż 16 cykli zegarowych(przy fxtal
22,1184MHz oczywiście) dzięki którym można zachować ciągłość transmisji.
Podczas wysyłania bitu startu i 8 bitów danych (+ opcjonalna parzystość)
mamy min. 8x16 = 128 cykli maszynowych, podczas których można przygotować
następny bajt do wysłania np. odczytując go nawet z wybitnie flegmatycznej
pamięci zewnętrznej. Obsługa przerwania od portu szeregowego może wygladać
następująco:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ; razem
7 cykli ( w tym momencie zostało zainicjowane nadawanie, które defakto
rozpocznie się za 9 cykli maszynowych)
PUSH PSW
MOV C,WcześniejPrzygotowanyBitParzystości
MOV RB8,C
POP PSW
RETI
W ten magiczny sposób załapujesz się ( z palcem w d...) na najbliższy cykl
sygnału TXC (sygnał taktujący nadajnika) i nadawanie przebiega bez żadnych
przerw.
Zycze szczescia ! Moze i da sie to zrobic jesli masz tylko to do roboty, ale
pusc jeszcze IN0,1, moze jakies przerwanie od timera i masz petle glowna do
obsluzenia !
Ja to przerabialem juz dawno temu i niestety 51-ka nie wyrabia sie niestety
z predkoscia 115200.
8,68056E-06 tyle trwa bit przy 115200
4,52112E-08 tyle trwa cykl zegara
5,42535E-07 tyle trwa cykl maszynowy (12 zegarow na 1 cykl maszynowy)
16 - czyli 16 cykli maszynowych to ten bit stopu dla 8N1
skok do procedury to 4 cykle czyli juz jest 12
zeby nie gubic bitu i zapewnic wydajnosc pompowania danych to nie mozesz
sobie pozwolic na opuszczanie nawet bitu pomiedzy ramkami UARTU i wolne
miejsca wypalniac stanem wysokim, bo tracisz 10% na przepustowosci
natychmiast
A co w tych 12 cyklach wsadzisz niby ? jeden rozkaz to zwykle 2 cykle
maszynowe czyli 24 zegary. Musisz zdazyc wpisac do SBUF przed zboczem
inicjujacym UART bo inaczej i tak ci opusci czyli zostaje ci faktycznie 10
cyki
A pomysl, ze jeszcze robisz inne rzeczy w procku niz tylko pisanie do SBUF.
Niech ci wyskoczy przerwanie zew. od INT0 lub INT1 .
Hahaha a niech np. wyskoczy ci przerwanie od odebranego znaku akurat ! to
juz stracisz kilka cykli i po ptakach - i masz przesunieta ramke o 1 bit
cvzyli wydajnosc spada.
Jezeli jest tu kwestia wysylania tylko to OK, ale jesli ktos chce zrobic
operacje full duplexowe bez degradacji wydajnosci TO NIECH ZAPOMNI o 51-ce -
oczywiscie przy tej predkosci
To sie nigdy nie wyrobi NIGDY
Natura transmisji asynchronicznej jest taka, ze nigdy nie wiesz kiedy
otrzymasz bajt do bufora. Pozostaje tak malo cykli (jesli pozostani) ze
nawet na maskowanie przerwania nie ma wolnego cyklu.
Ha nawet zrobienie petli full duplex takiej, ze dostajesz bajt i odsylasz go
natychmiast majac 16 cykli wolnych jest juz problemem, bo nigdy nie wiesz
kiedy ten bajt przyjdzie.
Juliusz
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 01:43:48 +0100
Zycze szczescia ! Moze i da sie to zrobic jesli masz tylko to do roboty,
ale
pusc jeszcze IN0,1, moze jakies przerwanie od timera i masz petle glowna do
obsluzenia !
Ja to przerabialem juz dawno temu i niestety 51-ka nie wyrabia sie niestety
z predkoscia 115200.
Ty chyba czytasz między wierszami.
Po pierwsze pytanie brzmiało: AT89C2051 i 115200bps da sie tyle wyciagnac ?
I na jakiej czestotliwosci zegara ?
Jeżeili facet zdecydował się na AT89C2051 (i to nie koniecznie z największ±
częstotliwo¶ci±) to chyba nie zamirzał liczyć całęk podczas transmisji.
Liczył się z możliwo¶ciami tego uC. Obsługa wysyłania danych moim sposobem z
omawian± prędko¶ci± zabiera ok. 15 procent mocy obliczeniowej. I to ma
spowodować niemożno¶ć wykonania pozostałych zamierzonych przez pytaj±cego
operacji??:{
skok do procedury to 4 cykle czyli juz jest 12
Po druge specjalnie napisałem:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ;
razem 7 cykli
Gdyby¶ nawet nie zauważył dyrektywy ORG i maksymalnej liczby cykli
potrzebnych na to aby IP znalazł się w tym miejscu to i tak 7+4=11 a nie 12.
Po trzecie: Spowolnienie transmisji to co¶ normalnego(jeżeli już do niej
dojdzie). Trzeba się liczyć z możlowo¶ci± powstawania błędów i zwi±zan± z
nimi obsług± retransmisji.
Hahaha a niech np. wyskoczy ci przerwanie od odebranego znaku akurat ! to
j>uz stracisz kilka cykli i po ptakach - i masz przesunieta ramke o 1 bit
cvzyli wydajnosc spada.
Nie chcę cię martwić ale to jest to samo przerwanie i wydajno¶ć nie spada.
Ha nawet zrobienie petli full duplex takiej, ze dostajesz bajt i odsylasz
go
natychmiast majac 16 cykli wolnych jest juz problemem, bo nigdy nie wiesz
kiedy ten bajt przyjdzie.
A to co?
Ogólnie sprawiasz wrażenie faceta zagubionego w temacie, a do tego
odpisujesz na pytania i odpowiedzi, których wcze¶niej nie czytasz (ja tak
nie potrafię). Przychylam się do opinii Olgierda (Re: mikrofon laserowy??),
ten sceptycyzm jest bardzo widoczny.
Pozdrawia Maciej, który nie jedno na MCS51 zrobił. Życzę więcej
optymizmu i wiary w możliwo¶ci prywatnych neuronów.
P.S. Na potwierdzenie mojego rozwi±zania przeczytaj Re: AT89C2051 i
115200bps rubikon_at_nospam_fema.krakow.pl 19 listopada 1998 22:54.
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 11:50:43 GMT
Maciej Adamski napisał(a) w wiadomo¶ci:
<732in2$r0r$1_at_nospam_gemini.webcorp.com.pl>...
Jeżeili facet zdecydował się na AT89C2051 (i to nie koniecznie z największ±
częstotliwo¶ci±) to chyba nie zamirzał liczyć całęk podczas transmisji.
Liczył się z możliwo¶ciami tego uC. Obsługa wysyłania danych moim sposobem
z
omawian± prędko¶ci± zabiera ok. 15 procent mocy obliczeniowej. I to ma
spowodować niemożno¶ć wykonania pozostałych zamierzonych przez pytaj±cego
operacji??:{
Nie wiem czy sie rozumiemy, ale skoro ci 115200 potrzebne to znaczy, ze
zalezy ci na szybkosci. Ale po co ustawiac na 115,2 skoro chcesz robic
przerwy miedzy bajtami ?
Po co ci taki szybki impuls skoro mozesz to samo wysylac znacznie wolniej?
skok do procedury to 4 cykle czyli juz jest 12
Po druge specjalnie napisałem:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ;
razem 7 cykli
Gdyby¶ nawet nie zauważył dyrektywy ORG i maksymalnej liczby cykli
potrzebnych na to aby IP znalazł się w tym miejscu to i tak 7+4=11 a nie
12.
Dobra dobra to jest wysylanie - a co z ronoczesnym odczytem ? Samo sie
odczyta z SBUF ? Ja tylko staram sie wyjasnic moj ponkt widzenia na
rownoczesna transmisje asynchroniczna przy 115,2. Nadawac to sobie mozna ale
juz rownoczesnie odbierac i cos z tym robic po drodze i nie robic przerw to
juz niewykonalne.
Aby zachowac przepustowosc do maximum musisz po bicie stopu zaraz miec bit
startu nastepnej ramki, a tego nie zrobisz przy 115200 jesli masz jeszcze
cos innego do roboty, bo zasze ci sie beda bity opuszczac po drodze.
Bedziesz robil przerwy miedzy bajtami.
Tak jak napisalem bez wzgledu na priorytet - jezeli przerwanie jakiekolwiek
wyskoczylo w trakcie tych 16 cykli, to juz musi sie niestety skonczyc zanim
bedzie obsluzone to od UARTU. Tracisz czas - tracisz bit.
I z tych 115200 bedziesz mial tylko impulsy o szerokosci jak dla 115,2 a
faktycznie to porobia sie przerwy miedzy ramkami - nadawanymi bajtami. A
wszystko to przez brak bufora dla TXD
Zreszta o czym my tu dyskutujemy. Zalezy do czego komu to jest potrzebne :)
Jak komus takie cos odpowiada:
8N1 111 8N1 11 8N1 1111
to niech mu bedzie. I jeszcze zapomniales, ze trzeba przetestowac i skasowac
flage informujaca od czego w SBUF bylo przerwanie, czy od RXD czy od TXD -
wiec masz kolejne cykle w plecy. A pamietaj zeby zachowac przepustowosc
musisz w ciagu tych feralnych 16 cyki od przerwania TXD obsluzyc nadawanie
bajtu. na odbior masz czas o dlugosci prawie pelnej raki.
Jak zrobisz fifo to tez ukradniesz cykle po drodze.
Po trzecie: Spowolnienie transmisji to co¶ normalnego(jeżeli już do niej
dojdzie). Trzeba się liczyć z możlowo¶ci± powstawania błędów i zwi±zan± z
nimi obsług± retransmisji.
Trzeba ale nie koniecznie :)) Mozna zrobic to tak, zeby pompowalo jak
ksiazka pisze ale nie na tym procku :)
Ogólnie sprawiasz wrażenie faceta zagubionego w temacie, a do tego
odpisujesz na pytania i odpowiedzi, których wcze¶niej nie czytasz (ja tak
nie potrafię).
Moze ty jestes zagubiony co ? I nie bardzo rozumiesz co mam na mysli ? To ze
sobie radosnie zgarniasz port do bufora UART-u i go wysylasz to po prostu
moze ci sie udalo napisac 50 linijek :)))
Juliusz
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: AT89C2051 i 115200bps
Date: 20 Nov 1998 13:27:00 GMT
On Fri, 20 Nov 1998 11:50:43 GMT, Juliusz <juliusz_at_nospam_wyscigi.multi-ip.com.pl> wrote:
omawian± prędko¶ci± zabiera ok. 15 procent mocy obliczeniowej. I to ma
spowodować niemożno¶ć wykonania pozostałych zamierzonych przez pytaj±cego
operacji??:{
Nie wiem czy sie rozumiemy, ale skoro ci 115200 potrzebne to znaczy, ze
zalezy ci na szybkosci. Ale po co ustawiac na 115,2 skoro chcesz robic
przerwy miedzy bajtami ?
Bo 115200 i 2-3 bity przewwy to nadal jest szybciej niz 57600 :-)
Dobra dobra to jest wysylanie - a co z ronoczesnym odczytem ? Samo sie
odczyta z SBUF ?
Na odczyt masz znacznie wiecej czasu - buforowany jest az na 8 bitow.
I jeszcze zapomniales, ze trzeba przetestowac i skasowac
flage informujaca od czego w SBUF bylo przerwanie, czy od RXD czy od TXD -
wiec masz kolejne cykle w plecy.
Zgadza sie - zapomnial :-)
No chyba ze robi tester wydajnosci sieci i nic nie odbiera, tylko
nadaje :-)
Nawiasem mowiac - jesli juz rozmawiamy o kwarcu 22MHz, to
procesor ma przy 115200 jakies 200 cykli na obsluge kazdego bajtu, czyli
ze 150 instrukcji. To by sie teoretycznie i bufor kolowy dalo zrobic,
i sumy kontrolne sprawdzic i protokol pozamieniac ...
J.
From: "Juliusz" <juliusz_at_nospam_wyscigi.multi-ip.com.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 15:01:56 GMT
J.F. napisał(a) w wiadomości: ...
Widze, ze ty czaisz o co mi chodzi :)))
Bo 115200 i 2-3 bity przewwy to nadal jest szybciej niz 57600 :-)
Jasne, ze szybciej, ale poczytaj dalej ...............
I jeszcze zapomniales, ze trzeba przetestowac i skasowac
flage informujaca od czego w SBUF bylo przerwanie, czy od RXD czy od TXD -
wiec masz kolejne cykle w plecy.
Zgadza sie - zapomnial :-)
Ha, albo nie wiedzial tylko sie popisywal :))
No chyba ze robi tester wydajnosci sieci i nic nie odbiera, tylko
nadaje :-)
Wlasnie - wali w SBUF bez opamietania i w koncu jakis bajt zaskoczy i sie
wysle :)))hahaha :)))
Nawiasem mowiac - jesli juz rozmawiamy o kwarcu 22MHz, to
procesor ma przy 115200 jakies 200 cykli na obsluge kazdego bajtu, czyli
ze 150 instrukcji. To by sie teoretycznie i bufor kolowy dalo zrobic,
i sumy kontrolne sprawdzic i protokol pozamieniac ...
Niby tak ALE: co sie stanie jezeli dane rownolegle beda pompowane do portu
co 160 (16 cykli x 8N1) cykli maszynowych a ty bedziesz opuszczal bit co
ramke ? Ha ? Na jak dlugo starczy ci RAMu na FIFO az zaczniesz dane tracic ?
Nikt mi nie powie, ze okienko z 16-ma cyklami maszynowymi wystarczy aby nie
opuscic bitow po drodze. Nawet podanie danych rownolegle musi byc jakos
sygnalizowane. Albo przez pooling linni portu co jest bez sensu bo zjada
czas w ciasnej petli albo przez INT0 lub INT1 "dostawca" danych
zasygnalizuje, ze wlasnie wystawil bajt rownolegle do portu powiedzmy P1 !!!
A taka ciasna petla przy poolingu (testowanie pinu) to 100% uzycia procesora
! (przypomnienie dla mniej siedzacych w temacie:)
A jak takie przerwanie wyskoczy cykl przed przerwaniem UARTU, ktorego
znaczenie nie jest znane do czasu zdekodowania flag ? To co sie stanie ?
Jeszcze trzeba skasowac flage bo nastepne przerwanie nie wyskoczy !
W takiej sytuacji 2 symultanicznych procesow (RXD>parallel i parallel>TXD)
nalezy dane takie przewalac przez software'owy bufor chocby 2-3 bajty dla
bezpieczenstwa na wypadek rozbieznosci w predkosciach UARTow komputerow i
rozbieznosci w tempie podawania danych. To jak uniknac utraty bitow inaczej
?
Co niby w full duplexie bedziesz zaglowal RTS/CTS i hamowal podawanie danych
czy jakos inaczej dalsza linia portu bedziesz powstrzymywal "tego" co dane
dostarcza ? A moze hamowal komputer zeby sie odwalil na chwilke ze swoimi
danymi ? Przeciez to bzdura, bo w full duplexie nie uzywa sie RTS/CTS, a
powstrzymywanie "dostawcy" danych jest bez sensu albo wrecz niewykonalne.
Zreszta ten tryb uartu temu przeczy.
Amator nie bardzo rozumie zagadnienie. Ja mimo szybkiego procka dodalem
jeszcze CPLD ze 256-ma makrocelami do takiego czegos aby miec pewnosc, ze
transmisja leci poprawnie, obslugiwac dodatkowe uklady, bo nozek zabraklo.
---
Na marginesie - dobra dyskusja sie wywiazala, bo i wielu niedoswiadczonych
sie czegos dowie :))
Juliusz
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: AT89C2051 i 115200bps
Date: 20 Nov 1998 17:58:52 GMT
On Fri, 20 Nov 1998 15:01:56 GMT, Juliusz <juliusz_at_nospam_wyscigi.multi-ip.com.pl> wrote:
[..]
Niby tak ALE: co sie stanie jezeli dane rownolegle beda pompowane do portu
co 160 (16 cykli x 8N1) cykli maszynowych a ty bedziesz opuszczal bit co
ramke ? Ha ? Na jak dlugo starczy ci RAMu na FIFO az zaczniesz dane tracic ?
Mowiac szczerze jak dane sa rownolegle, to zwykle jest jakis mechanizm
wstrzymywania ich doplywu ...
Nikt mi nie powie, ze okienko z 16-ma cyklami maszynowymi wystarczy aby nie
opuscic bitow po drodze.
Na oko jakies 32 cykle przy tym kwarcu ...
A taka ciasna petla przy poolingu (testowanie pinu) to 100% uzycia procesora
! (przypomnienie dla mniej siedzacych w temacie:)
Owszem, ale nie przeszkadzajaca w przyjeciu przerwania.
J.
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 15:27:04 +0100
Widzę, że czujesz MCSki. One mogą naprawdę dużo, tylko trzeba myśleć
przejrzyście i trochę kombinować.
Niedawno ukończyłem projekt centralki telefonicznej 2 linie miejskie i 6
portów wewnętrznych. Zarządza tym zwykły 80C52 z zegarem 12MHz a potrafi
operować na pamięci 128KB (powyżej 64k znajdują się spakowane tablice z
komunikatami słownymi - ok 20 sekund) i jednocześnie może:
- rozpakowywać komunikaty słowne i generować je (na żywo) przez przetwornik
CA do abonentĂłw ( komunikaty w stylu ,,rozmowa miejska'', ,,proszÄ™ czekac
będzie rozmowa'' itp.)
- generować (też przez przetwornik) sygnały wybiercze DTMF
- odbierać sygnały wybiercze od abonentów w systemie impulsowym i tonowym
- wysyłać sygnały wybiercze na centrale nadrzędne
- przekazywac połączenia, zestawiac konfwrencje, zamawiac połączenia
- dyskryminować prefiksy
- wykrywac automatyczne połączenia faksowe
- powiadamiać o włamaniu do budynku itp. itd.
Na dodatek program jest napisany w konwencji wielozadaniowej (dochodzi
przełączanie zadań, zarządzanie pamięcią i dostępem do portów). Juliusz to
by pewnie zastosował Pentium MMX 200 (albo dwa) (bez obrazy ;)
Serdecznie pozdrawiam
Maciej
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Maciej Adamski" <iksmada_at_nospam_friko4.onet.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 14:20:48 +0100
Juliusz napisał(a) w wiadomo¶ci: ...
Maciej Adamski napisał(a) w wiadomo¶ci:
<732in2$r0r$1_at_nospam_gemini.webcorp.com.pl>...
Jeżeili facet zdecydował się na AT89C2051 (i to nie koniecznie z
największ±
częstotliwo¶ci±) to chyba nie zamirzał liczyć całęk podczas transmisji.
Liczył się z możliwo¶ciami tego uC. Obsługa wysyłania danych moim sposobem
z
omawian± prędko¶ci± zabiera ok. 15 procent mocy obliczeniowej. I to ma
spowodować niemożno¶ć wykonania pozostałych zamierzonych przez pytaj±cego
operacji??:{
Nie wiem czy sie rozumiemy, ale skoro ci 115200 potrzebne to znaczy, ze
zalezy ci na szybkosci. Ale po co ustawiac na 115,2 skoro chcesz robic
przerwy miedzy bajtami ?
Po co ci taki szybki impuls skoro mozesz to samo wysylac znacznie wolniej?
Nie potrafię zrozumiec jak z powyższego tekstu wyci±gn±łe¶ wniosek, że
zamierzam robić przerwy między bajtami. Napisałem o 15% spadku mocy
obliczeniowej a nie prędko¶ci transmisji. Przerw nie ma! A nawet jeżeli
wprowadziłbym specjalnie jeden bit przerwy to i tak prędko¶ć spadłaby o 10%.
Natomiast gdyby¶ chciał wysył±ć to wolniej to następna prędko¶ć w szeregu to
57600 a to już 50% wolniej. Różnica jest, co?
skok do procedury to 4 cykle czyli juz jest 12
Po druge specjalnie napisałem:
ORG 0023H ; przyjęcie przerwania max 4cykle
AJMP RS232 ; 2 cykle
RS232:
MOV SBUF,WcześniejPrzygotowanyBajt ; 1 cykl ;
razem 7 cykli
Gdyby¶ nawet nie zauważył dyrektywy ORG i maksymalnej liczby cykli
potrzebnych na to aby IP znalazł się w tym miejscu to i tak 7+4=11 a nie
12.
Dobra dobra to jest wysylanie - a co z ronoczesnym odczytem ? Samo sie
odczyta z SBUF ? Ja tylko staram sie wyjasnic moj ponkt widzenia na
rownoczesna transmisje asynchroniczna przy 115,2. Nadawac to sobie mozna
ale
juz rownoczesnie odbierac i cos z tym robic po drodze i nie robic przerw to
juz niewykonalne.
Aby zachowac przepustowosc do maximum musisz po bicie stopu zaraz miec bit
startu nastepnej ramki, a tego nie zrobisz przy 115200 jesli masz jeszcze
cos innego do roboty, bo zasze ci sie beda bity opuszczac po drodze.
Bedziesz robil przerwy miedzy bajtami.
Tak jak napisalem bez wzgledu na priorytet - jezeli przerwanie jakiekolwiek
wyskoczylo w trakcie tych 16 cykli, to juz musi sie niestety skonczyc zanim
bedzie obsluzone to od UARTU. Tracisz czas - tracisz bit.
I z tych 115200 bedziesz mial tylko impulsy o szerokosci jak dla 115,2 a
faktycznie to porobia sie przerwy miedzy ramkami - nadawanymi bajtami. A
wszystko to przez brak bufora dla TXD
Dlaczego ty chcesz z każdym bajtem od razu co¶ robić. Transmisja szeregowa
jest transmisj± o błędzie niezerowym. W odróżnieniu na przykład od
transmisji po magistrali systemowej, gdzie zakłada się, że dane przechodz±
zawsze, a jeżeli pojawi się odpowiednio silne zakłucenie to sysetm po prost
się najczę¶ciej zawiesza albo robi bzdury. Przy transmisji RS przesyła się
nie pojedyncze bajty ale ramki zakończone sum± kontroln± po kilka,
kilkadziesi±t, kilkaset, albo kilka tysięcy bajtów. Bajty te przesyłasz do
bufora jeden za drugim obliczaj±c na bierz±co co najwyżej sumę kontroln±. Po
przesłaniu ramki sprawdzasz t± sumę co zajmuje jaki¶ tam czas i niech nawet
z tego powodu transmisja na chwilę będzie przerwana. I tak efektywna
prędko¶ć spada nieznacznie dużo dużo mniej niż 1% poniżej 115200.
Jeżeli ty stosujesz metodę PIZ (prze¶lij i zapomnij) to ja nie chcę z twoimi
urz±dzeniami mieć nic doczynienia(bardzo niestabilne systemy).
Zreszta o czym my tu dyskutujemy. Zalezy do czego komu to jest potrzebne :)
Jak komus takie cos odpowiada:
I tutaj zgadzam się z tob± kolego całkowicie. Jest okazja, aby
zaapelować do wszystkich pytaj±cych aby na¶wietlali w swoich listach trochę
więcej szczegółów. Pozwoli to rozwi±zywać problemy w znacznie szerszy
kontek¶cie. Nie będzie podobnych nieporozumień.
I jeszcze zapomniales, ze trzeba przetestowac i skasowac
flage informujaca od czego w SBUF bylo przerwanie, czy od RXD czy od TXD -
wiec masz kolejne cykle w plecy. A pamietaj zeby zachowac przepustowosc
musisz w ciagu tych feralnych 16 cyki od przerwania TXD obsluzyc nadawanie
bajtu. na odbior masz czas o dlugosci prawie pelnej raki.
TI mogę zerować po wpisaniu do SBUF, a więc nie ma obawy o dodatkowy
powód do zgubienia bitu.
Ostateczne rozwianie twoich w±tpliwo¶ci (działaj±cy układ) było w P.S.
Pozdrawiam
Maciej
--
Serwis RUBIKON - http://rubikon.pl - 020 92 47
From: "Filip R. Zawadiak" <philz_at_nospam_wasko.gliwice.pl>
Subject: Re: AT89C2051 i 115200bps
Date: Fri, 20 Nov 1998 10:12:28 +0100
rubikon_at_nospam_fema.krakow.pl wrote:
Czesc !
Da sie bez problemu z kwarcem 22.1184 MHz. Uzywam tego procesora do
komunikacji z innym modulem i dziala bez zarzutu juz od ponad roku.
Konwertuje dane z portu rownoleglego (2 x po 4 bity + linie
potwierdzajace ) na transmisje szeregowa (i odwrotnie). Dodatkowo
buforuje dane. Kwarc mozna kupic w Eurodisie za 1.66 zl. netto.
Ewentualnie moge podeslac jedna, dwie sztuki (jesli tyle jest
potrzebne), bo kupuje od nich w hurtowych ilosciach.
O dzieki :) Zapisalem sobie :)
A tak naprawde to sam nie wiem jeszcze dokladnie na czym chce dzialac...
Jak na razie do wyboru sa atmele, avr i pice :)
Tak powoli zaczynam sie sklaniac ku PIC1663 i 12CE509...
Moze jakies namiary na strony z porownaniami ? Zeby listy nie zasmiecac
;)
--
Filip R. Zawadiak (Philz) http://vyx.net/~philz
Isaac is alive ! mailto:philz_at_nospam_vyx.net
From: rubikon_at_nospam_fema.krakow.pl
Subject: Re: AT89C2051 i 115200bps
Date: Thu, 19 Nov 1998 21:54:06 GMT
Czesc !
Da sie bez problemu z kwarcem 22.1184 MHz. Uzywam tego procesora do
komunikacji z innym modulem i dziala bez zarzutu juz od ponad roku.
Konwertuje dane z portu rownoleglego (2 x po 4 bity + linie
potwierdzajace ) na transmisje szeregowa (i odwrotnie). Dodatkowo
buforuje dane. Kwarc mozna kupic w Eurodisie za 1.66 zl. netto.
Ewentualnie moge podeslac jedna, dwie sztuki (jesli tyle jest
potrzebne), bo kupuje od nich w hurtowych ilosciach.
Pozdrowienia
RUBIKON
Tomasz Ptaszynski
"Filip R. Zawadiak" wrote:
Witam,
da sie tyle wyciagnac ? I na jakiej czestotliwosci zegara ?
--
> Filip R. Zawadiak (Philz) http://vyx.net/~philz
> Isaac is alive ! mailto:philz_at_nospam_vyx.net