On 2011-08-24 10:25, Pawel "O'Pajak" wrote:
> krotko mowiac ani program, ani urzadzenie nie wie, ze po
> drodze ma jakas przejsciowke.

Diabeł tkwi w szeczegółach:

a) poziomy napięć są przeróżne, od prawidłowych, przez zbyt niskie (np.
nadawanie +/- 5V) po asymetryczne odwrócone ( czyli 0 i 5V jako 0 i 1
..). Wola amerykanka osiągająca poziom absurdu kiedy na opakowaniu jest
RS232C a w rzeczywistości mamy TTLowy UART (bo działa z telefonami i
dres nie widzi różnicy).

b) Timeouty jakie można ustawić w windowsie na przelotkach prolific z
nieznanej przyczyny mogą być minimalnie 20ms (podobnie z resztą na FT).
Poniżej tego tępacki driver olewa timeouty (!) i ustawia jakieś default
w okolicy 100ms. Tak działa na WinXP i Win7 z kilkoma sterownikami. Być
może to wina samego windowsa. Linux radzi sobie o rząd wielości lepiej.

c) Prolific przy dużych obciązeniach (duże ilości danych na max
prędkościach) zaczyna się gubić, potrafią wylatywać pojedyncze bajty z
bufora nadajnika. Być może to wina niedorobionych sterowników.
Kosztowało mnie to kilkanascie dni debugowania.

d) Niektore steorwniki Prolific generują śliczny BSOD w trakcie pracy.
Ostatnio żadko, ale trafia się.

e) Pooling danych w odbiorniku czasem się zatrzymuje na dziesiątki
milisekund diabli wiedza po co. Może taka specyfika USB.

Używam tych przelotek w zadaniach sterowania w przemyśle. Przeszlo mi
ich kilkanascie typów przez palce. Wieksza część miala kierunek kosz ze
względu na oczywiste wady które przekreślają nazwę RS232C z opakowania.
Najwięcej problemów jest z przelotkami ktore z premedytacują generują
zbyt niskie napięcia, albo co gorsza niesymetryczne względem masy.
Zazwyczaj nie dzialają i już. Ale mam też kilka które działają
zadowalająco. Loteria.