Skocz do zawartości

Przeszukaj forum

Pokazywanie wyników dla tagów 'FPGA'.

  • Szukaj wg tagów

    Wpisz tagi, oddzielając przecinkami.
  • Szukaj wg autora

Typ zawartości


Kategorie forum

  • Elektronika i programowanie
    • Elektronika
    • Arduino i ESP
    • Mikrokontrolery
    • Raspberry Pi
    • Inne komputery jednopłytkowe
    • Układy programowalne
    • Programowanie
    • Zasilanie
  • Artykuły, projekty, DIY
    • Artykuły redakcji (blog)
    • Artykuły użytkowników
    • Projekty - roboty
    • Projekty - DIY
    • Projekty - DIY (początkujący)
    • Projekty - w budowie (worklogi)
    • Wiadomości
  • Pozostałe
    • Oprogramowanie CAD
    • Druk 3D
    • Napędy
    • Mechanika
    • Zawody/Konkursy/Wydarzenia
    • Sprzedam/Kupię/Zamienię/Praca
    • Inne
  • Ogólne
    • Ogłoszenia organizacyjne
    • Dyskusje o FORBOT.pl
    • Na luzie
    • Kosz

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Rozpocznij

    Koniec


Ostatnia aktualizacja

  • Rozpocznij

    Koniec


Filtruj po ilości...

Data dołączenia

  • Rozpocznij

    Koniec


Grupa


Znaleziono 14 wyników

  1. Cześć, dzisiaj wykonałem próbę podłączenia prostej kamery VGA (sensor CMOS) do zestawu FPGA firmy QMTECH z Artix-7 (chip FPGA: XC7A100T-2FGG677i). Tutaj jest link do tego zestawu: https://pl.aliexpress.com/item/4000170042795.html?spm=a2g0o.productlist.0.0.1bbc3a488cWayC&algo_pvid=b8e2d6de-11a7-4045-be1d-dc82c5229b85&algo_expid=b8e2d6de-11a7-4045-be1d-dc82c5229b85-3&btsid=39edaf33-09cc-4522-882b-0168a91a733d&ws_ab_test=searchweb0_0,searchweb201602_4,searchweb201603_55i Zestaw ten kupiłem jakiś czas temu i postanowiłem go użyć w tym projekcie ze względu na dużą ilość zasobów - szczególnie dużą ilość BRAM 4,660Kb (potrzebna na frame-buffer). Pewnie łatwiej i sensowniej byłoby podłączać jakąś kamerę z interfejsem MIPI (i lepszym sensorem), ale nie posiadam żadnego zestawu FPGA, który by miał wbudowany taki interfejs Jest to moja pierwsza próba podłączenia jakiejkolwiek kamery do zestawu FPGA. Wybrałem tanią kamerę "OV7670" (sensor firmy Omnivision) - tutaj link do sklepu (chińskiego): https://www.banggood.com/Wareshare-OV7670-Camera-Module-CMOS-Acquisition-Board-Adjustable-Focus-300000-Pixel-p-1478355.html?rmmds=search&cur_warehouse=CN Tutaj link do datasheet do tego sensora: https://www.voti.nl/docs/OV7670.pdf Wybrałem projekt ze strony "FPGA4Student" ponieważ z kilku branych pod uwagę wydał mi się najprostszy:był https://www.fpga4student.com/2018/08/basys-3-fpga-ov7670-camera.html Projekt był zrobiny dla zestawu FPGA "Basys 3" z Artixem-7 (XC7A35T-1CPG236C) który posiada tylko 1800 Kb wewnętrznej pamieci BRAM - stąd frame-buffer obsługuje tylko max. rozdzielczość 320x240. Można by go też odpalić na zestawach "Artix-7 35T Arty" lub "Digilent Cmod At-35T" - tutaj linki do tych zestawów: https://kamami.pl/zestawy-uruchomieniowe/560134-artix-7-35t-arty-zestaw-ewaluacyjny-dla-fpga-artix-7.html https://kamami.pl/zestawy-uruchomieniowe/562401-digilent-cmod-a7-35t-modul-uruchomieniowy-z-fpga-artix-7-410-328-35.html Ale wracając do projektu - moja płytka FPGA firmy QMTECH (XC7A100T) nie posiada wyjściowego interfejsu VGA (ma HDMI które wypróbowałem i które działa dobrze), stąd wynikła potrzeba zbudowania go samemu. Wybrałem prosty interfejs (12) rezystorów wzorując się na układzie z zestawu "Basys 3". Tutaj schemat tego interfejsu: Zmontowałem do na płytce prototypowej (potrzebne jest gniazdo VGA 15 pinowe). Tak wygląda cały układ z kamerą, interfejsem VGA (na zielonej płytce) i zestawem FPGA QMTECH. A tu obraz na monitorze (tylko składowa niebieska): Jak widzicie próba nie zakończyła się pełnym sukcesem obraz jest o rozdzielczości 320x240 pikseli (i tak miało być) natomiast jest widoczna na ekranie tylko składowa niebieska.Podejrzewam, że błąd jest na zielonej płytce z interfejsem VGA - bo była ona dzisiaj "na szybko" polutowana a nie była najpierw przetestowana (może pomyliłem się przy gnieździe VGA). Zamieszczam tu pełen projekt dla Vivado 2018.3. Plik constraints dla mojej płytki QMETCH, ale na oryginalnej stronie projektu mo\zna pobrać pełen projekt dla "Basys 3". basys3_ov7670_v1.zip W najbliższym czasie zamierzam usunąć błędy z interfejsu VGA oraz zwiększyć pojemność frame-buffer'a do pełnej rozdzielczości VGA (na mojej płytce powinno wystarczyć pamieci BRAM w układzie FPGA). Zamieszczam projekt, bo może ktoś będzie także chciał spróbować podłączyć taki model kamery do układu FPGA. Zachęcam wszystkich do własnych prób z układami FPGA, bo w dziale "Układy programowalne" na Forbocie ostatnio bardzo mało się dzieje. Pozdrawiam
  2. Układy FPGA wydają się trochę bardziej tajemnicze niż mikrokontrolery. Można jednak dość szybko rozpocząć z nimi przygodę za pomocą narzędzi graficznych. W tutorialu przyjrzymy się układowi z rodziny Max10 znanej firmy Intel. Wykorzystamy go do sterowania silnikiem krokowym. Gotowy prototyp przedstawia Rys. 1. Rys. 1. Zmontowany prototyp. Składamy sprzęt W projekcie wykorzystamy płytkę Rysino z stosunkowo niewielkim układem z rodziny 10M04. Podłączymy do niej silnik krokowy 28BYJ-48 poprzez sterownik zbudowany z wykorzystaniem popularnego układu ULN2003. Nasz silnik składa się z dwóch uzwojeń. Każde z nich ma w połowie wyprowadzony odczep. Kolory z rysunku odpowiadają kolorom przewodów zamontowanych w użytym modelu. Obrót silnika następuje, gdy zmieniamy ich polaryzację poprzez zasilenie złącza +, albo złącza -. W tym projekcie skorzystamy z najprostszego typu sterowania zwanego pełno krokowym. Rys. 2. Stany na cewkach silnika. Rys. 3. Przebiegi czasowe na cewkach silnika. Na Rys. 2. widzimy, że aby obracać silnik musimy po kolei ustawiać cztery różne kombinację napięcia na cewkach. Natomiast Rys. 3. pokazuje jak będą wyglądały przebiegi przedstawione w tabelce. Jeżeli będziemy przechodzić „z góry na dół” nasz silnik będzie wykonywał obroty zgodnie z kierunkiem ruchu zegara. Aby zmienić kierunek obrotu wystarczy przełączać stany w przeciwnym kierunku. Pojawia się tu słowo klucz: stan, które pozwoli nam wybrać sposób implementacji sterownika. Zbudujemy maszynę stanów. Ale najpierw podłączmy silnik do układu FPGA. Schemat połączenia pokazuje Rys. 4. To jego wykonania potrzebujemy przewodów połączeniowych. Rys. 4. Sposób połączenia płytki Rysino z sterownikiem silnika. Wsad dla układu FPGA Aby zbudować wsad dla układu FGPA potrzebujemy zintegrowane środowisko dostarczone przez producenta. Najpierw musimy jednak się zarejestrować. Następnie ze strony producenta pobieramy środowisko Quartus Prime Lite Edition. Ja korzystałem z wersji 18.1. Pobieramy: Quartus Prime (includes Nios II EDS) (1.7GB) MAX 10 FPGA device support. (330MB) Jak widzimy niestety są to dość duże pliki... Po instalacji możemy przejść do tworzenia projektu. Przygotujemy go w całości w narzędziach graficznych. Składa się on z dwóch głównych części. Najpierw przygotujemy maszynę stanów, którą widzimy na Rys. 5. Rys. 5. Maszyna stanów. Następnie umieścimy gotową maszynę w projekcie, dołożymy licznik zmniejszający szybkość przełączania stanów oraz wejścia i wyjścia. Gotowy schemat pokazuje Rys. 6. Rys. 6. Diagram gotowego projektu. Jednak opisywanie „wyklikiwania” poszczególnych elementów było by dość zagmatwane, dlatego przygotowałem film, w którym zobaczymy wszystko krok po kroku. A na samym końcu znajdziemy demonstrację działania gotowego projektu. Na końcu pozostaje już tylko podłączenie płytki do komputera za pomocą przewodu miniUSB. Do złącza JTAG podłączamy programator USB Blaster i wgrywamy nasz projekt. Cały projekt jest także dostępny w repozytorium.
  3. Witam, po wgraniu przykładu( zgodnie z tym co jest na forum) płytka Elbert v2 przestała odpowiadać, jest jakiś sposób aby naprawić ? Po podłączeniu w windows wyświetla się "Nie rozpoznano urządzenia USB( żadanie deskryptora nie powiodło się)" , natomiast wskaźnik led( to inaczej te segmentowe ledy) się świeci. Załączam plik mojego projektu, aby udowodnić, wszystko jest tak samo jak w kursie Forbot( oprócz tego że mryganie_led zmieniłem na blink_led). EDIT( Jakiś czas później): Problem został naprawiony dzięki zrobieniu jednej prostej rzeczy. Jeśli ktoś też ma problemy to zalecam spojrzeć na: Unbricking Elbert . project_test.zip
  4. Witam, mam do sprzedania w pełni sprawny zestaw startowy Terasic DE0-Nano-SoC. Używałem go sporadycznie do nauki systemów wbudowanych i emulacji projektów w FPGA. Cena 300zł, sprzedaję razem z oryginalnym pudełkiem i dowodem zakupu ze sklepu Kamami. Odbiór osobisty w Gdańsku lub wysyłka kurierem.
  5. Posiadam kamerę Sony FCB-EV7520 (dokumentacja w załączniku), której wyjściem wideo jest sygnał w postaci YPbPr 4:2:2 wysyłany za pomocą interfejsu LVDS. To czego potrzebuje to napisanie programu na układ FPGA, który odbierze sygnał LVDS, przekształci go i wypuści sygnał zgodny ze standardem HDMI lub USB. Nie jest to coś nowego, bo tego typu urządzenia są w sprzedaży, lecz są drogie 350€ i mają już konkretny kształt, a w przyszłości chciałbym móc to zamknąć na swojej PCB. Jeżeli masz doświadczenie z FPGA, szczególnie z przetwarzaniem wyżej wymienionych sygnałów wideo to zapraszam do kontaktu. Jestem zainteresowany kompleksowym rozwiązaniem, ale również jestem otwarty na współpracę na zasadzie wskazania kierunku, zasugerowania możliwego rozwiązania i pomocy w wyborze odpowiedniego sprzętu. FCB-EV7520_Manual.pdf 22_FCB-EV7520A_S.pdf
  6. Cześć, ponieważ I2C jest jednym z najprostszych szeregowych protokołów komunikacyjnych (i jest bardzo często stosowany) postanowiłem sprawdzić jak wygląda przykładowa implementacja na zestawie FPGA. Zacząłem od prostszej rzeczy, czyli implementacji "I2C slave" (poniekąd też slave jest mi bardziej przydatny do moich eksperymentów). Ponieważ projekt jest stosunkowo prosty i nie zajmuje dużo zasobów postanowiłem go przetestować na zestawie FPGA ElbertV.2 (ten używany w kursie FPGA Forbot'a). Masterem I2C będzie zwykłe "Arduino UNO" - z poziomu Arduino bardzo prosto można oprogramować komunikację po I2C z użyciem biblioteki Wire. Punktem wyjścia do implementacji "I2C Slave" jest darmowy projekt zamieszczony na stronie opencores.org. Tutaj link do projektu: https://opencores.org/projects/i2cslave Projekt ma stosunkowo prostą budowę i jest właściwie tylko szkieletem do budowy na jego podstawie bardziej skomplikowanych układów (będzie to wyjaśnione dalej). Jak przeważnie się to zdarza trzeba było dodać nowy zegar (DCMs 1 ze Spartan3A) 48 MHz (pętla PLL), ponieważ oryginalny projekt pracował z takim zegarem. Po wykonaniu potrzebnych przeróbek projekt zajmuje niecałe 30% zasobów układu Spartan3 z Elberta - patrz screen: Jak można zobaczyć na podglądzie RTL - top entity projektu ma bardzo prosty interfejs - patrz screen: Tutaj kod w Verilog'u głównego modułu projektu (już po dodaniu zegara PLL 48 MHz) `include "i2cSlave_define.v" module i2cSlaveTop ( clk, rst, sda, scl, myReg0 ); input clk; input rst; inout sda; input scl; output [7:0] myReg0; wire clk48Mhz, clkBufg; // Instantiate the module PLL clock PLL_clock PLL_48Mhz ( .CLKIN_IN(clk), .RST_IN(~rst), .CLKFX_OUT(clk48Mhz), .CLKIN_IBUFG_OUT(clkBufg) ); i2cSlave u_i2cSlave( .clk(clk48Mhz), .rst(~rst), .sda(sda), .scl(scl), .myReg0(myReg0), .myReg1(), .myReg2(), .myReg3(), .myReg4(8'h12), .myReg5(8'h34), .myReg6(8'h56), .myReg7(8'h78) ); endmodule Jak widać "i2cSlaveTop" ma trzy wejścia: clk - główny zegar projektu (w Elbercie 12 Mhz) rst - reset asynchroniczny - stanem High więc dla naszej płytki FPGA trzeba go było zanegować scl - zegar magistrali I2c , jedno wejście/wyjście (inout) sda - dane magistrali I2C i jedno wyjście (wektor 8 bitów) myReg0 - na tym wyjściu równoległym będą się pojawiać dane wysłane przez mastera I2C (Arduino UNO), dlatego podłączymy je do diod LED w zestawie Elbert, aby móc te dane łatwo obserwować. Tutaj treść pliku ucf (user constraints) dla płytki FPGA Elbert: NET "clk" LOC = P129 | IOSTANDARD = LVCMOS33 | PERIOD = 12MHz; NET "rst" PULLUP; NET "rst" LOC = P76; NET "sda" LOC = P31 | IOSTANDARD = LVCMOS33 | SLEW = FAST | DRIVE = 12; NET "scl" LOC = P32 | IOSTANDARD = LVCMOS33 | SLEW = FAST | DRIVE = 12; # myReg0 - 8 bit data NET "myReg0[7]" LOC = P46 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[6]" LOC = P47 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[5]" LOC = P48 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[4]" LOC = P49 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[3]" LOC = P50 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[2]" LOC = P51 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[1]" LOC = P54 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; NET "myReg0[0]" LOC = P55 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 12; Jak widać zdefiniowany jest domyślny pin zegara (12 MHz), reset - dolny z pięciu switchy, diody LED (myReg0 - dane przesłane po I2C do płytki Elbert), scl i sda 2 piny magistarli I2C (pierwsze dwa piny złącza P1 na płytce Elbert - patrz rysunek: Jeśli chodzi o piny magistrali I2C (scl, sda) od strony Arduino UNO to zaznaczyłem je fioletową obwódką na rysunku pinout'u dla UNO: Oczywiście pomiędzy zestawem FPGA (poziom logiki 3,3V) a Arduini UNO (poziom logiki 5V) trzeba wstawić na tych dwóch liniach (scl, sda) konwertery poziomów logicznych.Ja zrobiłem to za pomocą takiego konwertera poziomów (bo tylko taki miałem pod ręką) https://botland.com.pl/pl/konwertery-napiec/2523-konwerter-poziomow-logicznych-dwukierunkowy-4-kanalowy-pololu.html Tutaj zdjęcie całego układu (konwerter poziomów na płytce stykowej): Skoro połączenia mamy omówione wróćmy może do kodu projektu (Verilog). Przejdżmy do pliku "i2cSlave_define.v" plik ten jest dołączany (dyrektywa include) za pomocą linii: `include "i2cSlave_define.v" do wszystkich plików żródłowych projektu (Verilog) podobnie jak w języku C. W pliku tym mamy zdefiniowane bardzo ważne parametry modulów - patrz źródła: // ----------------------- i2cSlave_define.v -------------------- // stream states `define STREAM_IDLE 2'b00 `define STREAM_READ 2'b01 `define STREAM_WRITE_ADDR 2'b10 `define STREAM_WRITE_DATA 2'b11 // start stop detection states `define NULL_DET 2'b00 `define START_DET 2'b01 `define STOP_DET 2'b10 // i2c ack and nak `define I2C_NAK 1'b1 `define I2C_ACK 1'b0 // ---------------------------------------------------------------- // ------------- modify constants below this line ----------------- // ---------------------------------------------------------------- // i2c device address `define I2C_ADDRESS 7'h3c // System clock frequency in MHz // If you are using a clock frequency below 24MHz, then the macro // for SDA_DEL_LEN will result in compile errors for i2cSlave.v // you will need to hand tweak the SDA_DEL_LEN constant definition `define CLK_FREQ 48 // Debounce SCL and SDA over this many clock ticks // The rise time of SCL and SDA can be up to 1000nS (in standard mode) // so it is essential to debounce the inputs. // The spec requires 0.05V of hysteresis, but in practise // simply debouncing the inputs is sufficient // I2C spec requires suppresion of spikes of // maximum duration 50nS, so this debounce time should be greater than 50nS // Also increases data hold time and decreases data setup time // during an I2C read operation // 10 ticks = 208nS @ 48MHz `define DEB_I2C_LEN (10*`CLK_FREQ)/48 // Delay SCL for use as internal sampling clock // Using delayed version of SCL to ensure that // SDA is stable when it is sampled. // Not entirely citical, as according to I2C spec // SDA should have a minimum of 100nS of set up time // with respect to SCL rising edge. But with the very slow edge // speeds used in I2C it is better to err on the side of caution. // This delay also has the effect of adding extra hold time to the data // with respect to SCL falling edge. I2C spec requires 0nS of data hold time. // 10 ticks = 208nS @ 48MHz `define SCL_DEL_LEN (10*`CLK_FREQ)/48 // Delay SDA for use in start/stop detection // Use delayed SDA during start/stop detection to avoid // incorrect detection at SCL falling edge. // From I2C spec start/stop setup is 600nS with respect to SCL rising edge // and start/stop hold is 600nS wrt SCL falling edge. // So it is relatively easy to discriminate start/stop, // but data setup time is a minimum of 100nS with respect to SCL rising edge // and 0nS hold wrt to SCL falling edge. // So the tricky part is providing robust start/stop detection // in the presence of regular data transitions. // This delay time should be less than 100nS // 4 ticks = 83nS @ 48MHz `define SDA_DEL_LEN (4*`CLK_FREQ)/48 Dla nas najważniejsze są dwa parametry: `define I2C_ADDRESS 7'h3c Pierwszy to adres naszego slave'a w magistrali I2C (jest dostepnych 128 różnych adresów) - wynosi on 3C zapisany heksadecymalnie. Drugi to częstotliwość zegara - 48 MHz: `define CLK_FREQ 48 Teraz drugi plik "registerInterface": `include "i2cSlave_define.v" module registerInterface ( clk, addr, dataIn, writeEn, dataOut, myReg0, myReg1, myReg2, myReg3, myReg4, myReg5, myReg6, myReg7 ); input clk; input [7:0] addr; input [7:0] dataIn; input writeEn; output [7:0] dataOut; output [7:0] myReg0; output [7:0] myReg1; output [7:0] myReg2; output [7:0] myReg3; input [7:0] myReg4; input [7:0] myReg5; input [7:0] myReg6; input [7:0] myReg7; reg [7:0] dataOut; reg [7:0] myReg0; reg [7:0] myReg1; reg [7:0] myReg2; reg [7:0] myReg3; // --- I2C Read always @(posedge clk) begin case (addr) 8'h00: dataOut <= myReg0; 8'h01: dataOut <= myReg1; 8'h02: dataOut <= myReg2; 8'h03: dataOut <= myReg3; 8'h04: dataOut <= myReg4; 8'h05: dataOut <= myReg5; 8'h06: dataOut <= myReg6; 8'h07: dataOut <= myReg7; default: dataOut <= 8'h00; endcase end // --- I2C Write always @(posedge clk) begin if (writeEn == 1'b1) begin case (addr) 8'h00: myReg0 <= dataIn; 8'h01: myReg1 <= dataIn; 8'h02: myReg2 <= dataIn; 8'h03: myReg3 <= dataIn; endcase end end endmodule Plik ten jest o tyle ważny, że widać w nim iż w projekcie jest używanych 8 rejestrów 8-mio bitowych (cztery wejściwe i cztery wyjściowe). Ale tylko jeden rejestr jest w głównym module (implementacja jest trochę niepełna - o czym autor pisze, że jest to punkt wyjścia do własnych implementacji). Dla nas jest jedynie istotne, że dla adresu 8'h00 (czyli 0 dziesiętnie rejestr myReg0 jest obsługiwany poprawnie), będzie to istotne przy pisaniu mastera I2C na Arduino UNO. Tutaj zamieszczam działający projekt " I2C slave" (dla Elbert'a) - Xilinx ISE 14.7: I2CSlave01.zip Jeśli ktoś nie chce uruchamiać syntezy może od razu załadować za pomocą programu "Elbert V2 Configurator" plik "i2cslavetop.bin" do zestawu FPGA. Po wgraniu do zestawu FPGA Elbert pliku konfiguracji i wykonaniu połączeń z Arduino UNO możemy przejść do programu dla Arduino. Najpierw warto programem "I2C scanner" sprawdzić, czy Arduino z załadowanym programem skanera wykryje nam slave'a i2C pod adresem 0x3C. Tutaj kod progrmu "I2C scanner" - program należy skompilować za pomocą "Arduino IDE" i wgrać do płytki Arduino UNO. Kod programu: #include <Wire.h> void setup() { Wire.begin(); Serial.begin(9600); while (!Serial); // Leonardo: wait for serial monitor Serial.println("\nI2C Scanner"); } void loop() { byte error, address; int nDevices; Serial.println("Scanning..."); nDevices = 0; for(address = 1; address < 127; address++ ) { // The i2c_scanner uses the return value of // the Write.endTransmisstion to see if // a device did acknowledge to the address. Wire.beginTransmission(address); error = Wire.endTransmission(); if (error == 0) { Serial.print("I2C device found at address 0x"); if (address<16) Serial.print("0"); Serial.print(address,HEX); Serial.println(" !"); nDevices++; } else if (error==4) { Serial.print("Unknown error at address 0x"); if (address<16) Serial.print("0"); Serial.println(address,HEX); } } if (nDevices == 0) Serial.println("No I2C devices found\n"); else Serial.println("done\n"); delay(5000); // wait 5 seconds for next scan } Tak wygląda prawidłowe wykrycie slave'a (FPGA) pod adresem 0x3C na magistrali I2C przez Arduino: Jeśli to zadziała, to możemy wgrać taki krótki program mastera I2C na Arduino UNO: #include <Wire.h> void setup() { Wire.begin(); // join i2c bus (address optional for master) } byte x = 0; void loop() { Wire.beginTransmission(0x3C); // transmit to device #3C Wire.write(0); //wysylamy adres rejestru 0 (ten odczytany w kodzie Verilog) Wire.write(x); // wysylamy jeden bajt - wartosc x Wire.endTransmission(); // stop transmitting x++; delay(500); } Jeśli wszystko poszło OK, możemy obserwować na diodach zestawu Elbert zmienijącą się wartość x (inkrementowaną co jeden obieg pętli głównej programu) przesyłaną z mastera (Arduino) do slave'a (FPGA). Patrz filmik (sorry nie mogę przesłać na forbot pliku mp4 z filmem). Pozdrawiam
  7. Cześć jestem tu nowy zakupiłem niedawno płytkę Elbert V2 do Waszego kursu, mam pytanie dotyczące instalacji środowiska ISE, która wersja będzie dla mnie najbardziej kompatybilna z zestawem ( mam windows 10 ) w instrukcji dotyczącej kursu jest podana wersja dla windowsa 7 powinienem ją zainstalować, czy pobrać wersję dla mojego windowsa 10? aktualizowaną 2018r. czy pobranie nowszej wersji znacząco utrudni mi "przejście" kursu? Pozdrawiam
  8. W ramach pewnego projektu muszę obsłużyć komunikację za pomocą interfejsu LVDS w układzie programowalnym FPGA (lub w zasadzie, w tej chwili, SoC). Interesuje mnie zarówno nadajnik, jak również odbiornik. Szukam materiałów na ten temat w internecie i w zasadzie jedyne co znalazłem to odpowiednie skonfigurowanie pinów i użycie prymitywów (np. IBUFDS - dla Xilinxa) w kodzie VHDL (tego języka używam). Czy jest jakaś (w miarę prosta) możliwość zastąpienia tych prymitywów własnym kodem? Nie mam pomysłu na napisanie takiego elementu, niewprowadzającego zbędnych opóźnień. Zależy mi na zapewnieniu możliwie jak największej „przenoszalności" kodu. Czy jest możliwość sprawdzenia, co tak naprawdę znajduje się w tych prymitywach (chciałbym zobaczyć, co „siedzi" w środku)? Czy może jest to po prostu fizyczny element, „zaszyty" wewnątrz FPGA? Czy jeżeli opiszę własny komponent, mający dwa wejścia (sygnały różnicowe zanegowany i nie) i jedno wyjście (które będzie po prostu podłączone do wejścia niezanegowanego lub będzie działać według załączonej tabeli zaczerpniętej z dokumentacji Xilinxa), to narzędzie do syntezy „domyśli się", że trzeba wstawić w to miejsce wejściowy bufor różnicowy? Czy nie będzie problemu z przeniesieniem projektu na inny układ (innego producenta)? Przepraszam za poziom pytań, ale pierwszy raz będę korzystał z transmisji różnicowej i nie wszystko jest dla mnie jasne. Ponadto, nie mam dużego doświadczenia z układami programowalnymi.
  9. Jakiś czas temu na forum zaprezentowałem projekt procesora zrealizowanego na układzie FPGA. Był to układ zrealizowany na dwóch płytkach Elbert v2. Aby go uruchomić należało wykonać dość sporo pracy. Dzisiaj prezentuję pierwszą wersję układu DCE Q816, czyli bezpośredniej kontynuacji poprzedniego projektu. Można powiedzieć, że pierwsza wersja Q818 to tak naprawdę Q816 zrealizowany tylko na jednej płytce Elbert v2. Układ jest w pełni kompatybilny z poprzednim projektem oraz posiada identyczną listę rozkazów. Na ten moment nie będę skupiał się na budowie procesora, ponieważ jest ona praktycznie identyczna jak w układzie Q816. Jedyną różnicą jest to, że pamięć ROM oraz procesor zaimplementowane została na tym samym układzie FPGA. W związku z tym każdy, kto posiada płytkę Elbert v2 może pobrać projekt, który dostępny jest tutaj, a następnie uruchomić procesor Q818 w swoim domu. Po implementacji projektu na płytce FPGA powinniśmy zobaczyć następujący efekt świetlny. Należy również wspomnieć, że porty procesora skonfigurowane zostały w następujący sposób. przełączniki DIP Switch - wejście IN procesora (logika odwrotna) przycisk SW1 - RESET port P1 - wyjście OUT1 procesora diody LED - wyjście OUT2 procesora Programowanie procesora odbywa się poprzez zmianę zawartości pamięci ROM procesora. Aby tego dokonać musimy otworzyć plik ROM.vhd i następnie wpisać binarną zawartość kolejnych komórek pamięci. Najmłodsze 5-bitów to rozkaz dla procesora. Kolejne 8 to tzw. dana bezpośrednia, którą możemy przesłać do innych rejestrów. Poniżej umieszczam spis dostępnych rozkazów procesora oraz instrukcje dla ALU zapisywane w rejestrze C. Na ten moment jest to pierwsza wersja układu Q816 w przyszłości postaram się o uporządkowanie samego kodu, jak i dodanie kolejnych funkcji. O zmianach i kolejnych wersjach postaram się informować w komentarzach do tego posta.
  10. Chciałbym krótko opisać projekt który obecnie realizuję a jest to procesor zrealizowany na układzie FPGA. DCE Q816 (nazwa własna bez większego znaczenia) to 8 bitowa jednostka o architekturze mojego własnego pomysłu. Procesor może działać przy maksymalnej częstotliwości taktowania 12MHz. Dodatkowym układem pełniącym funkcję pamięci ROM oraz koprocesora jest DCE Q817 również zrealizowany na układzie FPGA. Pierwszy jak i drugi układ powstały na płytce Elbert v2 a jest to płytka z kursu FPGA na Forbot. Kolejnymi elementami wchodzącymi w skład projektu jest wyświetlacz 7 segmentowy oraz LCD dzięki którym mamy możliwość komunikowania się ze światem zewnętrznym. Jak widać na zdjęciu płytki z układami FPGA przeszły kilka modyfikacji. Odlutowane zostały wyświetlacze LED, część przycisków oraz diody LED. Dzięki temu do dyspozycji miałem więcej pinów. Procesor może obsłużyć prosty program zapisany w pamięci ROM pełna lista rozkazów dostępna jest poniżej. Proces budowy oraz projektowania układu opisuję na moim blogu oraz Fanpagu. Jeżeli kogoś zainteresował temat zapraszam do zapoznania się z większą liczbą informacji. Dodatkowo poniżej umieszczam filmy pokazujące możliwości procesora DCE Q186.
  11. Witam, chciałbym zapytać czy do płytki z kursu Forbot możliwe jest podpięcie układu CD4056 (BCD-7 segment). Dokładniej mam na myśli podpięcie czterech wyjść FPGA do wejść BCDA układu. Czy zasilając układ scalony napięciem 5V nie uszkodzę FPGA? Wydaje mi się że takie połączenie nie uszkodzi FPGA ponieważ jego wyjścia podpięte zostaną do wejść układu zasilanego napięciem 5V. Na tych końcówkach nigdy nie powinno pojawić się 5V ponieważ są to wejścia. Jednak chciałbym na wszelki wypadek zapytać czy na pewno dobrze myślę.
  12. Temat o Arduino w dziale układów programowalnych może się w pierwszej chwili wydawać nieco nie na miejscu, ale chciałem napisać kilka słów o interesującej płytce od Arduino, a mianowicie o tytułowym MKR Vidor 4000. Układ chociaż zaprojektowany przez fundację Arduino jest jednak dość nietypowy. Nie znajdziemy w nim starego i niekoniecznie dobrego AVR, zamiast tego jest SAMD21 z rdzeniem ARM Cortex-M0+, 256KB pamięci flash oraz 32KB RAM. To jeszcze nic nadzwyczajnego, ciekawie robi się dalej. Okazuje się, że na tej małej płytce znalazło się miejsce na jeszcze jeden mikrokontroler - jest to moduł WiFi oparty o ESP32. Na koniec najciekawsze, czyli układ programowalny FPGA ze stajni Intel-a (dawniej Altery): nowiutki Cyclone 10. Więcej o samej płytce można przeczytać na stronie Arduino: https://store.arduino.cc/usa/arduino-vidor-4000 Płytka ma ogromne możliwości, ale wydaje się być jeszcze w fazie nazwijmy to późnego prototypu. Oprogramowanie nie jest jeszcze dopracowane, nie wszystko zostało opublikowane, a część kodu ma typowe dla Intela problemy z licencją - albo raczej z jej brakiem. Do tego nie najlepiej wygląda dokumentacja. Trochę to przypomina Intel Edison-a, ale miejmy nadzieję, że Intel nie spaprze kolejnego fajnego urządzenia. To co na dzień dzisiejszy jest dostępne to wsparcie dla płytki MKR 4000 w Arduino IDE. Dostępne są również cztery dedykowane biblioteki oraz nieco przykładów. Zabawę z płytką najlepiej zacząć od przeczytania instrukcji, czyli: https://www.arduino.cc/en/Guide/MKRVidor4000 W niej znajdziemy podstawowe informacje o płytce - zapomniałem wspomnieć, że jest dostępna nawet ładowarka dla akumulatora Li-Po. Zgodnie z instrukcją warto uruchomić nieśmiertelny przykład z migającą diodą - działa Z kolejnymi przykładami jest nieco trudniej. Ja na razie przetestowałem raptem kilka. Na początek bibliotekę "WiFiNINA" do obsługi WiFi za pomocą modułu firmy U-BLOX. Zgodnie z oczekiwaniami wszystko działa poprawnie, chociaż łączenie z siecią zajmuje zaskakująco dużo czasu - to chyba wina małej anteny przyklejonej na termogluta... producent chyba zdawał sobie sprawę, że zawalił projekt, bo opisano to w języku marketingu następująco: "The WiFi antenna built-in in the u-blox NINA-W102 module is made for embedded products and should NOT be touched." W każdym razie WiFi działa, czyli na początek mamy Arduino + moduł wifi. Można testować dalej. Kolejny etap to podłączenie monitora HDMI. MKR 4000 jest wyposażony w wyjście micro-HDMI podłączone do układu FPGA. Po podłączeniu monitora można zobaczyć logo Arduino: Jednak uruchomienie własnego programu (nawet przykładowego) jest nieco trudniejsze. Okazuje się że musimy uruchomić monitor portu szeregowego i... podłączyć monitor po uruchomieniu programu. Przynajmniej u mnie inaczej nie działało. Ale długo zgadywałem o co chodzi W każdym razie podłączając stary sprawdzony monitorek 7" udało mi się uzyskać Arduino z wyjściem HDMI: Samo programowanie odbywa się tradycyjnie w Arduino IDE. Cała komunikacja z FPGA ukryta jest w bibliotekach. Przykładowy program wygląda następująco: #include "VidorGraphics.h" #include "Vidor_GFX.h" Vidor_GFX vdgfx; void setup() { Serial.begin(9600); // wait for the serial monitor to open, // if you are powering the board from a USB charger remove the next line while (!Serial); // Initialize the FPGA if (!FPGA.begin()) { Serial.println("Initialization failed!"); while (1) {} } } void loop() { // Fill the screen with a white background vdgfx.fillRect(0, 0, 640, 480, vdgfx.White()); vdgfx.text.setCursor(150, 240); vdgfx.text.setAlpha(255); vdgfx.text.setSize(5); vdgfx.text.setColor(vdgfx.Blue()); vdgfx.println("Forbot"); while (1) { } } Arduino z monitorem to nie koniec możliwości jakie daje MKR 4000. Na płytce znajdziemy jeszcze złącze MIPI do podłączenia kamery. Jak można przeczytać na stronie jest to "Omnivision OV5647 camera. The MIPI camera connector is a standard format that you find on several commercial products". Okazuje się, że chodzi o kamerę do Raspberry Pi - wersja 1.3 zadziałała bez problemu. Dołączony przykład pozwala na wyświetlenie na monitorze HDMI obrazu, który rejestruje kamera: Nie widać tego na zdjęciu, ale warto podkreślić, że to nie jest znany z kamer dla Arduino standard 1 FPS. Obraz wyświetlany jest płynnie, a brak ostrości wynika z totalnie zdewastowanej kamery którą podłączyłem (jakoś nie miałem odwagi eksperymentować z nowym egzemplarzem). Wśród przykładów znajdziemy również rozpoznawanie kodów QR - ale wymaga lepszego "obiektywu" niż ma moja kamerka". Na koniec najciekawsze. Na mikrokontroler SAMD21 można wgrać "emulator" programatora FPGA, czyli USB Blaster-a. Dzięki temu będziemy mogli programować układ Cyclone 10 bezpośrednio z poziomu Quartus-a. Producent dostarcza kilka przykładowych projektów: https://github.com/vidor-libraries Jednak jak wspominałem, baza oprogramowania wydaje się dopiero powstawać. Ale jeśli Intel nie zniechęci się do własnego produktu, MKR 4000 wydaje się być bardzo ciekawym rozwiązaniem. Na koniec dostępność - jak zwykle Botland: https://botland.com.pl/pl/arduino-team-oryginalne-plytki/12946-arduino-mkr-vidor4000-abx00022-modul-z-fpga-cyclone-10.html A cena - porównując z Arduino raczej zaporowa, ale przy porównaniu z modułami FPGA - bardzo korzystna.
  13. Witam, tak jak w tytule mam do sprzedania zestaw startowy Terasic DE0-Nano, kupiłem go już dość dawno temu, ale prawie go nie używałem i tylko się kurzy, więc postanowiłem się go pozbyć. Myślę, że 200 zł będzie dobrą ceną za niego. Optymalny dla mnie jest odbiór osobisty w Warszawie, ewentualnie wysyłka(do ceny należy doliczyć jej koszt).
  14. Witam, Chciałbym zaprezentować swojego pierwszego robota "Robot FPGA v02". Opisywana konstrukcja to dwukołowy robot napędzany silnikami DC bezpośrednio połączonymi z kołami. Podwozie podpiera się na ruchomej kulce znajdującej się z tyłu. Platforma mobilna została wykonana z plastiku łączonego klejem lub śrubami. Silniki DC sterowane są metodą PWM i podłączone są do wyjść podwójnego mostka H bazującego na układzie L298. Zasilanie robota to osiem akumulatorów typu AA. Oprogramowanie zostało napisane w języku VHDL i wykonuje się na układzie FPGA Altera Cyclon II. Platforma FPGA to płytka rozwojowa Terasic DE1, zasilana jest przez przetwornicę impulsową. Robot posiada zapisaną na stałe sekwencję ruchów. W kodzie są to dwie listy, gdzie pierwsza lista zawiera nazwę ruchu, druga lista zawiera czas przez jaki ma się on wykonywać. Lista komend ruchu: IDLE, FORWARD, BACKWARD, TURN_LEFT, TURN_RIGHT, ROTATE_L, ROTATE_R. Dane techniczne: Masa robota: 965g Wymiary: szerokość, długość, wysokość : 190mm/200mm/105mm Maksymalna prędkość: 0.295 m/s (1.062 km/h) Maksymalny kąt podjazdu: 30 stopni Prześwit: 10mm Promień koła: 30mm Napięcie zasilania płytki FPGA Terasic DE1: 7,5V Parametry wyjść płytki DE1: 3.3V/25mA Napięcie zasilania silników DC: od 8,8V do 10,4V Rodzaj zasilania: 8 akumulatorów AA (NiMH) Częstotliwość PWM: 2000Hz Robot jest podstawową platformą, która posiada miejsce i zasoby pozwalające na rozbudowę i ulepszenia. Dla zainteresowanych, szczegóły opis projektu znajduje się na stronie: Link do dokumentacji robota
×
×
  • Utwórz nowe...