Matej Korade KOMUNIKACIJSKI MOST VGRAJENIH SISTEMOV V CAN OMREŽJU Diplomsko delo Jarenina, november 2012

Matej Korade KOMUNIKACIJSKI MOST VGRAJENIH SISTEMOV V CAN OMREŽJU Diplomsko delo Jarenina, november 2012

KOMUNIKACIJSKI MOST VGRAJENIH SISTEMOV V CAN OMREŽJU Diplomsko delo Študent: Matej KORADE Študijski program: Univerzitetni študijski program Smer: Telekomunikacije Mentor: doc. dr. Iztok KRAMBERGER

ZAHVALA Da sem lahko preživljal poučne ure v laboratoriju, kjer sem osvojil mnoga znanja. Četudi se kakšna stvar razloži mnogokrat, se razloži zmeraj z isto vnemo in energijo, važno je namreč, da se z njo reši problem. Kjer je tudi sestanek lahko poučen in zabaven hkrati. Hvala vsem v Laboratoriju za digitalne sisteme. doc. dr. Iztok Kramberger, Srečko Grašič, Dejan Gačnik, Miha Gostenčnik, asist. dr. Marko Kos. Hvala staršem, punci, vsem prijateljem, ki so mi stali ob strani v času študija. Zahvaljujem se za trud pri lektoriranju te diplomske naloge. Hvala mag. Gordana Rodinger in Lea Ekart i

KOMUNIKACIJSKI MOST VGRAJENIH SISTEMOV V CAN OMREŽJU Ključne besede: TCP/IP protokol, CAN omrežje, mikrokrmilniki, vgrajeni sistemi, programiranje UDK: 004.451.031.43:004.031.6(043.2) Povzetek V diplomski nalogi je opisan razvoj aplikacij, ki povezane v celoto tvorijo premostitev fizičnega CAN vodila preko vgrajenega sistema. Razvoj vsebuje analizo obstoječega vgrajenega sistema in načrtovanje programske opreme za mikrokrmilnik, ki je ključni del tega sistema. Analiziramo delovanje simulatorja, s katerim simuliramo ostalo strojno opremo enega izmed sistemov in razvijamo modul zanj. Opisane so tehnologije uporabljene pri razvoju sistema. Med te spada analiza TCP protokola za prenos podatkov in analiza CAN omrežja. Prikazan je sistem uokvirjanja, ki se uporablja v vseh aplikacijah in omogoča enostavno kodiranje in dekodiranje sporočil. CAN sporočila namreč zakodirana natovorimo v TCP paketke, kjer se kot takšni preko interneta pošiljajo med sistemi. S tem smo premostili CAN vodilo preko obstoječih tehnologij, kar pomeni, da se naši sistemi lahko med seboj pogovarjajo ne da se nahajajo na isti lokaciji. ii

COMMUNICATION BRIDGE FOR EMBEDDED SYSTEMS IN CAN NETWORK Key words: TCP/IP protocol, CAN network, microcontrollers, embedded systems, programing UDK: 004.451.031.43:004.031.6(043.2) Abstract This graduation thesis describes development of applications which all connected into whole make a bridge from the physical CAN bus over embedded system. Development contains analysis of the existing embedded system and planning the software for the microcontroller which is a key factor on the system. We analyze the simulator which we use to simulate the hardware of another existing system used and we develop the module for it. We describe technologies that are used in development of the system. Here we have analysis of the TCP protocol for transferring data and analysis of the CAN network. We show the developed system of framing used in all applications which makes coding or decoding data easy. Coded CAN messages are loaded into TCP packets where we send them over the internet between the systems. With this we have bridged the CAN bus using existing technologies, which means that our systems can now communicate without being on the same location. iii

Kazalo vsebine 1 Uvod... 1 2 Pregled stanja... 2 2.1 Komunikacijsko omrežje CAN...2 2.1.1 Plastni model CAN omrežja... 3 2.1.2 Glavne lastnosti CAN omrežja... 5 2.1.3 Tipi okvirjev sporočil v CAN omrežja... 6 2.1.4 Sinhronizacija... 8 2.1.5 Odpravljanje napak... 9 2.2 TCP/IP protokol... 10 2.2.1 Lastnosti TCP protokola...10 2.2.2 TCP vtičnica... 11 2.2.3 Potrjevanje in nadzor podatkov... 11 2.3 Komunikacijski most vgrajenih sistemov... 13 2.3.1 OSI model komunikacijskega mostu... 15 2.3.2 Povezava na CAN vodilo z vgrajenim sistemom USB2CAN... 16 2.3.3 Simulator TSIM z knjižnico CANIP.(SO DLL)... 16 2.3.4 Strežnik CANHUB...16 2.3.5 Testna aplikacija TCPCLIENT... 17 2.3.6 Razvojna programska okolja... 17 2.4 Programski jezik... 19 2.5 Dinamično povezovalne knjižnice... 19 2.6 Mikrokrmilniki in vgrajeni sistemi...20 3 Opis sistema... 21 3.1 Orodja... 21 3.1.1 CodeVision AVR 2.05... 22 3.1.2 TSIM ERC32/LEON simulator... 22 3.1.3 NetBeans IDE 6.9... 22 4 Strojna oprema... 22 4.1 Mikrokrmilnik Atmel AT90CAN32... 23 4.2 Procesor LEON3-FT SPARC V8 LEONDARE... 24 4.2.1 CAN krmilnik v GRCAN modulu znotraj LEONDARE... 27 4.3 Vgrajen sistem USB2CAN...28 4.4 Programiranje strojne opreme... 31 5 Programska oprema... 32 5.1 Način okvirjanja in pretvorbe CAN sporočila... 32 5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo... 34 5.3 Aplikacija gostitelja CANHUB... 37 5.3.1 Razlaga diagrama poteka CANHUB aplikacije... 37 5.4 Aplikacija odjemalec TCPCLIENT... 40 5.4.1 Razlaga diagrama poteka TCPCLIENT aplikacije... 40 5.5 Aplikacija odjemalca TCP2FTDI... 42 5.5.1 Razlaga diagrama poteka TCP2FTDI aplikacije... 42 5.5.2 Glavne funkcije in spremenljivke ter smer povezave... 46 5.6 Aplikacija na mikrokrmilniku... 48 5.6.1 Glavne funkcije in spremenljivke ter smer povezave... 48 5.6.2 Razlaga diagrama poteka aplikacije na mikrokrmilniku... 50 5.7 Aplikacija, ki teče na TSIM simulatorju... 52 5.7.1 Glavne funkcije in spremenljivke ter smer povezave... 52 6 Meritve in rezultati... 56 6.1 Čas oddajanja CAN sporočila iz vgrajenega sistema... 56 iv

6.2 Odzivni čas TCP paketa... 58 6.3 Hitrost prejemanja in oddajanja mostu... 59 7 Sklep... 60 8 Viri in literatura... 61 Kazalo slik slika 2.1 Omrežje CAN v sodobnih avtomobilih... 3 slika 2.2 OSI referenčni model za CAN... 4 slika 2.3 Podatkovni okvir sporočila CAN protokola... 6 slika 2.4 Oddaljen okvir sporočila CAN protokola... 6 slika 2.5 Okvir napake sporočila CAN protokola... 7 slika 2.6 Okvir preobremenitve sporočila CAN protokola... 8 slika 2.7 Segmenti bitnega časa v CAN protokolu... 9 slika 2.8 OSI referenčni model za TCP/IP... 10 slika 2.9 Sistem potrjevanja med odjemalcem in strežnikom... 12 slika 2.10 Tehnika drsečega okna... 13 slika 2.11 Primerjava OSI modelov TCP/IP in CAN... 14 slika 2.12 Komunikacijski most vgrajenih sistemov... 15 slika 2.13 Premostitev med plastmi CAN in TCP... 15 slika 2.14 Razvojno okolje Netbeans 6.9... 18 slika 2.15 Razvojno okolje Codevision AVR 2.05... 19 slika 3.1 Koncept komunikacijskega mostu...21 slika 4.1 Mikrokrmilnik Atmel AT90CAN32... 23 slika 4.2 Procesor LEON3-FT LEONDARE... 25 slika 4.3 Blokovni diagram LEONDARE zasnove... 26 slika 4.4 Blokovni diagram GRCAN modula... 27 slika 4.5 Vgrajen sistem USB2CAN... 28 slika 4.6 Shema linij D-SUB 9 konektorja... 28 slika 4.7 Shema linij FTDI FT232RL... 29 slika 4.8 Shema AT90CAN32... 30 slika 4.9 USBasp programator za Atmel mikrokontrolerje... 31 slika 4.10 Shema priključitve Atmel mikrokrmilnika z ISP... 31 slika 5.1 Razporeditev bitov v enem CAN sporočilu... 32 slika 5.2 Prikaz pretvorbe podatkov v ASCII znake in okvirjanje... 33 slika 5.3 Razbijanje okvirjev in pretvorba nazaj v CAN sporočilo... 36 slika 5.4 Diagram poteka aplikacije CANHUB... 39 slika 5.5 Diagram poteka TCPCLIENT aplikacije... 41 slika 5.6 Diagram poteka TCP2FTDI aplikacije... 45 slika 5.7 Smer povezave z funkcijami in spremenljivkami programa TCP2FTDI... 46 slika 5.8 Smer povezave z funkcijami in spremenljivkami programa GCN... 49 slika 5.9 Diagram poteka aplikacije na mikrokrmilniku... 51 slika 5.10 Smer povezave z funkcijami in spremenljivkami ter moduli programa TSIM... 53 slika 6.1 Zaslonska slika zajetega prometa na mrežni kartici s programom Wireshark... 56 slika 6.2 Časovni potek enega CAN sporočila na fizičnem vodilu... 57 slika 6.3 Časovni potek dveh CAN sporočila na fizičnem vodilu... 57 slika 6.4 Odzivni čas TCP paketkov... 58 slika 6.5 Padec hitrosti po zasičenju... 59 slika 6.6 Meritev hitrosti oddajanja in prejemanja podatkov mostu... 59 v

Seznam simbolov Ω V - ohm je simbol za električno upornost - volt je simbol za električno napetost RS232 - je ime za serijo standardov, ki predstavlja serijska vrata. k - kilo je simbol za 10 3 M - mega je simbol za 10 6 µ - mikro je simbol za 10-6 m - mili je simbol za 10-3 Hz s - hertz je simbol za frekvenco - je simbol za sekundo vi

Seznam uporabljenih kratic ECU CAN IP TCP SAE ISO OSI HLP D-SUB 9 CSMA CD ID ACK FIN RTR LLC MAC PLS PMA USB OS SOC RISC CMOS MIPS ALU ang. Electronic Control Units, Elektronske kontrolne enote ang. Controller Area Network, omrežje krmilnikov ang. Internet Protocol, internetni protokol ang. Transmission Control Protocol, Protokol za nadzor prenosa ang. Society of Automotive Engineers, združenje inženirjev avtomobilske industrije ang. International Standards Organization, mednarodna organizacija standardov ang. Open Systems Interconnection ang. Higher Layer Protocols, visoko plastni protokoli ang. D SUBminiature 9 pin connector ang. Carrier Sense Multiple Access, večkratno dostopanje z zaznavanjem vodila ang. Collision Detection, zaznavanje trkov ang. Identification, identifikacijsko številko ang. Acknowledge, sprejeto ang. Finnish, končaj ang. Remote Transmittion Request, zahteva po oddaljenem pošiljanju ang. Logical Link Control, linija logične kontrole ang. Medium Access Control, kontrola dostopa do medija ang. Physical Signaling, fizični signali ang. Physical Medium Attachment, priključitev fizičnega medija ang. Universal Serial Bus, univerzalno serijsko vodilo ang. Operating System, operacijski sistem ang. System On Chip, sistem na čipu ang. Reduced Instruction Set Computing, ang. Complementary Metal-Oxide Semiconuctor, komplementarni železo-oksidni polprevodnik ang. Million Instructiones Per Second, milijon inštrukcij na sekundo ang. Arithmetic Logic Unit, aritmetična logična enota vii

EEPROM SRAM RTC PWM USART ADC JTAG SPI IEEE FT DARE RAM AMBA AHB APB EDAC PROM SDRAM I/O GPIO UART ASCII FIFO ang.electrically Erasable Programmable Read-Only Memory, zbrisljiv in programirljiv bralni pomnilnik ang. Static Random-Access Memory, statični pomnilnik z naključnim dostopom ang. Real Time Counter, realno časovni števec ang. Pulze Width Modulation, pulzno širinska modulacija ang. Universal Synchronous/Asynchronous Receiver/Transmitter, univerzalni sinhroni/nesinhroni sprejemnik/oddajnik ang. Analog To Digital Converter, analogno-digitalni pretvornik ang. Joint Test Action Group, vmesnik za preizkušanje ang. Serial Peripheral Interface Bus, sinhrono vodilo za standardno serijsko podatkovno povezavo ang. Institute of Electrical and Electronic Engineers, Inštitut inženirjev elektrotehnike in elektronike ang. Fault Tolerant, odporen na napake ang. Design Against Radiation Effect, zasnova proti radiacijskemu efektu ang. Random Access Memory, pomnilnik navadnega dostopa ang. Advanced Microcontroller Bus Architecture, napredna arhitektura vodila mikrokontrolerja ang. Advanced High-speed Bus, napredno vodilo velikih hitrosti ang. Advanced Periheral Bus, napredno vodilo periferije ang. Error Detection And Correction, zaznava in odprava napake ang. Programable Read Only Memory, programirljiv bralni pomnilnik ang.synchronous Dynamic Random Access Memory, sinhroni dinamični pomnilnik z naključnim dostopom ang. Input/Output, vhod/izhod ang. General Porpouse Input Output, široko namenski vhodno izhodi priključki ang. Universal Asynchronous Receiver Transmitter, univerzalni asinhroni sprejemnik/oddajnik ang. the American Standard Code for Information Interchange, ameriška standardna koda za izmenjavo informacij ang. First In First Out, prvi not prvi ven viii

RTT ang. Round Trip Time, odzivni čas paketka ix

1 Uvod V današnjih časih so vgrajeni sistemi prisotni že na vsakem koraku. Od mobilnih naprav kot so pametnimi telefoni, multimedijske naprave, pametne naprave v avtomobilih, kot so navigacija, radio,klima, itd.. Priča smo razvoju visoko zmogljivih naprav z zelo specifičnim delovanjem, ki ga poganja procesor kot srce tega vgrajenega sistema. Pravzaprav skorajda več ni mogoče zaslediti sodobne elektronske naprave brez procesorja. Od preprostih mikrokrmilnikov do kar precej zmogljivejših procesorjev, kot na primer v mobilnih napravah. V sodobnih avtomobilih imamo veliko takšnih vgrajenih sistemov. Različne elektronske kontrolne enote (ang. electronic control units), v nadaljevanju ECU podsistemi, katerih del so senzorji, elektronika, mikroračunalniki, med seboj komunicirajo in v realnem času obdelujejo sporočila. To počno preko omrežja, ki smo ga podrobneje spoznali ter nadgradili v tej diplomski nalogi in se imenuje omrežje krmilnikov (ang. controller area network), v nadaljevanju CAN omrežje. Ta je bil razvit prav z namenom za uporabo v avtomobilih, zaradi zanesljivosti in visoke hitrosti pa se dandanes uporablja še v medicini, letalski industriji, navtiki, avtomatizaciji industrijskih obratov, vojski. Vse več je popularen tudi pri projektih za vesolje. Tema te diplomske naloge se nanaša na izdelavo komunikacijskega mosta med različnimi vgrajenimi sistemi, ki znajo komunicirati preko CAN protokola, vendar obstajajo vsak na svoji platformi in so celo pozicijsko dislocirani. Tako smo ustvarili most ali nekakšen virtualni podaljšek obstoječega CAN vodila. Z izvedbo tega mostu smo izgubili osnovno idejo, ki so jo imeli v mislih snovalci CAN protokola, da naprave komunicirajo brez gostiteljskega računalnika. Razvili smo namreč gostiteljsko aplikacijo nameščeno na gostiteljskem računalniku, katera bo sposobna komunicirati preko internetnega protokola (ang. Internet protocol), v nadaljevanju IP protokola. Del tega je protokol za nadzor prenosa (ang. transmission control protocol), v nadaljevanju TCP protokol. Tega smo uporabili z razlogom, saj ta skrbi, da sporočila prispejo k naslovniku v pravilnem vrstnem redu, brez da se kakšno izgubi. Vsako sporočilo, katero gostiteljska aplikacija sprejme, odpošlje vsem ostalim enotam, razen tisti, ki je sporočilo poslala. Ker njegovo delovanje spominja na omrežno napravo, ki deluje kot»repetitor«in se ji angleško reče HUB, smo to aplikacijo poimenovali kar CANHUB. S pomočjo gostiteljske aplikacije smo preko virtualnega CAN vodila povezali simulacijski program TSIM, enostaven program klient ter program klient kateri služi kot dejanski priključek na fizično CAN vodilo preko obstoječe strojne opreme katera je bila predhodno razvita s strani laboratorija kjer sem opravljal diplomsko nalogo. V sledečih poglavjih bomo predstavili obe uporabljeni tehnologiji, TCP protokol in CAN omrežje, opisali koncept mostu in izdelavo vseh programov. Na koncu bodo podani rezultati hitrosti prenosa podatkov preko tega edinstvenega komunikacijskega mostu različnih sistemov. 1

2 Pregled stanja Dandanes je možno zaslediti ogromno novih načinov, kako razširiti CAN protokol preko obstoječih komunikacijskih tehnologij. Vse več je razvoja v tej smeri, glede na to, da se je ta dobro uveljavil v različnih industrijskih panogah. Glede na veliko priljubljenost CAN protokola v zadnjih letih smo lahko priča razvoju takšnih ali drugačnih vgrajenih sistemov, ki dovoljujejo uporabo, komunicirajo s pomočjo sledečega. Kljub temu pa smo pri rešitvi problema, ki smo si ga zastavili pri tej diplomski nalogi, morali izhajati iz začetka. Da smo lahko povezali specifične sisteme in nadgradili CAN vodilo, ter tako ustvarili edinstven most, smo vse aplikacije razvili in napisali na novo. Pri gradnji mostu med sistemi, ki uporabljajo CAN omrežje in povezavi naših aplikacij, smo si pomagali z dobro znanim TCP protokolom, ki je del IP protokola, pogosto krat imenovan kar TCP/IP. 2.1 Komunikacijsko omrežje CAN Z hitrim razvojem elektronskih naprav in vedno večjem deležu le-teh v avtomobilih so pred dobrimi 20. leti iznašli CAN protokol, katerega so daljnega leta 1983 razvili pri Robert Bosch GmbH 1. Ta je bil razvit zaradi neuspešnih poskusov implementacije serijskega RS232 2, ki bi služil za komunikacijo med ECU enotami. Naposled so se odločili, da je čas za nov protokol. Takšen, ki bo v realnem času zagotavljal zanesljivo komunikacijo, ki bo zmanjšal število žic in na katerem bo hkrati več gospodarjev. Preden je ta bil uradno izdan, je minilo še nekaj let in tako smo leta 1986 s strani kongresa SAE ali združenja inženirjev avtomobilske industrije v Detroitu dobili tudi uradno verzijo. Leta 1987 so na tržišče izšli prvi čipi z CAN krmilniki. Te sta proizvajala Intel in Philips. Leta 1991 je iznajditelj objavil še CAN 2.0 specifikacijo katera se v širšem uporablja še danes. Vodilo CAN je eno izmed petih protokolov, ki se dandanes uporabljajo v diagnostičnih standardih za vsa vozila proizvedena po letu 2004. Zaradi vsesplošne razširjenosti in posledično relativno nizkih cen mikroračunalnikov, ki zmorejo delovati skladno z CAN protokolom, je uporaba le-tega skozi leta narasla. Pojavi pa se uporaba tega protokola pri razvoju drugih tehnologij, kot je na primer razvoj satelitov za vesolje ali pri kontroliranju industrijskih procesov, navtiki, vojski, medicini itd. CAN omrežje deluje na principu, da lahko več enot povežemo v eno skupno vozlišče, katerega predstavlja CAN vodilo podobno serijskemu vodilu. Vse te enote so si enakovredne, kar pomeni, da imamo mnogo gospodarjev vodila, vse te enote lahko istočasno razpršeno oddajajo. Vsaka enota je sposobna komunicirati vsaj z eno sebi enako. Lahko ali oddaja ali sprejema sporočila, 1 Robert Bosch GmbH je nemško podjetje, ki je razvilo in patentiralo CAN protokol za potrebe v avtomobilski industriji. 2 RS232 je v telekomunikacijah tradicionalno ime za serijo standardov, ki opisujejo podatkovne in kontrolne serijske signale med DTE (ang. data terminal equipment) in DCE (ang. data circuit-terminating equipment). V splošni uporabi v računalništvu predstavlja serijska vrata. 2

vendar tega ne more početi istočasno. Vse to poteka brez nadzornega ali gostiteljskega računalnika saj je mikroračunalnik kateri vsebuje CAN krmilnik in skrbi za pravilno delovanje že v sami enoti. V primeru avtomobilov so te enote elektronske kontrolne enote ECU, med katere spadajo na primer zračna blazina, sistem elektronskega zaviranja, senzorji itd. Slika 2.1 prikazuje splošno CAN omrežje v današnjih avtomobilih. slika 2.1 Omrežje CAN v sodobnih avtomobilih Kot smo že omenili, potrebuje vsaka enota svoj mikroračunalnik ter oddajnik. CAN krmilnik, ki je na mikrokrmilniku, skrbi za pravilno pošiljanje in sprejemanje sporočil. Mikrokrmilnik, ki je sprejel sporočilo, se odloči, kaj to sporočilo pomeni in katero sporočilo bo oddal. Pri sprejemanju sporočila CAN krmilnik shranjuje serijsko zaporedje bitov iz vodila, dokler ne dobi celotnega sporočila, katerega da v obdelavo mikrokrmilniku. Pri oddajanju sporočila mikrokrmilnik poda sporočilo CAN krmilniku, ki pošlje to sporočilo kot serijsko zaporedje bitov na vodilo. Naloga oddajnika je, da pri sprejemanju sporočil prilagodi nivoje signalov iz vodila na nivoje signalov CAN krmilnika. Pri oddajanju pa pretvori oddajne bitne signale iz CAN krmilnika v signale, ki se pošljejo na vodilo. 2.1.1 Plastni model CAN omrežja Kot večina omrežij tudi CAN omrežje sledi pristopu plastnega (ang. open systems interconnection), v nadaljevanju OSI referenčnega modela pri sami zasnovi sistema. Tega je razvila mednarodna organizacija standardov (ang. international standards organization), v nadaljevanju ISO organizacija kot standard, ki se uporablja kot osnutek, kateri sledi temu plastnemu pristopu. Tak pristop dovoljuje medsebojno delovanje produktov različnih proizvajalcev. slika 2.2 prikazuje referenčni model OSI za CAN omrežje. 3

slika 2.2 OSI referenčni model za CAN CAN protokol skoraj v celoti uporablja spodnji dve plasti OSI referenčnega modela. Izpuščena je samo definicija, kateri komunikacijski medij se naj uporablja za prenos. Tako je omogočena večja fleksibilnost, saj se snovalcem sistema omrežja dovoli optimizacija in prilagajanje komunikacijskega protokola na različnih medijih. Sukana parica, optični kabel, radijske frekvence, infrardeča svetloba, itd. Tako je snovalcem prepuščena svoboda pri ostalih petih zgornjih plasteh OSI referenčnega modela. Pomembno je le, da snovalci sistema uporabijo homogene bitne hitrosti v omrežju. Za snovanje le teh se pogosto uporabljajo visoko plastni protokoli (ang. higher layer protocols), v nadaljevanju HLP. Nekatere osnovne funkcionalnosti za katere se HLP uporabljajo : standardnih zagonskih procedurah, vključno z uporabljenimi bitnimi hitrostmi, razdeljevanje naslovov med sodelujočimi enotami ali tipi sporočil, določitvi strukture sporočil, zagotavljanju rutin za odpravljanje napak na sistemskem nivoju. Po standardu ISO 11898 so definirane nekatere lastnosti, ki so bile ob sami zasnovi sistema abstraktne. Te se nanašajo na fizični nivo. ISO 11898-2 določa elektronski vidik fizičnega nivoja. Katere napetosti se uporabljajo, tokovni nivoji, število prevodnikov. Kakorkoli, ta standard ne vključuje mehanskega vidika fizičnega nivoja. Tako je pri avtomobilih moč ugotoviti, da imajo ECU enote tipično svojevrstne priključke, ki povezujejo linije CAN vodila. Saj kot omenjeno standard ne specificira tip priključka, število žic, 4

barvo, oznake... Najbolj pogosto se uporablja D-SUB 9 3 vmesnik, ki je postal nekakšen nenapisan standard. Tako skorajda več ni moč zaslediti enote, ki nima ali moške ali ženske različice D-SUB9. Energija iz CAN vodila se daje enotam preko ženskega priključka in enote dajejo energijo CAN vodilu preko moškega priključka. Tako dobimo zaključen tokokrog pri ženskem priključka, s čimer se izognemo izdelavi posebnih vmesnikov za podaljševanje dveh kablov CAN vodila. ISO 11898-2 zavzema imunost CAN vodila na šum. Če vzdržujemo diferenčno impedanco vodila na nizkem nivoju z upori 120Ω na vsakem koncu CAN vodila, lahko zmanjšamo šum. Slaba stvar je, da bo vodilo porabilo veliko več energije kot smo vajeni pri drugih napetostno baziranih omrežjih. Standard določa tudi imuniteto skupne stopnje napetosti med oddajnikom in sprejemnikom. To se doseže tako, da imamo zraven vodila vključeno še linijo ničelne napetosti. S tem dosežemo veliko stopnjo razpoznavnosti napetosti med enotami. Nenapisano pravilo je, da se zraven linije ničelne napetosti doda še linija skupnega napajanja s čimer dovedemo napajanje vsem enotam. Sama napetost te ni specificirana vendar se v praksi največkrat uporablja linearno regulirana napetost 5V. 2.1.2 Glavne lastnosti CAN omrežja CAN komunikacijski protokol je CSMA/CD. Kratica CSMA (ang. carrier sense multiple access) pomeni, da mora vsaka enota, ki je del omrežja, opazovati vodilo za določeno periodo neaktivnosti preden lahko pošlje sporočilo na vodilo. To pomeni zaznavanje vodila (ang. carrier sense). Prav tako ima vsaka enota po pretečeni periodi neaktivnosti enako možnost, da prične pošiljati sporočilo (ang. multiple access). Sporočilo v grobem vsebuje ID (ang. identification) ali identifikacijsko številko kateri predstavlja prioriteto sporočila in naslov, temu pa sledi do osem zlogov podatkov. To se pošlje serijsko na skupno vodilo, katerega zaznajo vse enote, ki so na vodilu. Kratica CD (ang. collision detection) pomeni, da je protokol sposoben zaznavati trke sporočil. Kadar dve enoti istočasno pričneta pošiljati sporočilo, bosta zaznali trk in sprožili primerno dejanje imenovano deterministična arbitraža vodila. Sporočilo z dominantnim ID identifikatorjem dobi prioriteto pred sporočili z manj dominantnimi identifikatorji. Dominantna so sporočila z numerično manjšimi vrednostmi identifikatorjev, katera imajo prednost in se pošljejo prva. Vse ostale enote, ki so izgubile arbitražo, prenehajo oddajati in sprejmejo to sporočilo ne da bi izgubljale na času. CAN komunikacijski protokol je sporočilno baziran protokol ne naslovno baziran protokol. Kar pomeni, da se sporočila ne pošiljajo od ene enote do druge glede na naslov. Vse enote namreč sprejmejo vsa sporočila, ki so bila poslana na vodilo in ob pravilnem sprejemu tudi javijo potrditev 3 D-SUB 9 je elektronski vmesnik kateri ima 9 vtičnic v dveh vrstah obdanih z kovinskim ščitom oblike črke D. Ščit skrbi za pravilno orientacijo priključitve in ščiti pred elektromagnetnimi motnjami. Moški D-SUB predstavlja čep, ženski pa vtičnico. 5

(ang. Acknowledge), v nadaljevanju ACK. Vsaka enota se nato odloči ali je sporočilo potrebno takoj zavreči ali pa se obdrži za procesiranje. Tako je lahko eno samo sporočilo namenjeno eni sami enoti ali mnogim. Uporabna lastnost CAN protokola je tudi sposobnost, da enota zahteva informacije od drugih enot. To stori tako, da jim pošlje zahtevo za oddaljene podatke (ang. remote transmit request), v nadaljevanju RTR. Tako namesto, da enota čaka na informacije od druge enote jih specifično zahteva. Prav tako ima CAN protokol možnost dodajanja novih enot v omrežje brez dodatnega programiranja obstoječih enot, da bi te zaznale novinca. Ta takoj začne sprejemati sporočila in se glede na ID sporočila odloči, ali procesirati ali zavreči podatke. Pomembno je, da pri sami zasnovi sistema z razmislekom razdelimo identifikatorje oziroma prioritete naprav, kajti teh kasneje ne moremo dinamično spreminjati brez reprogramiranja. 2.1.3 Tipi okvirjev sporočil v CAN omrežja V CAN protokolu so definirani 4 tipi sporočil ali okvirjev. Najbolj pogost okvir se imenuje podatkovni okvir (ang. data frame), kar prikazuje slika 2.3. Ta se uporablja, kadar enota pošilja informacijo eni ali vsem enotam v sistemu. slika 2.3 Podatkovni okvir sporočila CAN protokola Drugi okvir se imenuje oddaljen okvir (ang. remote frame), kar prikazuje slika 2.4. To je v bistvu podatkovni okvir z nastavljenim bitom RTR, kar pomeni, da pošiljamo zahtevo za oddaljene podatke brez polja podatkov. slika 2.4 Oddaljen okvir sporočila CAN protokola 6

Polje arbitraže se uporablja za določanje prioritete sporočila na vodilu. CAN protokol verzije 2.0B pozna dva načina polja arbitraže. Poimenovana sta standardni okvir (ang. standard frame) ter razširjen okvir (ang. extended frame). Pri standardnem okvirju je polje arbitraže velikosti 12 bitov. 11 bitov za identifikator in eden bit za določanje RTR. Pri razširjenemu okvirju je to polje velikosti 32 bitne besede. 29 bitov za identifikator, eden bit, ki definira razširjen okvir, eden bit za določanje RTR in eden bit, ki ni uporabljen z imenom SRR. Polje kontrole je sestavljeno iz šestih bitov. Začne se z IDE bitom, kateri določa ali je v uporabi razširjen ali standardni okvir. Pri razširjenem okvirju je bit RB1, kar bit IDE kateremu sledi RB0. Ta dva sta rezervirana (ang. reserved bit). Zatem imamo 4 bite, ki se imenujejo DLC (ang. data lenght code) in določajo koliko zlogov podatkov sledi. Polje podatkov je veliko glede na DLC. Teh je lahko od nič do osem zlogov. Kadar se pošilja oddaljen okvir sporočila je število zlogov podatkov zmeraj nič ne glede na vrednost DLC. Polje CRC (ang. cyclic redundancy check) ali cikličnega preverjanja redundance, ki je ena izmed metod preverjanja ali so bili vsi podatki poslani brez napake, je veliko 15 bitov plus en bit kot ločevalnik. Torej velikosti 16 bitne besede. Polje ACK se uporablja za javljanje pravilnega sprejema sporočila in zaseda 2 bita. Vsaka enota, ki uspešno sprejme sporočilo, ne glede na to, ali ga obdela ali zavrže, doda dominantni bit v ACK polje. CAN protokol definira še dva okvirja za ravnanje z napakami. Eden se imenuje okvir napake (ang. error frame), kar prikazuje slika 2.5. Tega ustvarijo enote, kadar zaznajo katero od znanih napak v CAN protokolu. Sestavljeno je iz šest do dvanajst bitov za superpozicijo zastavic napak. Ter osmih bitov, ki jih zasede mejnik napake. Poznamo aktivno napako, pri kateri je zastavica napake sestavljena iz šestih dominantnih bitov ter pasivno napako, pri kateri je zastavica napake sestavljena iz šestih recesivnih bitov. slika 2.5 Okvir napake sporočila CAN protokola 7

Ter zadnji z imenom okvir preobremenjenosti (ang. overload frame), kar prikazuje slika 2.6. Tega ustvarijo enote, kadar potrebujejo več časa, da obdelajo že dobljeno sporočilo. Tako javijo omrežju, da niso sposobne sprejemati dodatnih sporočil. slika 2.6 Okvir preobremenitve sporočila CAN protokola 2.1.4 Sinhronizacija Sinhronizacija poteka večkrat med samim prenosom sporočila. Vsaka enota vsebuje svojo uro katera se ne pošilja v sporočilu. Da CAN protokol zagotovi pravilno vzorčenje vse do zadnjega bita, se mora vsaka enota večkrat sinhronizirati skozi celoten okvir. Sinhronizira se na začetku sporočila kjer je SOF (ang. start of frame) kateri deluje na padajoč rob nivoja signala ter na vsakem robu signala med recesivnim (logična ena) in dominantnim (logična nič) bitom. Vsak bit se razdeli na štiri segmente. Segment sinhronizacije je fiksno določen in je reda enega časovnega kvanta TQ (ang. time quantum). V tem času se naj bi pojavili robovi bitov, zato služi za sinhronizacijo. Segment propagacije je nastavljiv med enim pa vse do osem časovnih kvantov. Je dvakratnik vsote časa, ki ga potrebuje signal, da prepotuje pot med najbolj oddaljenima enotama in časa zakasnitve gonilnika vodila. Segmenta faze 1 in faze 2 sta v uporabi zato, da izničita napake ob robu faze bita. Z pravilnim večanjem in manjšanjem teh dveh dosežemo ponovno sinhronizacijo. Faza 1 je nastavljiva med enim do osem časovnih kvantov, faza 2 je nastavljiva med dvema do osem časovnih kvantov. Točka vzorčenja je točka v kateri se določi logični nivo bita. Ta točka je na sredini med fazo 1 in fazo 2. Kakorkoli CAN protokol pozna tudi trojno vzorčenje na bit. Takrat sta eno polovico časovnega kvanta pred prvim vzorcem vzeta še dva vzorca. Vrednost logičnega nivoja bita se takrat določi z večinskim glasovanjem med temi tremi vzorci. Slika 2.7 prikazuje razporeditev segmentov in točko vzorčenja. 8

slika 2.7 Segmenti bitnega časa v CAN protokolu 2.1.5 Odpravljanje napak CAN protokol ponuja hitro in robustno komunikacijo saj je pri avtomobilih kritičnega pomena, da se napake odpravljajo efektivno v realnem času. Z izidom verzije 2.0B se je povečala hitrost kar za 8 krat na zavidljivih 1M bit/sekundo. Tako se tudi najbolj časovno kritični parametri lahko oddajajo brez skrbi o zakasnitvah. Prav tako pa ima protokol zadosten spisek napak, ki jih lahko zazna in s tem doseže integriteto sporočil. Enote v CAN omrežju imajo sposobnost zaznavanja nepravilnih stanj in se glede teh sposobne odločati med različnimi načini delovanja. Zaznavajo lahko male motnje in jih ločijo od trajnih. Enote pa so se sposobne iz normalnega delovanja, kjer normalno pošiljajo in sprejemajo sporočila, v trenutku samodejno izklopiti glede na določene okoliščine. Ta lastnost je dobrodošla, kajti tako enota katera povzroča napake ne more škodovati vodilu z neprestanim pošiljanjem in zasedanjem pasovne širine vodila saj se ta avtomatsko izklopi. Poznamo pet tipov napak in tri stanja napak v katerih so lahko enote glede na količino in tip odkrite napake. Tipi napak so: napaka potrjevanja (ang. acknowledge error), napaka cikličnega redundančnega preverjanja (ang. CRC error), bitna napaka (ang. bit error), napaka oblike (ang. form error), napaka tlačenja (ang. stuff error 4 ). Stanja napak so: aktivna napaka (ang. error-active), pasivna napaka (ang. error-pasive), vodilo izklopljeno (ang. bus off) 4 stuff error je napaka metode. Metode z imenom vsiljevanje bitov (ang. bit stuffing), pri kateri se za vsakih pet bitov z enako polariteto vstavi en bit z nasprotno polariteto 9

2.2 TCP/IP protokol Ker smo si kot cilj te diplomske naloge zadali nalogo kako povezati pozicijsko dislocirane CAN enote smo te med seboj povezali s pomočjo TCP protokola in interneta. To je eden izmed ključnih protokolov, ki jih pozna skupek protokolov IP. Ker TCP dopolnjuje IP protokol in skupaj zagotavljata storitve, ki upravljajo z večino prometa v internetnem omrežju se mu velikokrat reče kar protokolni sklad TCP/IP. Na tem protokolu sloni tudi večina internetnih aplikacij kot so pregledovalniki pošte, spletni brskalniki, FTP odjemalci, itd. S tem lahko prenašajo velike količine podatkov brez napak. Kakorkoli ga poimenujemo, kratica TCP pomeni protokol za nadzor prenosa. Ta skrbi, da je povezava med dvema računalnikoma, ki sta priključena na internet zanesljiva, in da je tok podatkov med tema računalnikoma v pravilnem zaporedju. Glede na to, da je CAN omrežje znano po svoji robustnosti in zanesljivosti smo si za njegov povečevalnik dometa izbrali TCP/IP protokol. 2.2.1 Lastnosti TCP protokola TCP protokol spada v transportni sloj OSI referenčnega modela. Je kot nekakšen vmesnik med aplikacijskim slojem kamor spadajo aplikacije in omrežnim slojem v katerega spada IP protokol. V sliki 2.8 je predstavljen OSI referenčni model za TCP/IP protokol. slika 2.8 OSI referenčni model za TCP/IP TCP je primer povezavno orientiranega protokola, kar pomeni, da komunikacijska sistema pred izmenjavo sporočil vzpostavita povezavo. To zagotavlja, da so sistemi vedno aktivni in pripravljeni za zamenjavo sporočil. Zagotavlja dodatne storitve, kot je potrjevanje prejetih paketov, kontrolo pretoka, zaznavanje in odpravljanje napak pri prenosu. Sistem uporabi te storitve za prenos 10

relativno velike količine informacij. Te storitve zagotavljajo verodostojno prenašanje datotek. Povezovano orientirani protokoli so zanesljivi, saj se potrjuje prejetje paketa brez napak. Slabost tega protokola pa je, da potrjevanje povzroča dodaten promet v omrežju. Še dodaten promet pa je potreben za vzpostavitev in porušitev povezave. Zaradi preobremenjenosti omrežja, izravnave prometnega tovora omrežja ali kakšnega drugega nepredvidljivega vedenja se bo kakšen paketek na poti izgubil, podvojil ali bo prispel v napačnem vrstnem redu. TCP protokol lahko zazna takšne probleme, zahteva ponovno pošiljanje izgubljenih paketkov, preuredi vrstni red in celo zmanjša obremenjenost omrežja, da se ne pojavi še več novih problemov. Skrbi za potrjevanje prejetih paketov, kontrolo pretoka, zaznavanje in odpravljanje napak pri prenosu. Lahko bi rekli, da TCP protokol pri vzpostavitvi povezave ustvari neke vrste virtualni kanal. Za vzpostavitev povezave med dvema sistemoma se uporablja metoda trojnega rokovanja (ang. three-way handshake). Po uspešnem rokovanju se vzpostavi kanal ali seja po katerem se pošiljajo sporočila v obe smeri. Zato je TCP polno dvosmeren protokol. Pri povezavi med strežnikom in odjemalcem se določita IP naslov in vrata odjemalca ter strežnika. Vrata v povezavi z IP naslovom imenujemo vtičnica (ang. socket). Vtičnica odjemalca in vtičnica strežnika tvorita edinstveno določeno TCP povezavo. 2.2.2 TCP vtičnica TCP uporablja vrata za identifikacijo strežniških in odjemalčevih aplikacij. Vsaka stran povezave ima na voljo 16 ne-predznačenih bitov za vrata, kar znaša med 0 do 65535 vrat. Sprejet TCP paketek se identificira glede na pošiljateljev IP naslov in vrata ter sprejemnikov IP naslov in vrata. Tako se ve na katero vtičnico je namenjen kakšna je storitev in aplikacija za to določeno vtičnico. Veliko vrat je namreč določenih tako, da se uporabljajo samo za določeno storitev in aplikacijo. Za brskanje po spletu (HTTP) se uporabljajo vrata 80, za prenašanje datotek (FTP) vrata 20 ali 21, za pošto (SMTP) vrata 25. 2.2.3 Potrjevanje in nadzor podatkov TCP uporablja za prenos podatkov med gostitelji tako imenovano drseče okno. To nadzoruje koliko informacij se lahko pošlje preko TCP povezave, preden mora sprejemna stran poslati potrditev. Ker ima vsak gostitelj okno za pošiljanje in sprejemanje je tako proces komuniciranja veliko bolj učinkovit. S pomočjo tega okna ima sprejemna stran čas, da preuredi paketke v pravilno zaporedje medtem ko čaka na preostanek informacij. Stran, ki pošilja pa s tem oknom zbira podatke o informacijah, ki so bile poslane. Če v določenem roku ne sprejme potrdila o sprejemu te podatke 11

ponovno pošlje. Odjemalec je namreč zadolžen za potrjevanje prejema ko enkrat začne prejemati podatke. Ker vsak odjemalec ne tvori ločenih potrdil za čisto vsako sporočilo ampak to stori v nekem intervalu, pravimo da TCP uporablja zakasnjeno potrditev. Interval je odvisen od trenutne implementacije TCP. Slika 2.9 prikazuje primer potrjevanja med odjemalcem in strežnikom. slika 2.9 Sistem potrjevanja med odjemalcem in strežnikom Vsako potrditveno sporočilo, ki ga odjemalec pošlje v odgovor strežnikovim podatkovnim sporočilom ima ACK zastavico in vrednost polja potrditvene številke odseva število zlogov v sekvenci ki jo je odjemalec uspešno sprejel. Kadar kateri izmed podatkov v sekvenci ni uspešno prispel odjemalec po pretečenem intervalu o tem obvesti strežnik z uporabo potrditvenega polja v sporočilu ACK. Vrednost številke v potrditvenem polju odseva število zlogov od začetka sekvence do manjkajočega dela. Vse delčke sporočila od te vrednosti naprej strežnik še enkrat pošlje, čeprav so lahko bili že predhodno pravilno poslani. Sistem vzdržuje vrsto sporočil, ki jih je poslal in izbriše tista, za katera dobi potrditev, da so prispela. Za sporočila, ki ostanejo v vrsti izvirnega sistema za določeno količino časa, se sklepa, da so bila izgubljena ali izbrisana in sistem jih ponovno pošlje. Za zaznavanje napak se uporablja preverjanje izračuna za kontrolo podatkov. Pred pošiljanjem ta izračun naredi pošiljatelj in jih vključi v sporočilo. Tega pri prejemu ponovi sprejemna stran in primerja dobljeno. Če se ujemata potem ni napak oziroma so če se ta dva izračuna ne ujemata. Takrat se uniči sporočilo, ki ima napake. Ker je to edina kontrola podatkov aplikacijskega sloja v protokolu TCP je zelo kritična. Je nenavadna saj se kontrola izvede nad TCP glavo, aplikacijskimi podatki in psevdoglavo. Psevdoglavo velikosti 12 zlogov sestavljajo IP naslov vira glave, IP naslova cilja, protokola, dolžino polj in polnila. Protokol IP vključuje še kontrolo na omrežni plasti vendar ta preverja samo glavo IP paketa. Ker ima vsak sistem omejeno količino pomnilniškega prostora v katerega si shranjuje prihajajoče podatke, je smotrno, da se uporabi zaščita. Ta skrbi, da ne prekoračimo pomnilniški prostor na ciljnem sistemu saj sporočila tam ostanejo do potrditve. Ciljni sistem namreč izvoru pošilja informacije s katerimi ta nadzoruje hitrost pošiljanja podatkov. Kadar se podatki pošiljajo prehitro kot jih je cilj sposoben obdelovati in bi to povzročilo izgubo podatkov se uporablja tehnika drsečega okna kar prikazuje Slika 2.10. 12

slika 2.10 Tehnika drsečega okna Kadar sprejemna stran sprejme podatke jih lahko samo toliko kot jih gre v drseče okno. Kadar potrdi sprejem z ACK zastavico se to okno prestavi desno. Za vsako ACK zastavico se prestavi enkrat. To se javi nazaj pošiljatelju. Tako pošiljatelj ves čas ve količino podatkov, ki jih lahko posreduje naprej. Drseče okno se namreč dinamično premika po nizu podatkov in s tem zagotavlja, da ne presežemo pomnilniški prostor prejemnika. Kot je pri vzpostavitvi povezave v uporabi trojno rokovanje je pri prekinitvi povezave v uporabi metoda štiri kratnega rokovanja. Pri tem vsaka stran prekine posamezno. Ko ena stran želi prekiniti povezavo pošlje FIN (ang. finnish) ali končaj paket. Druga stran se odzove z ACK paketom. Zatem tudi druga stran pošlje FIN paket. Druga stran se odzove z ACK paketom. Povezava pa se ne prekine v trenutku. Stran ki je sprožila prekinitev počaka še nek delček časa preden dokončno zapre vtičnico. S tem poskrbi, da se tudi zakasnjeni paketki uspešno prenesejo. S tem se zaključi TCP povezava. 2.3 Komunikacijski most vgrajenih sistemov Dobra stran TCP protokola je ta, da razvijalec uporabniške aplikacije ne potrebuje poznati vseh pravil tega protokola, kako so paketki sestavljeni in kaj se zgodi če se kakšen izgubi. Dovolj je, da posreduje podatke TCP protokolu. Ta pa bo poskrbel, da se bodo podatki prenesli po omrežju v pravilnem vrstnem redu in brez izgub. Pri izdelavi mostu med vgrajenimi sistemi v CAN omrežju je ravno ta ugodnost TCP protokola predstavljala največji problem. Kadar se TCP paketek izgubi, podvoji ali prispe na cilj v napačnem vrstnem redu to TCP protokol popravi. Tako da pošlje zahtevo po manjkajočem paketku in počaka da manjkajoč paketek ponovno prispe. Posledica ponovnega pošiljanja manjkajočega paketka pa je lahko velika časovna zakasnitev. Včasih tudi reda sekund. Zato se ta protokol ne uporablja za realizacijo realno časovnih aplikacij. Kar pa CAN protokol seveda je. Skleniti smo morali pomemben kompromis med realno časovno izvedbo in izgubo 13

podatkov. Ker je za aplikacije, katere so priključene na ta most bolj pomembno, da se sporočilo dostavi pravilno, kot pa kako dolgo za to potrebuje smo se na koncu odločili za predstavljen TCP protokol. CAN omrežju smo morali zmanjšati hitrost prenosa med enotami, ki so bile priključene na komunikacijski most. Popoln komunikacijski most med dvema različnima načinoma komunikacije je praktično nemogoče doseči. Zaradi tega je namreč bilo razvito CAN omrežje z namenom, da ugodi realno časovnim storitvam brez napak, kjer omrežje predstavljajo enote priključene na skupno vodilo in pozicijsko locirane tako, da so blizu. Pri TCP protokolu, ki upravlja z sporočili v IP omrežju pa je zgodba drugačna. Enote so pozicijsko dislocirane. Pot oziroma razdalja med njimi je lahko ogromna, poteka čez različna omrežja ločena z usmerniki (ang. router), čez različne države celo kontinente. Paketi prepotujejo to pot pravilno, vendar zaradi možnih napak včasih počasi. Kaj hitro dobimo predstavo, da vsem lastnostim CAN omrežja ne bo moč ugoditi. Zaradi sledečega je treba narediti kompromis med hitrostjo pošiljanja CAN sporočil preko TCP/IP omrežja. Želimo namreč da se podatki pošljejo pravilno, čeprav na račun hitrosti. Ker v našem omrežju ni nobenih življenju pomembnih enot kot smo jih priča v avtomobilih. Na primer varnostna blazina (ang. airbag), senzor pri avtomatiziranem procesu, itd. Cilj razvoja tega mostu je namreč dati v skupno uporabo CAN omrežje študentskim skupinam, da bodo lahko testirale komunikacijo med različnimi dislociranimi CAN enotami. Meritve bodo podane v zadnjem poglavju te diplomske naloge. Slika 2.11 prikazuje primerjavo OSI modelov TCP/IP in CAN. slika 2.11 Primerjava OSI modelov TCP/IP in CAN Če pogledamo primerjavo med OSI modelom CAN protokola in TCP/IP protokola, kar prikazuje zgornja slika, vidimo razliko na katerem nivoju deluje kateri model. CAN specificira fizično in povezovalno plast, pri čemer TCP/IP specificira transportno in povezovalno plast z domnevanjem, da smo priključni na internet. Pri rešitvi komunikacijskega mostu smo morali na TCP/IP omrežje 14

preko aplikacijskega nivoja naložiti sporočila iz CAN omrežja, da so lahko ta prepotovala internet. Za to smo morali razviti kopico aplikacij, celoten sistem je predstavljen v sliki 2.12. slika 2.12 Komunikacijski most vgrajenih sistemov 2.3.1 OSI model komunikacijskega mostu Če pogledamo TCP OSI model vidimo, da aplikacijska plast zavzema aplikacijsko, predstavitveno in sejno plast OSI referenčnega modela. Kot razvijalcu programske opreme je dovolj, da podatke, ki jih želimo prenesti v aplikacijski plasti posredujemo TCP protokolu. Ta z nižjimi plastmi TCP OSI modela skrbijo za pravilen prenos podatkov preko TCP protokola in IP protokola v internetnem omrežju. Slika 2.13 slika prikazuje to premostitev. slika 2.13 Premostitev med plastmi CAN in TCP 15

2.3.2 Povezava na CAN vodilo z vgrajenim sistemom USB2CAN Na fizično CAN vodilo smo se povezali z vgrajenim sistemom, ki smo ga poimenovali USB2CAN. Na tej strojni opremi je mikrokrmilnik ATMEL AT90CAN32 kateri ima vgrajen CAN krmilnik. Za tega smo napisali program, da se je znal obnašati kot pošiljatelj in sprejemnik CAN sporočil. Če pogledamo OSI plasti vidimo, da mikrokrmilnik na tem vgrajenem sistemu obvladuje celotno povezovalno plast, ter delček fizične plasti. LLC (ang. Logical link control) linija logične kontrole, MAC (ang. medium access control) kontrola dostopa do medija in PLS (ang. Physical Signaling) fizični signali. Za PMA (ang. physical medium attachment) priključitev fizičnega medija skrbi čip SN65HVD1050. Kot vmesnik pa se uporablja RS232 serijski priključek. Da je naprava priključena na univerzalno serijsko vodilo (ang. Universal serial bus), v nadaljevanju USB vodilo skrbi čip FTDI FT232RL. Da lahko CAN sporočila preberemo preko USB vodila, smo za to morali razviti aplikacijo, ki jo je poganjal operacijski sistem (ang. operating system), v nadaljevanju OS. Tako imamo CAN sporočilo preko vseh spodnjih plasti sedaj v aplikacijski plasti CAN modela. Tukaj poteka premostitev CAN sporočila v TCP niz podatkov saj sta aplikacijski plasti CAN modela in TCP modela v tem vgrajenem sistemu združeni. Da se sporočilo lahko pošlje preko TCP/IP se v aplikacijski plasti pretvori v TCP niz podatkov z primernim okvirjanjem posameznih CAN sporočil. To je koristno, da lahko na sprejemni strani razbijemo okvirje in dobimo posamezna CAN sporočila, ki so v tem nizu podatkov. To okvirjanje deluje v obeh smereh prenosa. 2.3.3 Simulator TSIM z knjižnico CANIP.(SO DLL) Morali smo razvili aplikacijo, ki bo znala poslana CAN sporočila iz TSIM uokvirit in poslati kot TCP niz podatkov. Ter obratno, bo iz prejetega TCP niza podatkov razbrala CAN sporočila in jih poslala TSIM simulatorju oziroma LEON3 procesorju. 2.3.4 Strežnik CANHUB Srce tega komunikacijskega mostu predstavlja aplikacija, ki smo jo poimenovali CANHUB. Nanj so priključene vse enote v našem sistemu. Je strežnik, ki skrbi za vzpostavitev novih TCP povezav z odjemalci. Zasnovali smo ga tako, da deluje kot ponavljalec sporočil. Kadar ena od enot pošlje TCP niz podatkov ga CANHUB sprejme ter odpošlje vsem ostalim enotam s katerimi je povezan. Delovanje je podobno kot je pri CAN omrežju. Kadar katera enota pošlje sporočilo to prispe do vseh ostalih enot na vodilu. Ker TCP protokol skrbi, da so sporočila v pravilnem vrstnem redu in brez napak, lahko trdimo, da smo dokaj uspešno premostili CAN omrežje. 16

2.3.5 Testna aplikacija TCPCLIENT Kot dodatna enota v sistemu je bila razvita preprosta aplikacija CAN klient. Ta je zmožna pošiljati in sprejemati CAN sporočila kot TCP niz podatkov. Namenjena je predvsem razhroščevanju (ang. debugging) oziroma testiranju. Z njim lahko obremenimo TCP promet, kar je seveda dobrodošlo pri meritvah katere bodo predstavljene v enem izmed poglavij. V prihodnje pa se lahko uporabi kot temelj za nadgradnjo sistema z kakšno dodatno premostitveno aplikacijo. 2.3.6 Razvojna programska okolja Za razvoj programov imamo na voljo široko izbiro razvojnih okolij. Nekateri so kompleksnejši, drugi preprosti. Kadar smo razvijali zapletene programe je bilo smiselno izbrati razvojna okolja katera vsebujejo podporo za ustvarjanje grafične podobe programa, vključno z urejevalnikom kode in seveda razhroščevalnikom. Kadar naša aplikacija vsebuje relativno majhno število vrstic kode, bo brez grafične podobe in se bo poganjala iz ukazne lupine, je dovolj kar preprosta beležnica kot urejevalnik izvorne kode. Zapletenejša razvojna okolja poskrbijo, da se glede na programski jezik v katerem kodiramo ob pritisku na gumb stvari prevedejo (ang. compile), povežejo (ang. link) in ustvarijo (ang. make). Pri kodiranju v navadni beležnici pa je naloga programerja, da v ukazni lupini požene ustrezne prevajalnike. Za programe napisane za OS Microsoft Windows se največkrat uporabljajo razvoja okolja Microsoft Visual Studio. Med zmogljiva programska okolja pa spadajo še Eclipse, NetBeans, itd.. Pri čimer je vredno omenit, da slednja lahko poganjamo na različnih OS, Microsoftovi programi pa so pač predvideni za sisteme z OS Windows. Slika 2.14 je zaslonska slika programskega okolja NetBeans. To smo uporabljali za pisanje programov katere bomo poganjali v OS Linux. 17

slika 2.14 Razvojno okolje Netbeans 6.9 Za Mikrokrmilnike kateri ne vsebujejo operacijskega sistema, se uporablja specifičen tip razvojnih okolij. Večinoma se razvojna okolja delijo glede na proizvajalce mikrokrmilnikov. Ker je v našem sistemu uporabljen mikrokrmilnik znamke Atmel je na voljo razvojno okolje Atmel AVR Studio in HP Info Tech Code Vision AVR katerega zaslonsko sliko prikazuje slika 2.15. V OS Linux je na voljo še Code Blocks IDE, Rowley CrossWorks CrossStudio for AVR itd. Ta razvojna okolja izvorno kodo napisano v programskem jeziku C pretvorijo v strojni jezik. Dobrodošla možnost teh je, da zaznajo priključen programer mikrokontrolerja in nudijo možnost takojšnega programiranja mikrokontrolerja, kot tudi samo razhroščevanje. 18

slika 2.15 Razvojno okolje Codevision AVR 2.05 2.4 Programski jezik C (izgovorjeno si kot črka c) je računalniški programski jezik namenjen širšemu namenu. Najprej je bil razvit za uporabo na OS Unix, danes pa se uporablja kot najbolj razširjen programski jezik, za katerega skorajda ni platforme, na kateri C prevajalnik ne bi obstajal. Čeprav je bil sprva namenjen implementiranju sistemske programske opreme, se je hitro razširil in začel uporabljati za ustvarjanje razvojno prenosljive aplikacijske programske opreme. Kot nadgradnja in katerega je navdihnil, je programski jezik C++, kateri je vključil še objektno programiranje v sam C programski jezik. 2.5 Dinamično povezovalne knjižnice V računalništvu je dinamični povezovalec del OS, kii naloži in poveže skupne knjižnice, kadar se je izvršljiv program zagnal in jih potrebuje. Sam OS in format izvršljive datoteke določata, kako se bo dinamični povezovalec ob tem obnašal in kako bo implementiral določene funkcije. Povezovanje (ang. linking) je proces, ki se izvede, kadar se izvorna koda prevaja (ang.compiling) v izvršno datoteko, do čimer dinamično povezovanje skrbi za dodajanje skupnih zunanjih knjižnic in dinamično povezovanje v trajajoč proces. V OS Windows imajo dinamično povezovalne knjižnice 19

končnico.dll, v OS Linux končnico.so, v OS Mac OS X končnico.dylib, OS Unix končnico.elf. 2.6 Mikrokrmilniki in vgrajeni sistemi Mikrokrmilnik je naprava, ki je zmožna samostojno opravljati različne naloge, procesirati podatke, se odločati po nastavljenih pogojih. V bistvu je delovanje precej podobno dosti dražjim mikroprocesorjem, katere posedujemo v osebnih računalnikih, le da so ti cenovno dostopni in nekoliko manj zmogljivi. Mikrokrmilnik pa ni samo mikroprocesor saj v splošnem poleg mikroprocesorja vsebuje še druge pomembne enote. Od delovnega pomnilnika, stalnega pomnilnika, vhodnih/izhodnih vmesnikov, generatorja ure za frekvenco sistema, različne periferne enote, itd. V bistvu je mikrokrmilnik nekakšen majhen računalnik, s specifičnimi perifernimi enotami pa je zmožen opravljati še veliko več kot kot domač računalnik. Vse skupaj je zapakirano v majhno ohišje kot integrirano vezje (ang. Intergrated circuit), ki mu pravimo čip. Uporabljajo se predvsem kot srce in možgani vgrajenih sistemov. Lahko imamo vmesnike za serijska vrata RS232, CAN kontroler, analogno-digitalne pretvornike, itd. Tako je mogoče ustvariti majhen vgrajen sistem, kateri dobro opravlja točno specifično nalogo. Za programiranje mikrokrmilnikov pa obstajajo prevajalniki, ki izvorno kodo napisano v programskem jeziku C prevedejo v strojni jezik. Tako programski jezik Assembler kot strojni jezik za opisovanje delovanja mikrokrmilnikov ni več vodilni pri programiranju mikrokontrolerjev, kar je pripomoglo k popularnosti mikrokrmilnkov. V svetu obstaja veliko proizvajalcev mikrokrmilnikov kot so Motorola, Phillips, Texas Instruments, Atmel, itd. Poznamo veliko različnih arhitektur procesorjev v mikrokrmilnikih. 8-bitni, 16-bitni, 32- bitni. Te izbere razvijalec vgrajenega sistema, ko dobro preuči vse zahtevane naloge. Hitrost procesiranja je namreč boljša pri večji arhitekturi vendar s tem tudi cena samega mikrokrmilnika. Vgrajen sistem je skupek elektronskih naprav, kateri je bil ustvarjen, da je zmožen opravljati specifične funkcije znotraj večjega sistema v realnem času. Lahko bi rekli računalnik v malem z dodanimi elektronskimi in mehanskimi deli, da je sposoben opravljati svojo nalogo. Razlika je ta, da so osebni računalniki namenjeni široki rabi in so fleksibilni glede na širok spekter uporabnikov. S tem, ko ima vgrajen točno specifične naloge, je le-te veliko lažje optimizirati, kar v dolgem roku prinese manjše stroške zaradi optimiziranega delovanja. V večini primerov se vgrajeni sistemi proizvajajo v masovni proizvodnji, kar še dodatno zmanjša samo ceno izdelka. Dandanes skorajda več ni mogoče zaslediti elektronske naprave brez vgrajenega sistema. Za realizacijo te diplomske naloge smo uporabili mikrokrmilnik proizvajalca Atmel z oznako AT90CAN32. Ta ima kot dodatno periferno enoto vgrajen CAN krmilnik z serijskimi vhodno/izhodnimi vrati. Naš vgrajen sistem namreč opravlja specifično nalogo pošiljanja in sprejemanja CAN sporočil preko USB vodila do osebnega računalnika na katerega je priključen. Aplikacija na tem računalniku pa pošilja ta CAN sporočila naprej v obliki TCP/IP paketkov. 20

3 Opis sistema Cilj, ki smo si ga zastavili in je predstavljen v tem poglavju, je izdelati povezave med različnimi enotami ali vgrajenimi sistemi, katere želijo komunicirajo preko CAN omrežja in so lokacijsko dislocirane na večjih razdaljah. Z uporabo IP omrežja in preslikave CAN sporočil, ter zasnovo ustreznega omrežnega mosta, bomo zagotovili enovito komunikacijo med takšnimi sistemi. Koncept predstavljajo štiri aplikacije in vgrajen sistem povezan na CAN omrežje kot prikazuje slika 3.1. slika 3.1 Koncept komunikacijskega mostu 3.1 Orodja Za izvedbo diplomske naloge smo potrebovali več orodij. Aplikacije smo razvili v orodju NetBeans 6.9 v programskem jeziku C. Vso ogrodje, torej potrebne programe, da lahko iz izvorne kode nastane izvršljiv program, ima sistem, na katerem bomo razvijali že vgrajene. Za razvoj in testiranje aplikacije, ki bo tekla na mikrokontrolerju smo uporabili programsko orodje HP Info Tech CodeVisionAVR, kjer se programira v programskem jeziku C. Ta ob inštalaciji naloži na sistem tudi vso potrebno ogrodje. Za razvoj aplikacij, katere smo poganjali znotraj simulacijskega okolja TSIM, je potrebno naložiti tako imenovane (ang. toolchains 5 ) kar je v bistvu ogrodje ki vsebuje programe 5 Toolchain (slo. veriga orodij) je v programski opremi set povezovalnih razvojnih orodij, ki se uporabljajo za ustvarjanje produktov, kateri so tipično predvideni, da se poganjajo na drugi platformi. Ime veriga pa zato ker se ta orodja uporabljajo v verigi, se pravi ena za drugo, da pridemo do končnega produkta. 21

za prevajanje, povezovanje in ustvarjanje za specifično platformo. TSIM namreč simulira LEON3 procesor kateri temelji na arhitekturi SPARC V8 6. 3.1.1 CodeVision AVR 2.05 Je orodje napisano za Amel mikrokrmilnike za OS Windows in vsebuje urejevalnik izvorne kode, razhroščevalnik, podporo za različne programatorje za direktno programiranje mikrokontrolerjev. Najbolj pomembna lastnost tega orodja pa je zagotovo svojevrsten set toolchains, ki se inštalirajo s samim programom. Uporabnik zato ne izgublja dragocenega časa in lahko kar takoj začne s pisanjem izvorne kode v programskem jeziku C. To lahko medtem kar preko tega orodja zapisujemo na mikrokontroler. Seveda ob kompatibilnem programatorju za mikrokrmilnike. 3.1.2 TSIM ERC32/LEON simulator Je orodje, napisano za OS Windows, Linux, Solaris in je sposobno simulirati delovanje procesorjev iz družine LEON ter ERC32 na ukaznem nivoju. Je dobra nadomestitev, kadar nimamo pri roki dejanskega procesorja, ta je namreč zelo drag. Ker dovoljuje priključitev različnih modulov pa je sposoben simulacije ne samo LEON procesorja marveč tudi njegovih dodatnih komponent. Te imajo končnico».dll«pri OS Windows in končnico».so«pri OS Linux. S pomočjo proizvajalcev omenjenega procesorja smo dobili želeni GRCAN model, kateri je omogočil CAN 2.0B vmesnik in je opisan v GRLIB IP 7 knjižnici. Modul se imenuje GR704. Ta modul doda dve povezavi za Spacewire 8 in eno za GRCAN krmilnik k ostalim jedrom katere že vsebuje TSIM. Tako dobimo možnost simulacije CAN krmilnika znotraj TSIM okolja kot ga vsebuje zasnova LEON3 procesor z dodatnimi komponentami imenovan LEONDARE in je sistem na čipu (ang. system on chip), v nadaljevanju SOC. 3.1.3 NetBeans IDE 6.9 Netbeans je razvojo okolje za pisanje aplikacij v programskih jezikih kot so Java, Javascript, PHP, Python, Groovy, C, C++, in drugi. Program je napisan v Javi in ga lahko poganjamo na OS Windows, Linux, Mac OS, Solaris, itd. Praktično na vseh platformah ki podpirajo namestitev javanskega virtualnega stroja (JVM) in javanskega razvojnega kita (JDK). Uporabljali smo ga za pisanje aplikacij v programskem jeziku C in C++. 6 SPARC je procesorska arhitektura z setom navodil, ki temelji na RISC. V8 je osma verzija te arhitekture. 7 GRLIB IP knjižnica je zbirka kjer so opisana IP jedra katera uporabljajo GRLIP plug&play konfiguracijske metode. 8 Spacewire je komunikacijsko omrežje, ki se uporablja na vesoljskih plovilih in je del IEEE 1355 standarda o komunikacijah. 22

4 Strojna oprema V tem poglavju bo pobližje predstavljena strojna oprema katera je bila v uporabi, njena implementacija in delovanje. Predstavljeni so ključni elementi vgrajenega sistema za priklop na fizično CAN vodilo in procesor, ki smo ga kot takšnega simulirali z programom TSIM. 4.1 Mikrokrmilnik Atmel AT90CAN32 Slednji mikrokrmilnik smo uporabili za izvedbo našega vgrajenega sistema saj vsebuje CAN krmilnik. Spada v družino AT90CAN 32/64/128. Te tri različice se razlikujejo po velikosti spomina. Od 32 do 64 in 128 k zlogov spomina. Slika 4.1 prikazuje čip z tem mikrokrmilnikom slika 4.1 Mikrokrmilnik Atmel AT90CAN32 So nizko energetski 8 bitni CMOS mikrokrmilniki kateri so zgrajeni na AVR RISC arhitekturi. So sposobni dosegati visoke hitrosti en MIPS (ang. Million Instructiones Per Second), milijon inštrukcij na sekundo na MHz kar dovoljuje snovalcu strojne opreme, da prilagodi in omeji porabo energije glede na zahtevano hitrost. Jedro AVR vsebuje bogat nabor navodil z 32 delovnimi registri namenjenim splošnem namenu. Vsi ti registri so povezani direktno z aritmetično logično enoto (ang. arithmetic logic unit), v nadaljevanju ALU. Ta dovoljuje dostopanje do dveh samostojnih registrov v enem izvršljivem ukazu v enem urinem ciklu. Mikrokrmilnik AT90CAN32 ima naslednjo konfiguracijo: 1k zlogov EEPROM 9 32k zlogov sistemskega programirljivega spomina (ang. Flash memory 10 ) z sposobnostjo branja in zapisovanja 9 EEPROM je zbrisljiv in programirljiv bralni pomnilnik (ang. electrically erasable programmable read-only memory). Je električno zbrisljiv in ponovno programirljiv spomin namenjen hranjenju in branju majhnih količin podatkov. Ti ostanejo shranjeni tudi po tem ko čipu odvzamemo električno napajanje. 23

2k zlogov SRAM 11 53 generalno namenskih vhodno izhodnih linij 32 generalno namenskih registrov CAN krmilnik Realno časovni števec RTC (ang. Real Time Counter) štiri fleksibilne števce/časovnike z možnostjo primerjanja in PWM (ang. Pulse Width Modulation), pulzno širinska modulacija dva USART (ang. universal synchronous/asynchronous receiver/transmitter), v nadaljevanju univerzalni sinhroni/nesinhroni sprejemnik/oddajnik bitno orientiran dvožični serijski priključek 8 kanalni 10 bitni ADC (ang. analog to digital converter), analogno-digitalni pretvornik z opcijo diferenčne vhodne stopnje z nastavljivo amplitudo programirljiv časovnik čuvaj pes (ang. Watchdog Timer) z notranjim oscilatorjem SPI serijska vrata (ang. serial peripheral interface bus), v nadaljevanju sinhrono vodilo za standardno serijsko podatkovno povezavo JTAG (ang. joint test action group), vmesnik za preizkušanje skladen po standardu IEEE 12 standard 1149, ki se uporabljajo za dostop do razhroščevanja sistema (ang. on-chip debug) in programiranja sistema Pet programirljivih stanj, ki jih program na sistemu lahko izbira za varčevanje z energijo Za programiranje sistemskega programirljivega spomina uporablja SPI serijska vrata, kar dovoljuje konvencionalnim programatorjem direktno programiranje brez odstranitve samega mikrokontrolerja iz vezja. 10 Flash memory je neizbrisljiv pomnilniški čip za računalniško hrambo podatkov katerega lahko samo električno izbrišemo in nanj ponovno zapišemo. Razvil se je iz EEPROM in ga je potrebno izbrisati v precej velikih blokih preden se lahko nanj ponovno zapiše z novimi podatki. 11 SRAM (ang. static random-access memory) je statični pomnilnik z naključnim dostopom, kar pomeni, da ga ni potrebno večkrat osveževati (statičen) in lahko hrani podatke katere lahko beremo in zapisujemo tako dolgo dokler ima čip električno napajanje. 12 IEEE (ang. Institute of Electrical and Electronic Engineers), Inštitut inženirjev elektrotehnike in elektronike. 24

4.2 Procesor LEON3-FT SPARC V8 LEONDARE LEON3-FT procesor je LEON3 procesor zgrajen na SPARC V8 arhitekturi, kateri je zasnovan tako, da je odporen na napake (ang. fault tolerant), v nadaljevanju FT. Slika 4.2 prikazuje dejanski procesor. slika 4.216 Procesor LEON3-FT LEONDARE Kot skupek vseh dodatnih modulov zgrajenih okrog tega procesorskega jedra, katere opisuje GRLIB IP knjižnica, je procesor z imenom LEONDARE. Ta poleg samega jedra LEON3-FT vsebuje še vrsto različnih modulov, vse to pa je vgrajeno v sam procesorski čip z imenom LEON3-FT LEONDARE. DARE (ang. design against radiation effect) zasnova proti efektu radiacije nam pove, da je ta procesor namenjen delovanju v strogih pogojih kot jih poznamo v vesolju. Saj so procesor zasnovali tako, da je sposoben zaznati in odpraviti napake vseh RAM (ang. random access memory), pomnilnik navadnega dostopa na čipu. LEONDARE arhitektura sloni na AMBA 13 AHB (ang. advanced high-speed bus), napredno vodilo velikih hitrosti, na katerega so procesor LEON3- FT in druge enote povezane. Enote, ki ne potrebujejo visoke pasovne širine so povezane preko AMBA APB (ang. advanced periheral bus), naprednega vodila periferije, do katerega se dostopa preko AHB na APB mostu. Vsebuje naslednje module: LEON3 SPARC V8 celoštevilsko enoto, enoto z plavajočo vejico in IEEE-754 enoto za upravljanje z pomnilnikom enoto za podporo razhroščevanja z UART povezavo 8/32 bitnim krmilnikom pomnilnikov z podporo za zaznavo in odpravo napake EDAC (ang. error detection and correction) za zunanji programirljiv bralni pomnilnik PROM (ang. programable read only memory), sinhroni dinamični pomnilnik z naključnim dostopom 13 AMBA (ang. advanced microcontroller bus architecture) napredna arhitektura vodila mikrokontrolerja je standard za vodilo na čipu za SOC dizajn. 25

SDRAM (ang. synchronous dynamic random access memory) in vhodno izhodne enote I/O (ang. input/output) Enoto časovnika z 32 bitnimi časovniki in časovnikom čuvaj pes (ang. Watchdog Timer) Krmilnik prekinitev za 15 prekinitev v dveh prioritetnih nivojih in AMBA AHB statusni register dva UART z prvi not prvi ven FIFO (ang. first in first out) in ločenimi generatorji bitne hitrosti (ang. baud rate) 16 bitna široko namenski vhodno izhodni priključki GPIO (ang. General Purpose Input Output) Dve SpaceWire povezavi priključek CAN 2.0B vodila z ločenimi signali vodila priključka (v skupni rabi z GPIO) FT različica procesorja ima še dodatne lastnosti: Ugotovi in popravi do 4 napake na 32 bitno besedo v registrski datoteki kadar se pojavi SEU 14 (ang. single event upset), do 4 napake na 32 bitno besedo v delovnem pomnilniku (ang.cache memory) in avtonomno in transparentno popravlja napake v programski opremi Sistem, ki vsebuje LEONDARE procesor vsebuje tudi zunanji pomnilnik kot je PROM/EEPROM, SRAM/SDRAM, RS232/RS422 gonilnike in urin oscilator. Slika 4.3 prikazuje to zasnovo. 14 SEU (ang. single event upset) je sprememba stanja v mikro elektronskih napravah kot so mikroprocesorji. Ta se zgodi kadar visoko energetski ioni elektromagnetnega sevanja zadenejo občutljivo vozlišče in ob tem spremenijo na primer stanje enega bita v pomnilniku. Sam SEU ni sposoben trajno uničiti tranzistorjev ali vezja v napravi. 26

slika 4.317 Blokovni diagram LEONDARE zasnove 4.2.1 CAN krmilnik v GRCAN modulu znotraj LEONDARE CAN krmilnik kot se nahaja v GRCAN modolu je zmožen delovati v sistemu kateri ima AMBA vodilo z prisotnima AMBA AHB in APB vodili. Preko AMBA APB vodila upravljamo nastavitve, kontrolo in status CAN krmilnika. AMBA AHB vodilo pa se uporablja za prejemanje in shranjevanje sporočil CAN v zunanji pomnilnik. Ta pomnilnik je zunaj CAN krmilnika in je lahko lociran ali na čipu ali zunaj čipa. CAN krmilnik podpira oddajanje in sprejemanje seta sporočil s pomočjo ločenih sprejemnih in oddajnih krožnih pomnilnikov lociranih zunaj jedra krmilnika. Tako lahko poteka pisanje in branje sporočil istočasno. Ko sprejmemo set sporočil se preko AMBA APB vodila sporoči DMA krmilniku kateri sproži večkratno branje na AMBA AHB vodilu, da ujame sporočila iz spomina, kar stori AMB gospodar. Po določenem prebranem številu podatkov, kar je nastavljivo, sproži krmilnik DMA prekinitev. Kadar se nastavi sprejemanje sporočila preko AMBA APB vodila začne CAN jedro prejemati sporočila. Da se ta shranijo v spomin se preko DMA krmilnika začne večkratno zapisovanje na AMBA AHB vodilo, kar stori preko AHB gospodarja. Po določenem zapisanem številu podatkov, kar je nastavljivo, sproži krmilnik DMA prekinitev. Krmilnik CAN lahko sprejema in pošilja sporočila na obeh CAN vodilih, primarnem in sekundarnem, ampak ne istočasno. Izbira CAN vodila se nastavi preko AMBA APB vodila. 27

Slika 4.4 prikazuje blokovni diagram GRCAN modula. slika 4.4 Blokovni diagram GRCAN modula 4.3 Vgrajen sistem USB2CAN Vgrajen sistem smo poimenovali USB2CAN (ang. USB to CAN) ali USB na CAN, ker služi kot povezava med fizičnim CAN vodilom in osebnim računalnikom preko USB. Na tem vezju je kar nekaj elementov, ki kot celota predstavljajo praktično in majhno strojno opremo s katero smo v največji meri premostili fizično CAN vodilo. Slika 4.5 prikazuje dejansko strojno opremo. slika 4.5 Vgrajen sistem USB2CAN 28

Mikrokrmilnik AT90CAN32 na tem vgrajenem sistemu služi kot CAN krmilnik. Čip SN65HVD1050 skrbi, da so vsi nivoji signalov, ki jih dobi od mikrokrmilnika na pravi amplitudi preden jih pošljemo na CAN vodilo. Signali, ki bodo prispeli po CAN vodilu pa bi lahko uničili mikrokrmilnik če ne bi bilo tega čipa, ki bo skrbel, da so tudi vhodni signali v primernem amplitudnem rangu. Kot vmesnik preko katerega se priključimo na fizično CAN vodilo se uporablja RS232 serijski priključek, ki se imenuje D-SUB 9. Slika 4.6 prikazuje priključitev signalnih linij. slika 4.6 Shema linij D-SUB 9 konektorja Rele, ki je pred tem priključkom pa preklaplja med dvema nivojema CAN vodila. Ta dva nivoja sta HIGH in LOW. Med samim delovanjem vgrajenega sistema je možno preklapljati med nivoji. To storimo z nastavljanjem vrednosti določenega bita na logično ena za HIGH ali logične nič za LOW v samem CAN sporočilu. Ta bit je privzeto rezerviran, mi pa smo ga uporabili specifično za to preklapljanje. Na drugi strani vezja imamo čip z imenom FTDI FT232RL. Ta skrbi za USB povezavo z osebnim računalnikom. Na osebnem računalniku pod OS Windows se namestijo primerni gonilniki, Čip FTDI pa skrbi da se USB povezava smatra kot klasična serijska RS232 povezava. Kajti dejansko ima naš mikrokrmilnik vhodne priključke za USART povezavo, se pravi za standardni RS232 priključek in RX ter TX liniji za prenos podatkov v serijskem zaporedju. Slika 4.7 prikazuje priklop tega čipa na USB vodilo. 29

slika 4.7 Shema linij FTDI FT232RL Kot je razvidno iz sheme, pripeljemo na levi strani čipa podatkovni liniji iz USB priključka D+ in D-. Te pripeljemo na USBDM in USBDP vhod čipa FT232RT. Ta pa poskrbi, da se ti dve signalni liniji pretvorita v TxD, TxR, CST, RTS, DTR, DSR, DCD, katere vidimo na desni strani. Te signalne linije tvorijo serijsko RS232 povezavo katero nato pripeljemo na vhodne USART linije mikrokrmilnika kot prikazuje shema AT90CAN32 v sliki 4.8. Nekateri novejši mikrokrmilniki že imajo možnost za direkten USB priključek, če pa uporabimo kakšnega starejšega ali pa mogoče bolj specifičnega za doseganje želenih ciljev, potem je čip FTDI FT232RL enkratna rešitev. Slika 4.8 prikazuje kako pripeljemo serijske linije na mikrokrmilnik AT90CAN32, napajanje, linija SilentMode skrbi, da se mikrokrmilnik prestavi v stanje pripravljenosti, CAN switch je linija za preklop med HIGH in LOW izhodi na CAN vodilo. Na desni strani mikroprocesorja vidimo liniji TxCAN in RxCAN kateri sta liniji za sprejem in oddajo na fizično CAN vodilo. 30

slika 4.8 Shema AT90CAN32 Omeniti je treba, da zasnova in izdelava tega vgrajenega sistema ni bilo delo v sklopu te diplomske naloge. Je pa bil razvoj programske kode, ki opisuje delovanje in je zapisana na tem mikrokrmilniku. 4.4 Programiranje strojne opreme Za pisanje izvorne kode programov za mikrokrmilnik smo uporabili program HP info tech codevision AVR. Ta vsebuje prevajalnik iz programskega jezika C v strojno kodo. Da lahko to naložimo na notranji pomnilnik mikrokrmilnika od koder se bo ta koda izvajala pa potrebujemo za to primeren programator. Ker je bil izbran mikrokrmilnik Atmel AVR AT90CAN32 smo morali imeti 31

primeren programator, ki je sposoben programiranja te družine mikrokrmilnikov. Imeli smo dve opcije. Programator AVR ISP MKII in USBasp. Prvi je uradno potrjen iz strani Atmel in ga je možno uporabljati z programom Atmel AVR Studio. Drugi je programator za katerega sta načrt in koda splošno dostopna na spletni strani www.fischl.de in je cenovno dostopnejši. Uporabljali smo slednjega katerega prikazuje sledeča slika 4.9 z programom Khazama AVR programmer 1.7.0 slika 4.9 USBasp programator za Atmel mikrokontrolerje Mikrokontrolerji Atmel imajo možnost, da se jih programira preko vmesnika ISP 15 kar je zelo praktično saj nam pri programiranju ni potrebno mikrokrmilnika fizično ločiti od vezja. Programator se namreč na mikrokrmilnik priključi preko ISP povezave kar prikazuje slika 4.10. slika 4.10 Shema priključitve Atmel mikrokrmilnika z ISP 15 ISP (in-system programming) znotraj sistemsko programiranje je sposobnost nekaterih programirljivih vezij kot so mikrokrmilniki, da se jih programira kadar so le ti že del neke strojne opreme. Dopušča možnost, da jih programiramo brez, da bi jih morali fizično ločiti od vezja katerega del so. Takšno vezje pa potrebuje ISP priključek za programator 32

5 Programska oprema V tem poglavju bo predstavljena zasnova in delovanje več različnih aplikacij, ki smo jih razvili, da smo dosegli cilj te diplomske naloge. Pri tem smo si pomagali z različnimi orodji. Za razvoj več aplikacij so se uporabljala različna orodja. Za razvoj tistih katere poganjamo na osebnem računalniku smo uporabljali NetBeans 6.9, za razvoj in povezovanje aplikacije za mikrokrmilnik smo uporabljali HP Info Tech CodeVision AVR 2.04. Da smo to dobljeno strojno kodo shranili na mikrokrmilnik pa se je uporabljal program za programiranje z našim USBISP programatorjem z imenom Khazama AVR programmer 1.7.0. 5.1 Način okvirjanja in pretvorbe CAN sporočila Ker smo pri vseh aplikacijah uporabljali isti princip pretvorbe CAN sporočil za lažje transparentno pošiljanje, bodisi preko TCP/IP omrežja bodisi preko serijske povezave, bo predstavljen princip, ki smo ga uporabili za pretvorbo sporočila in njegovo okvirjanje. CAN sporočilo je sestavljeno iz 4 polj po 32 bitov. Kar prikazuje slika 5.1, na kateri je razvidno oštevilčenje bitov od 31 do 0 in na katerem mestu posameznega polja so določeni podatki. slika 5.1 Razporeditev bitov v enem CAN sporočilu 33

Iz slike 5.2 je razvidno, kako si sledi pretvorba iz CAN sporočila dolžine 4 polj po 32 bitov v 34 polj ASCII 16 znakov po 8 bitov. slika 5.218 Prikaz pretvorbe podatkov v ASCII znake in okvirjanje 16 ASCII (ang. the American standard code for information interchange ) ameriška standardna koda za izmenjavo informacij je karakterno kodirna shema predvidoma znakov angleške abecede. ASCII znaki pa predstavljajo besedilo v računalniški opremi, komunikacijski opremi in v vseh napravah, ki uporabljajo besedila. 34

CAN sporočilo, ki ga sestavljajo 4 polja dolžine 32 bitov, si razdelimo tako, da vsako izmed teh štirih polj razstavimo v 4 nova polja po 8 bitov. Dobimo torej 4 polja, v katerem je 4 krat po 8 bitov. Torej imamo tako rekoč 16 polj po 8 bitov. Teh 8 bitov lahko pretvorimo v dva ASCII znaka. Prvo polovico za en ASCII znak in drugo polovico za drug. Tako dobimo iz 16 polj z 8 biti sedaj 32 polj, v katerih so ASCII znaki. Ker pa je ASCII znak dolžine 8 bitov, dodamo začetne štiri bite 0000, naslednji štirje pa bodo v območju od 0000 do 1111. Če si sedaj predstavljamo naše CAN sporočilo kot zaporedje 32 ASCII znakov ali karakterjev, lahko takšno zaporedje iz 32 znakov še dodatno okvirimo. S tem določimo začetek in konec enega sporočila. To storimo tako, da dodamo na začetku in koncu zaporedja točno določen znak, ki nam bo predstavljal začetek in konec zaporedja ali CAN sporočila. Izberemo si takšen ASCII znak, da ga v nobenem primeru ne moremo sestaviti iz 4 bitov med 0000 in 1111. Izbrali smo si ASCII znak < za začetek sporočila in na repu sporočila ASCII znak > kot konec sporočila. Binarno nam znak < predstavlja 00111100 in znak > predstavlja 00111110. Tako v nobenem primeru ne more samo sporočilo vsebovati katerega izmed teh dveh znakov, kot vemo so začetni biti z leve strani namreč 0000. Vse je izvedeno v aplikacijski plasti. Na oddajni strani poteka pretvorba iz 16 zlogov sporočila v 34 zlogov skupaj z okvirji in na sprejemni strani pretvorba iz 34 zlogov v 32 zlogov brez okvirjev ter nato v 16 zlogov, kar tvori eno CAN sporočilo. Zato ker je vsaka aplikacija sprejemnik in oddajnik sporočil, mora vsaka stran obvladati obe smeri pretvorbe. 5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo Obratna smer se dogaja na sprejemni strani, kjer sprejemnik prejme zaporedje samih ASCII znakov. Ker to zaporedje vključuje začetni < in končni znak > ni težko ugotoviti, kaj so uporabni podatki oziroma kaj nam predstavlja eno sporočilo. Vemo namreč, da je sporočilo dolgo 34 krat po 8 bitov, skupno z okvirji oziroma 32 krat po 8 bitov brez okvirjev. Razbijanje okvirjev naredimo tako, da preverjamo vsak prejet ASCII znak ali je enak <. Ko prispe ta znak vemo, da mu sledi natanko 32 ASCII znakov, kar predstavlja naše sporočilo. Preprosto ignoriramo začetni in končni znak okvirja. Tem 32 ASCII znakom najprej odstranimo začetne štiri 0000. 35

Nato združimo preostanek tako, da sodi ASCII znak brez začetnih 4 bitov pomaknemo na te začetne bite, lihi ASCII znak brez začetnih 4 bitov pa prištejemo k le temu. Iz tega sledi, da smo uspešno združili dva ASCII znaka tako, da smo odstranili začetne štiri nične bite in ju sešteli. Iz 32 ASCII znakov smo dobili 16 polj v katerem je 8 bitov. Če si predstavljamo teh 16 polj po 8 bitov kot 4 polja po 32 bitov pridemo do originalne oblike CAN sporočila, slika 5.3 prikazuje zgoraj opisan potek. slika 5.3 Razbijanje okvirjev in pretvorba nazaj v CAN sporočilo 36

5.3 Aplikacija gostitelja CANHUB Aplikacija za gostiteljski program je bila spisana z namenom, da se s pomočjo nje lahko poveže več različnih vgrajenih sistemov preko TCP/IP omrežja. S pomočjo slednjega se prenašajo CAN sporočila preko interneta. Aplikacija skrbi za ustvarjanje novih TCP povezav z različnimi klienti. Sporočila, ki prispejo od katerega od teh, se preko te aplikacije pošljejo naprej vsem ostalim. Pri zasnovi te aplikacije smo se osredotočili na delovanje vtičnice kot datotečnega opisovalca (ang.file descriptor). Se pravi, da smo podatke iz vtičnice brali kot podatke iz datoteke. S tem smo si olajšali delo, saj smo optimizirali in zmanjšali število vrstic izvorne kode samega programa. 5.3.1 Razlaga diagrama poteka CANHUB aplikacije Ob inicializaciji se nastavijo vse privzete nastavitve vključno z vrati in IP naslovom mrežne kartice katera je priključena na omrežje. Program se poveže na to vtičnico in posluša. Ustvari se datotečni deskriptor te vtičnice, ki smo jo poimenovali listener in je tipa integer, torej celoštevilska spremenljivka. Ime datotečnega deskriptorja ni drugega kot navadna cela številka kot na primer 3 ali 4. Tako namesto ip naslova in vrat neke vtičnice dostopamo do nje preko te cele številke datotečnega deskriptorja. Naslednji korak je, da se ustvari spremenljivka za datotečni deskriptor z imenom fdmax, v katerega vedno shranjujemo največji datotečni deskriptor. Ta bo vodil evidenco največjega naslova, torej naslova zadnje povezave. V prvem primeru se tja shrani listener, saj je trenutno on največja številka. Kadar se nov klient poveže z ustvarjeno vtičnico na kateri program posluša nove povezave se ustvari nov deskriptor datoteke te vtičnice. To je tisti, kii se je ustvaril nazadnje in je za ena večji kot od predhodnika. Na primer: poslušamo na naslovu vtičnice 3, doda se nova povezava katera dobi naslov 4, itd. Vso to evidenco vodi glavni spisek datotečnih deskriptorjev (ang. master file descriptor list) katerega smo morali ob inicializaciji ustvariti in smo ga poimenovali master. V neskončni zanki sledi opazovanje, ali se je v spisku master kaj spremenilo, za kar smo uporabili funkcijo select. S tem smo dosegli, da se program ne bo po nepotrebnem vrtel v naslednjih zankah dokler ne bo sprejel prve povezave. Ko se to zgodi, se bo v prvem primeru program sprehodil po prvi for zanki. Ta ustvari spremenljivko r, ki začne pri številki listener in se povečuje dokler ne pride do vrednosti fdmax. V prvem primeru sta ti dve isti (fdmax = listener) in v naslednjem preverjanju (r == listener?) se ustvari novo povezavo. S tem pa bo v spremenljivko fdmax shranil vrednost nove največje spremenljivke zadnjega datotečnega deskriptorja z imenom newfd. Newfd se je kreiral ob uspešni vzpostavitvi povezave in je v bistvu naslednja številka datotečnega deskriptorja shranjena v spisku master, katera predstavlja ip naslov in vrata klienta, ki je se je uspešno povezal. Ob naslednji ponovitvi te for zanke se bo spremenljivka r povečevala od listener do fdmax. Torej se sedaj, ko imamo novo uspešno povezavo, ta ponovi dvakrat. Kadar je r enak listener se lahko, kot 37

v prejšnjem koraku, ustvari nova povezava. Kadar pa je r enak fdmax, pogledamo, ali nam iz tega naslova kaj pošiljajo. Pregledamo namreč količino podatkov, ki se trenutno nahaja pod tem datotečnim deskriptorjem. To storimo s funkcijo za sprejem recv, vendar nastavimo zastavico, ki določa, da podatkov ne vzamemo iz TCP pomnilnika, temveč jih samo pogledamo. Če količina ni primerne velikosti, torej velikosti enega CAN sporočila skupaj z okvirji, kar je dolžina 34 bitov, se program pomakne naprej in ne stori ničesar. Če se v TCP pomnilniku nahaja celo CAN sporočilo, ga preberemo in shranimo v spremenljivko buffer. Če ob klicu funkcije recv ne dobimo odgovora, pomeni, da se je povezava prekinila. V tem primeru zmanjšamo vrednost v fdmax, ampak samo kadar se je prekinila povezava z največjo vrednostjo datotečnega deskriptorja. V nasprotnem primeru bi pobrisali napačno vrednost iz fdmax. V tem primeru smo spet na začetku. Kadar je povezava uspešna in imamo sporočilo v spremenljivki buffer, pride program do nove for zanke. V tem primeru se spremenljivka s začne pri vrednosti listener+1 in se povečuje vse do fdmax. V vsakem koraku pogleda ali je trenutna vrednost s slučanjo enaka listener. Če je potem se s poveča brez, da bi storil kakšno nalogo. V tem primeru bi namreč program sam sebi poslal dobljeno sporočilo od r kar bi privedlo do anomalije. Kadar pa ni enak listener se požene funkcija za pošiljanje send. Ta pošlje vrednost v spremenljivki buffer na naslov datotečnega deskriptorja s. Torej naslednjemu povezanemu klientu. To se zgodi tolikokrat dokler se s ne poveča do fdmax, kar predstavlja zadnjega v master spisku. Na ta način se odpošlje sporočilo vsem, ki se nahajajo na tem spisku razen naslovu listener kateri predstavlja program CANHUB. Ob neuspelem pošiljanju se smatra povezava za prekinjeno. Zato se zmanjša fdmax, ampak samo kadar je s enak fdmax. V nasprotnem primeru bi pobrisali napačno vrednost iz fdmax. Kadar se obe spremenljivki s in r v obeh for zankah povečata do mejnih vrednosti program zaključi en krog in se vrne na pričetek kjer vse skupaj ponovi. Slika 5.4 prikazuje to delovanje prikazano kot diagram poteka CANHUB aplikacije. 38

slika 5.419 Diagram poteka aplikacije CANHUB 39

5.4 Aplikacija odjemalec TCPCLIENT Aplikacija je namenjena predvsem lažjemu testiranju obremenjenosti sistema ter odpravljanju napak (ang. debugging). Kot takšna nam je v veliko pomoč, saj nam omogoča lahkotno pošiljanje CAN sporočil preko TCP protokola. Poveže se z gostiteljsko aplikacijo CANHUB in začne oddajati in prejemati CAN sporočila. Z ustvarjanjem časovnega zamika med temi sporočili smo ustvarjali zakasnitve in spreminjali hitrost oddaje sporoči ter opravljali kasnejše meritve. Nastaviti smo morali namreč optimalno bitno hitrost za pošiljanje CAN sporočil preko interneta. Po drugi strani pa se aplikacija TCPCLIENT lahko uporabi kot skelet oziroma osnovni temelj nadaljnjega razvoja kakršnih koli novih aplikacij, ki bi se želele povezati na gostiteljsko aplikacijo CANHUB. Pri samem zagonu programa v ukazni lupini podamo za imenom programa kot dodatne parametre štiri stvari: IP naslov na katerega se želimo povezati, vrata na katera se želimo povezati, kretnica -s, če želimo na ekranu izpis poslanih sporočil, kretnica -r, če želimo na ekranu izpis prejetih sporočil. Primer zagona iz ukazne lupine:./tcpclient 164.8.22.38 2020 -s r 5.4.1 Razlaga diagrama poteka TCPCLIENT aplikacije Aplikacija ob zagonu postavi vse spremenljivke na privzete vrednosti. Nato se ustvari vtičnica in program se poveže na aplikacijo gostitelja CANHUB, katerega ip naslov in vrata smo vnesli ob zagonu. V sami izvorni kodi nastavimo pavšalno CAN sporočilo, katerega program najprej pretvori iz 4 polj tipa integer (32 bitov) v 16 polj tipa char (8 bitov). Funkcija, ki smo jo spisali, da opravi to nalogo, se imenuje cast_from_uint_to_uchar. Te podatke je potrebno pravilno okviriti ter zapisati v načinu, ki ga razume tudi sprejemna stran. To stori funkcija Make_frame_and_ascii, kot je predstavljeno v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Preden bomo poslali sporočilo, imamo nastavljen časovnik, katerega lahko spreminjamo v sami izvorni kodi. Tako imamo možnost zakasnitve pred samim pošiljanjem sporočil. Podatke, ki so v spremenljivki SendBuffer, nato odpošljemo in jih izpišemo na ekran glede na nastavljeno kretnico ob zagonu. Pred sprejemanjem sporočil imamo tudi postavljen časovnik. Ko ta poteče, čez nekaj časa pogledamo v sam TCP pomnilnik, ali je tam že celo sporočilo, ki je dolgo 34 zlogov. To storimo s funkcijo recv in postavljeno zastavico peek. Če nas čaka celo sporočilo, ga vzamemo iz TCP pomnilnika z funkcijo recv in ga izpišemo na ekran. Funkcija Write_hex_from_buffer te pretvori kot je zapisano v poglavju»5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo«. Če pa se zgodi, da sporočilo še ni prispelo k nam v celoti, preskočimo korak prejemanja sporočila in se vrnemo na začetek. To ponavljamo v preprosti neskončni zanki, vse dokler ne izklopimo 40

aplikacije. Kot smo že omenili je ta bila napisana v testne namene. Slika 5.5 prikazuje to delovanje kot diagram poteka TCPCLIENT aplikacije. slika 5.520 Diagram poteka TCPCLIENT aplikacije 41

5.5 Aplikacija odjemalca TCP2FTDI Ta aplikacija skrbi za pravilno povezavo med osebnim računalnikom ter vgrajenim sistemom USB2CAN. To stori preko povezave s čipom FTDI FT232RL preko USB vodila. Ta pa skrbi, da se signali iz USB vodila pretvorijo v klasične signale za serijsko USART povezavo, kakršno pozna mikrokrmilnik na vgrajenem sistemu. Na aplikaciji plasti poteka pretvorba in okvirjanje sporočil za pošiljanje v obe smeri. Kadar pošiljamo podatke preko TCP/IP omrežja ter kadar pošiljamo podatke serijsko preko USB vodila na čip FTDI FT232RL. V kombinaciji z aplikacijo, ki je na samem mikrokrmilniku, nam predstavlja vgrajen sistem in most, ki ga na eni strani povežemo na TCP/IP omrežje ter na drugi strani na CAN omrežje. Kot vse aplikacije, ki se povezujejo preko TCP/IP omrežja z gostiteljsko aplikacijo CANHUB, tudi ta aplikacija omogoča, da ob samem zagonu programa v ukazni lupini podamo za imenom programa kot dodatne parametre štiri stvari: IP naslov na katerega se želimo povezati, vrata na katera se želimo povezati, kretnica -d, če želimo na ekranu izpis poslanih sporočil, kretnica -r, če želimo na ekranu izpis prejetih sporočil. Primer zagona iz ukazne lupine:./tcp2ftdi 164.8.22.38 2020 -d -r 5.5.1 Razlaga diagrama poteka TCP2FTDI aplikacije Ob zagonu aplikacije se najprej postavijo vse privzete nastavitve, vključno s programskim krožnim pomnilnikom, ki deluje po principu FIFO (ang. first in first out). Tega ustvarimo dva, enega za RX_FIFO, se pravi sprejemni FIFO pomnilnik in drugega za TX_FIFO, se pravi oddajni FIFO pomnilnik. Nato se ustvari vtičnica in aplikacija poskuša vzpostaviti TCP povezavo s podanim IP naslovom in številko vrat. Ob uspešni vzpostavitvi povezave se preveri ali imamo priključeno FTDI napravo. Če jo program zazna, jo poskuša odpreti, to je vzpostaviti povezavo z njo. Imamo več možnosti odpiranja naprave, izbrali smo takšno, pri kateri odpiramo napravo FTDI po imenu, kar je dobrodošlo, kadar ima sistem več priključenih FTDI naprav. Tako se ne more zgoditi, da bi se poskušali povezati z napačno FTDI napravo, saj lahko vsaki nastavimo svoje edinstveno ime. OB uspešni povezavi z gostiteljsko aplikacijo in uspešnem odpiranju FTDI naprave, ki je na vgrajenem sistemu, smo uspešno vzpostavili povezavo v obe smeri. Sedaj se ustvari neprekinjena ponavljajoča zanka, v kateri se zaganja več funkcij. Najprej preverimo, ali ni RX_FIFO_FULL. To je pred-nastavljen macro, ki se postavi na logično ena, kadar bo sprejemni pomnilnik RX_FIFO poln. Smiselno je, da takrat ne poganjamo funkcije, ki shranjuje podatke v ta pomnilnik, saj bi s tem prepisali stare podatke. Če RX_FIFO ni poln, potem lahko poženemo funkcijo z imenom FTDI_read_data(). Ta bo poskušala iz FTDI pomnilnika brala 42

znak po znak in vsakič preverjala, ali je ta znak enak <. Ko najde ta znak, se začne naše sporočilo. Ta funkcija bo vseh vmesnih 32 ASCII znakov shranjevala v pomnilnik. Ko bo prispel znak za konec sporočila >, pa bo teh 32 ASCII znakov spremenila v 16 polj po 8 bitov, v katerih vsak ASCII znak predstavlja po 4 bite. Tako dobimo surovo CAN sporočilo dolžine 16 polj po 8 bitov. Te bomo shranili v RX_FIFO, kjer čakajo naslednjo funkcijo da jih odpošlje naprej. Sledi naslednji korak, v katerem preverjamo, ali ni RX_FIFO_EMPTY. To je pred-nastavljen macro, ki se postavi na logično ena, kadar bo sprejemni pomnilnik RX_FIFO prazen. Smiselno je, da se naslednja funkcija, ki jemlje podatke iz RX_FIFO, ne požene, kadar v njem ni podatkov, ki bi jih potrebovala. Če pa podatki so, potem se požene funkcija make_frame_from_fifo. Ta funkcija bo podatke, ki čakajo v RX_FIFO, spremenila v iz 16 polj po 8 bitov v 32 polj ASCII znakov, katere bo še okvirila. Tako nastane 34 polj, ki vsebujejo ASCII znake. Naslednja funkcija bo te podatke poslala preko TCP/IP omrežja aplikaciji CANHUB. Imenuje se funkcija send(). Sledi korak, v katerem preverimo ali ni TX_FIFO_FULL. To je pred-nastavljen macro, ki se postavi na logično ena kadar bo sprejemni pomnilnik TX_FIFO poln. Smiselno je, da takrat ne poganjamo funkcije, ki shranjuje podatke v ta pomnilnik, saj bi s tem prepisali stare podatke. Če ta pomnilnik ni poln, potem lahko izvedemo funkcijo, ki se imenuje recv(). Vendar jo poženemo s postavljeno zastavico, s katero bomo samo pogledali v TCP pomnilnik, ali že vsebuje vseh 34 znakov. Dolžino v tem pomnilniku shranimo v rec_len. Nato preverimo, ali je rec_len dolžine 34. Če je ta pogoj izpolnjen, potem pomeni, da imamo celotno dolžino enega CAN sporočila in lahko še enkrat poženemo funkcijo recv(sock, RecvBuffer, window, 0) == 34. Tokrat bomo za spremenljivko window, ki je velikosti 34, vzeli zlogov podatkov iz TCP pomnilnika. Funkcija, ki teh 34 zlogov podatkov pretvori v 16 zlogov surovega CAN sporočila, se imenuje Write_hex_from_buffer(*FromBuffer, reclen). Ta funkcija vrača celo število, katero shranimo v spremenljivko miss. Kadar poženemo funkcijo, tej podamo argument imena spremenljivke, v kateri so podatki (FromBuffer), kot tudi argument imena spremenljivke, v kateri je dolžina teh podatkov (reclen). V prvem primeru dobi ta funkcija vseh 34 zlogov podatkov. Po teh 34 zlogih se sprehodi in vsakič preverja, ali je zasledila znak za začetek < okvirja. V primeru, da ta ni na prvem mestu, ampak na na primer petem mestu, se v spremenljivko miss zapiše vrednost 5. V takšnem primeru smo namreč od celotnega 34 zlogov dolgega sporočila dobili 5 zlogov podatkov manj. V enem ciklu torej nismo zasledili začetka sporočila <, nato 32 zlogov sporočila in znak > za konec sporočila. Takšno pomanjkljivo sporočilo ne moremo shraniti v pomnilnik. Zato se ob naslednjem zagonu recv() funkcije iz TCP pomnilnika prebere samo za vrednost window, ki je enaka miss, število podatkov. Ko se bo Write_hex_from_buffer() funkcija ponovno zagnala bo obdelala še preostanek podatkov. Kar pomeni manjkajoče podatke do 34 zlogov enega sporočila. Jih pretvorila iz 32 ASCII znakov v 16 zlogov podatkov in shranila v TX_FIFO. Ker v tem primeru vrne miss, ki je enak 0, se spremenljivka window zopet nastavi na 34. Če vemo, da se podatki pošiljajo preko TCP protokola in, da pridejo na destinacijo v pravilnem zaporedju in brez izgub. Potem se bo ta 43

izenačitev sporočila zgodila samo enkrat. Od zdaj naprej bomo namreč zmeraj dobivali pravilen vrstni red okvirjenega sporočila dolžine 34 zlogov. Sledi zadnji korak, v katerem preverjamo, ali ni TX_FIFO_EMPTY. To je pred-nastavljen macro, ki se postavi na logično ena, kadar bo sprejemni pomnilnik TX_FIFO prazen. Smiselno je, da se naslednja funkcija, ki jemlje podatke iz TX_FIFO, ne požene, kadar v njem ni podatkov, ki bi jih potrebovala. Ta funkcija se imenuje FTDI_write_data(). Ta vzame podatke iz TX_FIFO pomnilnika in jih pretvori iz 16 zlogov v 32 zlogov oziroma v 34 zlogov dolgo sporočilo skupaj z okvirjem. Nato sporočilo zapiše na FTDI pomnilnik. Vse skupaj poteka v neprekinjeni zanki. Tako program zmeraj preverja, ali ima podatke za sprejeti in ali ima podatke za poslati v obe smeri. Slika 5.6 prikazuje diagram poteka TCPCLIENT aplikacije. 44

slika 5.6 Diagram poteka TCP2FTDI aplikacije 45

5.5.2 Glavne funkcije in spremenljivke ter smer povezave Slika 5.7 prikazuje smer oziroma povezanost med TCP povezavo in povezavo z FTDI oziroma USB (serijsko). Prikazane so glavne funkcije katere spreminjajo podatke in jih zapisujejo v določene spremenljivke. Razvidno je kako potujejo podatki v obe smeri in katere funkcije so za to zadolžene. slika 5.7 Smer povezave z funkcijami in spremenljivkami programa TCP2FTDI Omeniti je treba, da so zgoraj prikazane samo večje funkcije, katere smo razvili z namenom lažjega kontroliranja poteka programa. To so funkcije, katere so skrbele za pretok in pretvorbo podatkov ter spremenljivke, v katere so te zapisovale podatke. Znotraj teh so se uporabljale še druge, manjše funkcije, katere nismo posebej predstavili. Kot tudi funkcije, ki so že napisane in ki se nanašajo na TCP vtičnico in se uporabljajo za samo inicializacijo vzpostavitve povezave s strežnikom, za pošiljanje in prejemanje podatkov preko TCP ter za vzpostavitev povezave z FTDI napravo, itd. Potrebno je omeniti predvsem uporabo dveh krožnih pomnilnikov TX_FIFO in RX_FIFO, ki delujeta na principu FIFO. Torej bo prvi podatek zapisan vanj, tudi prvi podatek na vrsti za kasnejšo obdelavo. Vanj se zmeraj shranjuje surovo CAN sporočilo dolžine 16 zlogov. Spodaj so predstavljene spisane funkcije programa TCP2FTDI: BOOL FTDI_init ( FT_HANDLE Handle ); postavi privzete nastavitve katere smo nastavili za konfiguracijo FTDI naprave void Msg_printf ( unsigned int *data ); 46

Izpiše na ekran sporočilo CAN tako da so vidni vsi pomembni parametri ( RTR, DLC, IDE, extid, stdid, DATA...) void FTDI_read_data ( FT_HANDLE Handle ); Prebere podatke iz FTDI strojnega pomnilnika, kateri prispejo kot karakterji z okvirji. Te pretvori kot je zapisano v poglavju»5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo«ter shrani podatke v RX_FIFO. void FTDI_write_data ( FT_HANDLE Handle ); Prebere podatke iz TX_FIFO jih pretvori kot je predstavljeno v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila, tako da dobi CAN sporočilo z okvirji in karakterji dolžine 34 zlogov. Po končani pretvorbi zapiše te podatke v FTDI strojni pomnilnik za oddajo podatkov. void socket_options ( unsigned int sock, unsigned int l_onoff, unsigned int l_time, unsigned int rcv_size, unsigned int send_size, unsigned int rcv_low_wtm, unsigned int send_low_wtm, unsigned int rcv_tmout_ms, unsigned int send_tmout_ms ); Funkcija skrbi za nastavljanje več parametrov vtičnice (ang. socket) naenkrat. Ta je znotraj aplikacije bila napisana za lažje testiranje z različnimi nastavitvami vtičnice. void termination_handler ( int signum ); Funkcija katera ujame različne sistemske zastavice. Z njeno pomočjo lahko spremenimo obnašanje nekaterih sistemskih klicev, kot je na primer kombinacija tipk CTRL+C. Uporabna je, ker smo si z njeno pomočjo ob vsakem izhodu iz programa izpisali določene parametre in poskrbeli, da se je vtičnica zaprla pravilno. unsigned int Write_hex_from_buffer ( unsigned char *FromBuff, int reclen) ; Funkcija recv za sprejem podatkov preko TCP nam v spremenljivko RecvBuffer shrani prejete podatke. Nastavljena je tako, da nam naenkrat shrani samo eno CAN sporočilo dolžine 34 zlogov zapisano s karakterji in okvirji. Funkcija Write_hex_from_buffer te pretvori kot je zapisano v poglavju»5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo«ter shrani podatke v RX_FIFO. void make_frame_from_fifo ( unsigned char *TxBuffer) ; Ta funkcija podatke, ki so v RX_FIFO pretvori v CAN sporočilo z okvirji in karakterji dolžine 34 zlogov tako kot je predstavljeno v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Po končani pretvorbi zapiše te podatke v spremenljivko SendBuffer katera je na voljo funkciji send za oddajo teh podatkov preko TCP. 47

5.6 Aplikacija na mikrokrmilniku Aplikacijo z imenom GCN smo razvijali v razvojnem okolju CodeVision AVR. Je ključen del vgrajenega sistema z imenom CAN2USB, saj narekuje delovanje najpomembnejšega elementa na tem sistemu, torej podrobneje določa obnašanje CAN krmilnika na tem mikrokontrolerju. Ta deluje na principu poštnih nabiralnikov. Specifično za ta mikrokrmilnik je, da ima prostora za 15 poštnih nabiralnikov. Ti v principu delujejo kot nekakšen strojni pomnilnik, v katerega CAN krmilnik shranjuje sporočila za sprejem in oddajo, kadar ta čakajo na kasnejšo obdelavo. Bodisi za pošiljanje, kjer poteka arbitraža vodila, ali za sprejemanje in procesiranje dobljenega podatka kot smo določili v sami izvorni kodi. Naše delo je bilo pravilno programirati ta mikrokrmilnik, da je ta znal iz poštnega nabiralnika in njemu pripadajočih registrov prebrati sporočilo, ga razstaviti in pravilno zapisati v naš programski pomnilnik FIFO. Iz tega pomnilnika se sporočilo najprej okviri in pretvori ter da v obdelavo za pošiljanje preko serijskega vmesnika mikrokrmilnika. Za to smo zasnovali pretvorbo sporočila in okvirjanje, katera je opisana v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Okvirjeno sporočilo smo tako brez napak pošiljali preko serijskega vmesnika. In obratno, kadar smo sprejemali sporočilo iz serijskega vmesnika, smo ga najprej vzeli iz okvirjev, pretvorili in zapisali v FIFO pomnilnik. Pretvorba je opisana v poglavju 5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo. Tam je sporočilo na voljo aplikaciji katera ga pošlje naprej na CAN poštni nabiralnik, ta pa preko CAN krmilnika na fizično vodilo. 5.6.1 Glavne funkcije in spremenljivke ter smer povezave Slika 5.8 prikazuje smer oziroma povezanost med serijsko povezavo z strani FTDI FT232RL čipom in AT90CAN32 mikrokrmilnikom ter na drugi strani povezavo na CAN vodilo. Prikazane so glavne funkcije, ki spreminjajo podatke in jih zapisujejo v določene spremenljivke. Razvidno je, kako potujejo podatki v obe smeri in katere funkcije so za to zadolžene. To so funkcije, ki so skrbele za pretok in pretvorbo podatkov ter spremenljivke, v katere so te zapisovale podatke. Znotraj teh so se uporabljale še druge, manjše funkcije kot tudi veliko različnih»makrojev«s pomočjo katerih smo opisovali branje, pisanje in spreminjanje določenih registrov mikrokrmilnika. 48

slika 5.8 Smer povezave z funkcijami in spremenljivkami programa GCN Tudi tokrat smo z uporabo dveh krožnih pomnilnikov TX_FIFO in RX_FIFO, katera delujeta na principu FIFO ustvarili globalno spremenljivko, v katero se shranjujejo podatki. FIFO pomeni, da bo prvi podatek zapisan vanj tudi prvi podatek na vrsti za kasnejšo obdelavo. Vanj se zmeraj shranjuje surovo CAN sporočilo dolžine 16 zlogov. Spodaj so predstavljene spisane funkcije programa GCN: void transmit_serial (void); Ob klicu te funkcije se prebere CAN sporočilo iz serijske povezave. To je dolžine 34 zlogov zapisano z karakterji in okvirji kar pomeni, da ga je potrebno pretvoriti. Zato se znotraj te funkcije pokliče še nekaj manjših funkcij, ki skupaj tvorijo pretvorbo, kot je zapisano v poglavju»5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo«. Na koncu se shrani CAN sporočilo dolžine 16 zlogov v TX_FIFO. void transmit_fifo (U8 mob); CAN sporočilo iz TX_FIFO se razdre in zapiše v primerne registre CAN krmilnika in željen poštni nabiralnik mob se nastavi tako, da je pripravljen za oddajanje CAN sporočila. void setting_can_from_txfifo (); Ta funkcija se pokliče znotraj prejšnje funkcije in s pomočjo različnih»makrojev«zapiše CAN sporočilo iz TX_FIFO pomnilnika v točno določene registre samega CAN krmilnika. void receive_fifo (U8 mob); Funkcija preveri status željenega poštnega nabiralnika mob. Če je ta nastavljen za sprejem sporočila, potem se s pomočjo funkcije, ki je opisana spodaj, sporočilo iz registrov CAN krmilnika sestavi v CAN sporočilo in zapiše v RX_FIFO pomnilnik. void setting_rxfifo_from_can (); 49

Ta funkcija se pokliče znotraj prejšnje funkcije in s pomočjo različnih»makrojev«zapiše CAN sporočilo iz registrov samega CAN krmilnika v RX_FIFO pomnilnik. void receive_serial (void); Ob klicu te funkcije se prebere CAN sporočilo iz TX_FIFO pomnilnika. To je dolžine 16 zlogov kar pomeni, da ga je potrebno pretvoriti in uokviriti. Zato se znotraj te funkcije pokliče še nekaj manjših funkcij katere skupaj tvorijo pretvorbo kot je zapisano v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Na koncu se pošlje CAN sporočilo dolžine 34 zlogov, torej z okvirji preko serijske povezave. 5.6.2 Razlaga diagrama poteka aplikacije na mikrokrmilniku Ob samem priklopu vgrajenega sistema USB2CAN v USB vtičnico se požene delovanje samega sistema. Torej se zažene aplikacija, ki opisuje delovanje mikrokrmilnika. Ustvari se krožni pomnilnik TX_FIFO in RX_FIFO. Postavijo se privzete nastavitve za CAN, kjer se nastavi bitna hitrost, število poštnih nabiralnikov, vklopijo se priključki za CAN in sam CAN krmilnik. Privzete nastavitve za serijsko USART povezavo nastavijo bitno hitrost serijske povezave, velikost karakterjev na 8 bitov ter vklop sprejema in oddajanja. Sledi neskončna zanka, v kateri se ponavljajo sledeče funkcije. Najprej preverjamo ali RX_FIFO pomnilnik ni poln (!RX_FIFO_FULL?). Če ta ni poln, potem lahko sprejmemo podatke in jih shranimo v ta pomnilnik. To se zgodi ob klicu funkcije receive_fifo(). Če so na voljo CAN sporočila v trenutnem poštnem nabiralniku, jih ta funkcija prebere ter shrani iz določenih registrov mikrokrmilnika v RX_FIFO pomnilnik. Nato sledi preverjanje ali RX_FIFO ni prazen (RX_FIFO_EMPTY?). Če ta ni prazen, pomeni, da imamo kakšno sporočilo v RX_FIFO pomnilniku, kar pomeni, da lahko izvršimo naslednjo funkcijo receive_serial(). Ta bo podatke iz RX_FIFO spremenila tako, da bodo dobili potrebne okvirje in se bodo poslali preko serijskega vmesnika. Nato preverjamo, ali TX_FIFO pomnilnik ni poln (!TX_FIFO_FULL?). Če ta ni poln, potem lahko sprejmemo podatke in jih shranimo v ta pomnilnik. To se zgodi ob klicu funkcije transmit_serial(). Če so na voljo podatki na serijskem priključku, jih ta funkcija prebere. Sporočilo dolžine 34 zlogov zapisano s karakterji in okvirji pretvori in na koncu shrani CAN sporočilo dolžine 16 zlogov v TX_FIFO. Zadnje preverjanje bo, ali TX_FIFO ni prazen (TX_FIFO_EMPTY?). Če ta ni prazen, pomeni, da imamo kakšno sporočilo v TX_FIFO pomnilniku, kar pomeni, da lahko izvršimo naslednjo funkcijo transmit_fifo(). Ta bo podatke iz TX_FIFO zapisala v registre CAN krmilnika, ki jih bo poslal preko poštnega nabiralnika na CAN vodilo. 50

Nato se vse skupaj ponavlja v zanki. Slika 5.9 prikazuje diagram poteka aplikacije na mikrokrmilniku. slika 5.9 Diagram poteka aplikacije na mikrokrmilniku 51

5.7 Aplikacija, ki teče na TSIM simulatorju TSIM simulator za LEON3 procesor kot tak ne vsebuje vseh komponent za simulacijo procesorja v zasnovi LEONDARE, katerega smo simulirali mi. To smo storili tako, da smo dodali modul GR704 katerega smo priklopili na samo okolje TSIM kar smo storili z ukazom iz terminala ob zagonu programa : tsim-leon3 -ahbm gr704.(so dll) start-rtems-grcan -designinput can_filter.(so dll) -designinputend -v Zgornji primer zažene program TSIM in naloži GR704 module v obliki gr704.(so dll). Ta modul bo naložil uporabnikovo specifično dinamično knjižnico (ang. customer specific dynamic library) can_filter.(so dll), kar storimo z ukazom -designinput can_filter.(so dll) -designinputend. Program ki ga želimo naložiti oziroma izvajati, se imenuje start-rtems-grcan, kretnica -v pa je zmeraj dobrodošla, kadar želimo izpis dodatnih informacij, ki so nam v pomoč pri odpravljanju napak. V našem primeru smo uporabili ukaz : tsim-leon3 -ahbm gr704.(so dll) can_man -designinput canip.(so dll) -designinputend -v kateri je znotraj simulatorja TSIM k procesorju LEON3 preko AHMB vodila naložil modul GR704 in temu dodal knjižnico canip.(so dll) ter nato znotraj okolja TSIM zagnal program can_man. Vse programe in knjižnice napisane za TSIM simulator smo morali prevajati z BCC križnim prevajalnikom za LEON2 in LEON3 procesorje katerega smo inštalirali kot del verižnih orodij z imenom sparc-elf-3.4.4. Knjižnica z končnico».so«se uporablja v OS Linux in z končnico».dll«v OS Windows. 5.7.1 Glavne funkcije in spremenljivke ter smer povezave Slika 5.10 prikazuje smer potovanja CAN sporočil oziroma povezanost med CAN vodilom (virtualnim znotraj TSIM) in TCP povezavo katera se poveže na CANHUB aplikacijo. Razvidno je,, da znotraj TSIM okolja simuliramo LEON3 procesor, na katerem poganjamo program can_man. K temu smo dodali modul GR704, katerega priključimo na amba vodilo. S tem modulom dobimo možnost simulacije dveh CAN 2.0 priključkov, ki sta opisana znotraj GRCAN modula. Podrobno delovanje GRCAN modula smo predstavili v poglavju 4.2.1 CAN krmilnik v GRCAN modulu znotraj LEONDARE. 52

slika 5.1021 Smer povezave z funkcijami in spremenljivkami ter moduli programa TSIM Preko funkcije canipcan_transmit prejmemo CAN sporočilo iz CAN krožnega pomnilnika, katero smo tja poslali znotraj can_man programa. Preko funkcije canipcan_receive pa pošiljamo CAN sporočilo prejeto iz strani TCP povezave in ga vpišemo v CAN 2.0 krožni pomnilnik. Podatki se nahajajo v spremenljivki data po uspešnem klicu funkcije canipcan_transmit. Takrat je CAN sporočilo velikosti 16 zlogov. Z funkcijo cast_from_uint_to_uchar spremeni zaporedje zlogov znotraj sporočila ter jih shrani v spremenljivko SendBuffer. Iz te spremenljivke vzame podatke funkcija Make_frame_and_ascii, katera sporočilo uokviri ter ga pretvori kot je zapisano v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Po pretvorbi ga shrani v TxBuffer spremenljivko, kjer so podatki katerih je sedaj 34 zlogov pripravljeni, da jih send funkcija pošlje naprej preko TCP protokola do CANHUB aplikacije. Da prejmemo podatke iz CANHUB aplikacije poskrbi funkcija recv katera shrani podatke v RxBuffer. Ti so dolžine 34 zlogov nakar z funkcijo Write_hex_from_buffer te pretvorimo kot je opisano v poglavju 5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo ter shranimo dobljeno v Rbuffer. Nato funkcija cast_from_uchar_to_uint spremeni zaporedje zlogov 53

znotraj sporočila ter jih shrani v spremenljivko data. Tam so podatki na voljo za vpis iz data v CAN krožni pomnilnik, kar storimo preko funkcije canipcan_receive. Spodaj so predstavljene spisane funkcije v caniptcp.(so dll): void Make_frame_and_ascii ( unsigned char *FromBuffer, unsigned char *ToBuffer ); Funkcija pretvori sporočilo, ki je v spremenljivki FromBuffer dolžine 16 zlogov, kot je predstavljeno v poglavju 5.1 Način okvirjanja in pretvorbe CAN sporočila. Tako dobimo uokvirjeno sporočilo v katerih so karakterji in je dolžine 34 zlogov. To se shrani v spremenljivko ToBuffer. void cast_from_uint_to_uchar ( unsigned int *intbuff, unsigned char *charbuff, unsigned int intlenght ); Funkcija pretvori iz CAN sporočila, ki je v spremenljivki intbuff, v obliki 4 krat po 32 bitov tipa integer v CAN sporočilo v obliko 16 krat po 8 bitov ali 16 krat po en zlog in shrani dobljeno v spremenljivko charbuff. void cast_from_uchar_to_uint ( unsigned char *charbuff, unsigned int *intbuff, unsigned int charlenght ); Funkcija pretvori iz CAN sporočila, ki je v spremenljivki charbuff, v obliki 16 krat po 8 bitov ali 16 krat po en karakter (char) v CAN sporočilo v obliko 4 krat po 32 bitov tipa integer in shrani dobljeno v spremenljivko intbuff. unsigned int Write_hex_from_buffer ( unsigned char *FromBuff, int reclen, unsigned char ToBuff ); Funkcija spremeni sporočilo, ki je v spremenljivki FromBuff dolžine 34 zlogov kot je opisano v poglavju 5.2 Način razbijanja okvirjanja in pretvorbe nazaj v CAN sporočilo tako, da dobimo sporočilo dolžine 16 zlogov kar se shrani v spremenljivko ToBuff. int canipcan_transmit ( struct grcan_input *can, unsigned int *data, unsigned int len, unsigned int *flags ); Je funkcija katera sprejme CAN sporočilo, katero se nahaja v krožnem pomnilniku CAN krmilnika. To prispe shranjeno v spremenljivki data, ki ima strukturo 4 polj po 32 bitov. Znotraj te funkcije kličemo več manjših katere skrbijo za pretvorbo sporočila in njegovo pošiljanje preko TCP. int canipcan_receive ( struct grcan_input *can, unsigned int *data, unsigned int *valid, uint64 *delay, unsigned int *flags ); Je funkcija, ki sprejme CAN sporočilo preko TCP. To ma obliko 34 polj po zlog zato znotraj te funkcije kličemo več manjših katere skrbijo za pretvorbo sporočila. To shranimo v spremenljivki 54

data, ki ima strukturo 4 polj po 32 bitov. Sporočilo se sedaj zapiše v krožni pomnilnik CAN krmilnika. static void canipcan_inp_setup ( int id, struct grcan_input *l, char **argv, int argc ); Znotraj te funkcije nastavimo vse privzete nastavitve. Ta se namreč zažene ob samem vklopu TSIM simulatorja. Tako se ob samem zagonu najprej povežemo z določeno vtičnico kar nam predstavlja CANHUB aplikacijo. Ob uspešni vzpostavitvi lahko nadaljujemo z prejemanjem in pošiljanjem sporočil. 55

6 Meritve in rezultati Merili smo odzivni čas TCP paketkov, hitrost pošiljanja paketkov in čas potreben da vgrajen sistem odda sporočilo na vodilo. Za merjenje odzivnega časa potovanja enega paketka kot za merjenje hitrosti pošiljanja podatkov smo uporabljali program WireShark. Ta zna spremljati dogajanje na mrežni kartici Odzivni čas TCP paketka je čas, ki ga potrebuje paketek, da pripotuje do sprejemnika in čas, ki ga potrebuje ACK paketek kot odgovor na sprejet paket. Za merjenje časa, ki ga potrebuje vgrajen sistem, da pošlje CAN sporočilo na CAN vodilo smo uporabili osciloskop. Z njegovo pomočjo lahko izmerimo dejanski čas potreben za oddajo enega CAN sporočila. Podana je tudi razlaga o maksimalnem in minimalnem času, ki ga potrebuje vgrajen sistem za oddajo sporočila. Slika 6.1 prikazuje zajem paketkov v programu WireShark. slika 6.122 Zaslonska slika zajetega prometa na mrežni kartici s programom Wireshark 6.1 Čas oddajanja CAN sporočila iz vgrajenega sistema Kot je v predhodnem poglavju 2.1.2 Tipi okvirjev sporočil v CAN omrežja razvidno je najdaljši okvir CAN sporočila dolg 131 bitov. To je okvir sporočila z razširjenim identifikatorjem in osmimi zlogi podatkov. Glede na to, da smo nastavili bitno hitrost samega CAN krmilnika v mikrokrmilniku na 250 khz, pomeni, da se en bit sporočila pošlje v 4µs. Če jih imamo za poslati 131 kar predstavlja eno CAN sporočilo velja izračun (6.1): čas za oddajo enega bita * število bitov = čas oddaje enega sporočila (6.1) 4µs * 131 = 524µs 56

Za oddajo enega CAN sporočila torej krmilnik potrebuje 524µs. Slika 6.2 prikazuje meritve opravljene z osciloskopom. slika 6.2 Časovni potek enega CAN sporočila na fizičnem vodilu Iz zgornje slike je razvidno, da je bil dejanski čas enega oddanega sporočila, kar nam predstavlja čas ΔX, enak 552µs. Kako to da meritev za toliko odstopa od izračunane vrednosti, ko pa vemo, da je za 131 bitov potrebnih 524µs? Odgovor se skriva v metodi z imenom bit stuffing. Ta namreč za vsako zaporedje petih bitom z enako vrednostjo vrine en bit z nasprotno vrednostjo. Tako se zgodi, da več ne velja, da je maksimalno število 131 bitov pri sporočilu razširjenega formata. To je namreč sporočilo z najboljšim scenarijem, kjer ni bilo vrinjenega niti enega bita po omenjeni metodi. Dejansko pa je sporočilo z najslabšim scenarijem lahko dolžine 160 bitov. Preračunano: 4µs * 160 = 640µs Tako vidimo, da lahko čas potreben za oddajo enega CAN sporočila na fizično vodilo niha med 524µs in 640µs. Nič nenavadnega torej, da smo v našem primeru dobili vrednost nekje vmes. Slika 6.3 prikazuje čas, ki smo ga potrebovali za oddajo dveh CAN sporočil. slika 6.3 Časovni potek dveh CAN sporočila na fizičnem vodilu 57

V tem primeru je bil izmerjen čas potreben za oddajo dveh CAN sporočil nekje 1100µs oziroma 1,1ms. To pomeni da je povprečen čas v našem primeru bil nekje 550µs. 6.2 Odzivni čas TCP paketa Čas od oddaje paketka z zahtevo in prejetjem potrditvenega paketka imenujemo odzivni čas ali RTT (ang. Round Trip Time). Za pravilno meritev smo morali poslati več paketkov in izračunati povprečje med temi. Nekateri namreč prepotujejo drugačno pot in imajo zato odzivni čas različen. Omeniti je še potrebno, da smo merili odzivni čas med računalnikoma, ki sta približno nekaj kilometrov narazen. Ta meritev namreč ne more biti pregled dejanskega stanja, kadar na primer komunicirata dva računalnika, ki sta zelo oddaljena, recimo vsak na svojem kontinentu. Spodnji graf v sliki 6.4 prikazuje odzivni čas katerega smo izrisali s pomočjo programa za zajemanje paketkov WireShark. slika 6.4 Odzivni čas TCP paketkov Razvidno je, da je povprečje časa RTT vseh poslanih paketkov nekje okrog 0,00055 sekunde ali 550µ sekund. Tam je graf najgosteje poseljen z točkami, ki predstavljajo odzivni čas paketka. 58

6.3 Hitrost prejemanja in oddajanja mostu Uporabili smo več različnih časovnih intervalov zakasnitve med pošiljanjem paketkov, ki jih smo nastavljali znotraj testne aplikacija TCPCLIENT. Če teh časovnih intervalov nismo nastavljali, se je s časom zapolnil TCP sklad, kar je posledično pripeljalo do tega, da je aplikacija prenehala pošiljati sporočila. Vsaka ponovitev glavne zanke v sami aplikaciji je namreč povzročila ponovno pošiljanje naslednjega sporočila. Kar pomeni,da smo vsakih nekaj urinih ciklov poslali novo sporočilo, kolikor jih je namreč potrebovala sama zanka, da se je ponovno izvedla. Slika 6.5 prikazuje padec hitrosti po določenem času pri preveliki zasičenosti TCP sklada. slika 6.5 Padec hitrosti po zasičenju Ko smo z testiranjem različnih zakasnitev dobili optimalno hitrost, smo ugotovili, da povprečen maksimalen pretok podatkov preko TCP/IP omrežja lahko znaša 0,75 M bitov/s, torej nekje 94 k zlogov/s. Enako velja za prejemanje kot za pošiljanje. Večina ponudnikov interneta v Sloveniji ponuja dostop do interneta s hitrostjo vsaj 1Mbit/s prenosa podatkov. Pomembno pa je, da imamo za oddajanje podatkov enako hitrost, torej 1Mbit/s, če želimo zagotoviti optimalno hitrost našega mostu. Slika 6.6 prikazuje meritev izvedeno v programu Wireshark in izpis hitrosti pošiljanja in prejemanja v samem operacijskem sistemu Linux. slika 6.623 Meritev hitrosti oddajanja in prejemanja podatkov mostu 59

7 Sklep V sklopu te diplomske naloge smo napisali kar nekaj aplikacij. Najpomembnejša, z imenom CANHUB, predstavlja gostiteljsko aplikacijo, katero poženemo na gostiteljskem računalniku. Je srce predstavljenega mostu, saj omogoča, da se ustvarjajo nove povezave z različnimi klienti preko TCP/IP. Skrbi, da se vsa prejeta sporočila prejeta od teh klientov razpošljejo naprej vsem ostalim. Klientov je več. Napisali smo program TCP2FTDI, ki je klient za povezavo s strežniško aplikacijo preko TCP/IP na eni strani ter povezavo z vgrajenim sistemom preko USB priključka na drugi strani. Na tem vgrajenem sistemu imamo mikrokrmilnik, za katerega smo napisali aplikacijo z imenom GCN. Tako smo opisali, kako se naj obnaša mikrokrmilnik ter ustvarili povezavo iz fizičnega CAN vodila na USB vodilo. S tema dvema aplikacijama ter vgrajenim sistemom smo torej dosegli povezavo med strežniško aplikacijo in fizičnim vodilom CAN. Tako smo sporočila, katera so bila oddana na fizično CAN vodilo preko CANHUB aplikacije, posredovali tudi vsem ostalim klientom. Napisali smo še dve klient aplikaciji. CANCLIENT se poveže s strežniško aplikacijo preko TCP/IP in lahko izpisuje prejeta CAN sporočila. Ima tudi možnost ustvarjanja CAN sporočila znotraj same izvorne kode in pošiljanje tega, kar smo uporabljali pri testiranju. In kot zadnja aplikacija, katero smo napisali z imenom CANIPTCP, je kot dinamična povezovalna knjižnica dodana v sklop simulacijskega programa TSIM. Tako smo ustvarili povezavo s strežniško aplikacijo preko TCP/IP ter simulacijskim programom TSIM, kateri nam je simuliral procesor LEON3 v zasnovi LEONDARE. Tako smo povezali več različnih CAN enot, ki so lahko med seboj daleč narazen in si s pomočjo TCP/IP in interneta vseeno lahko med seboj izmenjujejo podatke v obliki CAN sporočil. Glede na opravljene meritve lahko trdimo, da smo zadovoljni z rezultati in hitrostjo sistema, vendar kot takšnega ne moremo zamenjati z obstoječim CAN vodilom. Lahko se namreč zgodi, da kakšen TCP paketek ne najde svojega cilja v prvem poskusu. Na primer v avtomobilu namreč ne bi hoteli, da je ravno v tem paketku CAN sporočilo, katero nosi informacijo, da se naj sproži varnostna blazina. Po drugi strani pa ne bi pa bilo slabo, če bi nam lahko avtomehanik pregledal diagnostiko stanja avtomobila tako, da bi se priključil na CAN omrežje našega avtomobila, brez da dostavimo avto v avtomehanično delavnico. V tej smeri bi lahko šel dalje razvoj omenjenega mostu. V našem primeru je bil smisel povezati več pozicijsko lociranih CAN enot preko TCP/IP, vendar pri kompromisu realno časovnosti in hitrosti CAN omrežja. 60

8 Viri in literatura [1] Jagodič M. Digitalne telekomunikacije: kompedij, 1. izdaja. FERI Maribor, 2002. [2] Robert Bosch GmbH. CAN Specification, 2. izdaja. Stuttgart, 1991. [3] Andrew S. Tanenbaum. Computer networks, 4. izdaja. Založništvo Pearson Education, 2003. [4] Olaf Pfeiffer, Andrew Ayre, Christian Keyde. Embedded Networking with CAN and CANopen. Založništvo RTC books, 2003. [5] Aeroflex Gaisler.»TSIM2 Simulator User's Manual«, dostopno na: http://gaisler.com/j25/j25/doc/tsim-2.0.23.pdf [10.10.2012]. [6] Aeroflex Gaisler.»LEON3/GRLIB: SOC IP Library«, dostopno na: http://gaisler.com/doc/leon3%20grlib%20folder.pdf [10.10.2012]. [7] Aeroflex Gaisler.»GRLIB IP Core User's Manual«, dostopno na: http://gaisler.com/products/grlib/grip.pdf [10.10.2012]. [8]»CAN bus«, dostopno na: http://en.wikipedia.org/wiki/can_bus [10.10.2012]. [9]»Atmel AT90CAN32/64/128«, dostopno na: http://www.atmel.com/images/doc7679.pdf [10.10.2012]. [10]»Transmition Control Protocol«, dostopno na: http://en.wikipedia.org/wiki/transmission_control_protocol [10.10.2012]. [11]»C plus plus«, dostopno na: http://www.cplusplus.com/ [10.10.2012]. 61