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

do góry

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

do góry

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

do góry

On 2015-03-31 17:01, s...@g...com wrote:
> 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
>

Jaką masz rewizję FT2232H ?

Adam

do góry

W dniu wtorek, 31 marca 2015 18:40:23 UTC+2 użytkownik Adam Górski napisał:

>
> Jaką masz rewizję FT2232H ?
>

Za cholerę nie odczytam nic ze scalaka. Może jutro rano ktoś z lepszymi gałami da
radę. Czyżbyś miał jakąś wiedzę tajemną w tym temacie?

do góry

On 2015-03-31 21:19, s...@g...com wrote:
> W dniu wtorek, 31 marca 2015 18:40:23 UTC+2 użytkownik Adam Górski napisał:
>
>>
>> Jaką masz rewizję FT2232H ?
>>
>
> Za cholerę nie odczytam nic ze scalaka. Może jutro rano ktoś z lepszymi gałami da
radę. Czyżbyś miał jakąś wiedzę tajemną w tym temacie?
>
Żadna wiedza tajemna. Rewizja A ma jakieś bliżej nieokreślone problemy z
FIFO w trybie synchronicznym i czasem gubi bajty. Errata bardzo
lakonicznie o tym wspomina. Mógłby to być jakiś trop.

Adam

do góry

W dniu środa, 1 kwietnia 2015 12:02:17 UTC+2 użytkownik Adam Górski napisał:
> On 2015-03-31 21:19, s...@g...com wrote:
> > W dniu wtorek, 31 marca 2015 18:40:23 UTC+2 użytkownik Adam Górski napisał:
> >
> >>
> >> Jaką masz rewizję FT2232H ?
> >>
> >
> > Za cholerę nie odczytam nic ze scalaka. Może jutro rano ktoś z lepszymi gałami da
radę. Czyżbyś miał jakąś wiedzę tajemną w tym temacie?
> >
> Żadna wiedza tajemna. Rewizja A ma jakieś bliżej nieokreślone problemy z
> FIFO w trybie synchronicznym i czasem gubi bajty. Errata bardzo
> lakonicznie o tym wspomina. Mógłby to być jakiś trop.
>

Akurat mój młody dał radę odczytać ze scalaka. Są poza typem IC 2 dodatkowe wiersze:
I245-C
D6LT32

Wracając do tematu, to opóźnienie wygląda tak, jakby w pamięci peceta tworzył się
FIFO o n-krotnej pojemności rozmiaru pojedyńczego frame'a akwizycji (16KB).

do góry

On 2015-04-01 14:08, s...@g...com wrote:
> W dniu środa, 1 kwietnia 2015 12:02:17 UTC+2 użytkownik Adam Górski napisał:
>> On 2015-03-31 21:19, s...@g...com wrote:
>>> W dniu wtorek, 31 marca 2015 18:40:23 UTC+2 użytkownik Adam Górski napisał:
>>>
>>>>
>>>> Jaką masz rewizję FT2232H ?
>>>>
>>>
>>> Za cholerę nie odczytam nic ze scalaka. Może jutro rano ktoś z lepszymi gałami da
radę. Czyżbyś miał jakąś wiedzę tajemną w tym temacie?
>>>
>> Żadna wiedza tajemna. Rewizja A ma jakieś bliżej nieokreślone problemy z
>> FIFO w trybie synchronicznym i czasem gubi bajty. Errata bardzo
>> lakonicznie o tym wspomina. Mógłby to być jakiś trop.
>>
>
> Akurat mój młody dał radę odczytać ze scalaka. Są poza typem IC 2 dodatkowe
wiersze:
> I245-C
> D6LT32
>
> Wracając do tematu, to opóźnienie wygląda tak, jakby w pamięci peceta tworzył się
FIFO o n-krotnej pojemności rozmiaru pojedyńczego frame'a akwizycji (16KB).

Czyli raczej z hw strony nie ma się czego przyczepić.

1. Ok. Czy masz jakiś alternatywny soft do odbioru danych ? Może FTDI
coś dostarcza ?
2. Inny PC, inne sterowniki ?

Nie chcę mi się wierzyć że podstawowa funkcjonalność ma takie problemy.

Adam

do góry

Użytkownik napisał w wiadomości
>Wracając do tematu, to opóźnienie wygląda tak, jakby w pamięci peceta
>tworzył się FIFO o n-krotnej pojemności rozmiaru pojedyńczego frame'a
>akwizycji (16KB).

Chyba jak najbardziej mozliwe, trzeba by sie doczytac opisu drivera.
Z tym, ze powinies go tez szybko oproznic, skoro przetwarzanie jest
szybkie.
No i powinny byc dane od razu do dyspozycji, a o ile rozumiem po
prierwszym uruchomieniu programu odbierajacego mamy sekunde czekania.

Z drugiej banki - a moze urzadzenie za malo wysyla ?
Jak rozumiem to w programie czytasz potrzebna ilosc bajtow ... i wedle
opisu funkcja czeka az tyle naplynie.
Jesli naplywa powoli, to czekamy.

Tylko wtedy na koncu nie ma pobierania danych z bufora.

J.

do góry

W dniu środa, 1 kwietnia 2015 15:14:46 UTC+2 użytkownik Adam Górski napisał:

> Czyli raczej z hw strony nie ma się czego przyczepić.
>
> 1. Ok. Czy masz jakiś alternatywny soft do odbioru danych ? Może FTDI
> coś dostarcza ?

Niestety nie. Pisałem do nich, ale ich tech. support odpisywał takie pierdoły, że
dałem se spokój.

> 2. Inny PC, inne sterowniki ?

Na innym PC, to samo. Znalazłem też takie coś spoza FTDI, ale nie obsługuje akurat
tej kostki.

http://www.intra2net.com/en/developer/libftdi/

>
> Nie chcę mi się wierzyć że podstawowa funkcjonalność ma takie problemy.
>
To może być dobre do odtwarzania audio/video, ale w moim przypadku to "przesunięcie
fazowe" jest niedopuszczalne.

do góry