Jak wspomniałem w poprzednim temacie 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 siedmiowarstwowy 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ędnią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:




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

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.

Na razie starczy ... ale pojawi się tu ciąg dalszy zanim przystąpimy do praktycznego używania.
...
Uffff ...

-- dodano 17 cze 2012, o 13:50 --

Myślę że wprowadzenie i zgrubne opisy standardów oraz podstawy budowy CAN
mamy za sobą i że wieczorkiem zajmiemy się już zagadnieniami przesyłania danych oraz budową ramki
, a potem zbudujemy nasz interfejs CAN ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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



jest to zgodne ze specyfikacją CAN2.0A a opisem ramki zajmiemy się wieczorem .....

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

echhh .... strasznie mi się nie chce przynudzać dalej , ale co zrobić ...
tak będziemy ciągnąc dalej słowotok tym razem postaram się opisać w miarę dokładnie całą ramkę
oraz ... a to się jeszcze okaże ...

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 mozliwe jest przez nadajnik debranie
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 ramke.

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

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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



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:)



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

Nic wiec teraz pójdę sobie ... a co tu będę taki sam siedział .... chlip chlip

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Po długiej przerwie chorobowej pozostało mi dokończyć lakoniczny opis CAN-a. Przepraszam też zainteresowanych za tak długie oczekiwanie, teraz już w zasadzie z górki bo zostało nam już tylko omówienie korekcji błędów , jednak nim do niej
dojdziemy .... niechcą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.

Wieczorem korekcja błędów i przechodzimy wreszcie do budowy sprzętu.... oraz do pierwszej transmisji

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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 pomarudzić, 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 sprawa

Odstę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 500kbitó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ędzie
wykryty. 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.

Na tą chwile wystarczy, wieczorem pójdzie mam nadzieje koniec gdzie już otrę się o wspomniane na
początku walory i aspekty użytkowe.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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



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

Ale o tym może już jutro co ....

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

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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żliwe
iż ktoś ma alergię na Microchipa ...

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



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:



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

Następnym RAZEM 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 ...

Zatem do zaś...

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.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

---- 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-a
choć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 ---------



dobra dziś wystarczy ... dalszy opis jutro ??? no może pojutrze .... hehehe
Miłego czytania

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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 CANINTE


Identycznie 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 jeszcze mam sporo w planie pisania , może wieczorem ..
a może jutro... już i tak uważacie mnie za dziwaka ale co tam .. jakoś dobrniemy powoli do końca mam taką nadzieję ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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

-- 1 lip 2012, o 22:27 --

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.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]