Skocz do zawartości

piotr96

Użytkownicy
  • Zawartość

    82
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

Wszystko napisane przez piotr96

  1. Ok, załączam jeszcze przykładowy kod testowy (w VHDL), gdybyś chciała się pobawić w symulacji. Jest tam zasymulowane przesłanie kolejno po sobie czterech liczb: 1, 2, 3, 4. W rzeczywistości ramki przychodzą z większymi odstępami czasowymi pomiędzy nimi. Ale i tak nie widzę skąd bierze się ta „3". LIBRARY ieee; USE ieee.std_logic_1164.ALL; use IEEE.Numeric_std.ALL; use ieee.math_real.all; ENTITY test IS END test; ARCHITECTURE behavior OF test IS --Inputs signal i_Clk : std_logic := '0'; signal i_UART_RX : std_logic := '0'; --Outputs signal o_UART_TX : std_logic; sig
  2. Tak, o to chodziło, chciałem się upewnić, czy ustawienia są takie same jak w kodzie odbiornika UART. Te piny DTR i CTS nie powinny mieć znaczenia, ponieważ nie używasz opcji „Flow Control". Chyba, że ten konwerter działa jakoś inaczej, ale to mało prawdopodobne. Chyba pozostaje sprawdzić dokładnie kod tego odbiornika UART, jego działanie w symulacji. Szkoda, że nie masz możliwości podejrzeć przesyłanej ramki, ale raczej powinna być poprawna.
  3. To dobrze, miało się właśnie wyświetlać na stałe A5. Wyświetlane jest ładnie, bez nakładania się cyfr? Jeśli tak, to możemy założyć, że problem jest z UARTem lub jego obsługą. Wróć z tym fragmentem kodu do stanu poprzedniego. Opis diod świecących w pliku UCF skopiowałem chyba z kursu Forbota bez sprawdzenia, tam jest odwrócony porządek bitów wobec tego, co zakładałem. Najmłodszy bit to dioda D8, a oczekiwałem, że będzie to D1. Nie ma to większego znaczenia. Trzeba ustalić skąd się biorą jedynki logiczne na D3 i D4 (czyli wartość 3, która już wcześniej pojawiała się na wyświetlaczu)
  4. Wcześniej pisałem, żebyś zmieniła liczbę na 12000, a nie 1200, ale to w tej chwili mało istotne. Te ostrzeżenia zamieszczone powyżej są niepokojące (nie widziałem ich wcześniej), w załączonym projekcie mam tylko cztery, niemające większego znaczenia. Jaką liczbę wysyłasz przez UART? Skoro diody D3 i D4 się świecą, to by oznaczało liczbę 12. To się zgadza? Zrób test – spróbuj na chwilę odłączyć UART, przypisując do zmiennej „nowy" stałą wartość: // if(w_RX_DV) // begin nowy = 8'h5A; // end Napisz, co wtedy jest na wyświetlaczach.
  5. Nic więcej nie modyfikowałaś? Wstaw cały projekt. Teraz wychodzi na to, że nic nie jest odbierane. Reszta kodu też nie działa, bo powinno coś się pokazywać na obydwu wyświetlaczach. Dziwna sytuacja. Możesz do debugowania spróbować użyć LEDów: 1. W pliku UCF dodaj coś takiego NET "LED[0]" LOC = P46 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "LED[1]" LOC = P47 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "LED[2]" LOC = P48 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "LED[3]" LOC = P49 |
  6. Nie zmieniaj CLKS_PER_BIT, tylko liczbę 120 w warunku „licznik == 120". Daj na początek 12000 (wtedy wyświetlacze będą zmieniane co około 1 ms). Jeśli chodzi o ostrzeżenia, to musiałabyś pokazać dokładnie o jakie chodzi w tym okienku: Ogólnie (bez odniesienia do tego konkretnego projektu), kod z ostrzeżeniami można wgrać na płytkę, będzie działał poprawnie lub nie, nie ma gwarancji. Ale w każdym razie nie zmieniaj tego parametru CLKS_PER_BIT.
  7. Spróbuj znacząco zwolnić przełączanie wyświetlaczy (zmniejszyć częstotliwość), poprzez modyfikację warunku „licznik == 120", zwiększając liczbę po prawej stronie znaku porównania i w razie potrzeby zwiększając liczbę bitów zmiennej licznik. Zrób test dla częstotliwości przełączania 1000 Hz (nie musi być dokładnie taka, może być zbliżona; mam kod z bliźniaczej płytki Mimas v2, który działał bezproblemowo właśnie z taką częstotliwością, ale nie wyświetlał znaków z UARTa, tylko generowane w kodzie VHDL), ale spróbuj też inne częstotliwości, np. 50, 200 Hz. Jakie dokładnie wartości pr
  8. Nie o to mi chodziło, to nie ma prawa działać, raczej coś takiego przewidywałem: always @(posedge i_Clk) begin if(w_RX_DV) begin nowy = w_RX_Byte; end licznik <= licznik + 1; if (licznik == 120) begin licznik <= 0; if (wybranyBajtMlodszy) begin nowyWektor = nowy[3:0]; end else begin nowyWektor = nowy[7:4]; end wybranyBajtMlodszy = ~wybranyBajtMlodszy; end if (licznik == 0) begin if (wybranyBajtMlodszy) begin led_enable = 3'b101; end else begin led_enable = 3'b110; end end Na wejściu modułu Bin
  9. 47 dziesiętnie, to 2F szesnastkowo i to powinno być wyświetlone na wyświetlaczu – tutaj trochę Cię nie rozumiem. Nie ma znaczenia postać liczby w terminalu i tak każda jest przechowywana binarnie i może być wyświetlana w różnych formatach. Niektóre terminale mają możliwość wprowadzania liczb w różnych formatach (zależy od konkretnego programu, którego używasz). Druga rzecz, która mi się nie podoba, to zachowanie się modułu odbiorczego UART. Byłem przekonany (bez analizy kodu), że moduł ten wystawia na swoje wyjście bajt po otrzymaniu całej ramki danych (a przynajmniej po odebraniu bitów d
  10. Napisz bardziej szczegółowo, co dokładnie się dzieje. Jeżeli np. wyślesz liczbę 0xA5, (poprzednio była 0xC2), to co jest wyświetlane na wyświetlaczach. Wspominasz, że na obydwu to samo, to znaczy która połówka bajtu (cyfra szesnastkowa)? Spróbuj może opóźnić to przełączanie, nie co takt zegara, tylko rzadziej, na początek np. co milisekundę (albo i rzadziej, jeżeli zrobisz przełączanie co 5 sekund, to może łatwiej będzie wyłapać co jest nie tak). Możesz to zrobić na przykład poprzez dodanie licznika i obudowanie wnętrza tego ostatniego ifa. Coś w stylu: module UART_RX_To_7_Seg_Top (
  11. Musisz wprowadzić dodatkowy sygnał pośredni (wektor czterobitowy), podać go na wejście modułu Binary_To_7Segment, a w innym miejscu przełączać (pseudokod w Verilogu – nie znam tego języka za dobrze, mogą być tam jakieś błędy składniowe): wire [3:0] nowyWektor = 4'h0; ... Binary_To_7Segment SevenSeg_Inst (.i_Clk(i_Clk), .i_Binary_Num(nowyWektor), ... // Zamiast x=3;y=0; nowyWektor = w_RX_Byte[3:0]; ... // Zamiast x=7;y=4; nowyWektor = w_RX_Byte[7:4]; Nie jestem do końca pewien, czy dokładnie w tym miejscu powinno się odbywać to przypisywanie wartości do nowej
  12. Domyślam się na podstawie innych tematów, że chodzi o terminal w programie System Workbench for STM32. Nie ma tutaj wbudowanego terminala, ale można go doinstalować. Przykładowy, pierwszy z brzegu dodatek pełniący tę funkcję to TM Terminal (nigdy nie testowałem, nie gwarantuję że działa). Dodatki instaluje się w menu Help->Eclipse Marketplace...
  13. Nie bardzo rozumiem tę koncepcję. Pojedynczy wyświetlacz siedmiosegmentowy ma 7 segmentów + kropkę dziesiętną. Zobacz przykładowy rysunek z Forbota. Segmenty, to te kreski. Oznacza się je na przykład literami od A do G, tak jak na rysunku, czy w kodzie. Jeżeli chcesz wyświetlić na przykład liczbę 0, to musisz zapalić linie dookoła, czyli segmenty A, B, C, D, E, F (6 segmentów). Żeby wyświetlić liczbę 8 zapalasz wszystkie siedem segmentów, i tak dalej. Stąd biorą się tego typu przypisania (gdy sobie rozpiszesz to na bity, wiedząc, że kolejne bity opisują kolejne segmenty, to powinno być to
  14. Można to uprościć zbierając pojedyncze sygnały w wektor, wtedy przełączanie odbywałoby się całym wektorem naraz. Tak się dzieje, gdy na przykład nie ma w projekcie pliku o danej nazwie. Ale ISE ma dużo bugów i często dzieje się tak bez przyczyny. Sprawdź w pierwszej kolejności, czy nie masz jakiś literówek w nazwach. Następnie spróbuj usunąć ten plik z hierarchii i dodaj go ponownie. Czasem u mnie działało otwarcie pliku projektu (z rozszerzeniem xise) w notatniku i usunięcie fragmentu dotyczącego danego pliku. Następnie mogłem dodać plik normalnie i był już widoczny w ISE. Ale
  15. Ten pierwszy konwerter wygląda najbardziej obiecująco. Na próbę podłączyłbym po prostu kabelkami do goldpinów – na pewno masę i pin Rx, nie wiem jak z zasilaniem (czy jest zasilony z usb, ale pewnie tak). W każdym razie musi podawać 3V3 na pin FPGA. Nie wiem o jakim kodzie jest mowa. Jeżeli każdy segment wyświetlacza to osobne wyjście modułu, to nic nie musisz zmieniać. Jeżeli zbierzesz je w wektor, to długość powinna się zgadzać. Zawsze możesz też podać na stałe sygnał dezaktywujący ten nieużywany segment i się nim nie przejmować (używać tylko fragmentu wektora bitów, bez tego jednego el
  16. Z czym konkretnie jest problem? Generalnie, jeżeli kod modułu UART_RX jest prawidłowy, to nie powinien wymagać wewnętrznych zmian. Jedyna zmiana (na zewnątrz tego modułu – w nadrzędnej jednostce projektowej) jest opisana w komentarzach: parametr CLKS_PER_BIT. Dla przykładowego zegara 25 MHz i żądanej prędkości transmisji 115200 b/s, wynosi 217 – jest to iloraz tych wartości. Musisz to policzyć dla Twojego zegara 12 MHz i oczekiwanej prędkości i wpisać tę wartość w pliku nadrzędnym, tam, gdzie używasz modułu UART_RX. Poza tym musisz dodać gdzieś w pliku ucf deklarację
  17. Nie wiem, dlaczego nazywasz D7 wejściem analogowym. Chyb nie do końca się rozumiemy. Tak w skrócie, podsumowując: Na płytce są złącza CN7 i CN10 opisane niebieskim kolorem – tutaj są wyprowadzone głównie piny „ogólnego przeznaczenie" (poza specyficznymi wyprowadzeniami jak na przykład zasilanie), oznaczone PXn, gdzie X to litera określająca port, a n liczba oznaczająca numer pinu w porcie. Te oznaczenia są zgodne z opisem nóżek w dokumentacji mikrokontrolera i używane w bibliotekach programistycznych producenta (na których opierają się kursy) Przeznaczenie pinu zależy od konfigur
  18. Jeżeli może być w Paincie, a nie na kartce, to bym to widział tak: Mam nadzieję, że połączenia są widoczne. Masę można wziąć z dowolnego pinu GND. Nie rozumiem do końca tego pytania. Domyślam się, że chodzi o te różowe napisy na płytce. To, czy wejście STM32 pracuje jako cyfrowe czy analogowe (podłączone do wejścia wewnętrznego przetwornika analogowo-cyfrowego) zależy od konfiguracji programowej, nie od oznaczeń na płytce. To, że jest napisane obok wyprowadzenia „A3", to nie wyklucza tego, że ten pin (PB0 w tym przypadku - patrz rysunek wyżej) może pracować jako norma
  19. Możesz narysować schemat połączeń i zrobić bardziej wyraźne zdjęcie (bliższe) na płytki? Wydaje mi się, że problem jest w połączeniach. Bazując na dokumentacji płytek, to port PA4 jest wyprowadzony na złącze CN7 (prawy rząd, czwarty pin od dołu), a tam na pewno nic nie masz podłączone:
  20. Hazard to inne zagadnienie. Tutaj problemem jest logika – funkcje wzbudzeń nie współgrają czasowo z aktualną wartością licznika. Sygnały w języku VHDL są uaktualniane przy zakończeniu procesu. To znaczy, przez cały proces zachowują przy odczycie swoją pierwszą wartość. Dlatego obliczeniach funkcje wzbudzeń czytają ich poprzednie wartości. Rozwiązaniem tego problemu może być na przykład zamiana sygnałów (funkcji wzbudzeń) na zmienne – coś takiego (uproszczony proces do symulacji): proc: process(Clk) variable J, K : std_logic_vector(qn'range) := (others => '0'); begin if rising_edge(Clk)
  21. Wydaje mi się, że problem tkwi w funkcjach wzbudzeń K(1) i K(2), gdzie powinny być iloczyny logiczne a nie sumy: K(1) <= qn(2) and qn(0); K(0) <= (not qn(2)) and qn(1); Reszta jest chyba poprawna. Jedynie mogę zasugerować, że fragmenty opisujące przerzutniki można napisać w pętli for: przerzutnikiJK : for ii in J'range loop -- lub for ii in 0 to 2 loop if (J(ii)='0' and K(ii)='0') then qn(ii) <= qn(ii); elsif (J(ii)='0' and K(ii)='1') then qn(ii) <= '0'; elsif (J(ii)='1' and K(ii)='0') then qn(ii) <= '1'; elsif (J(ii)='1' and K(ii)='1') then qn
  22. D jest wewnętrznym sygnałem modułu. Testowanie polega na pobudzaniu zewnętrznych „wyprowadzeń/" (wejść) modułu. Wewnątrz procesu stim_proc umieszcza się takie pobudzenia. W tym przypadku jedynym wejściem jest zegar. Zazwyczaj w takim przypadku jest pisany osobny proces do wytwarzania sygnału taktującego. Proces ten powinien być automatycznie wygenerowany przez program ISE. Tego przede wszystkim brakuje w przedstawionym kodzie. Sygnału D nie zmienia się w symulacji, można jedynie sprawdzać jego wartość. Nie przepisuje się też kodu z modułu do procesu symulacyjnego. Z punktu widzenia modułu
  23. Wprawdzie pytanie ma konkretnego adresata, ale ponieważ wisi kilka godzin, to wtrącę swoje 3 grosze: 1. Przedstawiony kod nie jest do końca zgodny z zasadami składniowymi vhdla. Podstawowy błąd to deklaracja zmiennych poza procesem – zwykłe zmienne definiuje się w funkcjach/procesach. 2. Nie zgadzają się długości wektorów – w instrukcji with select sygnał value jest traktowana jako czterobitowy, a deklarowany jako dwunastobitowy. Poza tym nie ma nigdzie jakiegokolwiek przypisania wartości do niego. 3. Instrukcja with select jest współbieżna, używana poza procesami (przynajmniej
  24. Zgadzam się, rezystancje te nie mają znaczenia w tym przypadku. Można znacząco uprościć analizę układu zauważając to. Ale i bez tego można otrzymać poprawny wynik.
  25. Ciężko się trochę połapać w tym rysunku, zwłaszcza we fragmencie, gdy 2 rezystory się krzyżują jakoś. W tym przykładzie chyba nie ucieknie się od przekształcenia trójkąt-gwiazda, ale najpierw można uprościć pewne pary rezystancji szeregowych. Proponuję zmodyfikować rysunek przemieszczając jedną gałąź z dwoma rezystorami na zewnątrz, tak, żeby wyeliminować skrzyżowanie (w załączeniu), potem szukać par rezystancji szeregowych (można też najpierw te rezystancje szeregowe uprościć). A później chyba trzeba trójkąt zamienić na gwiazdę i znowu szukać par szeregowych i równoległych.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.