CAN BUSZ ÁLTALÁNOS ISMERTETŐ

Átírás

1 CAN BUSZ ÁLTALÁNOS ISMERTETŐ 1. KIADÁS 2009 Szerző: Somlyai László Kandó Kálmán Villamosmérnöki Kar, IV. évfolyam oldal 1

2 Tartalomjegyzék 1. Bevezetés CAN busz Kialakulása Fizikai réteg Az üzenetek keretformátumai A CAN üzenetek fajtái Arbitráció A CAN busz felhasználási területei CAN kommunikáció Firmware Firmware fejlesztés Inicializálás CAN Irodalomjegyzék Mellékletek M4.a melléklet: MCP2551 specifikáció M4.b melléklet: MCP2551, DC karakterisztika M4.c melléklet: MCP2551, DC karakterisztika oldal 2

3 1. Bevezetés A dokumentáció célja, hogy egy általános leírás adjak a CAN buszról. A dokumentum elkészítésének alapját a szakdolgozatom (CAN buszra csatlakoztatható kijelző 32 bites mikrokontrollerrel; 2009-BMF-KVK) szolgáltatta. Célom a dolgozattal, hogy segítséget nyújtsak azoknak, akik a CAN busszal szeretnének foglalkozni. Az általam összegyűjtött adatok jó kiindulási alapként szolgálhatnak. A dolgozat elején a CAN busz általános ismertetése történik az interneten fellelhető forrásokból összegyűjtve. A dokumentum még fejlesztés alatt áll. Jelen verzió, az 1. kiadás. Később, a CAN busz elektronikai és szoftveres vonatkozásaival bővítem a leírást. oldal 3

4 CAN busz 1.1. Kialakulása Napjainkban sok jármű tartalmaz különböző elektronikus vezérlőegységeket (ECU 1 ). Az autóipar fejlődésével egyre több elektronikus rendszer került az autókba. Ezek egyrészt a felhasználói igényeket elégítik ki, így például az elektromos ablakemelők, multimédiás eszközök. Másrészt környezetvédelmi (az autó káros anyag kibocsájtás és az üzemanyag fogyasztásának a csökkentéséért többek közt az ECU 2 felelős) és biztonsági célokat (ABS 3, ASC 4, ACU 5 ) szolgálnak. Az eszközök bonyolultsága elengedhetetlenné teszi a kommunikációt közöttük. Ilyen egység például az ASC, itt a motor időzítése és a karburátor működik együtt, hogy a meghajtott kerék megcsúszása esetén, csökkenjen a meghajtó nyomaték. Egy másik példa a különálló egységek összehangolására az elektromos sebességváltó. A sebességváltás a gyújtás precíz vezérlésével állítható. Eleinte a különálló alrendszerek dedikált vonalakon tartották egymással a kapcsolatot. Így minden vezérlő, külön vezetékeket kapott az egyes funkciókhoz. Ez azonban az egyre összetettebbé váló rendszerek esetén egyre nagyobb problémát jelentett. Ezeket a vezetékkötegeket kábelkorbácsoknak nevezik. Jelentősen megnehezíti a szerelést és igen magas az ára. Valamint egy idő után az összeköttetések száma már tovább nem növelhető. Manapság egy autóban ECU is található. Egy érdekes adat, hogy egy mai átlagos autó vezetéseinek hossza 2-2,5 km és 100 Kg súlyú is lehet, illetve lehetne. 1 ECU: Electronic Control Unit, azaz elektronikus vezérlő egység. Az autóiparban használt autóelektronikák összefoglaló neve. 2 ECU: Engine Control Unit, más néven a motorvezérlő elektronika. 3 ABS: Anti-lock Braking System, a blokkolásgátló fékrendszer vezérlő elektronikája. A blokkolásgátló a kerekek blokkolását, illetve az útfelületen való csúszását hivatott megelőzni. 4 ASC: Automatic Stability Control, vonóerő szabályozás. Az ASC megelőzi a hajtott kerekek kipörgését és gondoskodik a lehető legjobb vonóerőről és stabilitásról, miközben az autó az úton van. 5 ACU: Airbag Control Unit, más néven a légzsák vezérlő elektronika. Az ő feladata a légzsákok felfújása baleset esetén. oldal 4

5 A régi kommunikációs módok kiváltására dolgozta ki a 80 -as években a Robert Bosch Kft. a CAN buszt (Controller Area Network). A kábelkorbácsok kiváltását egy soros kommunikációs csatorna alkalmazása oldotta meg. A rendszer lényege, hogy egy kétvezetékes kommunikációs csatornán helyezkednek el, a különböző elektronikus vezérlőegységek (0.1. ábra). Az első CAN buszvezérlő chipet az Intel és a Philips készítette el 1987-ben. Ez a vezérlő még a CAN 1.0-ás szabványt ismerte. A ma is használt CAN 2.0-ás szabványt a Bosch 1991-ben publikálta. A CAN busz megfelelő hibadetektálással és zavarvédelemmel rendelkezik, valamint a nagy adatátviteli (akár 1 Mbit/sec) sebesség tette alkalmassá az autóipari alkalmazásra. A magas megbízhatóság elengedhetetlen, hiszen ezen a csatornán helyezkednek el olyan rendszerek, mint az ABS, ASC, amiknek életvédelmi szempontból elengedhetetlen a megbízható működésük. A nagy adatforgalom és a biztonság növelése miatt már nem egy, hanem legalább 2 különálló CAN busz található a gépjárművekben. Az egyik általában a nagysebességű (1 Mbit/sec) vonal, ezen kapnak helyet a motorvezérlő elektronika, ABS, ASC. A másik egy kis sebességű busz (125 Kbit/sec), itt a nem létfontosságú eszközök helyezkednek el. Ilyen például a központi zár, elektromos ablakemelő és az ablaktörlő ábra - CAN busz a gépjárműben [6] oldal 5

6 A CAN busz mellet 1990-ben egy másik kommunikációs protokoll került kifejlesztésre az európai autógyártók által, a LIN busz (Local Interconnect Network). Ennek jóval kisebb az adatátviteli sebessége (19,2 Kbit/sec) valamint a megbízhatósága is kisebb. Nagy előnye abban rejlik, hogy igen olcsó. Általában a CAN hálózatok alhálózataként használják. A magasabb prioritású, fontos üzenetek a CAN buszon közlekednek, míg a LIN buszt a kisebb feladatok megoldására használják, ilyen lehet például az elektromos ablakemelés és ablaktörlés. Az egyre több elektronikával felszerelt járművek miatt a CAN busz is kezdi kinőni magát. A CAN kiváltására fejlesztették ki a FlexRay-t, ami 2007-ben látott napvilágot. Az adatátviteli sebessége 20 Mbit/sec. Az első FlexRay-el felszerelt autó 2007-ben gurult ki a BMW gyárból. oldal 6

7 1.2. Fizikai réteg A fizikai réteg feladata a bitek hibamentes továbbítása. Ezen a szinten van megfogalmazva a vezetékezés és a bitek továbbítási formája. A CAN hálózat szimmetrikus jelátvitelt alkalmaz. A szimmetrikus jelátvitelhez két vonalra van szükség, ami egy sodrott érpáron történik. Ez lehet árnyékolt, vagy árnyékolatlan érpár. A két vezetéket CAN_H-nak és CAN_L-nek nevezik. Erre az érpárra csatlakoztathatóak az eszközök (0.2. ábra). Előnye a buszrendszernek, hogy könnyedén csatolhatóak rá további eszközök, és el is távolíthatunk róla állomásokat. Két ISO szabvány rögzíti a CAN-t. Ezek között a különbség a fizikai rétegben jelentkezik. Az ISO a nagysebességű (akár 1 Mbit/sec) CAN alkalmazásokat foglalja magában, míg az ISO az alacsony sebességűeket (125 Kbit/sec) ábra - CAN hálózat A CAN busz az NRZ (Non-Returnto-Zero) [3] kódolást alkalmazza. A kódolás lényege, hogy csak akkor van átmenet a bitidő kezdetén, ha az előzőzőtől különböző bit érkezik (0.3. ábra). Az NRZ kódolásból nem lehet kinyerni az órajelet, ezért szükséges minden, a kommunikációban résztvevő eszköznek szinkronizálódnia a vételhez ábra - NRZ kódolás [3] oldal 7

8 A szinkronizálásnak kétféle fajtája van. Az egyik esetben az üzenet első bitjére történik a szinkronizálás, ez a SOF bit (Start of Frame). A busz nyugalmi helyzetben magas szinten van. A SOF bit kezdetekor egy lefutó él generálódik. Erre az élre történik az első szinkronizáció. Ezt Hard Syncronization -nak nevezik. A szinkronizáció második variációja előtt meg kell nézni egy fontos dolgot. Ez nem más, mint a Staff Bits, vagy más néven a beszúrt bit. Amikor létrejött az adó és a vevő eszköz közötti szinkron, az idő múlásával egyre jobban elcsúsznak egymástól. Hiszen saját órajel forrásuk van az eszközöknek és ezek sebessége, még ha igen kis mértékben is, de eltér egymástól. Egy 8 bites aszinkron adatátvitelnél, mint például az RS232, ez nem jelent gondot, hiszen a kevés bitidő alatt nem történik nagy szinkronelcsúszás. A CAN csomagok esetében két probléma merül fel. Az egyik a bitek nagy számából (akár 100 bit egy csomagban) és az NRZ kódolásból adódó bitátmenet hiánya. Abban az esetben, ha nagyon sok megegyező bit követi egymást, nem történik jelszint változás a buszon. Az alábbi ábrán (0.4. ábra) látható egy adat csomag, majd alatta a CAN busz által átalakított üzenet. A CAN szabvány kimondja, ha 5 megegyező bit követi egymást, akkor egy ellentétes bitértéket kell beszúrni. De hogy erre miért is van szükség? 0.4. ábra Beszúrt bitek [4] oldal 8

9 Erre a válasz az újra szinkronizáció. Lényege, hogy minden recessziv 1 - domináns 2 bitátmenetnél vevők újra szinkronizálódnak az adáshoz (0.5. ábra). Ezzel csökkentve az aszinkron kommunikációból eredő szinkronizáció problémáját ábra Újra szinkronizálás [4] A CAN vezérlő TTL jelszinten kommunikál a buszmeghajtó áramkörrel. A kontroller a CAN_TX és CAN_RX vonalakon küldi és fogadja a biteket. A buszmeghajtó feladata, hogy előállítsa a csavart érpárra jutó szimmetrikus jelértéket. A buszon kétféle érték lehet, az egyik a domináns 0, a másik a recesszív 1 bitérték. Mint az alábbi ábrán (0.6. ábra) is látható a CAN_H és a CAN_L vonalak feszültség különbsége adja meg, hogy a bit domináns, vagy recesszív értékű. A következő táblázat mutatja a jelszintekhez tartozó feszültségértékeket. Az itt rögzített értékek az ISO által megfogalmazott nagysebességű CAN alkalmazásokra értendők. Bitérték Feszültség Tűrés domináns 0 0V max. 0,5V recesszív 1 2V min. 0,9V 0.6. ábra - CAN busz jelszintek A csavart érpár és a szimmetrikus jelátvitel nagy előnye, az elektromágneses zavarással szembeni ellenállósága. Mint azt a 0.7. ábra is szemlélteti, ha egy 1 A recesszív bit a CAN buszon a logikai 1 -nek felel meg. 2 A domináns bit a CAN buszon a logikai 0 -nak felel meg és magasabb prioritással rendelkezik. oldal 9

10 elektromágneses impulzus éri a buszt, az mind a CAN_H és a CAN_L vonalon megjelenik, azonos előjellel. Mivel a két vonal különbsége adja meg a jelszintet, ez a zavarás kiesik. Az Udiff feszültség változatlan marad. Ez az egyik fontos tulajdonsága a busznak, ami alkalmassá tette az autókban való alkalmazásra ábra - Elektromágneses zavarás A fizikai rétegnél még egy fontos dolgot szükséges tárgyalni, ez nem más, mint a vezetékezés. A CAN szabvány kimondja, hogy megadott adatátviteli sebesség esetén mi a maximálisan használható vezetékhossz. Ezen kívül a lezáró ellenállások értékét is táblázat rögzíti (0.1. táblázat). Távolság Lezáró ellenállás Max. baud rate 0-40 m 124 Ω 1 Mbit/s m 127 Ω 500 Kbit/s m Ω 100 Kbit/s m Ω 50 Kbit/s 0.1. táblázat - CAN busz, vezetékek A maximálisan megadott kábelhossz értékeknél fontos szerepet játszott a jelterjedési idő. Az adó által kiadott domináns vagy recesszív bit, különböző késésekkel érkezik meg a vevőhöz, a jelterjedési idő miatt. Fontos kritérium a CAN busz esetében, hogy a kialakuló legnagyobb időkésés nem érheti el a mindenkori bitidő felét. oldal 10

11 1.3. Az üzenetek keretformátumai A CAN buszra kerülő üzenetek meghatározott keretformátumot kapnak. Az első változata a CAN 1.0 volt, ezt ma már nem használják. A ma használatos kétféle üzenettípus a CAN 2.0A és a CAN 2.0B. Mint azt a 0.8. ábra is mutatja, az eltérés a keretformátumok között az arbitrációs 1 részben van. Ez tulajdonképpen a csomag azonosítója vagy címe. A CAN 2.0A formátumnál 11 bit azonosít egy csomagot. Ezt Standard Frame -nek hívják. Ilyenkor 2048 féle cím osztható ki az üzeneteknek. Abban az esetben, ha ez kevésnek bizonyulna egy alkalmazásnál, akkor lehet használni a CAN 2.0B-t. Ilyenkor a 11 bit mellett további 18 bit áll a rendelkezésre a cím megadására. Ezt hívják Extended Fame -nek. Itt az összesen 29 bit segítségével db cím adható meg ábra - CAN keretformátumok [4] Az arbitrációs részt leszámítva látható, hogy az üzenetformák nagyjából megegyeznek. Általánosságban elmondható egy keretről, hogy a SOF (Start of Frame) bittel kezdődik. Majd ezután következik az arbitrációs rész, vagyis az üzenet azonosítója (ID-je). Majd a RTR (Remote Transmission Request) bit következik. Ha ennek a bitnek az értéke 1, akkor adáskérést jelent egy másik állomástól, azonban ha 1 Arbitráció: A CAN üzenet elejét, az üzenet címét jelenti. Az üzenet küldésekor ebben a részben dől el több adó között kinek lesz joga az adáshoz. Vagyis versengés a buszért. oldal 11

12 0, akkor adatküldés van. A standard és kiterjesztett formátumú üzenetet az IDE (Identifier Extension) bit különbözteti meg. Melynek értéke 0 a standard formátumú keret esetében, míg értéke 1, ha kiterjesztett formátumú a keret. Az ezt követő szakasz, a vezérlő rész (CTRL). Az IDE bit az általános keret esetében itt kapott helyet. A DLC (Data Length Code) adja meg az üzenetben található adatbájtok számát. Ennek az értéke minimum nulla és maximum nyolc lehet. Ebből a 4 bites részből fogja tudni a vevő, hogy hány bájt adat fog érkezni. A következő maximum 64 biten találhatóak az adatbájtok. Itt legfeljebb 8 bájtnyi hasznos információ tárolható. Ezután következik egy 15 bites CRC (Cyclic Redundancy Code) mező. Ez a kód az üzenet hibamentes célba juttatását segíti. Az adó állomás az adatbájtokból matematikai műveletek segítségével előállít egy 15 bites CRC kódot, majd az üzenetbe illeszti. A vevő egység ezt a kódot ugyanazokkal a matematikai műveletekkel visszafejti, és ha megegyezik az adatbájtokkal, akkor tudjuk az üzenetről, hogy az átvitel során nem szenvedett sérülést. A CRC mező végén található az ACK (Acknowledge) bit. Ha valamelyik vevő, a CRC alapján helyesnek találta az üzenetet, akkor a vevő ennek a bitnek a helyét domináns értékkel írja felül, így az adó látja, hogy az üzenet sikeresen célba ért. Amennyiben egy állomás se írja felül ezt a bitet, vagyis recesszív értéket olvas vissza, abban az esetben az adó átvált hibakereső üzemmódba. A keret végén egy 7 bites EOF (End of Frame) szakasz jelzi az üzenet végét. Minden bitjének értéke 1. Itt nem érvényes az 5 bitenkénti ellentétes bit beszúrása, ha nem történt változás a bitek értékében A CAN üzenetek fajtái A CAN buszon négy féle üzenetet különböztetünk meg. Ezek az üzenetek szállíthatnak adatot, vagy jelezhetnek hibát, esetleg adatot kérhetnek. Data Frame (Adat keret): Ez a csomag adatot juttat el az adótól a veő(k)ig. A már korábban tárgyalt bitek (0.8. ábra) közül a RTR bit domináns értéke jelzi egy üzenet Data Frame mivoltát. oldal 12

13 Remote Frame (Adat kérő keret): Az adatkérő keret lényege, hogy egy eszköz kezdeményezhesse, hogy egy másik állomás üzenetet küldjön. Fontos hogy az adatkérő keret azonosítójával megegyező azonosítójú választ kell küldenie. A Remote Frame -et az RTR bit recesszív értéke jelzi. Error Frame (Hibakezelő keret): A keret a segítségével jelezhetik vissza az állomások, ha hibát észleltek a fogadott adatban. Overload Frame (Túlcsordulást jelző keret): Ha egy csomópont nem tud több adatot fogadni pillanatnyilag, akkor ezzel az üzenettel jelezheti a hálózat fele, hogy késleltessék a neki küldött üzeneteket Arbitráció Az előző pontokban ismertetésre került a CAN busz fizikai rétege és az üzenetek formátumai. Mint korábban szó esett róla kétféle keretet használ a CAN. Az egyik a Standard Frame, ami 11 bites azonosítót tartalmaz, míg a másik az Extended Frame, ami 29 bites üzenetazonosítóval rendelkezik. A CAN busz esetében nem az állomásoknak van címe, hanem az üzeneteknek. Ha egy csomópont üzenetet akar küldeni, előtte meg kell szereznie a buszhozzáférési jogot. Azt, hogyha több eszköz egyszerre szeretne adni, ki kapja meg az adási jogot elsőként, az arbitrációs rész határozza meg. Két bitérték van, a domináns és a recesszív. A 0.9. ábra szemléltet egy olyan esetet mikor 3 csomópont szeretne egyszerre adni. A felső 3 idődiagram az egyes állomások kiküldött üzenete. Az alsó diagram pedig a CAN buszon megjelenő üzenet. Az üzenetküldés kezdetén mind a 3 állomás elkezdi az adást. Sorra küldik ki a biteket, majd visszaolvassák a buszt. oldal 13

14 0.9. ábra - Arbitráció A busz hozzáférési jog a döntési mezőben dől el. Addig, amíg mind a 3 állomás megegyező biteket küld a buszra, nem történik semmi, mind adó módban vannak. Az 5. bitnél történik az első fontos esemény. A második állomás recesszív, míg a többi domináns bitet küldött. A CAN buszon a domináns bit fog megjelenni, hiszen ez rendelkezik nagyobb prioritással. Mivel az eszköz vissza is olvassa a buszt, tudni fogja, hogy egy, vagy több állomás domináns bitet küldött, így ő elveszti az adási jogot, és átvált vételi módba. Majd a 2. bitnél az első állomás is elveszti az adási jogot. Ezzel a módszerrel nem alakul ki ütközés az üzenet küldésekor. Amelyik eszköz elveszti az adási jogot, átvált vételre és megkapja az aktuális csomagot. Összegezve tehát, annak az üzenetnek van nagyobb prioritása a buszon, aminek az azonosító ID-je kisebb értékű. oldal 14

15 1.6. A CAN busz felhasználási területei A CAN buszt elsősorban az autóipar használja. Hiszen eredetileg gépjárművekbe fejlesztették ki. Az autóipari alkalmazása megkövetelte a megbízható működést, gyorsaságot, magas zavarvédelmet. Manapság azonban egyre több helyen kezdik alkalmazni a megbízható működése miatt (0.10. ábra) ábra - CAN busz alkalmazási területei [4] A CAN busz elterjed kommunikációs protokollnak számít, az ipari folyamatautomatizálásban és az orvostechnikában, tömegközlekedésben, épületautomatizálásban, robotikában és még számos helyen. oldal 15

16 2. CAN kommunikáció A mikrokontrollerben található 2 db CAN vezérlő önmagában nem elég a buszmeghajtáshoz. Szükséges egy vonali illesztő elhelyezése a processzor és a CAN busz között. A mikrokontroller kimenete (CANRX, CANTX) 0-3,3V-os jelszinteket ad ki. A CAN busz vonalmeghajtó ezeket a jeleket illeszti a szimmetrikus jelszinteket tartalmazó buszra. A kapcsolásba az MCP2551 nevű vonali illesztő került. Az illesztő adatlapjából néhány oldal az M4-es mellékletben látható. Az M4.a melléklet tartalmazza az IC paramétereit. Az illesztő 1Mbit/sec adatátvitelre képes és az ISO es CAN szabványt támogatja. A kapcsolási rajz elkészítésénél az MCP2551-nek szükséges 5V-os tápfeszültségről kell gondoskodni, valamint a felfutási időt állító ellenállást (Rcanx) kell elhelyezni (2.1. ábra). Mivel a processzor 3,3V, és az illesztő 5V-os tápfeszültséget kap, elvileg szükséges lenne egy jelszint illesztés. Azonban a processzort támogatja a TTL jelszinteket és az MCP2551 a 3,3V-os bemenetet. A processzor bemenete elviseli az 5V-os jelszintet, és az illesztő már 2V-tól logikai 1 -nek veszi a jelet. Ez a M4.c mellékletben látható ábra - CAN busz vonalillesztők A kapcsolási rajzon látható kondenzátoroknak zavarszűrési szerepe van. Az IC, a kimenet változásakor megrántja a tápfeszültséget. Ezeket az ingadozásokat szűrik a kondenzátorok. Végül az RcanxCLS ellenállás, a CAN busz lezárásáról gondoskodik. Ezt csak akkor kell beforrasztani, ha az eszköz végponton kapott helyet. oldal 16

17 3. Firmware Ebben a fejezetben a mikrokontrolleren futó szoftver tervezése szerepel. Ez a kód működteti az egyes perifériákat, vezérli a kommunikációkat. A következőkben bemutatásra kerülnek az egyes vezérlőmodulok működése, a róluk készült folyamatábrák segítségével Firmware fejlesztés A mikrokontroller programkódja C nyelven készül. Saját modulok lettek tervezve a perifériák működtetéséhez. A modulok elkészítésénél az AT91SAM7A3 adatlapja [7] nyújtott segítséget. Az elkészült modulok fordítása a GCC fordítóprogrammal [8] történt. A szoftver felépítése moduláris, ezek a függvénygyűjtemények egy-egy nagyobb feladattal foglalkoznak. Az adott fájlon belül minden szükséges függvény megtalálható, ami ahhoz szükséges, hogy a modul el tudja látni a feladatát. Az alábbi 3.1. ábra szemléleti a modulok egymással való kapcsoltat. A legfelső szinten helyezkedik el a main.c fájl, ez alá sorakoznak fel a különböző funkciókat ellátó részek. A hardverszinttel a legalsó (spi.c, can.c, usart.c, uif.c) modulok tartják a kapcsolatot ábra - Modulok oldal 17

18 3.2. Inicializálás Az inicializálás függvény, a main.c modulban található. Ez a funkció csak egyszer, a processzor indítása után fut le. Feladata a processzor konfigurálása, az egyes perifériák élesztése. Az inicializálás blokkvázlata látható az alábbi ábrán (3.2. ábra), amit az Init() függvény valósít meg ábra - Inicializálás Első lépésként a mikrokontroller perifériáinak és IO portjainak konfigurálása történik. A perifériák beállítására segítséget nyújt az AT91SAM73A adatlapjában található példa a 213.oldalon [7]. Itt példákat hoznak fel kimeneti portok konfigurálására, például a port IO, periféria A vagy B használatára. Az IO inicializálásnál a port irányok beállítása történik. A következő részekben az SPI, az USART, a CAN és az LCD inicializálások történnek. Itt az Init() függvény csak meghívja a perifériakezelő modulok konfigurációs részét. Ezeknek a függvényeknek paraméterátadással leget megadni a periféria adatait, oldal 18

19 mint például a kommunikációs sebesség (baud rate), CAN esetében szűrőket, maszkokat, valamint a FIFO-k méretét is. A TIMER0 inicializálás azért szükséges, mert ez ad egy rendszeridőzítést. Vannak folyamatok, amiknek meghatározott időben újra és újra le kell zajlaniuk, ilyenkor az időzítő által generált megszakítás indítja el őket. A kimeneti kommunikációs FIFO-k ellenőrzése lehet egy példa. Hiszen bizonyos időnként ellenőrizni kell, nincsen e küldendő adat egy pufferben. Az inicializálás legvégén még a megszakítások engedélyezését el kell végezni. oldal 19

20 3.3. CAN Az alábbi ábrán látható a CAN modul kommunikációért felelős része (7.5. ábra). Ha egy folyamat küldeni szeretne ünetet, a CAN buszra, akkor azt a push() (3.5. ábra) függvénnyel teheti meg. A CAN kezelőnél alkalmazott FIFO-k tulajdonképpen kétdimenziós struktúra tömbök. A struktúra felépítése: typedef struct { unsigned char adr3; unsigned char adr2; unsigned char adr1; unsigned char adr0; unsigned char dlc; unsigned char data[8]; }mob; //üzenet címe //adatbájtok száma //8 bájt adat Egy ilyen típusú struktúrát kell átadni a FIFO-nak. Az adat elvétel a pop() (3.6. ábra) függvény segítségével történik. Ha a függvény visszatérési értéke nulla, akkor nincs beérkezett adat, egyébként egy struktúra címe, ami CAN csomag típusú ábra - CAN kommunikáció oldal 20

21 Az AT91SAM7A3 mikrokontroller CAN modulja (3.4. ábra) 16 db úgynevezett MOB-ot (Message Object) tartalmaz. Tulajdonképpen postaládák, amikbe a küldendő, vagy a vett adat érkezik. Ezek a MOB-ok tartalmaznak a vezérléshez szükséges változókat, és egy CAN csomag tárolásához szükséges megfelelő regisztereket. Egy MOB-ot lehet adó, vagy vevő módban használni. Az alábbi ábrán láthatók a MOB-ok, amiket MBx-el jelöltek. A vezérlő ezekből a MOB-okból prioritási sorrendben veszi ki az adatokat és kerül a CAN Protokol Controller -be, ami elküldi a buszra. A beérkező üzenet szintén egy postafiókba érkezik, majd egy megszakítás generálódik, ahol le kell kezelni az üzenetet, célszerűen a bemeneti FIFO-ba töltéssel ábra - Az AT91SAM7A3 CAN vezérlője A vezérlő függvény feladata, hogy figyelje a kimeneti puffert. Ha van a FIFO-ban adat, és szabad a CAN busz, akkor a soron következő elemet másolja egy MOB-ba. Ezután már a mikrokontroller hardvere a felelős az üzenet továbbításáért. oldal 21

22 3.5. ábra - FIFO írás 3.6. ábra - FIFO olvasás oldal 22

23 4. Irodalomjegyzék [1] BOSCH - CAN Specification version 2.0: [2] CAN busz - [3] NRZ - [4] ATMEL - CAN tutorial: ne_2005/pdf/can_tutorial.pdf [5] [6] [7] AT91SAM7A3 adatlap: [8] GCC: oldal 23

24 5. Mellékletek oldal 24

25 M4.a melléklet: MCP2551 specifikáció oldal 25

26 M4.b melléklet: MCP2551, DC karakterisztika oldal 26

27 M4.c melléklet: MCP2551, DC karakterisztika oldal 27