🚀 go-pugleaf

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> W full duplexie nie ma, ale w half duplexie jest.
> I do tego sluzy linia RTS ... czy raczj sluzyla ..

Który modem działa (na odcinku DTE-DCE) w half-dupleksie?

> V.24 circuit 133, RS-232 circuit CJ, DB-25 pin 4.

>> The ON condition on Circuit CJ (Ready for Receiving) indicates that the
>> DTE is capable of receiving data.
>
> Wow - nazwe zmienili? I numer obwodu?

Raczej dodali. Modemy ze sprzętowym handshakingiem pojawiły się
mniej-więcej w czasach, gdy upadał PRL. "Nowy" RTS jest w RS-232
z 1991 r. (wersja z 1986 r. jeszcze tego nie ma). Rekomendacja V.24
miała to od początku (pierwsza oficjalna wersja z 1988 r).

>> The OFF condition indicates that the DTE is not capable of receiving
>> data and causes the DCE, or the intermediate function, to retain the
>> data. In some DCEs the OFF condition on Circuit CJ (Ready for Receiving)
>> also causes a signal to be transmitted to the distant DTE causing an OFF
>> condition to be placed on Circuit CB (Clear to Send) extending the flow
>> control to distant DTE.
>
> Fajne, ale "in some".

Przecież to nie jest norma ustalająca działanie modemów, pokazuje tylko
(wtedy i dziś) istniejącą sytuację na styku DCE-DTE.
W praktyce hw flow control między modemami działa z MNP/V.42 zawsze.
W połączeniu transparentnym nie ma jak przekazać drugiej stronie
informacji o konieczności wstrzymania transmisji.

>> Nie, 8250 ani 16450 nie były "wystarczająco szybkie". To były scalaki
>> podpięte do szyny ISA (a właściwie XT-BUS), czasy dostępu (zwłaszcza
>> 8250) typu setek ns, były w stanie "zbuforować" ok. jednego bajta
>> danych, co oznaczało - przy np. szybkości 115200 bps - kilkadziesiąt,
>> a przynajmniej kilkanaście tysięcy przerwań/sekundę. I to pod warunkiem,
>> że opóźnienie obsługi nie przekroczy kilkudziesięciu us (dolicz do tego
>> zależności czasowe generowane np. przez twarde dyski). 
>
> Opoznienie o jeden czy nawet 2 bajty, czyli 100-200us tolerowane.

Nie.

Przy 115200 bps transmisja jednego znaku trwa ok. 87 us.

Powiedzmy, że odebrałeś znak w chwili T. Nie wiem jakie dokładnie
były dodatkowe opóźnienia wewnątrz 8250/16450, ale nawet zakładając, że
ich nie było: w chwili T otrzymywałeś też sygnał IRQ i CPU komputera
łaskawie zaczynał (albo i nie) obsługę przerwania. W tym samym czasie
odbiornik zaczynał odbieranie kolejnego znaku do swojego rejestru
przesuwnego.
Nowy znak był gotowy w rejestrze przesuwnym w chwili T + 87 us (nieco
wcześniej, bo scalak nie czekał do samego końca bitu stop). Jeśli nie
zdążyłeś odebrałeś znaku z bufora - to sorry, bufor nie mógł pomieścić
jednocześnie obu znaków. Ciesz się, że w ogóle był bufor, bo inaczej
musiałbyś odebrać znak z rejestru przesuwnego, np. w czasie między
ostatnim próbkowaniem bitu STOP i oraz początkiem START :-)

> A dyski byly przerywalne.

Przez kogo? Dyski (IRQ 14 i 15) miały wyższy priorytet od portów
szeregowych (IRQ 3 i 4, czasem także 5 i 7).
Ze specjalną kartą z IRQ 9 (IRQ 2 w nomenklaturze XT BUS), to może tak.
Co ciekawe, pamiętam, że kiedyś miałem kabel z karty modemowej
(z headera do ustawiania przerwań) do karty (chyba) VGA (to przerwanie
było wtedy często zbędne). Ale nie pamiętam dokładnie szczegółów, może
chodziło po prostu o wolne przerwanie.

W każdym razie temat pracy dysków vs gubienie znaków na RS-232 to była
norma na różnych forach w tamtych czasach (później z modyfikatorami "IO
CHRDY" i "bus mastering IDE" w czasach Tritona (a pewnie także wcześniej
w czasach Saturna itp)).

>> To po prostu nie miało prawa działać, 
>
> Tyle, ze działało :-)

To w jakiejś równoległej rzeczywistości.
Albo w takiej opcji, że program transmitował dane w pollingu
z wyłączonymi przerwaniami (na chwilę, np. na czas transmisji bloku).
Jak zapewne pamiętasz, były takie rozwiązania (np. IIRC Norton Commander
4 mógł tak robić) - po coś chyba istniały?

>> Praktyka była taka, że 16450 działały "od biedy" @ 38400 bps, natomiast
>> 8250 @ 9600 bps (albo i nie) - to ostatnie mogło być spowodowane nie
>
> Moze w jakim linuxie, u mnie zawsze chodzilo na 115200.
> Nawet w linuxie.

Na jakim komputerze i w którym roku???

Na tej samej zasadzie ja portem równoległym ściągałem dane z magistrali
SPI (czy jakiejś tam podobnej) z gwarantowanym samplingiem < 1 us.
Wystarczyło (w dwurdzeniowym CPU) zablokować jeden rdzeń. Ale to raczej
nie znaczy, że port równoległy w pececie jest wystarczająco szybki do
takich celów.

>> tylko samym scalakiem, ale także konstrukcją karty wieloportowej, której
>> używałem (jednakże 8250 były wolniejsze i mogły wymagać dodatkowych wait
>> statów na ISA itp).
>
> Jak miales jakas dziwną kartę, to oczywiscie tak.

Ale co w niej było dziwnego? 8250 był wolniejszy od 16450, wait staty
mogły być niezbędne.

> Pamietam takie zagadnienie  16 portow, 9600, ale na 8080.
> No i ktos podobnie policzyl, ze to nie ma prawa dzialac na
> przerwaniach, wiec przerwanie bylo jedno, co 0.5ms, w przerwaniu
> sprawdzane wszytkie porty, zapisywane do buforow ... i dzialalo.

2000 przerwań/sekundę. Krótkie przerwania, niewiele rejestrów do
odłożenia na stos (i zdjęcia z niego), i to tylko 9600 bps.
A Ty chcesz 115200 bps, na (w tamtych czasach typowo) jakimś 386DX-25
z pipelined RAM :-)
2000 przerwań/sekundę byłoby problemem dla tamtego peceta. Ale może
pokonywalnym. Natomiast 20 tysięcy przerwań/sekundę by go zabiło.

No i nie twierdzę, że tak by się w ogóle nie dało zrobić. Ale pecet to
był komputer uniwersalny, nie miał marnować 50% CPU na polling portów.
Sam procesor kosztował setki dolców, nie lepiej było kupić za grosze
kartę z 16550A (albo tylko samego scalaka i wymienić)?

> A moze ... brak przerwania od TE? 
> Wpisujesz ostatni bajt, za chwile przjdzie przerwanie THRE, 
> wtedy juz nie bedzie nic do wyslania ... ale uart ciagle wysyla.
> I trzeba sprawdzac, kiedy sie zakonczy.

Tak właśnie było, ale to 100 razy mniej istotny problem (jeśli w ogóle
był to problem).

To przerwanie służyło do poinformowania CPU o tym, że może wysyłać
kolejny bajt, i nic nie mówiło o tym, co się dzieje na wyjściu.
Dodatkowo przerwanie jakiego chcesz byłoby typowo bezużyteczne, ponieważ
zwykle HD DCE nie mogły zdjąć sygnału z linii natychmiast po bicie STOP,
musiały nieco odczekać (w przeciwnym przypadku często pojawiały się
przekłamania, które np. rozwiązywano programowo transmitując dodatkowy
bajt - miałem raz coś takiego na RS-485). Wszystko razem powodowało, że
i tak konieczne było sprzętowe rozwiązanie (oczywiście HD DCE to było
sprzętowe rozwiązanie).

>> Połączenie DCE-DTE raczej nigdy nie było wolniejsze niż DCE-DCE.
>
> BYlo takie samo, zanim sie pojawily smartmodemy.

No raczej. Jak "dumb" modemy miałyby realizować jakikolwiek flow
control?

>> To działało, bo po prostu handshaking RTS/CTS działał.
>
> IMHO - dzialalo, bo komputery byly szybkie.

To sprawa względna, dla mnie zawsze były za wolne.

W każdym razie z całą pewnością 16450 itp. sprawiały problemy z modemami
V.32 i szybszymi i można ich było używać z szybkością max 38400 bps
(chociaż oczywiście w pollingu działały i @ 115200).
Po wymianie na 16550A lub nowszego scalaka (były praktycznie
kompatybilne pin-pin) problem magicznie znikał. Z tym samym komputerem,
rzecz jasna.
Np. typowe karty RS-232 (wtedy raczej nie było jeszcze tych portów na
płycie głównej) miały wlutowanego 16450 oraz podstawkę na drugiego
scalaka. Można tam było włożyć 16550A i nowsze scalaki, niektóre miały
jeszcze dłuższe FIFO. Były też specjalne karty od razu z odpowiednim
scalakiem, wieloportowe itp.

> Jak widac, cos tam w definicji zmienili, ale czy wszystkie modemy 
> to respektowały?

Nie. Tylko te prawidłowo skonfigurowane.
BTW domyślna konfiguracja była często niewłaściwa, stąd tematy
o "init stringach".
-- 
Krzysztof Hałasa