MCP2517FD/MCP2518FD - czyli CAN FD w akcji - pierwsza w Polsce próba uruchomienia komunikacji w nowym standardzie CAN :)

Ponieważ dotarły do mnie świeżo wypieczone kontrolery CAN FD firmy Microchip. Zabieram się niezwłocznie za ich rozpracowanie. Bohaterem testu będzie MCP2517FD (obecnie zastąpiony przez MCP2518FD) czyli pierwszy na świecie zewnętrzny kontroler CAN FD. Z tego co się zorientowałem po okolicy :) będzie to również pierwszy praktyczny test w Polsce tego układu. Fajne uczucie jeśli wiemy , że nikogo nie było przed nami na tym polu.

Większe wymagania aplikacyjne w szczególności na rynku motoryzacyjnym wymuszają na producentach komponentów pokonywanie kolejnych barier technologicznych. Wszech obecny CAN 2.0 stał się już dawno wąskim gardłem w przesyłaniu informacji. 1Mb/s i 8 bajtów w jednej ramce CAN, to za mało jak na bieżące i przyszłe wymagania rynku motoryzacyjnego. W przemyśle ,automatyce czy inteligentnym budynku nie jest to może obecnie krytyczny aspekt ale w automotive tak.

CAN FD  daje możliwość przesyłania do 64 bajtów w jednej ramce CAN z prędkością do 8 MB/s Z grubsza CAN FD może być ok 30 razy szybszy niż CAN 2.0. Taki skok możliwości w standardzie robi wrażenie.

Pamiętamy artykuł, w którym udało się odpalić CAN 2.0 w mikrokontrolerach PIC24HJ128GP502, tam kontrolery CAN były na pokładzie procka . Wyprowadzenie kontrolera CAN na zewnątrz procka daje elastyczne możliwości w zakresie wyboru miktokontrolera. W przypadku CAN FD trudno obecnie znaleźć kontrolery zaimplementowane wewnątrz mikrokontrolera a jeśli już, to są to mikrokontrolery 32 bitowe z wyższej cenowo półki i nie mam tu na myśli ARM-ów bo w ich przypadku CAN-FD zobaczymy od poziomu Cortex-M4F.
Mając zatem kontroler MCP2517FD możemy go zaaplikować do dowolnego mikrokontrolera , który posiada szybki protokół transmisji SPI i cieszyć się możliwością wykorzystania nowego standardu CAN.

Do dyspozycji mamy m.in 31 buforów FIFO  na nadawanie i odbiór danych.
Ustanowić możemy 32 filtry i maski.

MCP2517FD  w obudowie SOIC 300 mil (mojej ulubionej) 14 pin obsadzimy na płytce konwertującej SOIC na DIP .

Obsadzone płytki w realu na zdjęciu poniżej :

Na zdjęciu widzimy również przygotowane i czekające w lukach startowych moje autorskie płyteczki bazowe dla mikrokontrolerów 16 i 32 bitowych PIC24/ds33 i PIC32MX. Po prostu lubię na nie patrzeć :)

Strona sprzętowa nie powinna stwarzać problemów bo to będzie raczej najprostsza część testu. Pracuję obecnie nad schematem elektrycznym. Bardziej obawiam się zmierzenia z dokumentacją MCP2517FD bo tutaj trzeba pokonać ok 200 stron dosyć abstrakcyjnej wiedzy i na tej podstawie napisać jakiś soft . Ale udało się wcześniej uruchomić CAN 2.0 na wewnętrznym kontrolerze mikrokontrolera PIC24HJ128GP502, więc będzie to jakaś baza i wsparcie dla zrozumienia zagadnień związanych z MCP2517FD.

Najpierw muszę zapoznać się z SPI w PIC24HJ  i wykorzystaniem DMA do komunikacji , następnym krokiem będzie szczegółowe ogarnięcie komunikacji po SPI miedzy kontrolerem CAN a mikrokontrolerem.


Ogólny schemat podłączenia  kontrolera MCP2517FD :

Z powyższego schematu wynika, że potrzebujemy dwóch napięć zasilania +3.3V i 5V. Zasilanie 5V jest wymagane dla transcivera CAN. Do poprawnej pracy kontrolera CAN, potrzebujemy zewnętrzny kwarc 4,20 lub 40 MHz. Jak widzimy na rysunku kontroler CAN może dać nam sygnał zegarowy dla MCU.

Dokumentacja kontrolera jak wspominałem jest dosyć obszerna aby ją pokonać trzeba trochę czasu. Nie będę wnikał we wszystkie szczegóły skupię się na aspektach z grubsza istotnych w/g mojej oceny.
Aspekt , którego nie możemy pominąć to struktura pamięci kontrolera. Zobaczymy ją na obrazku poniżej :

Jak widzimy pamięć ma szerokość 32 bitów i zawiera trzy bloki funkcjonalne :

- CAN FD Controler Module SFR (Special Function Register)

- RAM 2 KB Message Memory (tu przechowywane są komunikaty CAN)

- MCP2517FD SFR (Special Function Register)

Każdy rejestr SFR lub obszar pamięci RAM ma swój adres początku , którym się posługujemy w procesie wymiany informacji pomiędzy  MCU a kontrolerem.
W tym momencie przytoczymy jak wygląda obrazowo wymiana danych po SPI jest to bardzo istotny aspekt bo bez zrozumienia tego nie zagadamy z kontrolerem.

Nas będą interesować tylko trzy formy : RESET, READ, WRITE.
Każda z tych operacji zaczyna się stanem niskim na pinie nCS kontrolera a kończy stanem wysokim (musimy to programowo załatwić)
Struktura wymiany danych wygląda tak, że na początku wysyłana jest 4-bitowa sekwencja , która determinuje rodzaj operacji. Następnie idzie na 12-bitach adres dostępu do SFR lub RAM kontrolera.
Na końcu sekwencji lecą dane w segmentach bajtowych. tu warto wspomnieć , że wymiana danych z RAM kontrolera odbywa się w sekwencjach 4 bajtowych danych. Czyli w jednej operacji READ lub WRITE lecą 4 bajty danych co daje szerokość pamięci 32 bity ale nie traktujemy tego jako jedną zmienna 32 bitową ale 4 zmienne bajtowe.

Na początku zabawy z kontrolerem musimy stworzyć funkcję , które będą realizować trzy operacje RESET, READ, WRITE w/g opisanego wyżej schematu wymiany danych po SPI.
Kolejnym krokiem powinno być sprawdzenie poprawności działania tych funkcji bo to one będą stanowić fundament współpracy z mikrokontrolerem.
I tutaj STOP. Miłą niespodzianką jest odkrycie tego, że Microchip przygotował specjalne API do obsługi kontrolera. Czyli tak jakby nie musimy odkrywać koła na nowo. W linkach na dole jest przekierowanie m.in do API i innych pomocnych narzędzi takich jak Bit Time Calculations czy RAM Usage Calculations.
API jest przygotowane w MPLAB Harmony pod mikrokontroler PIC32MX470512H. Naszym zadaniem będzie zatem wykorzystanie elementów API od Microchipa stworzenie z tego projektu w MPLABX-IDE i ewentualnie dostosowanie do mikrokontrolera PIC24HJ128GP502. Na pewno jest to mniej roboty niż dzierganie własnej bibliotek.

Na pewno musimy mieć jakieś pojęcie o zegarze kontrolera CAN. Na rysunku poniżej blokowy schemat :

W zasadzie filozofi tutaj żadnej nie ma. Na wejście dajemy zewnętrzny kwarc 4,20 lub 40 MHz i odpowiednimi rejestrami ustawiamy dzielnik zegara wewnętrznego SYSCLK i zegara na wyjściu CLKO , które podłączamy do MCU jako jego źródło zegara. Parametry te konfigurujemy w rejestrze OSC kontrolera. Wszelkie ustawienia zegara, muszą być robione w trybie konfiguracji. Tryb konfiguracji jest ustawiany automatycznie po resecie kontrolera CAN lub możemy go wymusić ustawiając bity REQOP = 100 w rejestrze CiCON.

Kolejnym zagadnieniem wartym odnotowania są tryby pracy pinów kontrolera INT,INT0,INT1 :

Pin INT może być skonfigurowany aby reagował na dowolne zdarzenie dostępne w rejestrze CiINT a jest tego od ciorta.
Pin INT0 może pracować jako przerwanie sygnalizujące nadanie ramki CAN lub jako zwykłe GPIO.
Pin INT1 może pracować jako przerwanie sygnalizujące odbiór ramki CAN lub jako zwykłe GPIO.
Wystąpienie przerwania generuje stan niski na odpowiednim wyjściu.

Nie będę omawiał BIT TIMINGU dla naszego kontrolera bo jest to mocno rozbudowane zagadnienie z pogranicza matematyki i fantastyki :) Jeśli ktoś będzie pisał  doktorat z CAN to na pewno tego zagadnienia nie pominie. My amatorzy mamy do dyspozycji kalkulator od Microchipa  i ewentualnie przykłady typowej konfiguracji dla zadanych parametrów i to nam wystarczy.
O Bit Timingu szerzej pisałem we wcześniejszym  artykule o CAN. Tam możemy doczytać co to za zwierz.

Poniżej zbiór rejestrów kontrolera CAN , tak żeby można było jednym okiem je ogarnąć :)
Specific Register
OSC
IOCON
CRC
ECCCON
ECCSTAT
Configuration Register :
CiCON
CiNBTCFG
CiDBTCFG
CiTDC
CiTBC
CiTSCON
Interrupt and Status Register
CiVEC
CiINT
CiRXIF
CiRXOVIF
CiTXIF
CiTXATIF
CiTXREQ
Error and Diagnostic Register
CiTREC
CiBDIAG0
CiBDIAG1
FIFO Control and Status Register
CiTEFCON
CiTEFSTA
CiTEFUA
CiTXQCON
CiTXQSTA
CiTXQUA
CiFIFOCONm (m=1 to 31)
CiFIFOSTAm (m=1 to 31)
CiFIFOUAm (m=1 to 31)
Filter Configuration and Control Register
CiFLTCONm (m=0 to 7)
CiFLTOBJm (m=0 to 31)
CiMASKm (m=0 to 31)


Teraz przyjrzymy się bliżej pamięci RAM kontrolera służącej do przechowywania komunikatów (obiektów) CAN, zarówno tych do transmisji jak i odebranych.
Jest to wydzielony blok RAM o rozmiarze 2 KB . Determinuje to ile komunikatów możemy upakować do wysłania i ile do odebrania. Mając wiedzę ile komunkatów będziemy wysyłać i ile spodziewamy się odbierać możemy wyliczyć czy nam wystarczy RAM-u w kontrolerze :). Można to wyliczyć na piechotę lub posłużyć się kalkulatorem dostarczonym przez Microchipa (jest w linkach).

W Message Memory czyli RAM kontrolera możemy wyodrębnić trzy rodzaje bloków koegzystujących  z message objects czyli ramkami CAN.
- TEF (Transmit Event FIFO)
- TXQ (Transmit Queue)
- FIFO (RX and TX)

Przedmiotem naszych zainteresowań będzie głównie FIFO, za pomocą tego bloku w Message Memory  będziemy wpisywać i odbierać ramki CAN (message objects). TEF i TXQ zostawiamy do późniejszego rozpoznania te bloczki wyłączamy w rejestrze CiCON.

Jeśli chodzi o FIFO to jak wynika z wykresu powyżej pod jeden"bloczek" lub worek np FIFO2 możemy dopakować teoretycznie dowolną ilość komunikatów (ramek CAN) jedyne ograniczenie to rozmiar pamięci RAM kontrolera czyli 2 KB. Z rejestrów jednak wynika , że jest ograniczenie do 32 wiadomości. i ten parametr jest ustawiany w rejestrze CiFIFOCONm  Jest to unikalne i bardzo ciekawe podejście i jak na razie nie spotkałem się nigdzie z takim rozwiązaniem .
Pomimo pewnego skomplikowania (rozbudowania możliwości) MCP2517FD zaczynam go intuicyjnie coraz bardziej lubić :)

Nie zaszkodzi również mieć pojęcie jaka wygląda z grubsza  ramka CAN FD :

Pole ARBITRATION jest wysyłane z prędkością 1 Mbps/s czyli tak jak CAN 2.0 a pole z danymi DATA z prędkością do 8 Mbps/s.

Szczegółowe omówienie poszczególnych pól znajdziemy w manualu (na dole w linkach). Ważną rzeczą i jednocześnie różnicą w stosunku do CAN 2.0 jest kodowanie w DLC (element pola ARBITRATION) informacji o ilości przesyłanych danych. O ile w CAN 2.0 było to po prostu wpisanie wartości odpowiedającej ilości przesyłanych bajtów to w CAN FD posługujemy się taką tabeleczką :

Czyli jeśli chcemy przesłać 64 bajty to w DLC wpisujemy wartość 15. Jest to istotny szczegół o którym trzeba pamiętać.

Zabieram się powoli za część programową, małymi kroczkami do przodu w chwilach wolnego czasu.
Część programową najpierw chcę zacząć od sprawdzenia poprawności komunikacji z kontrolerem. W szczególności zapisu danych do rejestrów kontrolera i sprawdzeniu czy te wartości poprawnie zostały zapisane.Sprawdzimy jednocześnie poprawność operacji READ i WRITE.
Zrobię to opierając się na  przykładowym kawałku kodu do API. Kod znajduje się w manualu i wygląda tak :

Powyższy fragment kodu z API tworzy dwa bufory txd i rxd. Bufor txd wypełniamy losowymi wartościami a txd wartością 0xFF. Następnie pojawiają się dwie funkcje , zapisująca tablicę z danymi do wybranego rejestru i odczytująca dane z tego rejestru. Na końcu sprawdzamy czy dane w buforach txd i rxd są zgodne. Jeśli tak to operacja zakończyła się sukcesem.Niby proste ale jak zaczniemy rozwijać funkcje i definicje API i implementować je pod własne potrzeby np pod obsługę SPI za pomocą DMA to się trochę zasapiemy.
W moim kodzie testowym bufor nadawczy txd[] wypełnię ustalonymi danymi nie losowymi.

Zadanie nr 1 
Nawiązać, komunikację z kontrolerem , przesłać dane do wybranego rejestru i odczytać je.
Poniżej schemat połaczeń do testów i wykonania Zadania nr 1. Jak widzimy zminimalizowałem funkcjonalnie połączenia i na tym etapie nie podłączyłem transcivera CAN. Mikrokontroler taktowany jest swoim wewnętrznym kwarcem 40 MHz a kontroler CAN zewnętrznym 20 MHz.

No i wreszcie doszedłem do momentu w którym przydałby się analizator stanów logicznych. Muszę podejrzeć jak wygląda w realu wysyłana ramka SPI do kontrolera CAN. Kawałek kodu testowego uruchomiłem i za pomocą debugera sprawdziłem poprawność formowania wysyłanych danych po SPI, wszystko jest oki a kontroler CAN nie zwraca mi danych wcześniej zapisanych do niego.
Analizator zamówiony czekam na dostawę.
Analizator dotarł , cena zakupu z przesyłką 60 zł. Jak na razie są to najlepiej wydane pieniądze w nowym roku. Za pomocą analizatora błyskawicznie wykryłem przyczynę problemu. Zakończenie sygnału na linii CS było w niewłaściwym miejscu w kodzie testowym. Analizator zaoszczędził mi z grubsza z "pół roku" poszukiwań błędu. Dodatkowo okazało się, że SPI musi być delikatnie inaczej skonfigurowane niż standardowe ustawienia w rejestrach. Chwalę dzień w którym dojrzałem do zakupu analizatora stanów logicznych.

Poniżej  pokazuję prawidłowe ustawienia w programie Salea tak aby poprawnie odczytać dane wysyłane i odbierane po SPI przy komunikacji MCU z MCP2517FD. Szybkość próbkowania  Sample Rate ustawione na 8 MS/s (przy zegarze SPI 1.250 MHz) .

Na wykresie od góry mamy odpowiednio :

• sygnał zegara SPI 
• dane wysyłane przez MCU do kontrolera CAN po SPI
• stan wyjścia CS
• dane odebrane od kontrolera CAN 

Dane wysyłane przez MCU to zapytanie do kontrolera CAN o zawartość rejestru OSC. Widzimy tutaj bitową reprezentację danych . Struktura wysłanej ramki SPI to 4 bity (rodzaj operacji Read/Write), 12 bitów adres rejestru lub komórki pamięci RAM do , którego chcemy się odwołać i 4 bajty nie istotne w przypadku odczytu danych z kontrolera CAN. Podczas operacji zapisu do kontrolera te 4 bajty to dane do zapisu (rejestry kontrolera są 32 bitowe ale fizycznie reprezentowane są przez 4 bajty). Adres początku rejestru OSC to E00 (111000000000) adresy kodujemy na 12 bitach w wysyłanej ramce SPI.

W pierwszych dwóch bajtach wysyłanych na linii MOSI mamy sekwencję (0011 + 1110)+(00000000). Cztery pierwsze bity 0011 to wybór operacji odczytu z kontrolera CAN a pozostałe 12 bitów to adres w naszym przypadku E00.
Dopóki na linii CS mamy sygnał niski dopóty wymiana danych pomiędzy MCU a kontrolerem CAN jest aktywna.
Na linii MISO mamy odpowiedź od kontrolera CAN , dane które bierzemy pod uwagę to 4 ostatnie bajty.
Trzeci bajt od lewej reprezentuje zawartość najmłodszego bajtu (bity 0-7) rejestru OSC, czwarty bajt od lewej to drugi bajt rejestru (bity 8-15) etc..

Teraz pokażę poprawną konfigurację SPI w MCU (bez tego zapomnijmy o komunikacji z kontrolerem CAN) :

/*konfiguracja SPI dla Mastera*/

void config_SPI_MASTER(void) {
IFS0bits.SPI1IF = 0; /*Clear the Interrupt Flag*/
IEC0bits.SPI1IE = 0; /*Disable the Interrupt*/
/*Set clock SPI on SCK, 40 MHz / (4*8) = 1,250 MHz*/
SPI1CON1bits.PPRE = 0b10; /*Set Primary Prescaler 4:1*/
SPI1CON1bits.SPRE = 0b000; /*Set Secondary Prescaler 8:1*/
SPI1CON1bits.CKE = 1 ; /*UWAGA ten tryb jest potrzebny do MCP2517FD*/
SPI1CON1bits.MODE16 = 0; /*Communication is word-wide (8 bits)*/
SPI1CON1bits.MSTEN = 1; /*Master Mode Enabled*/
SPI1STATbits.SPIEN = 1; /*Enable SPI Module*/
IFS0bits.SPI1IF = 0; /*Clear the Interrupt Flag*/
IEC0bits.SPI1IE = 1; /*Enable the Interrupt SPI*/
}

Na czerwono zaznaczyłem tryb bez którego nie uzyskamy poprawnej komunikacji z kontrolerem CAN.

UFFF... w sumie kolejny przyczółek zdobyty , przybliża to mnie znacznie do realizacji Zadania 1. Potem wytyczymy sobie kolejne zadanie i tak małymi kroczkami będziemy się posuwać do przodu ,aż do nawiązania komunikacji pomiędzy dwoma węzłami CAN w nowym standardzie CAN FD.. Takie zadaniowe podejście do rozpracowania kontrolera CAN - MCP2517FD wydaje mi się optymalnym podejściem.

Zadania 1 udało się zrealizować, ale się cieszę hurra :) 
Czekamy na wstawienie kodu testowego do realizacji Zadania 1, zrzutów z analizatora stanów logicznych i opisu.

Na powyższym zdjęciu mamy zrzut z analizatora stanów logicznych pokazujący operację zapisu do wybranego rejestru kontrolera CAN. Wybranym rejestrem jest CiFLTCON0 (rejestr 32 bitowy ale traktujemy go w rozbiciu na 4 x bajt).  Adres początku tego rejestru to 1D0 (odczytane z datasheetu kontrolera CAN), na 12 bitach to będzie wyglądać tak : 000111010000. Jeśli dodamy do tego sekwencję 4 bitową WRITE czyli 0010 to po sklejeniu tego mamy 0010_000111010000, jeśli rozbijemy to na dwóch bajtach to mamy wartość w DEC 33 i 208 i to tłumaczy dlaczego na analizatorze na pierwszych dwóch bajtach linii MOSI mamy takie wartości. Kolejne bajty o wartości DEC 140, dowolne dane testowe zapisywane do rejestru  CiFLTCON0. To co pojawia się na linii MISO przy operacji WRITE kompletnie nas nie interesuje.Linia CS (Enable)podczas całej operacji musi być w stanie niskim.

Operacja zapisu do kontrolera CAN jest nudna jak flaki z olejem. O wiele ciekawsza jest operacja READ w której prosimy grzecznie kontroler o przesłanie do MCU danych. W kodzie testowym dane to stałe wartości w DEC 140 na 4 bajtach, wcześniej zapisane w operacji WRITE. Nasza prośba o dane składa się z sekwencji 4 bitowej 0011 i adresu zasobu na 12 bitach o którego dane prosimy . Prosimy o dane rejestru CiFLTCON0 adres początku 1D0 . Robimy składańca tak jak w operacji WRITE i otrzymujemy 0011_000111010000 . W rozbiciu na dwa kolejne bajty da nam to wartości w DEC 49 i 208 i tak wyglądają dwa pierwsze bajty na linii MOSI podczas operacji READ. Cztery kolejne bajty o wartości 0 są bez znaczenia bo nic nie zapisujemy tylko odczytujemy. Na linii MISO otrzymujemy dane zwrotnie od kontrolera CAN, interesują nas tylko cztery ostatnie bajty na linii MISO. Widzimy tam wartość 140 powieloną na czterech bajtach, jest to dokładnie to co w operacji WRITE zapisaliśmy do wybranego rejestru kontrolera CAN.

Mamy zatem czytelny i namacalny dowód na to , że Zadanie 1 udało nam się zrealizować. Traktuję to jako małe zwycięstwo na drodze ku poznaniu kontrolera CAN 2517FD.

Tutaj kod projektu w MPLABX-IDE do realizacji Zadania 1.

Co robi program testowy do Zadania 1 :

Zapis do wybranego rejestru - CiFLTCON0 - 4 x bajt o wartości DEC 140
Odczyt zawartości wybranego rejestru - CiFLTCON0 .

Najważniejsze funkcje kodu testowego to :
DRV_CANFDSPI_WriteByteArray(); /*formuje dane do wysłania i pakuje je do bufora nadawczego DMA0 i wywołuje funkcję wysyłającą*/
 
DRV_CANFDSPI_ReadByteArray(); /*formuje dane do wysłania i pakuje je do bufora nadawczego DMA0, wywołuje funkcję wysyłającą , pobiera odczytane dane z bufora DMA1 i zapisuje je w buforze pomocniczym w pamięci RAM */

DRV_SPI_TransferData();/*funkcja ustawia linię CS w tryb nadawania/odbioru
, konfiguruje kanały DMA0 (jako nadawczy) i DMA1 (jako odbiorczy), odpala transfer DMA, czeka na zamknięcie kanału odbiorczego. Po zamknięciu kanału odbiorczego dane odebrane od kontrolera CAN mamy w buforze odbiorczym DMA. Uwaga linia CS jest zamykana w przerwaniu odbiorczym DMA1*/

Czas na kolejny krok w kierunku poznania kontrolera CAN FD.
Zdefinjujmy zatem kolejne zadanie do wykonania.

Zadanie nr 2
Konfiguracja kontrolera CAN FD. 
W zadaniu tym spróbujemy rozgryźć konfigurację w/g poniższego klucza :

• Reset  MCP2517FD
• Konfiguracja Oscylatora  i ewentualnie CLKO pin
• Konfiguracja  pinów I/O
• Konfiguracja  CAN Control register
• Konfiguracja  Bit Time registers
• Konfiguracja  TEF, TXQ, TX and RX FIFO (przy czym TEF i TXQ wyłączymy)

Inspiracją dla mojego kodu w tym zadaniu będą przykładowe kody z manuala :

Opierając się na powyższych kodach (lekko je modyfikując) spróbujemy w szybki sposób uporać się z Zadaniem 2.

Kod do Zadania 2 mam już gotowy i niebawem go powieszę na Githubie. Program w stosunku do Zadania 1 znacznie się rozbudował , dodane zostały m.in nowe funkcje zapisu i odczytu. Na tym etapie nie będę sprawdzał poprawności działania konfiguracji, zrobię to za pomocą ostatniego zadania w którym będę próbował przesłać ramkę CAN FD z jednego MCU do drugiego.


Tutaj kod projektu w MPLABX-IDE do realizacji Zadania 2

Tylko uczulam, że to nie są dokładnie te same funkcje co w API od Microchipa, troche je podrasowałem tak aby mnie było wygodnie a nie Microchipowi :)

Przechodzimy do ostatniego zadania w którym spróbujemy przesłać ramkę CAN FD z 64 bajtami danych. 


Zadanie nr 3
Transmisja i odbiór ramki CAN FD.

Do nadania i odbioru ramki CAN FD posłużymy się przykładem z API Microchipa.

cdn..

Pozdrawiam
picmajster.blog@gmail.com



Linki :
MCP2517FD - datasheet
MCP2517FD - manual
MCP2517FD - API, Bit Time Calculations, inne