piotr96

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

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.

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)

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.

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 |

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.

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

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

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

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 (

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

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

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

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

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