W dniu 2014-07-02 21:27, s...@g...com pisze:
> W dniu środa, 2 lipca 2014 12:48:40 UTC+2 użytkownik Adam Górski napisał:
>> W dniu 2014-07-02 01:04, s...@g...com pisze:
>>
>>> W dniu wtorek, 1 lipca 2014 23:08:48 UTC+2 u�ytkownik Adam G�rski napisa�:
>>
>>>> W dniu 2014-07-01 14:06, s...@g...com pisze:
>>
>>>>
>>
>>>>> Witam,
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Mam na pok�adzie swojej PCB, FT2232H i FPGA. Zapis z PC do FPGA w trybie
synchronicznym dzia�a OK, natomiast mam jajca przy odczycie z FPGA do PC.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Najpierw hardware w FPGA. Wygl�da to mniej wi�cej tak:
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> USB_CLK: in std_logic;
>>
>>>>
>>
>>>>> RST : in std_logic;
>>
>>>>
>>
>>>>> TXE_n : in std_logic;
>>
>>>>
>>
>>>>> WR_n : out std_logic;
>>
>>>>
>>
>>>>> USB_DATA: inout std_logic_vector(7 downto 0);
>>
>>>>
>>
>>>>> RAM_DATA: in std_logic_vector(7 downto 0);
>>
>>>>
>>
>>>>> RD_ADDR: out std_logic_vector(12 downto 0);
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> signal RD_ADDRs: std_logic_vector(12 downto 0);
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> process (USB_CLK,RST,TXE_n)
>>
>>>>
>>
>>>>> begin
>>
>>>>
>>
>>>>> if RST='1' then
>>
>>>>
>>
>>>>> RD_ADDRs<=(others=>'0');
>>
>>>>
>>
>>>>> RD_ADDR<=(others=>'0');
>>
>>>>
>>
>>>>> USB_DATA<=(others=>'Z');
>>
>>>>
>>
>>>>> WR_n<='1';
>>
>>>>
>>
>>>>> else
>>
>>>>
>>
>>>>> if USB_CLK'event and USB_CLK='1' then
>>
>>>>
>>
>>>>> WR_n<=TXE_n;
>>
>>>>
>>
>>>>> if TXE='0' then
>>
>>>>
>>
>>>>> USB_DATA<=RAM_DATA;
>>
>>>>
>>
>>>>> RD_ADDRs<=RD_ADDRs+1;
>>
>>>>
>>
>>>>> RD_ADDR<=RD_ADDRs;
>>
>>>>
>>
>>>>> else USB_DATA<=(others=>'Z');
>>
>>>>
>>
>>>>> end if;
>>
>>>>
>>
>>>>> end if;
>>
>>>>
>>
>>>>> end if;
>>
>>>>
>>
>>>>> end process;
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> =========
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> I teraz software (Delphi):
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> ResetAddressCounters;
>>
>>>>
>>
>>>>> ftresult:=FT_Read(FT_HANDLE,@FT_In_Buffer,8192,@Read
_Result);
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Za��my, �e chc� odczyta� RAM zaimplementowany w FPGA. Zawarto��
RAM'u:
>>
>>>>
>>
>>>>> 0,1,2,3...255,0,1,2....255,....,.... - razem 8kB (taka 32-z�bna pi�a)
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Przy pierwszym odczycie zawarto�� FT_In_Buffer jest cholera jakby zrotowana
w prawo o losow� ilo�� adres�w. Np. o trzy adresy, w wyniku czego
odczytujďż˝:
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> 253,254,255,0,1,2,3....255,0,1,2....255,0,1,2....252
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Ka�dy kolejny odczyt powoduje rotacj� w prawo o dok�adnie 16 bajt�w..
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Jakieďż˝ porady?
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> Wycz�ci� fifo przed u�yciem ?
>>
>>>
>>
>>> Te� o tym my�la�em. Problem w tym, �e w drajverach D2XX od FTDI brak
takiej funkcji.
>>
>>>
>>
>>>>
>>
>>>> Ustawi� RD_ADDR na pocz�tek po pierwszym odczycie.
>>
>>>>
>>
>>>> Jak z poziomu pc ustawiasz RD_ADDRES na pocz�tek ? Jaka jest idea
>>
>>>>
>>
>>>> synchronizacji ?
>>
>>>
>>
>>> Dok�adnie!! Przed ka�dym rozpocz�ciem odczytu daj� impuls RST, kt�ry
asynchronicznie zeruje licznik RD_ADDR (popatrz na kod VHDL). Impuls RST generujďż˝
programowo, dzia�a poprawnie, sprawdzi�em na oscylu. Synchronizacja jest banalnie
prosta. Leci akwizycja danych do bufora w pami�ci FPGA i sprawdzam bit statusu
akwizycji. Jak akwizycja zako�czona, to wal� 2 komendy opisane w pierwszym
po�cie. Aha!! Robi�em eksperymenty i tak np. przy odczycie tylko 512 bajt�w z
bufora, ka�dorazowo robi mi rotacj� o jeden bajt. Podejrzewam, �e co� jest
nawalone w drajverach D2XX, albo pieron wie co ?!
>>
>>
>>
>> Ok. Jaka to fpga ? Na pewno s� tam jakie� mechanizmy dost�pu przez jtaga
>>
>> : podgl�d ram-u , podgl�d sygna��w itd czy nawet rejestratory z
wyzwalaniem.
>>
>>
>>
>> 1. Czy jeste� pewien zawarto�ci pami�ci - ale tak na 10000%? Czyli np
>>
>> rom ze wzorcem. Napisa�e� �e jest tam jaki� ram, ale mo�e by�
dwuportowy
>>
>> lub inna cholera.
>>
>>
>>
>> 2. Mo�e by� te� tak �e w momencie rozpocz�cia przesy�ania FT czy�ci
>>
>> sobie fifo ,wiec nale�a�oby wpisa� do fifo dopiero jak zacznie si�
>>
>> odczyt po pc stronie. Na pewno jest to w sheecie opisane.
>>
>>
>>
>> 3. Szuka�e� jaki� app note, white papers etc ?
>>
>>
>>
>> VHDL nie wygl�da �le, mo�e ja bym go zrobi� ca�kowicie synchronicznie,
>>
>> albo przynajmniej synchronizowaďż˝ RST do zegara USB_CLK ( albo oba
>>
>> powy�sze ). Nie widz� reszty wiec nic wi�cej nie powiem.
>>
>>
>>
>> Pzdr.
>>
>>
> Popatrz na kolejne moje wpisy.. Na 99.99% obstawiam na spaprane drjwery przez
producenta, A producent.. , normalka, jak "application engineer" nie wie o co biega,
to za Wuja Wacka nie odpowiada na emaile. Krótko mówiąc, support techniczny FTDI nie
istnieje, albo ma to w d.... Ponieważ nie znam przyczyny. a tylko skutki, więc
zastosowałem "leczenie objawowe". Najsampierw puszczam z ROM'u wzorzec, łapię jego
przesunięcie adresowe, a następnie przy każdym kolejnym "frame"'ie danych robię
przesunięcie o 16 bajtów. No i to działa. Niestety jest to zrobione metodą
empiryczną, zostały wyleczone objawy, lecz nie przyczyny. Nie podoba mi się to moje
rozwiązanie, ale póki co jest skuteczne i muszę z tym żyć...

Rozwiązanie o którym piszesz ma króciutkie nóżki. Co będzie jak w/w bug
zostanie naprawiony ? ( O ile to jest bug ).

Jeżeli to komercyjne lub przemysłowe lub inne niż amatorskie, to jest to
rozwiązanie nie do przyjęcia. Tak naprawdę , nie wiadomo co powoduje
przesunięcie o te 16 bajtów.

1. Trzeba gnębić dystrybutora o dojście do ludzi którzy mogą mieć
pojęcie o w/w problemie.

2. Jeżeli app engineer nie ma pojęcia - domagać się pchnięcia sprawy wyżej.

Zrób jeszcze proszę jeden test:
1. Uruchom program odbierający na PC - niech sobie czeka na dane
2. Dane do fifo z fpga zacznij wpisywać dopiero po 2 - 3 sekundach tak
żeby połączenie z pc zostało zainicjowane zanim dodasz jakiekolwiek dane
do fifo.

Daj znać co wyszło

Pzdr


Adam



---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ
ochrona avast! Antivirus jest aktywna.
http://www.avast.com