W dniu niedziela, 29 marca 2015 13:14:04 UTC+2 użytkownik Adam Górski napisał:
> On 2015-03-28 08:40, s...@g...com wrote:
> > W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik s...@g...com napisał:
> >> 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.
> >>
> >
> > 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.
> >
>
> 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 ?

Tak.

> 2. Czy po zakończeniu przesyłania zamykasz w jakiś sposób połączenie ,
> może czekasz aż wszystkie dane dojdą ?

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.



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

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

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

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