On 2015-03-29 13:14, Adam Górski wrote:
> 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 ?
> 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