Dnia 2015-04-01, o godz. 07:42:28
s...@g...com napisał(a):
> Na innym PC, to samo. Znalazłem też takie coś spoza FTDI, ale nie
> obsługuje akurat tej kostki.
>
> http://www.intra2net.com/en/developer/libftdi/
>

Na wstępie witam całą grupę !

Nie prawda, że libftdi nie wspiera FT2232H:

http://developer.intra2net.com/git/?p=libftdi;a=blob
_plain;f=README;hb=HEAD

Od dłuższego czasu używam FT2232H (tryb asynchroniczny) + libftdi. W
pierwszej wersji korzystałem z binding'ów do python'a, teraz mam już
wszystko przepisane na natywne C. System operacyjny: Linux.
Tryb synchroniczny FIFO jest również wspierany przez libftdi dla
FT2232H, w źródłach masz nawet przykład:

http://developer.intra2net.com/git/?p=libftdi;a=blob
_plain;f=examples/stream_test.c;hb=HEAD

Wydajność z tego co piszą ludzie (nie robiłem porównania osobiście)
jest trochę gorsza niż binarne d2xx ale w zamian masz:
- dostęp do całego kodu źródłowego: kernel + libusb + libftdi
- bezproblemowe i stabilne działanie na mips/arm - to akurat dla mnie
warunek konieczny

Korzystając z dołączonych przykładów, ogarnięcie w python'ku libftdi +
FT2232H to jeden dłuższy wieczór.

Jeżeli chodzi o samo opóźnienie to nic takiego nie zauważyłem. Wiadomo
działamy w userspace więc coś tam może się przytkać i zbuforować, ale
to raczej dziesiątki-max setki ms, przy mocno obciążonym systemie. W
takim układzie zadziała handshake sprzętowy po stronie ftdi - nie dasz
rady do niego pisać. Sprawdzone w praktyce, ale tj pisałem w trybie
asynchronicznym.

--
Pozdrawiam
Michał Semeniuk