ATNEL tech-forum https://forum.atnel.pl/ |
|
Magistrala CAN -- technologia https://forum.atnel.pl/topic1183.html |
Strona 1 z 1 |
Autor: | SunRiver [ 17 cze 2012, o 12:28 ] |
Tytuł: | Magistrala CAN -- technologia |
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 ... |
Autor: | SunRiver [ 17 cze 2012, o 19:35 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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 |
Autor: | SunRiver [ 24 cze 2012, o 13:58 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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 |
Autor: | SunRiver [ 25 cze 2012, o 17:19 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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. |
Autor: | SunRiver [ 25 cze 2012, o 21:03 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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 |
Autor: | SunRiver [ 28 cze 2012, o 19:38 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
---- 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ć język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. Na magistrali SPI dane mogą być wysyłane i odbierane jednocześnie. Więc by otrzymać bajt musimy użyć tzw. Dummy-Byte język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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 ---- język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. ----- ODCZYT --------- język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
dobra dziś wystarczy ... dalszy opis jutro ??? no może pojutrze .... hehehe Miłego czytania |
Autor: | SunRiver [ 29 cze 2012, o 15:50 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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ę ... |
Autor: | SunRiver [ 29 cze 2012, o 22:14 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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. język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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. |
Autor: | SunRiver [ 30 cze 2012, o 16:39 ] |
Tytuł: | Re: Magistrala CAN -- technologia |
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: język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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: język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. Prawda że lepiej to wygląda ?? teraz wystarczy strukturę przekazać do Funkcji wysyłającej : język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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. język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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 język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. Dlatego łatwiej i lepiej jest najpierw sprawdzić czy IRQPin jest w stanie Niskim czy nie i jeśli jest to odbieramy mową wiadomość: język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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. język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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. |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |