Opóźnienie w transmisji USB przy demodulacji AM w prototypie z FPGA i FT2232H

Wed Apr 01, 2015 10:02 am   

On 2015-03-31 21:19, stchebel@gmail.com wrote:

FIFO w trybie synchronicznym i czasem gubi bajty. Errata bardzo
lakonicznie o tym wspomina. Mógłby to być jakiś trop.

Adam

Wed Apr 01, 2015 1:14 pm   

On 2015-04-01 14:08, stchebel@gmail.com wrote:

Czyli raczej z hw strony nie ma się czego przyczepić.

1. Ok. Czy masz jakiś alternatywny soft do odbioru danych ? Może FTDI
coś dostarcza ?
2. Inny PC, inne sterowniki ?

Nie chcę mi się wierzyć że podstawowa funkcjonalność ma takie problemy.

Adam

Wed Apr 01, 2015 1:46 pm   

Użytkownik napisał w wiadomości

Chyba jak najbardziej mozliwe, trzeba by sie doczytac opisu drivera.
Z tym, ze powinies go tez szybko oproznic, skoro przetwarzanie jest
szybkie.
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.

Wed Apr 01, 2015 2:08 pm   

W dniu środa, 1 kwietnia 2015 12:02:17 UTC+2 użytkownik Adam Górski napisał:

Akurat mój młody dał radę odczytać ze scalaka. Są poza typem IC 2 dodatkowe wiersze:
I245-C
D6LT32

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

Wed Apr 01, 2015 4:42 pm   

W dniu środa, 1 kwietnia 2015 15:14:46 UTC+2 użytkownik Adam Górski napisał:


Niestety nie. Pisałem do nich, ale ich tech. support odpisywał takie pierdoły, że dałem se spokój.


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/

Thu Apr 02, 2015 12:38 am   

Dnia 2015-04-01, o godz. 07:42:28
stchebel@gmail.com napisał(a):

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

Thu Apr 02, 2015 10:46 pm   

W dniu czwartek, 2 kwietnia 2015 02:38:07 UTC+2 użytkownik Michał Semeniuk napisał:

Witaj !!


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


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


Jak to sprawdzałeś ?

Thu Apr 02, 2015 11:29 pm   

W dniu środa, 1 kwietnia 2015 15:46:50 UTC+2 użytkownik J.F. napisał:

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/ProgramGuides/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/AN_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20Mode.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?

Fri Apr 03, 2015 1:23 am   

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


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

2m

Fri Apr 03, 2015 1:57 am   

W dniu piątek, 3 kwietnia 2015 01:23:59 UTC+2 użytkownik 2m napisał:

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ść.



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

Fri Apr 03, 2015 4:41 am   

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

2m

Fri Apr 03, 2015 1:10 pm   

W dniu piątek, 3 kwietnia 2015 04:41:16 UTC+2 użytkownik 2m napisał:

16K

Fri Apr 03, 2015 4:12 pm   

W dniu 2015-04-02 o 23:29, stchebel@gmail.com pisze:

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

Fri Apr 03, 2015 4:21 pm   

W dniu piątek, 3 kwietnia 2015 13:10:24 UTC+2 użytkownik stch...@gmail.com napisał:

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

Fri Apr 03, 2015 6:26 pm   

W dniu piątek, 3 kwietnia 2015 16:21:10 UTC+2 użytkownik 2m napisał:

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"