W dniu piątek, 27 marca 2015 16:30:06 UTC+1 użytkownik Adam Górski napisał:
> On 2015-03-21 19:32, s...@g...com wrote:
> > W dniu piątek, 20 marca 2015 14:19:06 UTC+1 użytkownik J.F. napisał:
> >
> >
> >>
> >> 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.
> >
> > 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.
> >
> >>
> >>
> >> 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 ..
> >>
> >
> > 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.
>

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

> A jesteś pewien że z kostki na szynę wyłazi ? Podepnij może oscyloskop i
> zobacz.
>
Jakby nie wychodziło, to miałbym spaprane dane lub nie miałbym ich. Dane przychodzą
jak najbardziej przewidywalne i poprawne.