Temat: Obsługa prokokołu CAN w układzie FPGA

Witam wszystkich,

zastanawiam się jak zrobić prostą komunikację (wyświetlanie stanu układu) dla prostego sterownika rolet (który to temat poruszałem we wcześniejszych postach). Po drugiej stronie (mieszkanie) byłby mikro-kontroler z niedużym (dotykowym wyświetlaczem).
Dlaczego mój wybór padł właśnie na "CAN BUS":
1) Jest to protokół szeregowy i wymaga tylko dwóch kabli oraz zapewnia transmisję na duże odległości (przy odpowiednim zmniejszeniu prędkości transmisji)
2) Jest mocno niezawodnym protokołem
3) Jest dostępnych sporo płytek implementujących ten protokół dla mikro-kontrolerów (z gotowymi bibliotekami)
np. dla Arduino UNO
4) Nie ukrywam, że bardzo ważnym powodem jest chęć nauki powszechnie używanego protokołu (implementacji w układach FPGA jak i za pomocą programu dla mikro-kontrolera)

Znalazłem IP core na opencores.org:

https://opencores.org/project,can

Jak i wersję ewaluacyjną dla FPGA Xilinx:

https://www.xilinx.com/products/intellectual-property/d...

Czy myślicie, że dla początkującego w tematyce FPGA to zbyt ambitny plan?

Pozdrawiam

Temat: Obsługa prokokołu CAN w układzie FPGA

Nie używaj słowa "prosty" ponieważ dla każdego to pojęcie oznacza zupełnie co innego (to takiego samego pokroju słowo jak "odpowiedni" czy "oczywisty" - coś co rasowy inżynier unika za wszelką cenę). Natomiast jeśli chodzi ci o komunikację to odpowiedź sam sobie udzieliłeś - po prostu dobierasz taki protokół i standard, który tobie jako konstruktorowi pasuje do własnych potrzeb (a co w 4 punktach ująłeś). I nie - czemu zaraz ma to być zbyt ambitne - da się to zrobić od ręki. Skoro wybrałeś CAN no to sposób podłączenia masz załatwiony (wiadome - CAN H i CAN L, czyli na jednej linii np: logiczna 1, a na drugiej logiczne 0 i vice wersa czyli różnicowe przesyłanie danych) i tylko zostaje implementacja wysyłania i odbierania ramek w postaci maszyny stanów (oczywiście nie chodzi od razu o implementację całego protokołu, a tylko tego co ci jest potrzebne do komunikacji - np uznajesz, że ci synchronizacja niepotrzebna to nie dodajesz mechanizmu "Bit Stuffing" - uznasz, że dany rodzaj ramki też ci niepotrzebny to i nie uwzględniasz tego w maszynie stanów itd. Ja w końcu tak implementowałem kontroler do kart SD w pracy magisterskiej idąc i tak wbrew zaleceniom w oficjalnym dokumencie standardu bo i tak pewne rzeczy były mi autentycznie niepotrzebne.) W każdym razie cała sprawa sprowadza się do jednego: budujesz maszynę stanów, w której przez określoną liczbę cykli zegara wysyłasz pojedynczy bit (przez ile to zależy jaki ty zegar dobierzesz i jaką przepustowość chcesz sobie założyć - typu, że od biedy mam tylko 10 MHz na płycie, a chcę mieć 1 Mbps - no to wtedy masz 1 bit trwający przez 10 cykli zegarowych), po wysłaniu nasłuchuje początku ramki od innego odbiornika, odbiera ją i interpretuje itd. Jedna czynność - jeden stan maszyny w dużym skrócie. Generalnie proponuję zacząć od obsługi RS232 czy też UART-a, jako że pod względem implementacyjnym to jest zbliżone do CAN-a i łatwiej i szybciej to zrozumieć (jak to pojmiesz to i CAN-a od ręki zrobisz). I tyle :)Ten post został edytowany przez Autora dnia 24.09.17 o godzinie 17:32

Temat: Obsługa prokokołu CAN w układzie FPGA

W zasadzie to przy różnych modułach czy rozwiązaniach dominuje SPI (najpopularniejszy), no ale tak jak mówię - to tobie ma być wygodnie, a nie że bierzesz protokół, który jest najpopularniejszy bo taka moda.

Temat: Obsługa prokokołu CAN w układzie FPGA

Cześć,

stwierdziłem jednak, że protokół CAN jest zbyt skomplikowany dla tego projektu. Postanowiłem zostać przy RS485 jako warstwie fizycznej i prostym protokole tekstowym (moim własnym) w najwyższej warstwie modelu ISO-OSI.

Mam już działającą komunikację RS485 pomiędzy Elbert V2 a mikro-kontrolerem Arduino-Uno.

Osiągnąłem to poprzez implementację UART (tylko Tx - bo potrzebuję tylko prostej komunikacji w jedną stronę od FPGA do mikro-kontrolera).

Wykorzystałem implementację UART Tx z tej strony :

https://github.com/FPGAwars/FPGA-peripherals/wiki/Async...

zajmuje około 50 LUT i działa super (tylko trochę niefart, że to Verilog , ale kod czytelnie napisany).

UART Tx z FPGA jest połączony z takim konwerterem UART-RS485:

https://botland.com.pl/konwertery-usb-uart-rs232-rs485/...

Z "drugiej strony" jest Arduino-UNO + taki sam konwerter Sparkfun UART-RS485 (z prostym programem). Sprawdzałem na na 10-cio metrowym kablu (skrętka kat. 5) działa to super.

Odległość pomiędzy układami była powodem dla którego nie mogłem zastosować protokołu SPI czy I2C.

Mój protokół tekstowy ma bardzo proste ramki wiadomości (wysyłam komunikaty o stanie sterownika w jedną srtronę z FPGA do uC, nawet nie martwię się, czy komunikat na pewno został odebrany poprawnie - "jak w UDP" . Jeśli stwierdzę, że potrzebuję transmisji z potwierdzeniem to zaimplementuję "drugą część" UART -> Rx.

PozdrawiamTen post został edytowany przez Autora dnia 24.10.17 o godzinie 17:50

Temat: Obsługa prokokołu CAN w układzie FPGA

I o to mi chodziło, gdy mówiłem, że implementujesz tylko wybrane elementy standardów - sam pokazałeś, że potrzebny był ci wysył, a odczyt już nie i tego nie implementowałeś (chyba, że ewentualnie w przyszłości). A to co zamieściłeś jako link to w praktyce tak się właśnie implementuje UART-y czy inne szeregowe standardy ala użyty przez ciebie RS485 (z pętlą prądową, więc nie dziwota, że i 10 metrów jest nieźle:) ) czy też po prostu RS232. A że Verilog - spokojnie - konstrukcje te same, tylko inna składnia (C-podobna po prostu) - po pewnym czasie przywykniesz tak jak ja :) I już :)