Opó?nienie w transmisji USB

Użytkownik napisał w wiadomości grup

A predko tam ? Bo z tego co piszesz to gdzies po drodze mogloby byc 30-80MB zmagazynowane - a to na pewno nie FT2232, i pewnie nie w FPGA, tylko gdzies w komputerze.

Na konwerterze RS-USB mozna sie chyba spodziewac opoznien o pare ms - raz, ze jesli dobrze udaja 16550, to staraja sie same zbuforowac troche znakow wejsciowych a nie meczyc systemu przerwaniami, dwa, ze USB w podstawowym trybie jest przegladane co 1ms ..

J.

W dniu piątek, 20 marca 2015 14:19:06 UTC+1 użytkownik J.F. napisał:

No może nie aż tyle, bo cały mój "frame" zbierania danych to zaledwie 16KB. Z tych zaledwie 16KB muszę zrobić kupę postprocessingu i wyświetlić to jako wykres, obraz 2D, cokolwiek... Natomiast układ akwizycji może śmigać na 20MHz, ale cały "obraz" akwizycji mogę odebrać zgodnie z portokołem USB (1ms scheduling). Podejrzewam, że drajwery FTDI buforują dane na f=60MHz z sobie jedynie znanych powodów.

A cóż to takiego "tryb podstawowy"? Nie ma nic takiego! Czy ja coś pisałem o konwerterze RS-USB? Chyba nie. Protokół USB to nie przerwania! Odpytuje jednak co 1ms chęć dostępu do urządzenia/transmisji. Jest to tzw. scheduled protocol, czy jak kto woli "planowany". W moim przypadku czas tworzenia kompletnego zestawu danych (16KB), to aż 60ms. Dodając do tego 1ms na "dobicie się" do transmisji mamy 61ms, co daje 16 obrazów/s. Czas postprocessingu i samej transmisji jest pomijalny na byle jakim pececie. I faktycznie tak jest! Ale owego "przesunięcia fazowego" za cholerę nie rozumiem... Podejrzewam drajwery FTDI, a z tym już nic nie jestem w stanie nakombinować. Chyba trza będzie zastosować inne kostki. Tylko jakie, coby nie mieć tej samej checy ?

Czyli jeśli dobrze rozumiem robiąc np. "ping" PC->device->PC (albo device ->PC-> device ) dostajesz odpowiedź mierzoną w sekundach ? No to jakieś jaja by były.

Gdybyś tak zechciał zmierzyć czas tego "ping" to coś by się dało powiedzieć. Dziwnie 16kB co 60ms i taka latencja ... hm dziwne.

A jesteś pewien że z kostki na szynę wyłazi ? Podepnij może oscyloskop i zobacz.

Adam

Źle mnie zrozumiałeś. 60ms to nie latencja, lecz czas akwizycji danych. Praw fizyki nie zmienię. Natomiast po zakończeniu akwizycji, transmisja+postprocessing+wyświetlenie tego na ekranie powinno być szybkie jak cholera, coby rozpocząć kolejny cykl akwizycji. I tak w koło Macieju... Czyli powinienem mieć jakieś 16 obrazów/s (1/60ms). I faktycznie tyle mam! Problem w tym, że jak warknę do swojego badziewia "Hallo", to owo badziewie czysto i wyraźnie mi odpowiada "Hallo", ale z opóźnieniem 1-2s. Ot takie "przesunięcie fazowe". Przeczytaj jeszcze raz główny wątek. Przykład panienki z TV chyba najlepiej to obrazuje.

Jakby nie wychodziło, to miałbym spaprane dane lub nie miałbym ich. Dane przychodzą jak najbardziej przewidywalne i poprawne.

W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik snipped-for-privacy@gmail.com napisał:

Upsss... Chyba jednak mnie dobrze zrozumiałeś. To ja nie załapałem Twojej odpowiedzi. Wniosek: po wybudzeniu należy najpierw wypić kawę i dopiero wtedy czytać i odpowiadać.

Ano masz rację!! To są jaja!! Podejrzewam, że drajwery FTDI są jakie są, buforują dane i wypluwają je zgodnie z jakąś tam kolejnością. Albo coś przeoczyłem w dokumentacji softwarowej, albo te drajwery są o kant poopy rozbić.

Bo cały mój hardware już normalnie "oddycha".

Aha!! Ciekawy przykład:

1) Podpinam sygnał wejściowy do mojego badziewia. 2) Na swoim sofcie klikam guzik "START". Pojawia się obraz po 1-2s, ale zasuwa dalej z prędkością ok. 16obr./s. 3) Naciskam guzik "STOP" i odpinam sygnał wejściowy. Idę se zrobić kawę... 4) Wracam, naciskam guzik "START" i jeszcze przez 1-2s widzę stare dane wejściowe na ekranie.

A jak wygłada klient ? Ktos juz napisal, ze wygłada to na buforowanie danych, ktore nie są odbierane. Być może jest jakis antyvirus ktory ma interakcje w API z ktorego korzysta aplikacja.

Pozdrawiam

Marek

Sprawdzę jutro na CZYSTYM kompie/dysku. Dzięki za info!

W dniu 2015-03-28 o 11:21, snipped-for-privacy@gmail.com pisze:

Sprawdź na kompie ze sprzętowym UARTem.

W dniu sobota, 28 marca 2015 18:59:14 UTC+1 użytkownik Mario napisał:

To nic nie da w chwili obecnej, bo korzystam z trybu synchronicznego. Nie mniej jednak mogę zrobić czarymary w FPGA i zaimplementować tryb asynchroniczny. Tylko najpierw muszę poczytać jaka jest prędkość transmisji i czy w ogóle ma to sens. Bo np. w trybie "processor bus emulation mode" prędkość transmisji po USB, to zaledwie 8KB/s, co dawałoby mi 1 obraz/2s. Ale przynajmniej w tym trybie nie ma żadnej latencji.Empirycznie sprawdzone. Szczerze powiedziawszy, ta kostka FT2232H zaczyna mnie już wku...ć. Razem z jej drajwerami. Kręcę się w tym temacie już zbyt długo. Jak g.... w przerębli.

Jaja są ale nie powiedziałem że w driverach.

Buforowanie może być w driverach a może wcale z IC nie jest to wypychane.

Ale coś mi mówi że gdzieś flush-a brakuje.

1. Czy za pierwszym razem ( po power up i włączeniu aplikacji ) występuje ten problem ?
2. Czy po zakończeniu przesyłania zamykasz w jakiś sposób połączenie , może czekasz aż wszystkie dane dojdą ? Bo to trochę wygląda jakbyś przestawał dane wyciągać po stronie PC a po stronie device nadal zapychał dane właśnie przez 1-2 s. Te wysłane dane same nie znikną. Trzeba by je do odebrać i wywalać.

Musiałbyś dokładnie opisać jak to działa, tzn mechanizm wznawiania i stopowania wysyłania danych.

Adam

I ?

Adam

Tak.

Nie zamykam i na nic nie czekam. Korzystam z funkcji z biblioteki DLL. Wywołuję te funkcję i od razu biorę się za obróbkędanych i wyświetlenie rezultatów na ekranie.

Niemożliwe, bo po pierwsze zabrakłoby mi pamięci w moim badźewiu, a po drugie dane by się tak "skaszaniły" pod względem synchronizacji, że od razu bym to zauważył.

Działa to tak:

1) Układ akwizycji zbiera dane i zapisuje je do pamięci na FPGA(16KB) przez 60ms. 2) Odczytuję pamięć funkcją FT_READ(FT_HANDLE,@Buffer,BytesToRead,@BytesRead). 3) Obrabiam i wyświetlam dane. Trwa to pomijalnie krótko <1ms. 4) Powrót do pkt.1

Jaką masz rewizję FT2232H ?

Adam

W dniu wtorek, 31 marca 2015 18:40:23 UTC+2 użytkownik Adam Górski napisał:

Za cholerę nie odczytam nic ze scalaka. Może jutro rano ktoś z lepszymi gałami da radę. Czyżbyś miał jakąś wiedzę tajemną w tym temacie?

Żadna wiedza tajemna. Rewizja A ma jakieś bliżej nieokreślone problemy z FIFO w trybie synchronicznym i czasem gubi bajty. Errata bardzo lakonicznie o tym wspomina. Mógłby to być jakiś trop.

Adam

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

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

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.

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.

To może być dobre do odtwarzania audio/video, ale w moim przypadku to "przesunięcie fazowe" jest niedopuszczalne.