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

do góry

W dniu czwartek, 2 kwietnia 2015 02:38:07 UTC+2 użytkownik Michał Semeniuk napisał:
> 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ę !

Witaj !!

>
> Nie prawda, że libftdi nie wspiera FT2232H:
>
> http://developer.intra2net.com/git/?p=libftdi;a=blob
_plain;f=README;hb=HEAD

Ano być moxe masz rację. Ja "zabazowałem" na tym co znalażłem (link w poprzednim moim
wpisie)

>
> 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)

Zrób, jak coś sensownego wyjdzie, to się dogadamy w sprawach finansowych.

>
> Jeżeli chodzi o samo opóźnienie to nic takiego nie zauważyłem.

Jak to sprawdzałeś ?

do góry

W dniu środa, 1 kwietnia 2015 15:46:50 UTC+2 użytkownik J.F. napisał:
> Użytkownik napisał w wiadomości
> >Wracając do tematu, to opóźnienie wygląda tak, jakby w pamięci peceta
> >tworzył się FIFO o n-krotnej pojemności rozmiaru pojedyńczego frame'a
> >akwizycji (16KB).
>
> Chyba jak najbardziej mozliwe, trzeba by sie doczytac opisu drivera.
> Z tym, ze powinies go tez szybko oproznic, skoro przetwarzanie jest
> szybkie.

No w końcu mnie zrozumiałeś!! Zdarza się, że czasami zbyt "zawile" opisuję problemy.
Zacznijmy od dokumentacji:

1) datasheet:

http://www.ftdichip.com/Support/Documents/DataSheets
/ICs/DS_FT2232H.pdf

Ot, takie pierdulamenty jak to pospawać, jakie tryby są możliwe, etc..

2) D2XX Programmer's Guide:

http://www.ftdichip.com/Support/Documents/ProgramGui
des/D2XX_Programmer%27s_Guide%28FT_000071%29.pdf

Na stronie 18 masz opisaną funkcję FT_READ. Ano z niej korzystam !!

3) No i dokumentacja trybu jakiego używam:

http://www.ftdichip.com/Support/Documents/AppNotes/A
N_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20M
ode.pdf

====================

No i rva jego mać, zaczynam mieć tego dosyć!! Zbyt długo się w tym ciapram.
Na ChipScopie(XILINX) wszystko zapindala jak se Stachu zaplanował..

Wracając do głównego wątka.. Pytanie do WSZYSTKICH, aktywnych w tym wątku:

Jaka inna kostka? Może jakiś Cypress?

> No i powinny byc dane od razu do dyspozycji, a o ile rozumiem po
> prierwszym uruchomieniu programu odbierajacego mamy sekunde czekania.
>
> Z drugiej banki - a moze urzadzenie za malo wysyla ?
> Jak rozumiem to w programie czytasz potrzebna ilosc bajtow ... i wedle
> opisu funkcja czeka az tyle naplynie.
> Jesli naplywa powoli, to czekamy.
>
> Tylko wtedy na koncu nie ma pobierania danych z bufora.
>
> J.

do góry

W dniu czwartek, 2 kwietnia 2015 23:29:07 UTC+2 użytkownik s...@g...com napisał:

> http://www.ftdichip.com/Support/Documents/ProgramGui
des/D2XX_Programmer%27s_Guide%28FT_000071%29.pdf
>
> Na stronie 18 masz opisaną funkcję FT_READ. Ano z niej korzystam !!
>
> 3) No i dokumentacja trybu jakiego używam:
>
> http://www.ftdichip.com/Support/Documents/AppNotes/A
N_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20M
ode.pdf
>

A jak masz ustawione Timeouty ? i co ważniejsze parametry USB funkcja
FT_SetUSBParameters....
Moze zerknij tutaj:
http://www.ftdichip.com/Support/Documents/AppNotes/A
N232B-03_D2XXDataThroughput.pdf

2m

do góry

W dniu piątek, 3 kwietnia 2015 01:23:59 UTC+2 użytkownik 2m napisał:
> W dniu czwartek, 2 kwietnia 2015 23:29:07 UTC+2 użytkownik s...@g...com
napisał:
>
> > http://www.ftdichip.com/Support/Documents/ProgramGui
des/D2XX_Programmer%27s_Guide%28FT_000071%29.pdf
> >
> > Na stronie 18 masz opisaną funkcję FT_READ. Ano z niej korzystam !!
> >
> > 3) No i dokumentacja trybu jakiego używam:
> >
> > http://www.ftdichip.com/Support/Documents/AppNotes/A
N_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20M
ode.pdf
> >
>
> A jak masz ustawione Timeouty ? i co ważniejsze parametry USB funkcja
FT_SetUSBParameters....

Timeouty są ustawione na maxa. Na 256ms. Dlaczego na aż tyle? Moje badziewie robi
akwizycję przez 60ms. Dopóki nie zakończy, to pomimo wysłanego sygnału TXE# ze strony
FT2232H, sygnał WR# jest w stanie '1'. I to działa! Bo gdyby nie działało, to cała
synchronizacja poszła by się paść.

> Moze zerknij tutaj:
> http://www.ftdichip.com/Support/Documents/AppNotes/A
N232B-03_D2XXDataThroughput.pdf
>
Znam to!! Nie chodzi mi o prędkość transmisji, bo owa jest zarąbista. Nie mierzyłem
precyzyjnie, ale z całą pewnością >30MB/s. Ale nie w tym rzecz!!

Przeczytaj główny wątek jeszcze raz, dyskusję z Kolegami, bo nie chce mi się po raz
setny tłumaczyć w czym problem.

do góry

> Przeczytaj główny wątek jeszcze raz, dyskusję z Kolegami, bo nie chce mi się po raz
setny tłumaczyć w czym problem.

Czytałem.
Czy i na jaką wartość masz ustawiony parametr dwInTransferSize w funkcji
FT_SetUSBParameters ?

2m

do góry

W dniu piątek, 3 kwietnia 2015 04:41:16 UTC+2 użytkownik 2m napisał:
> > Przeczytaj główny wątek jeszcze raz, dyskusję z Kolegami, bo nie chce mi się po
raz setny tłumaczyć w czym problem.
>
> Czytałem.
> Czy i na jaką wartość masz ustawiony parametr dwInTransferSize w funkcji
FT_SetUSBParameters ?
>
> 2m

16K

do góry

W dniu piątek, 3 kwietnia 2015 13:10:24 UTC+2 użytkownik s...@g...com napisał:
> W dniu piątek, 3 kwietnia 2015 04:41:16 UTC+2 użytkownik 2m napisał:
> > > Przeczytaj główny wątek jeszcze raz, dyskusję z Kolegami, bo nie chce mi się po
raz setny tłumaczyć w czym problem.
> >
> > Czytałem.
> > Czy i na jaką wartość masz ustawiony parametr dwInTransferSize w funkcji
FT_SetUSBParameters ?
> >
> > 2m
>
> 16K

Moim zdaniem powinieneś pomanipulować tą wartością uwzględniając to, że dane są
przesyłane w 64bajtowych pakietach (endpoint size) i w każdym pakiecie USB 2 bajty są
zarezerwowane przez FTDI.
Czyli dwInTransferSize powinien być:
A) wielokrotnością 64
B) jego wartość powinna uwzględniać TwojDane + wspomniane 2 bajty na pakiet.
Wtedy będzie to transakcja. Host Controller Driver robi sheduling USB optymalizowny
na transakcje. (UHCI OHCI EHCI każdy z nich stosuje różne algorytmy).
Twój przypadek pasuje mi do sytuacji kiedy TwojeDane nie mieszczą się w jednej
transakcji i stąd powstaje opóźnienie.
Daj znać jeśli trafiłem.
2m

do góry

W dniu 2015-04-02 o 23:29, s...@g...com pisze:
> W dniu środa, 1 kwietnia 2015 15:46:50 UTC+2 użytkownik J.F. napisał:
>> Użytkownik napisał w wiadomości
>>> Wracając do tematu, to opóźnienie wygląda tak, jakby w pamięci peceta
>>> tworzył się FIFO o n-krotnej pojemności rozmiaru pojedyńczego frame'a
>>> akwizycji (16KB).
>>
>> Chyba jak najbardziej mozliwe, trzeba by sie doczytac opisu drivera.
>> Z tym, ze powinies go tez szybko oproznic, skoro przetwarzanie jest
>> szybkie.
>
> No w końcu mnie zrozumiałeś!! Zdarza się, że czasami zbyt "zawile" opisuję
problemy. Zacznijmy od dokumentacji:
>
> 1) datasheet:
>
> http://www.ftdichip.com/Support/Documents/DataSheets
/ICs/DS_FT2232H.pdf
>
> Ot, takie pierdulamenty jak to pospawać, jakie tryby są możliwe, etc..
>
> 2) D2XX Programmer's Guide:
>
> http://www.ftdichip.com/Support/Documents/ProgramGui
des/D2XX_Programmer%27s_Guide%28FT_000071%29.pdf
>
> Na stronie 18 masz opisaną funkcję FT_READ. Ano z niej korzystam !!
>
> 3) No i dokumentacja trybu jakiego używam:
>
> http://www.ftdichip.com/Support/Documents/AppNotes/A
N_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20M
ode.pdf
>
> ====================
>
> No i rva jego mać, zaczynam mieć tego dosyć!! Zbyt długo się w tym ciapram.
> Na ChipScopie(XILINX) wszystko zapindala jak se Stachu zaplanował..
>
> Wracając do głównego wątka.. Pytanie do WSZYSTKICH, aktywnych w tym wątku:
>
> Jaka inna kostka? Może jakiś Cypress?
Wtrącę swoje 3 grosze, mam kupiony analizator stanów logicznych Saleae i
też się nie wyrabia, teoretycznie powinien samplować 24M a ja w porywach
osiągam 500k, jak poczytałem to podobno wina sterowników usb które w
jakiś sposób się gryzą i zabagnionego windowsa, tyle że ja nie mam
zabagnionego a mimo to się nie wyrabia, więc wychodzi kicha, może
postawię czystego XP i spróbuję znowu.
Więc zastanów się zanim sięgniesz po cypressa bo może się okazać że ma
tak samo złe drivery usb jak reszta.


--
Pozdr

Janusz_K

do góry

W dniu piątek, 3 kwietnia 2015 16:21:10 UTC+2 użytkownik 2m napisał:
> W dniu piątek, 3 kwietnia 2015 13:10:24 UTC+2 użytkownik s...@g...com napisał:
> > W dniu piątek, 3 kwietnia 2015 04:41:16 UTC+2 użytkownik 2m napisał:
> > > > Przeczytaj główny wątek jeszcze raz, dyskusję z Kolegami, bo nie chce mi się
po raz setny tłumaczyć w czym problem.
> > >
> > > Czytałem.
> > > Czy i na jaką wartość masz ustawiony parametr dwInTransferSize w funkcji
FT_SetUSBParameters ?
> > >
> > > 2m
> >
> > 16K
>
> Moim zdaniem powinieneś pomanipulować tą wartością uwzględniając to, że dane są
przesyłane w 64bajtowych pakietach (endpoint size) i w każdym pakiecie USB 2 bajty są
zarezerwowane przez FTDI.
> Czyli dwInTransferSize powinien być:
> A) wielokrotnością 64
> B) jego wartość powinna uwzględniać TwojDane + wspomniane 2 bajty na pakiet.
> Wtedy będzie to transakcja. Host Controller Driver robi sheduling USB optymalizowny
na transakcje. (UHCI OHCI EHCI każdy z nich stosuje różne algorytmy).
> Twój przypadek pasuje mi do sytuacji kiedy TwojeDane nie mieszczą się w jednej
transakcji i stąd powstaje opóźnienie.
> Daj znać jeśli trafiłem.
> 2m

Nawet nie podchodzę do Twoich sugestii, bo są bezsensowne. To o czym piszesz ma wpływ
na całkowitą prędkość transmisji, a nie na buforowanie "w stylu FIFO"

do góry