CAN – Controller Area Network

Magistrala Controller Area Network (CAN) opracowana przez niemiecką firmę BOSCH na potrzeby komunikacji w przemyśle samochodowym(ABS, sterowanie silnikiem), jest standardem multipleksowanej magistrali szeregowej. Jej niezaprzeczalne cechy użytkowe sprawiły, że z pozycji magistrali przeznaczonej do pojazdów przeszła do technologii popularnej w przemyśle i określonej przez międzynarodowy standard ISO 11 898.

W ostatnich latach wprowadzono do stosowania
również standard wojskowy MIL CAN.

Szeroki zakres zastosowań obejmuje między innymi:

———— zastosowania w technice cywilnej:
– inteligentne budynki,
– przemysł lotniczy,
– przemysł samochodowy – samochody osobowe i ciężarowe,
– ciężki sprzęt budowlany,
– pojazdy specjalne (np. wozy strażackie),
– przemysłowe układy automatyki i sterowania;

———— zastosowania w technice wojskowej:
– transportery opancerzone – kołowe i gąsienicowe,
– stacje radiolokacyjne – morskie i lądowe,
– mosty przewoźne,
– symulatory,
– inne;

———— inne zastosowania:
– sworznie pomiarowe,
– czujniki i przetworniki pomiarowe,
– sterowniki plc,
– pulpity i konsole operatorskie,
– konwertery.

Z w/w jest kilka którymi zajmuje się na co dzień, ale zakres tego zastosowania
jest nieco poza możliwościami tego tematu więc skupmy się na podstawach.

Jak więc wiemy z poprzedniego tematu Podstawą standardu pracy magistrali CAN
jest siedmio-warstwowy model odniesienia ISO/OSI. W przypadku systemów
komunikacji m/in w magistrali pojazdów warstwy 3..6 są puste, i tylko warstwy 1,2 i 7
są wyspecyfikowane szczegółowo.

Czym więc są te owe warstwy ?? no cóż prawie jak w torcie ciasto/masa/ciasto/masa/
no dobra obiecałem że się poznęcam nad wami wiec jazda

—– Warstwa 1

Jest to warstwa fizyczna , w tej warstwie znajduje się specyfikacja medium transmisji
danych oraz złączy, poziomów przesyłania oraz elementów nadawczo-odbiorczych.
Wiąże się ona bezpośrednio z dwoma standardami CAN:

ISO11529-2 – mała szybkość
ISO11898 – duża szybkość

—– Warstwa 2

To warstwa łącza danych. Tu określa się sposób dostępu do medium przesyłania danych w odniesieniu do faktu gdy jakaś cześć systemu chce nadawać, oraz tworzony jest komunikat (adres, sterowanie, dane i zabezpieczenie przed błędami CRC) oraz ustalany jest protokół przesyłania danych. Warstwa 2 była modyfikowana i dziś są 2 jej wersje CAN2.0A i CAN2.0B. O właściwościach obu będziemy mówić później.

Przez ostatnie lata opracowano 3 obszerne gałęzie CAN dla róznych aplikacji, są to:

CANopen, DeviceNET i SDS (Smart Distributed System).

Specyfikacje ich są zbyt obszerne jak na tak małą prezentację w tym poście że pozwolę sobie jedynie na podsumowanie a więc w skrócie ze są one kompatybilne z Warstwami 1 i 2. Dla chcących zgłębić temat i poszerzenie wiedzy o w/w gałęziach proponuję odwiedzenie strony : http://www.can-cia.de

Jak więc zauważyliście w WF jest zawarta cała specyfikacja topologi sieciowej dla magistrali CAN i dołączania do niej kolejnych stacji. Termin topologia sieci – jednoznacznie mówi nam o fizycznej konstrukcji systemu komunikacyjnego i odpowiada na nasuwające się wam pytania.

Czyli gdybyście chcieli mnie teraz zapytać — Jak stacje/elementy są podłączone do magistrali CAN??
– odpowiedzią jednoznaczną z mojej strony było by stwierdzenie : TOPOLOGIA SIECI !

No ale jak na nieopierzonych newbie przystało wcale nie musicie wiedzieć co ja mam na myśli mówiąc TS więc już pędzę wyjaśnić i radzę dobrze to zapamiętać gdyż TS odnosi się nie tylko do CAN ale i wielu innych magistral, ale to stanie się jasne już za chwilę:

Wiec CAN jak już wiecie wykorzystuje topologię sieci (czasem nazywaną topologią magistrali) co oznacza że wszystkie bez wyjątków urządzenia i elementy są połączone z pojedynczą skrętką pary przewodów mogącej mieć ekran lub nie zakończoną na obu końcach odpowiednią rezystancją terminującą co widzicie poniżej:

Taka organizacja zapewnia, że każda stacja/element może komunikować się z każdym innym w sieci bez żadnych ograniczeń.

Jak widzicie wyżej układ transceiwera R/TX sieci CAN jest połączony z medium przez 2 sygnały CAN-H (Can High) i CAN-L (CAn Low), uwzględniając wymagane zabezpieczenie przed błędami, w rzeczywistym przesyle danych zastosowano różnicowe sygnały napięciowe, oznacza to tyle, że różnica napięcia między obydwoma liniami czyli CAN-H i CAN-L jest skwantowana. W standardzie ISO11898 wyspecyfikowane są dwa różne zakresy napięć różnicowych, służących do reprezentacji danych, a więc :

– recesywny i dominujący (cokolwiek to znaczy no nie)

Jest jednak ku temu ważna przyczyna, mianowicie zwykła logika 0 i 1 tu nie jest stosowana.teraz nie będę pisał dlaczego i po co, ale zauważcie że :
( to jest ważne radzę czytać uważnie bo później będzie tylko coraz dziwniej i trudniej)

– gdy napięcie różnicowe pomiędzy CAN-H i CAN-L wynosi 0,5V – to status linii jest — RECESYWNY,
– zaś gdy napięcie różnicowe wynosi 0,9V – to mamy status magistrali — DOMINUJĄCY

Poziom nominalny magistrali jest wyznaczany w odniesieniu poszczególnych LINI do MASY LOKALNEJ co widać poniżej:

(Obrazek 1)

Oczywiście w praktyce nie jest tak fajnie i poziomy te maja swoje tolerancje  Napięcie różnicowe może nawet osiągać maksymalny dopuszczalny poziom widoczny w ostatnim wierszu tabelki

(Obrazek 2)

Specyfikacja CAN-L w ISO11519-2 jest nieco inna, ale jako że ISO11898 może być zastosowane dla małych i dużych prędkości obecnie stosuje się tylko tą specyfikację.

Użytkownik nie musi się w tym przypadku zajmować tak prozaicznymi zajęciami jak konstrukcja łącz TRX, ponieważ wielu producentów oferuje gotowe układy , które zostały zoptymalizowane w szczególności kładąc nacisk na eliminacje zakłóceń elektromagnetycznych (EMC), ale też przeciążeń termicznych występujących w przypadku zwarcia linii CAN-L i H, oraz wyjściowego standardu poziomów sygnałów dla magistrali CAN. Odpada więc wszystko co jest niezbędne do zestawienia łącza CAN i dołączenia go do magistrali. Jedyne czym musimy się zająć to upewnić dla jakiego standardu CAN układ został zbudowany. JA preferuję ISO11898.

Powinniście na tym etapie wiedzieć tez że w praktyce używa się również innych sposobów różnicowego przesyłu danych, które też mogą być użyte do przesyłania sygnałów CAN,

Np ….. i tu was zaskoczę ….  RS485

Co zdziwieni ?? …. w takim razie widać ile jeszcze przed wami tajemnic do odkrycia

Ostatecznie na tym etapie są jeszcze 2 sprawy których nie sposób lekceważyć, a dotyczą one:

– maksymalnej długości i związanej z tym szybkości magistrali
oraz
– ilości możliwych do dołączenia na magistrali stacji bądź elementów

Zasadniczo dyktuje nam te zagadnienia tylko i wyłącznie zastosowane medium, wspomniałem już we wprowadzeniu jak to wygląda w tabelce , ale teraz nieco rozszerzymy wiadomości i przypomnimy sobie:)

Widzicie tu korelacje między szybkością przesyłu , a długością i terminatorami na końcach magistrali. Z doświadczeń wynika że najlepszym medium jest skrętka pary przewodów o przekroju 0.34 do 0.6 mm2, z terminatorami o rezystancji 127om, przy czym rezystywność przewodów nie powinna być większa niż 60mOm/m, warunek ten jest spełniony gdy przekrój poprzeczny przewodu jest większy niż 0,30mm2.

Przy dołączaniu stacji bezpośrednio do magistrali CAN długość przewodów linii doprowadzających nie powinna być dłuższa niż 2m jeśli szybkość ma wynosić 250kb/s, natomiast nie więcej niż 30cm jeśli chcecie uzyskać większe szybkości. I tu mała uwaga !!!

Długość „CAŁKOWITA” wszystkich linii doprowadzających nie powinna być większa niż 30m. 

Uffff …

Myślę że wprowadzenie i zgrubne opisy standardów oraz podstawy budowy CAN
mamy za sobą tym samym możemy zająć się już zagadnieniami przesyłania danych oraz budową ramki , a potem zbudujemy nasz interfejs CAN …

—- Wymiana DANYCH…….

Wymiana danych w CAN może się odbywać na dwa sposoby, mianowicie możemy:
– odwołać się do określonej stacji (orientacja na stację)
lub
– podanie określonej wiadomości (orientacja na wiadomość)

Wynika z tego ze stacje mogą być adresowane, a powoduje to że „nadawca” adresuje „odbiorcę” podając po prostu adres stacji. Przykładowo Termometr chce wysłać wynik pomiaru do sterownika wentylatora. Niech to będą nasze umowne Stacje 10 i 60. W tym celu najpierw ustalane jest połączenie „rzeczywiste” pomiędzy nadawcą , a odbiorcą. Pakiet danych zawiera w sobie adres zarówno Termometru jak i Sterownika. Jeśli mamy na linii inne urządzenia np Woltomierze, inne termometry , sterowniki oświetlenia itd.. to ignorują one ten pakiet bo nie jest do nich adresowany.
Nasz sterownik wentylatora po odebraniu wiadomości zwykle wysyła potwierdzenie, a jeśli wystąpi błąd transmisji lub brak potwierdzenia, termometr będzie powtarzał transmisję. W drugim przypadku wiadomość ma nadany niepowtarzalny identyfikator i zostaje wysłana magistralą

– np. nasz termometr wysyła wynik pomiaru temperatury wody z identyfikatorem 678. Tu nie ma wyspecyfikowanych adresów i nadajnika i odbiornika , czyli wiadomość może być skierowana do kilku odbiorców dołączonych do magistrali.
Urządzenia korzystają z niej w zgodzie z zasadą :

Bierz to co jest ci potrzebne !

Czyli wszystkie urządzenie odbierają pakiet , ale muszą zadecydować czy jest im potrzebna czy nie.

Wymiana informacji w magistrali CAN jest realizowana na zasadach rywalizacji kontrolowanej, poprzez opatrzenie wiadomości odpowiednim priorytetem lub nadaniem właściwej ramki. W rzeczywistości jak już wspomniałem transmisja danych nie jest realizowana w postaci tradycyjnych 0 i 1, ale poprzez bity dominujące i recesywne. Co ciekawe stan recesywny na magistrali może być nadpisany przez stan
dominujący. Czyli jeśli jedna stacja nadaje stanem recesywnym, a inna dominującym to magistrala automatycznie ustala pierwszeństwo dla bitu dominującego. Reasumując stany logiczne na magistrali są ustalone następująco:

0 – reprezentuje stan dominujący , a 1 stan recesywny

Taki stan w sumie tworzy podstawy specyfikacji CAN i powinniście to zapamiętać i dobrze zrozumieć.

Wymiana danych w CAN jest zasadniczo oparta na 4rech ramkach : danych, zdalnego wywołania, błędu i przepełnienia. Ramkę danych stosuje się w celu wysłania na linię informacji. Standardowo wygląda ona następująco:

[Obrazek3]

jest to zgodne ze specyfikacją CAN2.0A

Zaczynamy …… skupcie się choć trochę … wiem wydaje się trudne , ale nie taki diabeł straszny popatrzcie na rysunek ramki w poście wyżej … z lenistwa nie chce mi się kopiować …. hihihihi

SOF ….

tak nazywa się bit startowy ramki, zawsze jest on bitem dominującym czyli jego poziom = 0 Każde urządzenie na magistrali swoje wewnętrzne stopnie odbiorcze właśnie z nim synchronizują, a dokładnie z jego zboczem narastającym.

Pole arbitrażu

ma ono długość 12bitów i zawiera tylko określenie dostępu do magistrali, w uproszczeniu jest to sekwencja decyzyjna

IDENTYFIKATOR ….

zawiera on 11bitów ID ramki. Słowo 11 bitowe, z którego składa się ID umożliwia utworzenie aż 2048 rożnych identyfikatorów. Wprawdzie dostępnych jest tylko 2032 bo pozostałe są zarezerwowane dla funkcji specjalnych. W zasadzie to i tak wiele bowiem jeden sterownik potrafi poradzić sobie z przetworzeniem 2032 różnych wiadomości które mogą zawierać wiele danych jak wyniki pomiarów, pozycje przełączników czy różne sygnalizacje i wiele innych…

Dla nas pewnie to już jest wystarczająca ilość przynajmniej na tym etapie wiedzy , ale warto napomnieć, że okazuje się iż jest to za mało w wielu zastosowaniach. Spowodowało to powstanie ramki EFF (Extended Frame Format), która posiada 29 bitowy ID czyli właśnie wspomniany wcześniej CAN 2.0B. Przy ID 29Bit możliwe jest przetworzenie aż 536 870 912 ramek.

RTR ……

jak wspomniałem jest to bit zdalnego żądania transmisji (Remote Transmision Request), odpowiada on za zaadresowanie i wysłanie wiadomości do określonego urządzenia na magistrali. Zwykle jest on ustawiony na stan 0 czyli jest bitem dominującym. Bit ten jest dosyć ważny gdy jakieś dane są pilnie potrzebne.

Pole sterujące …….

w 6 bitach tego pola zawiera się informacje o budowie ramki danych.

IDE

jest to bit rozszerzenia identyfikatora (Identifier Extension).
Ustawienie tego bitu informuje nas o standardzie formatu :
Gdy IDE = 0 format standardowy ID-11
Gdy IDE = 1 format rozszerzony ID-29

r0 ….

mało istotny zapasowy bit w razie kolejnych mutacji ….

DLC …….

zawiera 4 bity, które wskazują ile bitów jest kolejno transmitowanych, w CAN specyfikacja określa pole danych w rozmiarze od 0 do 8bajtów na ramkę.

Pole danych ……

jak już pewnie się domyślacie ma długość 8bajtów danych do transmisji

CRC ….

aż 15 bitów dodatkowych informacji, które mają na celu zabezpieczyć transmitowane dane przed błędami transmisji. nadajnik generuje 15 bitowa sumę kontrolną , na podstawie transmitowanych danych i wysyła je wraz z ramka danych, a odbiornik oblicza na podstawie odebranych danych podobna sumę CRC i porównuje z odebrana jeśli są identyczne transmisja może być kontynuowana, a jeśli nie uruchamiana jest procedura korekcji błędu. CRC jest zakończone bitem ograniczającym zazwyczaj przesyłanym w stanie 1.

Potwierdzenie …

2 bity tego pola służą do wysłania potwierdzenia poprawności transmisji danych.

ACK …..

zawiera tylko 1bit zwykle recesywny czyli w stanie 1 i może zostać nadpisane bitem w stanie 0, który wysyła inne urządzenie na magistrali. Daje to możliwość odbiorcom potwierdzenia poprawnego odbioru danych. Czyli ACK to bit okienka przerwy, podczas którego możliwe jest przez nadajnik Odebranie potwierdzenia od odbiorników. ACK jest zamykane transmisja 1 w tym bicie (ACK delimiter)

EOF …..

nie no panowie toż wiadomo że to End of FRAME czyli koniec RAMKI , ale składa się on aż z 7 bitów w stanie 1 czyli recesywnych zamykających kompletna ramkę.

Zanim zaczniemy nadawanie kolejnej ramki musimy chwilkę poczekać aż odbiorniki na naszej magistrali przetworzą lub przynajmniej zapamiętają odebrane dane. Ta przerwa a właściwie jej długość określona jest przez 3 bitowe pole przerwy kończące każdą ramkę, które są wystawione w stan recesywny.

UFF… przebrnęliśmy przez ramkę teoretycznie więc jesteśmy w stanie ja skompletować i mam nadzieje że ja rozumiecie jak nie to czytać jeszcze raz  bo zacznie się problematyka użytkowania magistrali CAN mianowicie występowanie
konfliktów, które mogą się przytrafić w przypadku jednoczesnego nadawania 2ch lub więcej urządzeń. Wypadało by jednak jakoś kontrolować i decydować które urządzenie może nadawać, a które musi poczekać.

Ale to omówimy trochę później. nadmienię teraz tylko iż istnieje specjalna procedura dostępu do magistrali, która pozwala kontrolować gadatliwość urządzeń i ważna role odgrywa tutaj pole decyzyjne (Arbitration Field), a właściwie bity recesywne
lub dominujące zawarte w tym polu. Każde urządzenie na magistrali CAN MUSI !!! przestrzegać tej procedury.

Wygląda strasznie no nie ??
To prawdziwy horror użytkowników CAN bójcie się bardzo się bójcie …. ta procedura to istne maniactwo pełne zawiłości i niejasności. ustrojstwo tak paskudne jak płytka stykowa bez styków w środku ….. albo jeszcze coś gorszego ….

….
Strach ma wielkie oczy …………………………………………….

W sumie to pokrótce opiszę ta zarazę w miarę możliwości ….

W uproszczeniu wygląda to tak … w zasadzie żadne uproszczenie bo ten mechanizm jest banalnie prosty choć strasznie zawile opisany w specyfikacji. Całość funkcjonalna sprowadza się do tego że:

(uwaga tylko dla czytelników pełnoletnich o mocnym sercu i braku problemów
z hemoroidami i tym podobnymi …..
:)

Każdy układ na magistrali CAN który nadaje …. odbiera swoje dane (echo jak na terminalu) czyli każdy jeśli np termometr wyśle jakiś bit , odbierze go z powrotem, wtedy następuje porównanie go z wysłanym , jeśli są one identyczne oznacza to, że może nadawać,a jak nie to jest problem bo nie wolno nadawać to właśnie zawarte w polu decyzyjnym bity recesyjne mogą zostać nadpisane przez inne urządzenie bitem dominującym. Ale dlaczego tak się dzieje wyjaśnimy później bo mam na razie dość po za tym nie chciałbym by ktoś dostał palpitacji wątroby lub powyrywał sobie wszystkie włosy z połyskującej w zachodzącym słońcu, wypolerowanej na wysoki połysk łysiny

Słowo się rzekło więc troszeczkę koniecznie i bezwzględnie , żeby nie powiedzieć
” z uporem maniaka  ” będę wam kładł prastarą wiedzę szamańską — no dobra nie aż tak starą

————- Arbitraż ….. trochę zawiłości technicznych

To co teraz napiszę odnosi się do uproszczenia napisanego wyżej , celem moim w tym wywodzie nie jest teraz mieszanie wam w głowach ….. aczkolwiek zupka ze świeżych umysłów …. dosyć kuszące  niemniej musimy choć w minimalnym stopniu poznać budowę stopni wejściowych urządzeń dołączonych do magistrali CAN by zrozumieć zjawisko Arbitrażu — czyli pola decyzyjnego, które odpowiada za wagę wiadomości i pozwala uniknąć wielu przykrych sytuacji podczas przesyłu danych.

Do dzieła ……

[Obrazek 4]

powyższy obrazek stanowi dosyć duże uproszczenie obwodów dołączających , urządzenia do magistrali CAN. Zasadniczo ” stopnie wejściowe ” są w konfiguracji otwartego kolektora co tworzy tzw. iloczyn galwaniczny – można powiedzieć takie „zwarte AND”. Jeśli odniesiemy się w naszym przypadku do układu 1 (ten po lewej) to nadawany recesywnie bit 1 zagwarantuje że tranzystor w stopniu wejściowym nie będzie przewodził. Cała magistrala zostanie wiec ustawiona wstępnie na stan recesywny (1) po czym urządzenie odczytuje stan magistrali, i jeżeli teraz zostanie wysłany bit dominujący (0) to nasz tranzystor zostanie włączony a co za tym idzie linia magistrali będzie zwarta do masy. Czyli znajdzie się w stanie dominującym (0), a nasze urządzenie 1 ponownie odczyta otrzymany z powrotem wysłany bit.

W przypadku naszego przykładu jeśli tylko jedno z naszych urządzeń nada bit dominujący to spowoduje to zmianę stanu na linii magistrali na 0 w efekcie czego oba urządzenia odczytają ten stan.

Wynika z tego właśnie realizacja procedury dostępu do magistrali. Jak to ??? — teraz pewnie chcecie spytać.

Przecież jest to oczywiste. Załóżmy że oba nasze urządzenia są gotowe do wysłania własnych ramek z różnymi identyfikatorami np. U1 – ID361, a U2 232 … hmmm oba rozpoczynają uzgadnianie dostępu tak zwaną fazą arbitrażową czyli nadają bit SOF, jest on bitem dominującym, co powoduje że obydwa doczyta zwrotnie swój własny wysłany … no tak ale się okazuje że oba są poprawne więc oba mogą nadawać !
Spoglądnijmy więc na mały rysuneczek pozwalający zrozumieć co się będzie działo i dlaczego:)

[Obrazek 5]

Tak to prawda ale oba zaczynają nadawanie identyfikatorów, następnie podczas „b” wysyłają bit dominujący i wszystko jest tak jak powinno, podczas „c” dalej nic się nie zmienia, ale podczas „d” 1 wysyła bit recesywny podczas gdy 2 dalej nadaje dominujący. Wiec co się stanie ??

1 połapie się po odebraniu zwrotnym że wysłany stan 1 został zmieniony na 0 co oznacza że właśnie straciła dostęp do magistrali na rzecz 2jki. W takiej sytuacji nasze U1 przechodzi na tryb odbiorczy (mimo że uparcie próbuje dalej nadawać swoje dane) natomiast U2 kontynuuje transmisje. Jak widać U2 wygrała i może wysłać swoje dane bez przeszkód.

Zapewne zauważyliście że jako pierwsza w tym wypadku dostało zgodę na transmisję to urządzenie które nadawało najmniejszy ID — oznacza to że uzyskało najwyższy priorytet wysyłki. Jak więc się domyślacie —- przynajmniej powinniście — no chyba, że nieuważnie czytaliście ten trochę nudny opis — w ID zawarte jest również automatyczne pierwszeństwo w transmisji wiadomości.

Pamiętajcie więc że dane z ID = 0 będą zawsze przesłane PIERWSZE !!!, a np z ID 2000 … trochę sobie poczeka bo ma najniższy priorytet ….

Ufffff….. ale to jeszcze nie koniec ….. czeka nas jeszcze trochę drogi przez mękę , mam nadzieję ze ten opis uproszczony arbitrażu pozwolił wam zrozumieć jak to działa , Sprawa jest prosta , ale wypada wiedzieć co, gdzie, z kim i za ile.

Neichcący mogłem ominąć bardzo ważną sprawę mianowicie RAMKĘ ZDALNEGO ŻĄDANIA TRANSMISJI (RTR – Remote Transmision Request) dlatego w tym miejscu poświęcę się jej.

W sieci CAN – RTR spełnia jedna z najważniejszych funkcji. Dlaczego … popatrzmy na taki przykład:

Urządzenie C transmituje co 5 min dane o temperaturze z 3ch czujników z ID np 598, oznacza to, że dane w ramce danych zawierają 3 bajty, które są odbierane i przetwarzane przez kilka innych urządzeń na magistrali. Ale urządzenie I potrzebuje pilnie wartości pomiaru temperatury i sprawa jest na tyle pilna że nie może ona czekać 5min na następną transmisję. I tu właśnie pojawia się RTR. Mianowicie nasze urządzenie I może zażądać wyników bezpośrednio od urządzenia C. W celu realizacji takiego „obejścia” normalnego cyklu transmitowania danych nadaje ramkę RRF,
jest ona podobna w budowie do ramki danych DF jednak jest z kilkoma różnicami , a oto one :

— ID Urządzenia, do którego wysyłane jest żądanie (nasze 598) zostaje podane w polu Identyfikatora.
— Liczna przydatnych bajtów w wywoływanej wiadomości (3) jest podana w polu DLC,
— Bit RTR, jest to bit dominujący (0) jest transmitowany jako recesywny (1).
— W RRF nie występuje pole danych , a pole DLC znajduje się bezpośrednio przed CRC

Jak więc widać RRF ma konstrukcje podobna do DF tylko liczba bajtów danych wynosi 0.

Realizacja funkcji zdalnego żądania transmisji jest realizowana następująco:
Wszystkie urządzenia na magistrali odbierają RRF i po ustawieniu bitów RTR rozpoznają, że jakieś tam urządzenie żąda określonych danych od innego. Nasze urządzenie C też odebrało RRF i co …?? a właśnie ustaliło sobie że ID zawarte w ramce jest takie jak JEGO własne ID , w związku z czym natychmiast przesyła swoja odpowiedź w postaci ramki DF zawierającej żądane dane. Urządzenie I odbiera i ma frajdę mam nadzieję że jasne jest teraz działanie tej ramki.

Heh tym sposobem przebrnęliśmy przez rys historyczny, normalizację i podstawy struktury oraz protokół transmisji w sieci CAN… Wiem, strasznie przynudzałem i wysypałem tu niezrozumiały językowy jazgot, wybaczcie , jeszcze trochę muszę ponudzić i po marudzić, ale postaram się teraz też poza teorią poruszyć już zastosowania praktyczne oraz aspekty moralne z użytkowania
CAN.—>>> JEDZIEMY W CAN najbardziej ciekawą, wręcz zjawiskową formą jest niesamowita zdolność do wykrywania wielu błędów występujących w trakcie transmisji danych i sposoby reagowania na nie.Zastosowano tu odstęp Haminga, nazywany czasem – nie bezpodstawnie z resztą – odstępem
sygnałowym – równy (=) 6.Cóż to jest ?? zaś wymyślił jakieś dziadostwo !!
Tak brzmi strasznie ale to banalnie prosta sprawaOdstęp sygnałowy występujący między 2ma słowami dwójkowymi o tej samej długości jest po prostu liczbą bitów na odpowiadających sobie pozycjach w szeregu, muszą one mieć różne wartości. Dla przykładu bo brzmi to jak bezsensowny bełkot – odstęp sygnałowy między słowami dwójkowymi 11011010 oraz 10000110 = 4 Dlaczego skoro pisałeś że 6 ??

No przecież to proste popatrzcie na bity : 3; 4; 5 i 7 (liczymy od prawej żeby potem nie było )różnią się wartościami prawda  i tych różnic jest tylko 4

Co za bydle ze mnie co ?  No ale luzik, wiecie już że CAN może przesyłać dane z dużą szybkością nawet 500 kbitów/s. To dużo, ale teraz sobie wyobraźcie że na każde 0,7s pojawia się jeden zbłąkany błędny bit – zapomniany przez Boga i ludzi niechciany zwykle biedaczek ten jest spowodowany przez zakłócenia zewnętrzne. Co to ma do rzeczy ?? Wyobraźcie sobie więc,że cała nasza sieć będzie pracować 8h/dobę przez 365 dni w roku. Wbudowany system zabezpieczeń przed błędami gwarantuje nam iż przez 1000 lat pracy tylko 1 bit nie będziewykryty. Daje do myślenia co nie . Oczywiście błędy mogą występować i będą taka ich uroda ale skoro są rozpoznawane to można je naprawić prawda ?? Dokładnie TAK JEST !!
Tylko nierozpoznane błędy mogą zafałszować wyniki pomiarów, aby zminimalizować ryzyko błędu zastosowano tu równocześnie kilka różnych sposobów ich wykrywania:

Detekcja błędnego bitu – jak wiemy każde urządzenie podłączone do CAN zawsze odbiera zwrotnie swoją własną transmisję, Dlatego by po arbitrażu jeśli znajdzie się choć tylko jedno ustrojstwo na magistrali, które otrzymało zwrotnie inny różniący się od wysłanego bit – to jest oczywiste, że wystąpił błąd. W takiej sytuacji urządzenie przechodzi w tryb korekcji błędu.

Błędne bity dodatkowe – CAN w swojej specyfikacji ma określone wyraźnie, że gdy w ramce danych transmitowane jest kolejno więcej niż 5 bitów o tej samej wartości (np 8 razy 0 w jakimś polu), to każda grupa pięciu bitów jest poprzedzana przez bit komplementarny (w tym przypadku 1). Ten bit, nie zawiera oczywiście żadnej informacji, jest bitem dodatkowym, a po zakończeniu transmisji jest usuwany z danych i tylko pierwotna wiadomość jest przetwarzana. Bity dodatkowe mogą więc być użyte do kontroli błędów bowiem jeśli odbiorca wiadomości wykryje w ramce więcej niż 5 bitów
o takiej samej wartości (za wyjątkiem EOF), to oczywistym jest że nie jest to poprawny odczyt, i że pojawił się błąd podczas transmisji czyli wystąpił dodatkowy bit lub jego wartość została odwrócona lub też więcej takich bitów) w odpowiedzi na takie coś odbiorca zawiesza działanie i uruchamia procedurę poprawiania błędów.

Błędy CRC – to teraz będzie bardzo prosto bowiem proces ten polega na oszacowaniu sumy kontrolnej w urządzeniu odbiorczym, a gdy odebrana i obliczona są różne od siebie odbiorca co robi ??
– TAK uruchamia procedurę korekcji błędów

Błąd potwierdzenia – kiedyś tam wspomniałem o czymś takim jak Bit ACK – czyli bicie przerwy na potwierdzenie – ta zaraza jest wysyłana przez urządzenie jako bit recesywny. Każde urządzenie, które odebrało poprawnie poprzednią ramkę nadpisują ten bit bitem dominującym. Urządzenie nadające wykrywa to i można powiedzieć, że „wie” iż przynajmniej jedno urządzenie odebrało dane poprawnie. Jeśli jednak nadawca stwierdzi, że jej bit w czasie ACK nie został nadpisany, to jest to jasna informacja, że nikt nie odebrał wiadomości poprawnie i w takim razie ….. co robi ??
No oczywiście co innego by mogła zrobić — zawiesza działanie i przechodzi do procedury korekcji błędów.

Błąd formatu — tu stosuje się fakt, że w ramce jest kilka miejsc, które muszą mieć ZAWSZE określoną zawartość, a są to: bit końca CRC, ogranicznik potwierdzenia i EOF wartości te zawsze są recesywne. Jeśli w tych polach zostaną wykryte bity dominujące, to takie coś może być tylko i wyłącznie spowodowane przez błąd transmisji i co robi nasze urządzenie ……. ?? znów to samo – uruchamia procedurę korekcji błędów …. jakie to monotonne ….

To skoro już tak przy nudziłeś to może wreszcie powiesz co to za dziadostwo ta korekcja błędów ..

No owszem powiem, proszę bardzo …

Więc procedura korekcji błędów to procedura zajmująca się korekcją błędów  – macie co chcieliście hehehe

Dobra żartowałem …. a jest to tak :

W przypadku błędu transmisji jest realizowana nasza „ukochana procedura” w dwóch wariantach:

  1.  Ramki, w których stwierdzono jakiś błąd są natychmiast odrzucone przez       odpowiednie urządzenie i nie są przetwarzane.
  2. Jeśli któreś z urządzeń w systemie wykryje błąd, to natychmiast wysyła ramkę informującą o błędzie, która składa się z 6 bitów dominujących (tzw: sygnalizacja błędu) i ogranicznika ramki błędu zawierającego 8 bitów recesywnych.

W skutek czego bity recesywne na magistrali zostają nadpisane, tak że występuje na niej tylko 6 bitów dominujących, ale …. jest to naruszenie zasady, że nie więcej niż 5 bitów może mieć tą sama wartość. Wszystkie urządzenia na magistrali wykrywają ten stan i uznają właśnie odebraną ramkę jako błędną i odrzucają ją oraz wysyłają ramkę sygnalizacji błędu. Można powiedzieć że urządzenie, które wykryło błąd celowo wykłada całą transmisję w taki sposób że wszystkie urządzenia odbierają ja jako błędną. Czyli jak widzicie o błędzie lokalnym jednego urządzenia natychmiast wiedzą wszystkie pozostałe. Wszystko to dlatego, że głównym założeniem i celem sieci jest aby każde urządzenie odbierało poprawne dane, które są mu potrzebne lub by wszystkie urządzenia dostawały błędne dane i je odrzucały. Faktem jest też to że urządzenie które nadało taką wiadomość tez stwierdzi, że zawiera ona błąd, poprawi ją i wyśle ponownie.

A gdy wystąpi błąd wewnątrz urządzenia – samo stwierdzi, że jest uszkodzone ??, czy będzie wysyłać dane z nieodpowiednią szybkością lub odbierać tylko błędne dane ??
TAK to przypadek można można powiedzieć śmiertelny, takie urządzenie wysyłające ramkę błędu mogłaby spowodować blokadę całej sieci. ……..ale na szczęście CAN jest odpowiednio zabezpieczony przed takim przypadkiem i nie musimy się nim przejmować po szczegóły odsyłam do specyfikacji CAN.

Upss już tak późno … no dobra pozbierajmy wreszcie te dziwne wiadomości których się może nawet nauczyliście

Jak już wiecie są 2 standardy/wersje CAN:

CAN20A – z formatem ramki standardowej;
CAN20B – z formatem ramki rozszerzonej

oto ich porównanie :

[Obrazek 6]

Jak widać CAN to łakomy kąsek stanowiący efektywny i niezawodny system transmisji danych, to wiem że od samego początku zastanawiacie się jak można go wykorzystać praktycznie … W końcu składa się z bitów dominujących i recesywnych, 11bitów ID, 15bit CRC, 1bit ogranicznika, 7bit EOF, 6bit ramka błędu i cała masa tym podobnych dziwadeł. Nic nie kojarzy się ze strukturą 8bitowego Mikrokontrolera , ba nawet 16 bitowego. Czy możliwe wiec jest zaprogramowanie AVRa zgodnie z protokółem ??

Tak to poważne pytania, ale nie powinniście się tym martwić dla sieci jest wiele gotowych i tanich, a przede wszystkim popularnych układów i modułów przez co kan zyskał tak dużą popularność. Typowe interfejsy CAN to tylko 3 układy, a jedyne co musi robić mikrokontroler to tylko wpisać 8 bajtów danych do wysłania, wypełnić ID i DLC oraz ustawić RTR. Całą nudna resztą czyli:

– obliczenie CRC
– dodanie pozostałych pól do ramki
– połączenie z magistralą
– Transmisja danych
– wykrywanie i korekta błędów

Wykonuje kontroler CAN, dane zaś są wprowadzane do magistrali poprzez transceiver CAN , który jest zresztą bezpośrednio do niej podłączony. Mickrokontroler otrzymuje potwierdzenie wysłania danych, albo info o błędzie, po czym podejmuje odpowiednie działania. Przy odbiorze danych jest podobnie zresztą. Wymagania CAN nie są wielkie, a zbudowanie 2 stopniowego interfejsu CAN proste. Można więc zająć się wreszcie budową interfejsu ….. HURAAAAA !!!!!! KONIEC NUDY ……..

hehe tak ale jeszcze musimy coś ważnego omówić zanim przedstawię interface mianowicie kilka istotnie ważnych spraw jedną z nich może być tzw/ Filtrowanie akceptacyjne , dlaczego warto poruszyć w tym akurat miejscu ??
to proste …… Jak wiecie CAN20A działa w standardowym formacie ramek co pozwala na przetworzenie aż 2048 różnych identyfikatorów. Nie wymaga się oczywiście , by każde urządzenie na magistrali otrzymało wszystkie ramki bo było by to bezsensowne prawda ?? Np w naszej sieci dla urządzenia G istotne są tylko ramki z ID 50, 1234, 2000, a 2045 pozostałych jest bez znaczenia. Ważne jest wiec wprowadzenie właściwej
selekcji ID , tak by dany mikrokontroler w urządzeniu dostawał tylko to co potrzebuje i taka własnie selekcja nazywa się filtracja akceptacyjna. Umożliwia ona takie zaprogramowanie sterownika CAN , by sprawdzał wszystkie wiadomości, wraz z korekcją błędów ale przekazywał mikrokontrolerowi określone ramki o określonych ID
przez co przetwarzanie danych jest szybsze. D filtrowania akceptacyjnego możemy zastosować 2 różne układy scalone.

hehehe jeszcze was trochę podręczę i potrzymam w słodkiej niepewności …. choć może nie zdajecie sobie z tego sprawy , ale już z tymi wiadomościami możecie zbudować swój interfejs. Ja później będę bazował na specjalizowanym mikrokontrolerze AT90CAN128 firmy ATMEL, który zawiera w sobie już kontroler CAN ..
…..
….. hahaha mam was trochę was rozczarowałem co  owszem mogę go użyć bo mam i często je używam, ale obiecałem że zrobimy to na zwykłym AVR więc tak będzie jedynie co będziemy potrzebować to: MCP2515 – czyli kontroler CAN z SPI

http://ww1.microchip.com/downloads/en/D … 21801F.pdf

MCP2551 – Szybki Transceiver CAN

http://ww1.microchip.com/downloads/en/d … 21667d.pdf

proponuję byście się zaprzyjaźnili z tymi dwoma scalaczkami oraz zapoznali z ich notami. Bo właśnie ich użyjemy do budowy naszego interfejsu, i pamiętajcie że zbudować trzeba minimum 2 by nawiązać transmisje. Na razie dość jutro jeszcze troszkę ponudzę i zaprezentuję schemat , choć po przejrzeniu not nie będzie stanowić to dla was problemu

No i nieuchronnie idzie ku pełnoletności ….

Zasadniczo możemy się pokusić o budowę interfejsu , Niemniej zanim do tego przejdziemy chciałbym przedstawić jeszcze 2 możliwości – w zasadzie drogi do naszej sieci CAN.

BASICAN — to taki uproszczony układ zawierający prosty filtr 8 bitowy, który pozwala
na zgrubną preselekcję identyfikatorów. Chodzi tu o to, że ID są przepuszczane grupowo, np tylko zakres 600 – 606. Niemniej wybór 1 ID jest wykonalny ale tylko w tedy gdy zostanie przeprowadzona dalsza selekcja z użyciem mikrokontrolera. Ramki zdalne, które są przeznaczone dla danego urządzenia także przechodzą przez filtr zanim dotrą szczęśliwie do mikrokontrolera, a wtedy ten szczęśliwy że ma coś do roboty może wygenerować właściwe dane i skierować je do sterownika CAN niejako w odpowiedzi.

FullCAN — Tutaj sprawa ma się znacznie lepiej, możemy zaprogramować bardzo dokładnie i dokonać selekcji pojedynczego ID. Czyli możemy sobie dokładnie sprecyzować jakie ramki mają być akceptowane przez nasze urządzenie. Np ma tylko odbierać ID 667 czyli niech to będzie zapytanie o temperaturę. Ma to tez wady. Układ taki nie będzie przepuszczał wielu ramek bo ustaliliśmy, że ma się on interesować tylko tą jedną.

Jak więc widać budując nasz kawałek CAN-a musimy jeszcze brać to pod uwagę. Ważnym dla nas jest :

– Ile ramek o różnych ID ma być odbieranych.

Jeśli wiele powinniśmy skorzystać z układu BasiCAN. Musimy też pamiętać, że wtedy znaczna cześć selekcji będzie musiała przejść na mikrokontroler, który będzie musiał dysponować odpowiednią
mocą obliczeniową . Niemniej FullCAN ma zalety np. umożliwia zaprogramowanie w sterowniku CAN odpowiedzi na RTR. Czyli gdy nadejdzie dozwolona ramka dla tego urządzenia , może ono wysłać w odpowiedzi ramkę danych z pominięciem mikrokontrolera. Obecnie rozwój magistrali CAN zaczyna zacierać różnice między BasiCAN i FullCAN, a sprawność kontrolerów FullCAN jest coraz wyższa i umożliwia wybieranie coraz większych zakresów ID.

Miedzy standardami 2.0A i 2.0B istnieje pewna zgodność i można w ramach jednej magistrali używać obu standardów, ale trzeba być ostrożnym dlatego trzeba dobrze się zastanowić nad wyborem kontrolera CAN. Dla kontrolerów 2.0A możliwe jest przetwarzanie tylko ramek standardowych, a gdy trafi na ramkę rozszerzoną generuje ramkę błędu. Może to wstrzymać nawet całkowicie działanie systemu, co za tym idzie mogą być używane tylko w sieciach gdzie nadawane są tylko ramki standardowe. Zaś dla kontrolerów z możliwymi 2.0A i biernymi cechami 2.0B akceptacja obejmuje
ramki rozszerzone, a po przeprowadzeniu próby błędu odpowiadają bitem ACK lub ramką błędu. W tym wypadku łączność nie zostaje zakłócona, ale ramki z 29bitowym ID nie są ani zapisywane, ani przepuszczane ponieważ przewidziano te kontrolery do przetwarzania tylko ramek z ID 11bitowym. Ale nadają się do systemów hybrydowych gdzie są stosowane oba standardy 2.0A i 2.0B. Natomiast Kontrolery 2.0B zapisują,przepuszczają i przetwarzają oba typy ramek.

Tak więc podczas podejmowania decyzji o zakupie sterownika CAN , czy też mikrokontrolera z wbudowanym już w rdzeń sterownikiem CAN. Należy dokładnie się zastanowić co jest nam potrzebne warto też zapoznać się z najpopularniejszymi układami CAN jak Choćby ATMEL , Microchip, Texas Instruments

Dlaczego o tym wspomniałem ?? dlatego , że my oprzemy się o produkty Microchipa, ale wygodniej było by nam użyć np mikrokontrolera AT90CAN128  z którego często sam korzystam , choć często muszę dołączyć do CAN istniejące urządzenie które nie posiada CAN-a i muszę się posiłkować właśnie tandemem MCP2551 i 2515. Oczywiście interfejs CAN możemy zbudować w oparciu o dowolny przeznaczony i dedykowany sterownik np. popularny SJA1000 a wspominam o tym dlatego, że możliweiż ktoś ma alergię na Microchipa …

Schemat blokowy SJA1000 wygląda następująco:

[OBRAZEK 7]

sam interfejs jest tez jakby bardziej skomplikowany i wymaga oprócz transceivera dedykowanego PCA82C250 również 2ch szybkich optocouplerów 6N137 pracujących do 10Mbit/s.

Dla nas bazowy będzie następujący schemat:

[SCHEMAT 1]

Jest to możliwie najprostsza forma interfejsu CAN …

Jeśli ktoś mnie posłuchał wcześniej i zapoznał się z notami naszych faworytów
Już wie że nasz kontroler CAN pracuje na magistrali SPI dzięki czemu łatwo go podłączyć do dowolnego miktokontrolera, postaram się jednak bazować na 2ch rozwiązaniach, pozwalających na pracę z CAN prze nasze ATmegi , mianowicie GCC i C++ oczywiście nie będę nic mieszał w kodach. Wiem że się spodziewacie po mnie masakry jakiejś , ale będą to czyste kody dla obu języków osobne zatem bierzemy się za ujarzmianie potwora …. od strony programowej, czyli zajmiemy się naszym MCP2515 bo tylko z nim będziemy gadać ,a niejako transceiver MCP2551 zajmie się sam sobą i poza zajmowaną przestrzenią na schemacie i płytce od strony programowej nas nie interesuje …

Zapoznajcie się jednak ze schematem interfejsu oraz notami układów obu, a ze szczególną uwagą MCP2515. Ja preferuje wersje smd , ale są one też w wersji DIP dla stykowców …. nie polecam  bo chcę uniknąć problemu 200000000000000 pytań czemu mam błędy i czemu nie działa. To działa Interfejs ten stosuje od dawna i nie mam z nim problemów.

—- No i stało się wszyscy się wreszcie cieszą zapewne bo już jest schemat i możemy zacząć wreszcie po zbudowaniu interfejsu go oprogramowywać , jak pisałem będzie i GCC i C++. Zacznę więc mało elegancko od …………
………….
haha nie prawda  bo od GCC:)

Nasz interface podłączymy sobie do Atemegi ………..<chwila potrzebna na pogrzebanie w statystykach i organizerze> 8 skoro już Wylazła nam ATMega8 niech będzie

Zaczynamy…..

Całość podzielę na 3 części. Mianowicie

1. Inicjacja MCP2515
2. Przekazywanie wiadomości
3. Odbieranie wiadomości

Jest to konieczne by łatwiej było wam zrozumieć ideę oraz … na końcu nie dostaniecie gotowego programu a będzie waszym zadaniem na podstawie poznanych tu szczegółów i funkcji napisać program, który pozwoli na wymianę danych miedzy 2ma urządzeniami na magistrali CAN np termometrem i LCD

Dlaczego takie urządzenia ??— bo przecież każdy z was umie je już obsłużyć prawda ?? Po co więc tu CAN ?? — dla celów poznawczych choćby bo zakres używalności jest CAN, achoćby w instalacjach typu HOME INTELIGENCE gdzie można zaszaleć

Jeśli więc jesteście gotowi to możemy zaczynać.

1. Inicjacja MCP2515

Jak już wiecie nasz bohater pierwszej linii jest tworem który z nami będzie chętnie rozmawiał , ale tylko przez interfejs SPI. W zasadzie jako adepci sztuki tajemnej po przeczytaniu 1 tomu opasłej trylogii pisanej prozą i popełnionej przez zaiste Wielkiego Mistrza Zakonu Obrońców 8 bitowego „C” (wiecie kogo mam na myśli) więc imienia jego nie będę wzywał nadaremno…. (ci co nie wiedzą niech się idą z żalu utopić <niewskazane>
pędzą skruszeni na stronę sklepu Atnel w celu zamówienia obu już opasłych tomów
wiedzy tajemnej) potraficie mam nadzieję zainicjować połączenie SPI jeśli nie to …………
wasz problem i zamiast czytać o CAN ie zacznijcie od pierwszej literki tego skrótu ….. No dobra w celu zainicjowania SPI możemy następującej procedury … tak jestem zwolennikiem rozbijania wszystkiego na funkcje , procedury itp … łatwiej znaleźć problemy. Dlatego warto się takiego stylu pisania nauczyć

Jak widzicie SPI pracować będzie w trybie master. Dla naszego SPI wybieramy prędkość maksymalna (FOSC/2 = 8Mhz CLK dla Kwarcu 16Mhz pędzącego Procka ). Na szczęście dla nas MCP2515 potrafi obsłużyć transmisje SPI do 10MHz.
W przypadku kiepskich stykówek może być z taką prędkością problem ….
<żeby nie było że nie uprzedzałem> Jednak w tym wypadku prędkość musi być ustalona. Na czas testu można uruchomić SPI na prędkości około 3.7Mhz (7.3728Mhz ze względu na ATmegę) i transmisja będzie/powinna przebiegać prawidłowo.

Podczas inicjacji należy pamiętać o ustawieniu właściwych pinów jako wyjście (SCK, MOSI, \CS) i wejście (MISO). Gdyz w przeciwieństwie do innych pinów obsługujących np UART, TWI itd , w przypadku SPI nie jest to wykonywane automatycznie:)
W celu łatwiejszego dostosowania kodu do innych AVR proponuje nauczyć się korzystać z dobrodziejstwa języka C i zdefiniować sobie potrzebne piny poprzez znana wam już z książki instrukcję #define. Dzięki czemu zmiany
będą wprowadzane w jednym miejscu kodu i jeśli będziecie chcieli zdefiniować np. \CS <pozostałe 3 są specyficzne dla AVR i nie można ich zmieniać — chyba że będziecie korzystać z programowego SPI — my jednak zajmiemy się sprzętowym>.

Przykładowo nasze definicje pinów mogą wyglądać następująco:

 

Oczywiście w celu ułatwienia sobie życia poprzez #define możemy sobie też zdefiniować adresy rejestrów naszego MCP2515 i potem zarejestrowanych nazw lub nazw bitowych używać w kodzie. Ja to wszystko mam pliku nagłówkowym *.h który na końcu wam udostępnię.

Teraz po takiej ładnej inicjacji już prosto możemy wypychać bajty przez SPI:

Na magistrali SPI dane mogą być wysyłane i odbierane jednocześnie. Więc by otrzymać bajt musimy użyć tzw. Dummy-Byte

No od teraz możemy już rozmawiać z naszym MCP2515. Komunikacja zawsze będzie się odbywać według tego samego wzorca:

— /CS ustawione na stan niski (LOW)
— SPI Inicjacja
— transmisja danych odbiór/nadawanie
— /CS ustawione na stan wysoki (HIGH)

Teraz zobaczycie funkcje odczytu i zapisu rejestrów MCP2515 …

— ZAPIS —-

—– ODCZYT ———

W zasadzie to upały dają się we znaki , ale jak się już powiedziało A trzeba by powiedzieć B więc polecimy dalej ….. jak daleko nie wiem jeszcze , ale nie chcę tu mącić tak od razu więc … do roboty bo pewnie wieczorem mi się nie będzie chciało

Nasze MCP2515 ma też taka ciekawą i bardzo przydatną funkcję BIT-Modify, która określa czy bity są tylko ustawione czy też zostały wyczyszczone. Przykładem uwidaczniającym może być np inicjowanie gdzie powinien być włączony tryb pracy.

Jednak tak kolorowo nie jest funkcja ta ma zastosowanie tylko do niektórych rejestrów , szczegóły w Nocie (str.59) Tylko te bity które są tu ustawione można później zmieniać. Dopiero po tym są przesyłane nasze dane. Jednak jeśli bit jest ustawiony ” w masce” i usunięty z danych , to odpowiedni bit w rejestrze MCP2515 tez zostanie usunięty.
Analogicznie jeśli będzie ustawiony. W sumie teraz już można się pokusić o wysyłanie i odbieranie komunikatów CAN. Jedyne trudności możemy mieć podczas inicjowania i szybkości transmisji na magistrali. Wydaje się z noty że aby ustawić rejestry konfiguracyjne MCP2515 należy najpierw włączyć ją w tryb konfiguracji. W tym trybie tylko możemy zarejestrować filtry, Bit Timing i maski w rejestrach : CnF1, CnF2, CnF3, TXRTSCTRL. Nasza kostka ma jeszcze parę innych trybów które są dość dobrze opisane w nocie więc sobie je tutaj daruję  (z czystego lenistwa )

BIT TIMING

Hmmm… się trochę wpakowałem , bo jest to dosyć trudny temat, ale nieco sobie ułatwimy życie , zakładam że macie notę pod ręką więc przejdziemy do gotowych wartości rejestrów dla różnych szybkości transmisji. Bit Rate ustawia się w trzech
rejestrach CnF1 do CnF3 w zasadzie wygląda to tak:

Po szczegóły odsyłam do noty strona 37
A Co trzeba trochę się wysilić panowie bo się wam jeszcze zwoje mózgowe wyprostują jak banany w EU I teraz zajmiemy się przerwaniami w MCP2515:) tak … no ma przerwania i co gorsza jest ich aż 8:)
1. Messages ERROR
2. WakeUp IRQ
3. ERROR IRQ ENABLE (gdy wystąpi wiele źródeł w rejestrze EFLG)
4. Transmit Buffer 2 Empty Interrupt
5. Transmit Buffer 1 Empty Interrupt
6. Transmit Buffer 0 Empty Interrupt
7. Receive Buffer 1 Full Interrupt
8. Receive Buffer 0 Full Interrupt
Gdy uaktywnimy jedno z tych przerwań, to za każdym razem pojawi się „0” jeśli warunek będzie spełniony. Elektrycznie Linia zostanie sprowadzona do LOW dopóki warunki wszystkich przerwań są spełnione. Możemy to zastosować w programie
do zapełniania bufora przerwań w celu sprawdzenia czy wiadomość dotarła. Jest oczywiście wiele więcej możliwości, które zostały szczegółowo opisane na stronie 49 noty. Aby skorzystać z przerwań musimy je włączyć co sprowadza się do ustawienia
odpowiedniego bitu rejestru CANINTEIdentycznie posługujemy się pinami TXnRTS, które możemy ustawić jako wejścia cyfrowe. Wszystko oczywiście w rejestrze TXRTSCTRL który jest opisany na stronie 19 noty, a używa się go na tej samej zasadzie co RXnBF. dobra zostawię na razie bo strasznie gorąco , a  jakoś dobrniemy powoli do końca mam taką nadzieję …
No wreszcie temperatura opadła , procek ma chłodzenie zaczynam myśleć na tyle logicznie, ze mogę pisać dalej. Nasze małe MCP2515 posiada Pin CLKOUT , zapewnia on pin zegara CLK dla innych układów jeśli jest to konieczne.Czyli pin CLKOut jest wyjściem sygnału zegarowego. Co ciekawe można też sobie włączyć wewnętrzny PRESCALER, który jak wiecie z książki Mirka dzieli sygnał zegara przez zadaną wartość , co pozwala uzyskać różne wartości sygnału zegarowego. W przypadku naszego układu interfejsu dołączymy do MCP kwarc 16Mhz , dzięki takiemu posunięciu będziemy mieli możliwość uzyskania CLK o wartościach :

16/8/4 i 2 MHz.

Pin CLKOut jest kontrolowany przez 3 ostatnie bity rejestru CANCTRL. Niemniej trzeba wiedzieć że jeśli chcemy z niego skorzystać do generowania CLK dla ATmegi i nie mamy 2ch linii RESET (dla MCP i Atmegi) możemy mieć problem dosyć duży z programowaniem ATmegi. Dlatego że resetowanie AVR odbywa się stanem niskim i jeśli do Lini RST Podłączymy MCP i podamy stan Niski, to MCP przejdzie ładnie w stan zerowania i ….. wyłączy pin CLKOut. A jak wiadomo bez sygnału zegarowego nie zaprogramujemy ATmegi … W takim wypadku można jednak sobie poradzić wystarczy zrobić 2 odrębne linie RESET (oddzielnie dla MCP i ATmegi) oraz podciągnąć RST w MCP osobnym PULL-Upem do VCC. Trzeba zawsze pamiętać podczas inicjalizacji MCP2515 że po resecie pojawia sie określony STAN początkowy na pinie CLKOut.


jutro pokażę jak obsługiwać Filtry akceptacji i maski oraz zajmiemy się buforami , wysyłaniem i odbieraniem wiadomości i w zasadzie to będzie koniec wywodu na temat CAN i ATmegi… w GCC natomiast dla duinowców będzie wsad PDE/INO
na tyle prosty że nie trzeba go tłumaczyć oraz zestaw potrzebnych plików i bibliotek. Z pewnością otworzę nowy temat
do prowadzenia dyskusji o CAN tak by tu zatrzymać konieczną wiedzę.

Mam nadzieję że jest to wszystko klarowne i zaczyna mieć jakiś sens dla was … i że nie marnotrawię tym wywodem
niepotrzebnie miejsca w bazie danych.

No obiecałem że dziś zakończymy to przynudzanie i będzie można sobie podyskutować o CAN-ie i nie tylko
upał trochę zelżał i po spacerze mam trochę energii (alternatywnej oczywiście i z odnawialnych źródeł).
Więc możemy powoli zakończyć ….

Jak poprzednio wspomniałem jedna z zalet magistrali CAN (lub bardziej precyzyjnie to określimy -> kontrolera CAN) jest
fakt umożliwiający filtrowanie wiadomości. Nasz kontroler posiada 2 filtry dla bufora 0 i jeszcze 4 na buforze 1. Dzięki
temu wiadomości które nie są przeznaczone dla naszego urządzenia , mogą być „odfiltrowane” bez użycia Mikrokontrolera.
Częściowo przedstawię zależności filtrów w tabelce :

Jak widzicie poszczególne bity ID Wiadomości są używane do filtrowania tylko wtedy gdy jest ustawiony odpowiedni Bit w MASCE.
Jeśli więc chcecie po testować otrzymywanie wszystkich komunikatów, wystarczy w masce ustawić wszystkie bity na dominujące,
czyli 0. Kontroler będzie wtedy wiedział że wszystkie wiadomości niezależnie od ID zostaną przekazane do bufora.
Popatrzcie tak wygląda kompletny kod inicjalizacji dla naszego MSP2515:

Oczywiście można to zrobić bardziej elegancko i wysłać cały zestaw danych prosto do rejestrów, ale
byłoby to mało czytelne. Jak więc widzicie doszliśmy do takiego momentu naszego wywodu , w którym
już niewiele nam brakuje by wysłać pierwszą wiadomość przez CAN. Żeby nie utrudniać zajmiemy się
wysłaniem wiadomości z ID 11bit. Oczywiście jak będziecie chcieli bez problemu przerobicie sobie
do ID rozszerzonych czyli 29 bitów. W tym miejscu wypadało by jednak bym tradycyjnie coś namieszał :)
Co zresztą uczynię z premedytacją i pełną świadomością faktu że jest to moja złośliwość :P
Więc bez dalszego owijania w bawełnę czy coś innego powiem wam w tajemnicy, że nasz malutki kontroler
jakim jest dzielny MCP2515 ma aż 3 bufory nadawania i do tego z niezależnymi ustawieniami priorytetu.
Dzięki czemu nasze zadanie czyli wysłanie wiadomości jest banalnie proste i sprowadza się tylko
do rejestracji odpowiedniego ID, wypełnienia pola danych i już … można wysłać wiadomość :)

Oczywiście jest jednak jedno małe ale …..
mianowicie są trzy różne sposoby by wysłać wiadomość :)

— przez ustawienie odpowiednich bitów w rejestrze TXBnCTRL
— przez wysłanie poleceń RTS po SPI
— ustawienie stanu niskiego dla odpowiednich bitów TXnRTS buforów

Przykład wysłania wiadomości może być następujący:

Jakoś poszło no nie :) ale to mało elegancki sposób takie pakowanie bezpośrednie bardziej optymalne jest wysyłanie do bufora
określonych danych co też umożliwi nam wymianę danych między funkcjami i dlatego w tym celu lepiej pakować dane
w struktury :) np. tak:

Prawda że lepiej to wygląda ?? teraz wystarczy strukturę przekazać do Funkcji wysyłającej :

 

Oczywiście można funkcje bardziej rozbudować , i używać dzięki temu do wysyłania pierwszego wolnego buforu
w którym bit TXREQ w rejestrze TXBnCTRL gdzie n to numer bufora. Jest tęż to łatwiejsze dzięki dodatkowym poleceniom
SPI :) jaką jest np. komenda RSI (Read Status Instruction).

W przeciwieństwie jednak do powyższych przykładów teraz nie będziemy korzystać z „prefabrykowanych” funkcji rejestrów,
dodatkowo przyspieszymy transmisję wysyłając dane bezpośrednio na SPI, które następnie będą przechowywane
w odpowiednich rejestrach MCP2515.

Teoretycznie może się też zdarzyć tak, że będziecie wysyłać wiele wiadomości jedna po drugiej. Pamiętajcie, że jako pierwszy
zostanie wysłany ten bufor , który ma najwyższy priorytet. Aby temu zapobiec , powinniście się starać o to by zawsze mieć
bufor z którego chcecie wysyłać wiadomości bieżące ustawiony na najniższy priorytet i zwiększać priorytet pozostałych
o 1. Wtedy macie pewność że wiadomości będą wysłane w takiej kolejności w jakiej były wpisane do buforów.

I pozostało nam już w zasadzie tylko odbieranie wiadomości.

No tu troszkę schodów nas czeka bo musimy określić czy wiadomość jest nowa , a to zależy od konfiguracji MCP2515
i można oczywiście to tez zrealizować na kilka sposobów.

— stanem piny RXnBF
— LInią IRQ
— Poleceniami SPI

Oczywiście, żeby było trudniej można te sposoby łączyć ze sobą . Bardzo przydatne jest w jednym z przypadków uruchomienie
IRQ i sprawdzenie stanu na Mikrokontrolerze, wtedy widać czy są nowe wiadomości czy nie, a następnie pobrać przez
polecenia SPI bufora, w którym jest wiadomość. I w sumie tym przypadkiem zajmiemy się teraz.

W celu wykorzystania IRQPin i sprawdzeniu czy jest nowa wiadomość jak sie zapewne domyślacie musimy go najpierw ustawić :)
Wykonujemy to podczas Inicjalizacji i potem możemy sobie cierpliwie czekać aż na IRQPin pojawi się stan NISKI, co informuje
nas o tym że możemy odczytać nową wiadomość. Ale musimy też ustalić teraz gdzie jest ta nowa wiadomość (w którym buforze)
, a może jest to coś innego ?? np (STD ID, EXT ID, RTR itp :) ) :) Jest to proste bo MCP2515 ma taką extra komendę SPI pozwalającą na alternatywną ocenę rejestru CANINTF :)

Dlatego łatwiej i lepiej jest najpierw sprawdzić czy IRQPin jest w stanie Niskim czy nie i jeśli jest to odbieramy mową wiadomość:

Jak widać praktycznie rutynowa obsługa SPI :) , pobieramy informacje o typie wiadomości, i buforze z wiadomością . Następnie
odczytujemy dane z właściwych rejestrów. Dla komunikatów z EXT ID (29bit) jest obsługa w pierwszej kolejności. Funkcja
Filtrująca zwraca numer , przez który wiadomość zostanie wysłana z powrotem, a jeśli niema żadnych nowych wiadomości
do odczytania zwraca komunikat o błędzie – wartość 0xff. I to by było na tyle jęsli chodzi o implementacje CANA dla
mikrokontrolerów AVR jak nasza ATMega8 użyta do testu. Teraz powinniście już umieć wysłać i odebrać wiadomość
przez magistrale CAN. Oczywiście nasz tort jeszcze nie ma wiśienki :) bo pewnie się już połapaliście że używam jakiejś
magicznej biblioteki i plików dodatkowych. TAk to prawda dlatego też przygotuje tą wisienkę wraz z małym programikiem
który wysyła i odbiera bzdury z CANA :), a właściwie to wykonuje tylko inicjalizacje MSP2515, przełącza w tryb pętli zwrotnej
co powoduje że wiadomość jest wysłana tylko wewnętrznie, odbiera ją i przechodzi do normalnego trybu, w którym ponawia
wysłanie wiadomości na magistrale CAN i oczekuje przychodzących.

Mam nadzieję że was nie zanudziłem na śmierć , i że zrozumieliście że CAN jest ciekawą alternatywą dla USARTA i pożądaną,
a jednocześnie nie jest ani skomplikowany , ani kosztowny w implementacji. Oczywiście polecam korzystać ze sprzętowego
SPI. Czytać notę, i odpowiednie rozdziały traktujące o SPI w książce Mirka.

TO JUŻ WSZYSTKO PANOWIE ….
PLIKI UMIESZCZĘ TUTAJ JAK BĘDĄ GOTOWE DO PUBLIKACJI , ORAZ ODPOWIEDNI ZESTAW INO dla ARDUINOWCÓW.

— 1 lip 2012, o 14:38 —

Obiecałem, że będzie też CAN dla Arduinowców … tu sprawa jest prosta i wręcz nie wymagająca żadnego opisu, jak to w Arduino.
Całość sprowadza się do zakupienia lub zrobienia sobie CAN-Shielda. Wszystko co potrzeba jest dostępne na stronie
sparkfuna : http://www.sparkfun.com/products/10039
a biblioteka dla Arduino jest do pobrania pod tym adresem:
http://code.google.com/p/sparkfun-ardui … p&can=2&q=
Użycie jak to w Arduino jest proste i bez problemowe więc nie będę się rozwodził nad tym.

Życzę miłej zabawy .. z magistralą CAN oraz zapraszam do dyskusji w nowym temacie.

Jak obiecałem , oto przykładowy programik demonstrujący działanie kontrolera CAN,
Na tej podstawie możecie już napisać co wam się podoba panowie :)
I przesyłać co chcecie przez magistralę CAN.

No panowie mam nadzieję że jest to jasne.
Potrzebna biblioteka i pliki nagłówkowe w załączniku , nie jest mojego autorstwa , ale używam jej dosyć często i wiem że jest OK, po za tym niema potrzeby wymyślania koła od nowa w tym akurat przypadku . Polecam również zapoznać się wieloma opracowaniami i dokumentami w sieci , którymi również się posiłkowałem
materiałów jest ilość spora aż nie sposób wyliczyć…
Teraz możecie się bawić CANEM już do WOLI.