Opóźnienie w transmisji USB przy demodulacji AM w prototypie z FPGA i FT2232H

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

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

On 2015-03-21 19:32, stchebel@gmail.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.

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

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

W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik stch...@gmail.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, stchebel@gmail.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

On 2015-03-28 08:40, stchebel@gmail.com wrote:
W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik stch...@gmail.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, stchebel@gmail.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!

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!

W dniu 2015-03-28 o 11:21, stchebel@gmail.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.

W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik stch...@gmail.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, stchebel@gmail.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.

On 2015-03-28 08:40, stchebel@gmail.com wrote:
W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik
stch...@gmail.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, stchebel@gmail.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

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

On 2015-03-28 08:40, stchebel@gmail.com wrote:
W dniu sobota, 28 marca 2015 07:45:19 UTC+1 użytkownik stch...@gmail.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, stchebel@gmail.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.

Jaką masz rewizję FT2232H ?