1. Home
  2. Electronics (Polish)
  3. CY7C68013 -- szczegóły

CY7C68013 -- szczegóły

Witam,

chciałbym uzyskać odpowiedzi na kilka dość nietypowych pytań na temat tytułowego chipu. Niestety w datasheecie niewiele znalazłem, więc liczę na pomoc osób używających tej kostki. Oto one:

  1. Przeznaczenie linii CTL3--5 podczas wewnętrznego masteringu jest dobrze określone. A co się z nimi dzieje, gdy FIFO pracuje w trybie slave? Manual mówi, że:

"The state of the GPIF signals during the Idle State is determined by the contents of the GPIFIDLECS and GPIFIDLECTL registers."

ale to dotyczy trybu master. Czy jeśli używam trybu slave, to GPIF znajduje się stale w trybie idle i czy w takim razie mogę używać linii CTL jako dodatkowych pinów wyjściowych przez zapisywanie rejestru GPIFIDLECTL?

  1. Co się stanie, gdy pin #WAKEUP zostanie aktywowany podczas pracy chipu? Zostanie to zignorowane, czy mogę liczyć na zgłoszenie związanego z tym przerwania?

  1. W którym momencie zostaje wystawiony bit danych na linii RXDnOUT względem zegara na linii TXD, jeśli UART pracuje w trybie synchronicznym (tj. nr 0) z szybkim taktowaniem (CLK/4 zamiast CLK/12)? Niestety rysunek w PDF jest bardzo nieczytelny. Czy mogę zatrzaskiwać w zewnętrznym rejestrze stan RXDOUT podczas _opadającego_ zbocza na linii TXD?

  2. Czy przy wewnętrznym masteringu istnieje możliwość automatycznego wyzwalania transmisji na podstawie zajścia określonego stanu na liniach RDY? Chodzi mi o zasymulowanie trybu "pseudo-slave", tj. mastering jest wewnętrzny, ale z widziany z zewnątrz przypomina slave: układ czeka na przejście co najmniej jednej z dwóch linii RDY, powiedzmy nr 1 i 2, w stan aktywny. Jeśli na RDY1 pojawia się stan niski, to Cypress pobiera z zewnętrznego FIFO blok danych i wysyła go przez USB i wraca do oczekiwania na ponowną aktywację. Jeśli stan niski pojawia się na RDY2, to Cypress wysyła ze swojego FIFO dane do FIFO zewnętrznego i przechodzi do trybu oczekowania. Jeśli obie linie są aktywne, to układ wykonuje powyższe czynności w dowolnej kolejności. Oczywiście całość powinna się odbywać bez ingerencji CPU, np. być zaszyta w programie GPIF, który nigdy się nie konczy. Czy to jest w ogóle do zrobienia?

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski
Loading thread data ...

ze tak sie zapytam..doktorat piszesz z tej kostki?:) uzywalem i uzywam ja do kilku zastosowan..i jesli bardzo chcesz, to moge niektore rzeczy sprawdzic..ale pytanie - po co ci to wszystko wiedziec??

BTW,ostatnio pojawila sie texasowa wersja tego scalaczka, filozofia dokladnei ta sama..rozni sie szczegilami, dostalem juz probki..

Reply to
Greg

Bo uczyniłem go odpowedzialnym za obsługę sporej liczby peryferiów i chcę wiedzieć, czy on da radę. A ponieważ planuję używać część z nich w sposób, który raczej nie przyszedł do głowy projektantom tej kostki, to i pytania wykraczają nieco poza to, co można wyczytać w manualu. :-)

Jeśli życzysz sobie bardziej szczegółowych wyjaśnień -- oto one:

Potrzebuję kilku linii wyjściowych do realizowania prostych funkcji:

a) sterowanie przekaźnikiem dostarczającym zasilanie do przetwornic zasilających główny układ; Cypress ma pomocnicze zasilanie do trybu standby.

b) informowanie o przyczynach błędów wykrytych podczas procesu autodiagnostyki urządzenia. Informacja będzie przekazywana poprzez miganie diodą LED według odpowiedniego dla błędu kodu.

Nie chcę marnować GPIO do tak prostych funkcji, więc niepotrzebne mi linie CTL idealnie by się do tego nadawały.

Do pinu #WAKEUP będą podpięte linie IRQ z panelu dotykowego oraz RTC -- urządzenie powinno się samo włączyć po dotknięciu ekranu albo o określonej porze.

To jest barzdo ważne: Cypress będzie odpowiadał m.in. za wczytanie z pełniącej rolę wewnętrznego dysku twardego karty CompactFlash odpowiedniego w danej sytuacji pliku konfiguracyjnego FPGA i przesłanie go do Cyclone'a w trybie Passive Serial. Ponieważ CPU to klon mojego "ulubionego" 8051, to mimo taktowania go zegarem 48MHz i skrócenia cyklu rozkazowego do 4 taktów zegara, programowe konfigurowanie FPGA potrwałoby około sekundy, czyli nieznośnie długo. Dlatego wymyśliłem sposób sprzętowy, polegający na podłączeniu linii RXDOUT CPU do linii DATA0 w FPGA i taktowanie zanegowanym sygnałem z linii TXD portu szeregowego pracującego w trybie synchronicznym. Przyspieszy to ładowanie konfiguracji FPGA około

10-krotnie, tylko problem polega na tym, że FPGA zatrzaskuje dane na zboczu narastającym zegara DCLK, a więc opadającym zanegowanego zegara z linii TXD. No i teraz nie mam stuprocentowej pewności, czy dane na RXDOUT będą poprawne podczas zbocza opadającego na TXD -- z rysunku nic sensownego nie umiem odczytać, zwłaszcza na temat pierwszego bitu.

BTW, po skonfigurowaniu FPGA UART zostanie "odzyskany" do normalnego użycia, bo linia TXD jest też połączona z MAX3232 przez MOSFET, którego bramka jest z kolei podłączona do linii CONFIG_DONE, która po zakończeniu konfiguracji FPGA automatycznie przejdzie ze stanu 0 do 1, co podłączy TXD do MAXa. :-)

Jeśli mamy na myśli ten sam chip, to wersja z TI jest znacznie uboższa, m.in. nie ma trybu slave.

Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.