Witam,

Prototypię obecnie takie urządzenie:
Wejście (sygnał analogowy zmodulowany AM/nośna 3-5MHz)=>Wzmacniacz=>przetwornik A/C
12-bit/fs=20MHz=>FPGA(demodulacja cyfrowa,decymacja i kompresja logarytmiczna do
8-bit)=>interface USB(FT2232H)=>PC

Na pececie wyświetlam dane w postaci graficznej w czasie rzeczywistym, więc używam
trybu synchronicznego FIFO. Zapycha 30-40MB/s bez problemu, ale...
To wszystko jest opóźnione jakby "w fazie" o jakieś 1-2 sekundy. Efekt podobny do
tego jak panienka w studio TV zadaje pytanie reporterowi w terenie, a on to odbiera z
kilkusekundowym opóźnieniem i dopiero zaczyna odpowiadać.

Korzystam z drajwerów FTDI d2xx.dll. Co jest grane? Drajwery takie, czy ki pieron?

Najgorsze, że w moim badziewiu taka sytuacja jest niedopuszczalna. Co radzicie? Może
jakieś inne kostki USB, np. Cypressa, albo jakieś inne czarymary macie do
zaproponowania?

do góry

Użytkownik napisał w wiadomości grup
>Prototypię obecnie takie urządzenie:
>Wejście (sygnał analogowy zmodulowany AM/nośna 3-5MHz)=>Wzmacniacz
>=>przetwornik A/C 12-bit/fs=20MHz
>=>FPGA(demodulacja cyfrowa,decymacja i kompresja logarytmiczna do
>8-bit)
>=>interface USB(FT2232H)=>PC

>Na pececie wyświetlam dane w postaci graficznej w czasie
>rzeczywistym, więc używam trybu synchronicznego FIFO. Zapycha
>30-40MB/s bez problemu, ale...
>To wszystko jest opóźnione jakby "w fazie" o jakieś 1-2 sekundy.
>Korzystam z drajwerów FTDI d2xx.dll. Co jest grane? Drajwery takie,
>czy ki pieron?
>Najgorsze, że w moim badziewiu taka sytuacja jest niedopuszczalna. Co
>radzicie? Może jakieś inne kostki USB, np. Cypressa, albo jakieś inne
>czarymary macie do zaproponowania?

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.

do góry

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 ?

do góry

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.

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

Adam

do góry

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.

do góry

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.

do góry

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

do góry

W dniu sobota, 28 marca 2015 11:08:30 UTC+1 użytkownik Marek Borowski 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.
> >
> >
> 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.
>
Sprawdzę jutro na CZYSTYM kompie/dysku. Dzięki za info!

do góry

W dniu 2015-03-28 o 11:21, s...@g...com pisze:

>>>
>>> 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.
>>
> Sprawdzę jutro na CZYSTYM kompie/dysku. Dzięki za info!
>

Sprawdź na kompie ze sprzętowym UARTem.

--
pozdrawiam
MD

do góry

W dniu sobota, 28 marca 2015 18:59:14 UTC+1 użytkownik Mario napisał:
> W dniu 2015-03-28 o 11:21, s...@g...com pisze:
>
> >>>
> >>> 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.
> >>
> > Sprawdzę jutro na CZYSTYM kompie/dysku. Dzięki za info!
> >
>
> Sprawdź na kompie ze sprzętowym UARTem.
>

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.

do góry