Linux

ˇ e vysoké uˇcen´ı technické v Praze Cesk´ Fakulta elektrotechnická Katedra ˇr´ıdic´ı techniky

Diplomová práce

CAN - USB pˇ revodn´ık pro integraci do operaˇ cn´ıho syst´ emu GNU/Linux Bc. Jiˇr´ı Vanˇek

Vedouc´ı práce: Ing. Pavel P´ıˇsa, Ph.D.

Studijn´ı program: Otevˇrená informatika, Navazuj´ıc´ı magistersk´ y Obor: Poˇc´ıtaˇcové inˇzen´ yrstv´ı 11. kvˇetna 2012

iv

Podˇ ekov´ an´ı Chtˇel bych podˇekovat zejména vedouc´ımu mé práce Ing. Pavlu P´ıˇsovi, Ph.D. za uˇziteˇcné rady, pˇripom´ınky a konzultace. D´ ale bych chtˇel podˇekovat své rodinˇe a pˇr´ıtelkyni za podporu v pr˚ ubˇehu mé pr´ ace.

Abstract This diploma thesis implements the firmware for delivered hardware device that represents the CAN-USB converter. The firmware uses mechanisms from the LinCAN project. The work also includes design and implementation of the driver for the operating system GNU/Linux, which is based on SocketCAN, the current CAN Linux kernel subsystem. The implemented firmware is tested with both the character device driver LinCAN and the implemented driver using SocketCAN. There is also a comparison of these two drivers. The work also includes a brief overview and analysis of suitable microprocessors based on ARM architecture, which are suitable for the implementation of the CAN-USB converter.

Abstrakt Diplomov´ a pr´ ace implementuje firmware pro dodané hardwarové zaˇr´ızen´ı pˇredstavuj´ıc´ı pˇrevodn´ık CAN-USB. Firmware vyuˇz´ıvá mechanismy projektu LinCAN. Práce dále obsahuje návrh a implementaci ovladaˇce pro operaˇcn´ı systém GNU/Linux, kter´ y je zaloˇzen na SocketCAN, coˇz je souˇcasn´ y CAN subsystém Linuxového jádra. Realizovan´ y firmware je otestován jak se znakov´ ym ovladaˇcem LinCAN, tak s realizovan´ ym ovladaˇcem vyuˇz´ıvaj´ıc´ım SocketCAN a je uvedeno srovn´ an´ı obou ovladaˇc˚ u. Souˇcást´ı pr´ ace je i struˇcn´ y rozbor a pˇrehled vhodn´ ych mikroprocesorov´ ych obvod˚ u zaloˇzen´ ych na architektuˇre ARM, které jsou vhodné pro realizaci CAN-USB pˇrevodn´ıku.

vi

Obsah ´ 1 Uvod

1

2 Sbˇ ernice CAN 2.1 Obecné principy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ 2.2 Casov´ an´ı komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Pˇr´ıklad fyzické vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 3 4

3 Sbˇ ernice USB

5

4 Architektura ARM 4.1 Obecnˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Popis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Historie spoleˇcnosti . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Vhodné ˇreˇsen´ı pro realizaci pˇrevodn´ıku . . . . . . . . . . . . . . . . . 4.2.1 Moˇznosti realizace . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Porovn´ an´ı procesorov´ ych ˇrad . . . . . . . . . . . . . . . . . . 4.2.3 V´ ybˇer vhodného procesorového jádra . . . . . . . . . . . . . . 4.2.4 V´ ybˇer vhodného mikrokontroléru s jádrem ARM Cortex-M3 5 Firmware pˇ revodn´ıku CAN-USB 5.1 Anal´ yza u ´kolu . . . . . . . . . . . . . . . . ˇ c CAN . . . . . . . . . . . . . . . . . 5.2 Radiˇ 5.3 Implementace . . . . . . . . . . . . . . . . 5.3.1 Funkcionalita a struktura LinCAN 5.3.2 Uˇzivatelské poˇzadavky . . . . . . . 6 SocketCAN 6.1 Linux a jeho s´ıt’ov´ y subsystém . 6.2 CAN a s´ıt’ov´ y pˇr´ıstup . . . . . 6.3 Rodina protokol˚ u PF CAN . . 6.3.1 Struktura . . . . . . . . 6.3.2 Local loopback . . . . . 6.3.3 Datov´ a cesta . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

vii

. . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . .

7 7 7 7 8 8 8 10 12

. . . . .

15 15 15 17 17 19

. . . . . .

20 20 21 22 22 22 23

viii

OBSAH

7 Ovladaˇ c pˇ revodn´ıku CAN-USB 7.1 Jaderné moduly . . . . . . . . . . . . . . . . . . . . . 7.2 Ovladaˇce . . . . . . . . . . . . . . . . . . . . . . . . 7.3 USB ovladaˇce . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Struktura USB ovladaˇc˚ u. . . . . . . . . . . . 7.3.2 USB v j´ adˇre Linux . . . . . . . . . . . . . . . 7.3.2.1 Koncové body (Endpoints) . . . . . 7.3.2.2 Rozhran´ı (Interfaces) . . . . . . . . 7.3.2.3 Konfigurace (Configurations) . . . . 7.3.2.4 Zaˇr´ızen´ı (Devices) . . . . . . . . . . 7.3.2.5 USB Request Blocks . . . . . . . . . 7.3.3 USB v GNU/Linux . . . . . . . . . . . . . . . 7.4 Imlementace ovladaˇce pˇrevodn´ıku . . . . . . . . . . . 7.4.1 Registrace . . . . . . . . . . . . . . . . . . . . 7.4.2 Priv´ atn´ı data . . . . . . . . . . . . . . . . . . 7.4.3 Pˇripojen´ı a odpojen´ı zaˇr´ızen´ı . . . . . . . . . 7.4.3.1 Funkce probe() . . . . . . . . . . . 7.4.3.2 Funkce disconnect() . . . . . . . . 7.4.4 Funkce s´ıt’ového rozhran´ı . . . . . . . . . . . 7.4.5 Nastaven´ı, povolen´ı a zakázán´ı CAN zaˇr´ızen´ı 7.4.5.1 Nastaven´ı . . . . . . . . . . . . . . . 7.4.5.2 Povolen´ı . . . . . . . . . . . . . . . 7.4.5.3 Zak´ az´ an´ı . . . . . . . . . . . . . . . 7.4.6 Obsluˇzné vl´ akno a fronty . . . . . . . . . . . 7.4.7 Pˇr´ıjem . . . . . . . . . . . . . . . . . . . . . . 7.4.8 Odes´ıl´ an´ı . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

24 24 26 27 28 28 29 29 30 30 30 33 35 35 38 39 39 40 41 41 42 42 43 43 44 46

8 Testov´ an´ı 48 8.1 Pr˚ ubˇeh test˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2 Zhodnocen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9 Z´ avˇ er

53

A Seznam pouˇ zit´ ych zkratek

55

B Obsah pˇ riloˇ zen´ eho CD

56

Seznam obr´ azk˚ u 2.1 2.2 2.3 2.4

Uk´ azka arbitr´ aˇze CAN sbˇernice ˇ Casov´ an´ı CAN sbˇernice . . . . Podoba zapojen´ı ISO11898-2 . Napˇet’ové u ´rovnˇe ISO11898-2 .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 3 4 4

3.1

Pˇrehled hierarchie USB zaˇr´ızen´ı . . . . . . . . . . . . . . . . . . . . . . . . . .

6

4.1 4.2

Rozdˇelen´ı procesor˚ u ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rozdˇelen´ı procesor˚ u ARM ˇrady Cortex-M . . . . . . . . . . . . . . . . . . . .

10 11

5.1

Blokové schéma ˇradiˇce CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

6.1 6.2

S´ıt’ov´ y subsytém Linuxu a funkce PF CAN . . . . . . . . . . . . . . . . . . . Rozd´ıln´ y koncept adresace u Ethernetu a CAN . . . . . . . . . . . . . . . . .

21 22

7.1 7.2 7.3 7.4

Rozdˇelen´ı j´ adra . . . . . . . . . . . . Struktura USB ovladaˇc˚ u v Linuxu . Vytv´ aˇren´ı pipes . . . . . . . . . . . . Struktura datového bloku pro pˇrenos

8.1 8.2 8.3 8.4 8.5

Sestava hardware pro v´ yvoj a testován´ı . . . . . . . Round trip time - 1 vl´ akno, nulová prodleva . . . . . Round trip time historie - 1 vlákno, nulová prodleva Round trip time - 3 vl´ akna, nulová prodleva . . . . . Round trip time - 1 vl´ akno, prodleva 0, 1 a 2 ms . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAN zprávy po USB

ix

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

26 28 32 35

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

49 50 50 51 51

Seznam tabulek 4.1 4.2 4.3 4.4 4.5

NXP . . . . . . . . STMicroelectronics Texas Instruments Fujitsu . . . . . . . Toshiba . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

x

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 13 13 14 14

Kapitola 1

´ Uvod CAN (Controller Area Network) je komunikaˇcn´ı sbˇernice ˇsiroce rozˇs´ıˇrená v automobilov´ ych systémech a v pr˚ umyslov´ ych ˇr´ıdic´ıch odvˇetv´ıch obecnˇe. Nejˇcastˇeji komunikuje prostˇrednictv´ım dvojice vodiˇc˚ u a zjednoduˇsuje tak rozvody. Poskytuje deterministick´ y zp˚ usob pˇr´ıstupu k médiu a je tak vhodn´ a i pro pouˇzit´ı v ˇcasovˇe kritick´ ych aplikac´ıch. CAN pˇredstavuje spolehlivé, levné, osvˇedˇcené a dobˇre zn´ amé s´ıt’ové ˇreˇsen´ı. D´ıky tˇemto nesporn´ ym kvalitám je nepravdˇepodobné, ˇze bude nasazov´ an´ı CAN v dohledné dobˇe omezeno a to i pˇres to, ˇze jsou k dispozici modern´ı ˇreˇsen´ı jako FlexRay ˇci r˚ uzné standardy pro pr˚ umyslov´ y Ethernet. ˇ Casto je nutné ke sbˇernici CAN pˇr´ıpojit poˇc´ıtaˇc pro u ´ˇcely konfigurace, monitorován´ı nebo diagnostiky. To lze realizovat napˇr. pomoc´ı speciáln´ıch pˇr´ıdavn´ ych karet pro PCI rozhran´ı. Pro snadné a levné pˇripojen´ı poˇc´ıtaˇce ke sbˇernici CAN je vˇsak vhodn´ y CAN-USB pˇrevodn´ık. Rozhran´ım USB jsou v dneˇsn´ı dobˇe vybaveny témˇer veˇskeré osobn´ı poˇc´ıtaˇce. Naopak instalace speci´ aln´ı karty napˇr. pro notebook ˇcasto nen´ı ani moˇzná. Práce po struˇcném pˇredstaven´ı sbˇernic USB a CAN pˇrináˇs´ı informace o archituktuˇre ARM. Stˇeˇzejn´ı je pˇrehled souˇcasné nab´ıdky mikroprocesorov´ ych obvod˚ u zaloˇzen´ ych na této architektuˇre a také v´ ybˇer vhodného ˇreˇsen´ı pro realizaci CAN-USB pˇrevodn´ıku. Je také k dispozici pˇrehled nab´ıdek od nˇekolika v´ yrobc˚ u. Následuje ˇc´ ast t´ ykaj´ıc´ı se u ´kolu implementace firmware pro CAN-USB pˇrevodn´ık s mikrokontrolérem LPC1768, kter´ y vyuˇz´ıv´ a zdrojov´ ych kód˚ u projektu LinCAN. Po anal´ yze tohoto u ´kolu následuje popis zprovoznen´ı itegrovaného CAN ˇradiˇce mikrokontroléru a dále popis zaˇclenˇen´ı funkcionality do struktury LinCAN. Nejrozs´ ahlejˇs´ı ˇc´ ast tvoˇr´ı nejdˇr´ıve popis souˇcasného CAN subsystému Linuxového jádra SocketCAN a poté popis v´ yvoje ovladaˇce pro pˇrevodn´ık. Tato ˇcást zahrnuje seznámen´ı s principem ovladaˇc˚ u v Linuxu a jejich implementace jako jadern´ ych modul˚ u. Následuje nˇekolik obecn´ ych vˇec´ı t´ ykaj´ıc´ıch se USB ovladaˇc˚ u v jádru Linux a pak jiˇz kompletn´ı popis v´ yvoje s´ıt’ového ovladaˇce CAN-USB pˇrevodn´ıku zaloˇzeného na SocketCAN. Práci uzav´ır´ a kapitola vˇenovan´ a testován´ı, kde je zhodnocena souˇcinnost implementace firmware jak se znakov´ ym ovladaˇcem LinCAN, tak s vytvoˇren´ ym s´ıt’ov´ ym ovladaˇcem zaloˇzeném na SocketCAN. Také je n´ azornˇe pˇredvedeno porovnán´ı obou ˇreˇsen´ı.

1

Kapitola 2

Sbˇ ernice CAN 2.1

Obecn´ e principy

CAN je sériov´ a sbˇernice typu multi-master pˇredstavená v roce 1986 Robert Bosh GmbH. Standard CAN definuje pouze spojovou (linkovou) vrstvu tedy ˇr´ızen´ı pˇr´ıstupu k médiu, kódován´ı a dek´ odov´ an´ı r´ amc˚ u atd. Varianty fyzické vrstvy (parametry veden´ı, u ´rovnˇe signál˚ u, konektory atd.) mohou b´ yt r˚ uzné. Definuj´ı je napˇr. standardy ISO11898-2 nebo ISO11898-3. Základn´ı poˇzadavek na fyzickou vrstvu je podpora pˇrenosu dvou stav˚ u - dominantn´ıho a recesivn´ıho. Pokud ˇz´ adn´ y uzel nevys´ılá dominantn´ı stav, sbˇernice z˚ ustává v recesivn´ım stavu. Kdykoliv nˇejak´ y uzel vys´ıl´ a dominantn´ı stav, sbˇernice je v dominantn´ım stavu. Tato vlastnost je pouˇz´ıv´ ana ve vrstvˇe pˇr´ıstupu k médiu (MAC) pro dosaˇzen´ı nedestruktivn´ıho arbitr´ aˇzn´ıho mechanismu. Ten zajiˇst’uje pˇr´ıstup k médiu zprávˇe s nejvyˇsˇs´ı prioritou bez jak´ ychkoliv zpoˇzdˇen´ı. Priorita zprávy je urˇcena jej´ım identifikátorem, kter´ y identifikuje obsah zprávy sp´ıˇs neˇz adresu vys´ılaˇce nebo pˇrij´ımaˇce. Vˇsechny uzly vys´ılaj´ı bity synchronnˇe a pˇri vys´ıl´ an´ı zpr´ avy u f´ aze arbitr´ aˇze uzel kontroluje rozd´ıl mezi t´ım co vyslal a t´ım co skuteˇcnˇe je na sbˇernici. Pokud uzel zaznamená rozd´ıl, odpoj´ı se. Identifikátor zprávy, kter´ y je vys´ılán ve f´ azi arbitr´ aˇze je bud’ 11 nebo 29 bit˚ u dlouh´ y v závislosti na tom, zda je pouˇz´ıván rozˇs´ıˇren´ y form´ at zpr´ avy. Pˇr´ıklad na arbitráˇz sbˇernice lze vidˇet na obrázku 2.1 (pˇrevzatém z [5]1 ). Zde 3 uzly zaˇc´ınaj´ı vys´ılat v jeden okamˇzik. Arbitráˇz vyhraje posledn´ı z nich, jelikoˇz j´ım vys´ılan´ a zpr´ ava m´ a identifik´ ator s nejvyˇsˇs´ı prioritou (nejniˇzˇs´ı hodnotou). Vzhledem k tomu, ˇze arbitr´ aˇz sbˇernice vyˇzaduje synchronn´ı bitov´ y pˇrenos a rychlost ˇs´ıˇren´ı signálu veden´ım je koneˇcn´ a, je omezena délka veden´ı sbˇernice. Pro 125 kbit/s je maximáln´ı délka sbˇernice je 500 m, pro maxim´ aln´ı rychlost 1 Mbit/s to je 30 m [6]. Délka skuteˇcn´ ych dat (payload) m˚ uˇze b´ yt aˇz 8 byt˚ u a kaˇzdá zpráva je chránˇena 15 bitov´ ym CRC. Kaˇzdá zpráva je potvrzena bitem ACK. Vys´ılaˇc vys´ılá tento bit jako recesivn´ı. Vˇsechny pˇrij´ımaˇce, které korektnˇe pˇrijmou zpr´ avu, nastav´ı tento bit jako dominantn´ı. T´ımto zp˚ usobem, kdyˇz ˇzádn´ y pˇrij´ımaˇc nen´ı je schopen pˇrijmout zprávu korektnˇe, vys´ılaˇc m˚ uˇze signalizovat chybu vyˇsˇs´ım vrstv´ am. 1

Vˇsechny obr´ azky v této kapitole o CAN byly pˇrevzaty z [5]

2

ˇ KAPITOLA 2. SBERNICE CAN

3

Obr´ azek 2.1: Ukázka arbitráˇze CAN sbˇernice

2.2

ˇ Casov´ an´ı komunikace

Vˇsechny uzly v s´ıt´ı mus´ı m´ıt nastavenu stejnou nomináln´ı pˇrenosovou rychlost. Aby toto bylo moˇzné, mus´ı m´ıt kaˇzd´ y uzel (resp. jeho ˇradiˇc) korektnˇe definovanou délku bitového intervalu. Programovateln´ a dˇeliˇcka (Baudrate prescaler) generuje signál s délkou oznaˇcovanou jako ˇcasové kvatum (time quantum). Interval jednoho bitu je pak sloˇzen z celoˇc´ıselného poˇctu tˇechto ˇcasov´ ych kvant. Ta jsou rozdˇelena do 4 segment˚ u, jak lze vidˇet na obrázku 2.2.

ˇ Obr´ azek 2.2: Casov´ an´ı CAN sbˇernice Synchronizaˇcn´ı segment je dlouh´ y 1 ˇcasové kvantum. Propagation segment slouˇz´ı ke kompenzaci zpoˇzdˇen´ı mezi uzly. Phase segment 1 a Phase segment 2 urˇcuj´ı bod, kde ˇradiˇc vzorkuje, zda je na sbˇernici recesivn´ı ˇci dominantn´ı u ´roveˇ n. V nastaven´ı ˇradiˇce se pak ˇcasto uvád´ı pouze souˇcet Propagation segment + Phase segment 1 jako Time segment 1 (tseg1) a Phase segment 2 jako Time segment 2 (tseg2). Kv˚ uli tomu, ˇze skuteˇcné rychlosti se mohou m´ırnˇe liˇsit (tolerance oscil´ ator˚ u), je zaveden tzv. Synchronization Jump Width (sjw). To je poˇcet ˇcasov´ ych kvant, o kter´ y se m˚ uˇze prodlouˇzit/zkrátit Phase segment 1 nebo Phase segment 2 k doc´ılen´ı opˇetovné synchronizace.

ˇ KAPITOLA 2. SBERNICE CAN

2.3

4

Pˇ r´ıklad fyzick´ e vrstvy

Jak jiˇz bylo zm´ınˇeno, varianty fyzické vrstvy mohou b´ yt rozd´ılné. Typick´ ym pˇr´ıkladem je ovˇsem metalické dvouvodiˇcové diferenciáln´ı veden´ı podle standardu ISO11898-2. Pˇr´ıklad m˚ uˇzeme vidˇet na obr´ azku 2.3.

Obr´ azek 2.3: Podoba zapojen´ı ISO11898-2 Sbˇernicov´ a struktura se zakonˇcovac´ımi rezistory s hodnotou odporu 120 Ohm˚ u. Diferenciáln´ı komunikace, kde u ´roveˇ n je dána rozd´ılem napˇet´ı mezi vodiˇci CAN H a CAN L. Recesivn´ı u ´roveˇ n zajiˇst’uj´ı pull-up rezistory, rozd´ıl CAN H – CAN L je bl´ızk´ y 0. V domi’ nantn´ım stavu je rozd´ıl CAN H – CAN L kladn´ y, u ´rovnˇe zajiˇst uje budiˇc pˇr´ısluˇsného uzlu 2.4.

Obr´ azek 2.4: Napˇet’ové u ´rovnˇe ISO11898-2

Kapitola 3

Sbˇ ernice USB USB (Universal Serial Bus) je standard vyv´ıjen´ y od roku 1994. Definuje komunikaˇcn´ı protokol, kabely i konektory. Pouˇz´ıv´ a se k propojen´ı zaˇr´ızen´ı (klávesnice, tiskárny, flash disky atd.) a hostitelského systému (PC, notebook) za u ´ˇcelem jejich vzájemné komunikace. Pˇresn´ y popis lze naj´ıt ve specifikaci USB1 . Rychlosti: • USB 1.0 - Low Speed: aˇz 1,5 Mb/s • USB 1.1 - Full Speed: aˇz 12 Mb/s • USB 2.0 - Hi Speed: aˇz 480 Mb/s • USB 3.0: aˇz 5 Gbit/s

2

Hierarchie v zaˇr´ızen´ı (obr´ azek 3.1 pˇrevzat´ y z [9]) je popsána USB deskriptory. Ty definuje USB specifikace a jsou nez´ avislé na operaˇcn´ım systému. Existuj´ı tyto: • Zaˇ r´ızen´ı (Device) - reprezentuje fyzické zaˇr´ızen´ı pˇripojené na sbˇernici. Pˇr´ıklad: USB reproduktor s tlaˇc´ıtky na ovl´ adán´ı hlasitosti. • Konfigurace (Configurations) - reprezentuj´ı stavy zaˇr´ızen´ı. Pˇr´ıklad: Active, Standby, Initialization. • Rozhran´ı (Interfaces) - reprezentuj´ı jednotlivá logická zaˇr´ızen´ı a je s nimi svázán ovladaˇc. Pˇr´ıklad: reproduktor, tlaˇc´ıtka na ovládán´ı hlasitosti. • Koncov´ e body (Endpoints) - reprezentuj´ı jednosmˇernou komunikaˇcn´ı rouru3 . IN k hostovi, OUT od hosta.

1

http://www.usb.org/developers/docs/ Pˇredstavena jiˇz v roce 2008, ale v souˇcasné dobˇe st´ ale nen´ı masovˇe rozˇs´ıˇrena 3 Kromˇe ˇr´ıdic´ıho koncového bodu, kter´ y je obousmˇern´ y. 2

5

ˇ KAPITOLA 3. SBERNICE USB

6

Obr´ azek 3.1: Pˇrehled hierarchie USB zaˇr´ızen´ı Kromˇe smˇeru je komunikaˇcn´ı roura definována také typem koncového bodu. Existuj´ı tyto: • Control - Pouˇz´ıv´ ana pro konfiguraci zaˇr´ızen´ı. Pˇres tuto rouru se z´ıskávaj´ı informace o zaˇr´ızen´ı a také se mu pˇres ni pos´ılaj´ı pˇr´ıkazy. Kaˇzdé zaˇr´ızen´ı disponuje koncov´ ym bodem tohoto typu (tzv. EP0). Slouˇz´ı k enumeraci, coˇz je posloupnost standardizovan´ ych poˇzadavk˚ u a pˇr´ıkaz˚ u od hosta k identifikaci zaˇr´ızen´ı a zjiˇstˇen´ı potˇrebného ovladaˇce. Pˇrenos malého mnoˇzstv´ı dat, kde je doruˇcen´ı garantováno. • Bulk - Slouˇz´ı k pˇrenos˚ um vˇetˇs´ıho mnoˇzstv´ı dat. Doruˇcen´ı je garantováno, nen´ı vˇsak zaruˇcena ˇs´ıˇrka p´ asma ani moˇzné zpoˇzdˇen´ı. Typické pouˇzit´ı napˇr. pro tiskárny, pamˇeti, s´ıt’ov´ a zaˇr´ızen´ı atd. • Isochronous - Slouˇz´ı také k pˇrenos˚ um vˇetˇs´ıho mnoˇzstv´ı dat. Je sice garantováno maxim´ aln´ı zpoˇzdˇen´ı, nen´ı vˇsak garantováno doruˇcen´ı. Typické pouˇzit´ı je u audio/video zaˇr´ızen´ı. • Interrupt - Vhodné pro ˇcasté pˇrenosy malého mnoˇzstv´ı dat. Garantováno doruˇcen´ı, maxim´ aln´ı zpoˇzdˇen´ı i ˇs´ıˇrka p´ asma. Typické pouˇzit´ı napˇr. u klávesnic a myˇs´ı. V´ yhodou je dˇelen´ı zaˇr´ızen´ı do tˇr´ıd a podtˇr´ıd podle jejich typu. U komunikace s takov´ ymito zaˇr´ızen´ımi je komunikace standardizována podobnˇe jako tomu je u enumerace. Zaˇr´ızen´ı, které spadá do nˇejaké tˇr´ıdy, pak mus´ı b´ yt schopno reagovat na vˇsechny poˇzadavky, které tato tˇr´ıda definuje. S t´ımto principem m˚ uˇze existovat jednotn´ y ovladaˇc pro danou tˇr´ıdu zaˇr´ızen´ı. Napˇr. typicky obsahuje operaˇcn´ı systém jeden ovladaˇc pro tˇr´ıdu flash disk˚ u. Po pˇripojen´ı flash disku pak nen´ı tˇreba dod´ avat speci´ aln´ı ovladaˇc, ale je pouˇzit obecn´ y ovladaˇc pro flash disk v operaˇcn´ım systému. Pokud zaˇr´ızen´ı nespadá do ˇzádné konkrétn´ı tˇr´ıdy, je potˇreba pro nˇej dodat speci´ aln´ı ovladaˇc. To je tˇreba pˇr´ıpad naˇseho CAN-USB pˇrevodn´ıku.

Kapitola 4

Architektura ARM 4.1 4.1.1

Obecnˇ e Popis

ARM je 32-bitov´ a RISC (Reduced instruction set computer) architektura souboru instrukc´ı (ISA) vyv´ıjen´ a spoleˇcnost´ı ARM Holdings. Spoleˇcnost nevyráb´ı vlastn´ı procesory, ale vˇenuje se v´ yvoji procesorov´ ych jader, které pak pod licenc´ı poskytuje v´ yrobc˚ um. V´ yrobci pak ke standardizovanému j´ adru pˇrid´ avaj´ı vlastn´ı periferie a tento jednotn´ y integrovan´ y obvod prezentuj´ı veˇrejnosti jako v´ ysledn´ y mikroprocesor. Podle spoleˇcnosti ARM pˇredstavuj´ı jejich procesory od roku 2009 pˇribliˇznˇe 90% veˇsker´ ych vestavˇen´ ych 32-bitov´ ych RISC procesor˚ u. Jejich licenci vyuˇz´ıvá nˇekolik des´ıtek v´ yrobc˚ u a uplatnˇen´ı nach´ azej´ı v aplikac´ıch od mobiln´ıch telefon˚ u, tablet˚ u, hern´ıch konzol´ı aˇz po oblasti pr˚ umyslové automatizace.

4.1.2

Historie spoleˇ cnosti

V roce 1983 firma Acorn Computers zaˇcala s projektem Acorn RISC Machine a v roce 1985 byl pˇredstaven historicky prvn´ı ARM procesor. P˚ uvodn´ı zámˇer byl vyrábˇet procesory pro PC, coˇz vy´ ustilo v roce 1987 k pˇredstaven´ı osobn´ıho poˇc´ıtaˇce Acorn Archimedes, zaloˇzeného na architektuˇre ARM. Na konci osmdesát´ ych let spolupracovaly s Acorn firmy Apple Computer a VLSI Technology na v´ yvoji nového jádra ARM. To dalo v roce 1990 oddˇelen´ım v´ yvojového t´ ymu vzniknout nové spoleˇcnosti Advanced RISC Machines Ltd. s c´ılem vytvoˇrit nov´ y mikroprocesorov´ y standard. V´ yznam akronymu ARM byl tedy upraven na Advanced RISC Machine. Jiˇz po roce pak bylo pˇredstaveno prvn´ı RISC jádro pouˇzitelné jako vestavˇené - ARM6 a byla tak odstartov´ ana nová éra mikroprocesor˚ u a mikropoˇc´ıtaˇc˚ u. V roce 1998 v dobˇe vstupu na burzu pak probˇehlo pˇrejmenován´ı spoleˇcnosti na souˇcásn´ y název ARM Holdings.

7

KAPITOLA 4. ARCHITEKTURA ARM

4.2 4.2.1

8

Vhodn´ eˇ reˇ sen´ı pro realizaci pˇ revodn´ıku Moˇ znosti realizace

V zásadˇe existuj´ı 3 z´ akladn´ı moˇznosti, jak lze realizovat mikroprocesorov´ y obvod s periferiemi. V naˇsem pˇr´ıpadˇe s USB a CAN pro realizaci CAN-USB pˇrevodn´ıku: • Mikroprocesor m´ a periferii integrovanou pˇr´ımo v ˇcipu od v´ yrobce. • Periferie je extern´ı sériovˇe vyr´ abˇen´ y integrovan´ y obvod. • Pouˇzit´ı IP (Intellectual Property) core pro programovatelné logické obvody (FPGA, CPLD). IP core je v n´ avrhu hardware komplexn´ı funkˇcn´ı blok, kter´ y implementuje dan´ y element, tedy i nejr˚ uznˇejˇs´ı periferie. Je implementován v nˇekterém z HDL (Hardware Description Language) jazyk˚ u (Verilog, VHDL) a m˚ uˇze b´ yt tak pˇr´ımo pouˇzit v programovateln´ ych logick´ ych obvodech. Licencov´ an´ı z´ avis´ı na vlastn´ıkovi, existuje vˇsak také v´ yvoj open source blok˚ u1 , kde lze z´ıskat mnoho hardwarov´ ych návrh˚ u pod svobodn´ ymi licencemi. V´ yjimkou nejsou ani implementace ˇradiˇc˚ u pro CAN a USB. Pokud bychom volili variantu pouˇzit´ı extern´ıho obvodu, nese to s sebou v´ yhody i nev´ yhody. Pˇr´ıkladem ˇcip˚ u od firmy Philips2 m˚ uˇze b´ yt pro USB PDIUSBD12, pro CAN SJA1000. V´ yhoda pr´ avˇe tˇreba ˇradiˇce CAN SJA1000 ˇci jin´ ych (Intel i82527, Microchip MCP2510, Freescale MSCAN atd.) je ta, ˇze jsou standardnˇe pouˇz´ıvany a existuje tak pro nˇe vcelku ˇsiroká podpora. Pro programové vybaven´ı obsluhy tˇechto standardn´ıch ˇcip˚ u pak lze tedy napˇr. ˇcerpat z nˇekter´ ych jiˇz hotov´ ych otevˇren´ ych ˇreˇsen´ı. Nev´ yhodou tohoto ˇreˇsen´ı je samozˇrejmˇe potˇreba v´ıce m´ısta na desce ploˇsného spoje a dále sloˇzitost obvodu, kdy je nutné zajistit propojen´ı ˇradiˇce s procesorem. To vede k pouˇzit´ı mnoha propojovac´ıch vodiˇc˚ u ˇci k pouˇzit´ı relativnˇe pomal´ ych sériov´ ych sbˇernic (napˇr. SPI). Dalˇs´ı nespornou v´ yhodou integrovan´ ych periferi´ı oproti extern´ım jsou niˇzˇs´ı energetické nároky. V´ yrobci procesor˚ u (a zejména filozofie procesor˚ u ARM na tomto stav´ı) zavádˇej´ı vysoce optimalizovan´ y energetick´ y koncept. Ten je zahrnuje r˚ uzné uspávac´ı módy s odpojován´ım zdroj˚ u hodinov´ ych sign´ al˚ u ˇci samotného napájen´ı od periferi´ı a dále pouˇzit´ı v´ıce vnitˇrn´ıch sbˇernic s rozd´ıln´ ymi pracovn´ımi frekvencemi podle potˇreb jednotliv´ ych periferi´ı a jejich propojen´ı pˇrechodov´ ymi m˚ ustky. V neposledn´ı ˇradˇe vede integrace do jednoho ˇcipu ke zkrácen´ı spoj˚ u a t´ım i zpoˇzdˇen´ı sign´ al˚ u. V dneˇsn´ı dobˇe je na trhu jiˇz mnoho mikroprocesor˚ u od r˚ uzn´ ych v´ yrobc˚ u s nejr˚ uznˇejˇs´ımi intern´ımi periferiemi, CAN a USB nevyj´ımaje. Jejich pouˇzit´ı je tak pro u ´ˇcely CAN-USB pˇrevodn´ıku nejsch˚ udnˇejˇs´ı.

4.2.2

Porovn´ an´ı procesorov´ ych ˇ rad

Spoleˇcnost ARM dˇel´ı svoje procesory do tˇrech základn´ıch skupin podle jejich architektury, v´ ykonu, schopnost´ı, efektivnosti a vhodnosti pouˇzit´ı: 1 2

napˇr. OpenCores - http://opencores.org/ Dnes m´ a toto odvˇetv´ı na starosti jejich dceˇrin´ a firma NXP


9

• Classic ARM Processors • ARM Cortex Embedded Processors • ARM Cortex Application Processors Classic ARM Processors zahrnuje procesory ˇrady ARM7, ARM9 a ARM11. ARM7 je klasická rodina procesor˚ u, kter´ a byla nesm´ırnˇe u ´spˇeˇsná a kterou si firma ARM otevˇrela dveˇre do digit´ aln´ıho svˇeta. V souˇcasné dobˇe je vˇsak pˇrekonána a jej´ı pouˇzit´ı pro nová zaˇr´ızen´ı nen´ı doporuˇceno. ARM9 a ARM11 pak zahrnuj´ı r˚ uznˇe v´ ykonné procesory s rozmanit´ ymi vlastnostmi a zp˚ usoby aplikace. ARM Cortex Embedded Processors zahrnuje dvˇe ˇrady procesor˚ u a to Cortex-M a Cortex-R. Procesory z ˇrady Cortex-M jsou urˇceny primárnˇe pro deterministické mikrokontrolérové3 aplikace, procesory z ˇrady Cortex-R jsou pak urˇceny pro v´ ykonné real-time aplikace a jsou tak ˇcasto vyuˇz´ıv´ any v kombinaci s nˇejak´ ym operaˇcn´ım systémem reálného ˇcasu (RTOS). ARM Cortex Application Processors jsou procesory ˇrady Cortex-A. To jsou jiˇz vysoce v´ ykonné procesory pracuj´ıc´ı s frekvencemi v jednotkách GHz urˇcené pro operaˇcn´ı systémy (Android, Linux, Symbian, Windows Phone atd.) a pouˇz´ıvané v r˚ uzn´ ych aplikac´ıch od tablet˚ u a smartphon˚ u pˇres routery a digitáln´ı televize. Rozdˇelen´ı je moˇzné vidˇet na obr´ azku 4.1 (pˇrevzatého z [7]).

3

Mikrokontrolér (anglicky microcontroller) je oznaˇcen´ı jednoˇcipového mikropoˇc´ıtaˇce vhodného pro pouˇzit´ı v ˇr´ızen´ı


10

Obr´ azek 4.1: Rozdˇelen´ı procesor˚ u ARM

4.2.3

V´ ybˇ er vhodn´ eho procesorov´ eho j´ adra

Z uvedeného srovn´ an´ı lze vyvodit, ˇze pro realizaci CAN-USB pˇrevodn´ıku nemá smysl uvaˇzovat nad procesory z ˇrady Cortex-A ani Cortex-R, protoˇze pro u ´ˇcely jednoduchého vestavˇeného zaˇr´ızen´ı jsou v´ ykonem i funkcionalitou pˇredimenzovány, coˇz by se zcela urˇcitˇe prom´ıtlo na cenˇe. Lze uvaˇzovat tedy nad ˇradou Cortex-M nebo nad nˇekter´ ym ze skupiny klasick´ ych procesor˚ u. V tomto ohledu je tˇreba uvaˇzovovat nad uplatnˇen´ım. Sbˇernice CAN je hojnˇe vyuˇz´ıvána v pr˚ umyslové automatizaci. Nejsp´ıˇse tedy má smysl pro práci s touto sbˇernic´ı (v tomto pˇr´ıpadˇe ve funkci pˇrevodn´ıku) volit stejn´ y typ procesoru, kter´ y se pouˇz´ıvá pro jej´ı nejˇcastˇejˇs´ı aplikaci, tedy jako MCU (Microcontroller Unit). CAN-USB pˇrevodn´ık by tak mohl fungovat nad stejn´ ym zaˇr´ızen´ım, které se pouˇz´ıvá pro reálnou aplikaci s mikrokontrolérem (napˇr. ve funkci ˇr´ızen´ı motoru). To pˇrin´ aˇs´ı mimo jiné v´ yhodu moˇznosti snadného rozˇs´ıˇren´ı funkcionality dané aplikace o funkcionalitu CAN-USB pˇrevodn´ıku, napˇr. pro diagnostické u ´ˇcely. Tomuto poˇzadavku tedy plnˇe vyhovuje procesorová ˇrada Cortex-M. Také proto, ˇze podle spoleˇcnosti ARM se tato ˇrada stala celosvˇetov´ ym pr˚ umyslov´ ym standardem mezi mikrokont-


11

roléry, o cemˇz svˇedˇc´ı i fakt, ˇze licence poskytuje v´ıce neˇz 40ti spoleˇcnostem v ˇcele s Freescale, NXP Semiconductors, STMicroelectronics, Texas Instruments a Toshiba. ˇ Radu Cortex-M tvoˇr´ı nˇekolik procesorov´ ych jader, které se liˇs´ı v´ ykonnost´ı a aplikaˇcn´ım vyuˇzit´ım. Konkrétnˇe se jedn´ a o: • Cortex-M0 • Cortex-M0+ • Cortex-M1 • Cortex-M3 • Cortex-M4 Cortex-M1 je navrˇzen speci´ alnˇe pro pouˇzit´ı v programovateln´ ych hradlov´ ych pol´ıch (FPGA). Cortex-M0, Cortex-M0+ a Cortex-M3 jsou primárnˇe navrˇzeny pro vyuˇzit´ı v MCU aplikac´ıch. Vyznaˇcuj´ı se n´ızkou spotˇrebou, malou velikost´ı a vysokou efektivitou zpracován´ı. Cortex-M3 je nejv´ ykonnˇejˇs´ı, obecnˇe pouˇziteln´ y a podle spoleˇcnosti ARM tvoˇr´ı v souˇcasnosti hlavn´ı vˇetev v oblasti mikrokontrolérov´ ych aplikac´ı. Cortex-M4 vycház´ı koncepˇcnˇe z Cortex-M3 a pˇridává nav´ıc zejména funkcionalitu zpracován´ı signál˚ u z oblasti signálov´ ych procesor˚ u (DSP). Pˇrehled je moˇzné vidˇet na obrázku 4.2 (pˇrevzatého z [7]).

Obr´ azek 4.2: Rozdˇelen´ı procesor˚ u ARM ˇrady Cortex-M Pro CAN-USB pˇrevodn´ık se jev´ı jako nejvhodnˇejˇs´ı Cortex-M3. Podle provedeného rozboru poskytuje v pomˇeru k ostatn´ım jádr˚ um relativnˇe vysok´ y v´ ykon s n´ızk´ ymi nároky na spotˇrebu, cenu i rozmˇery. Zˇrejmˇe proto je podle spoleˇcnosti ARM tolik obl´ıben a tvoˇr´ı jedniˇcku mezi j´ adry mikrokontrolér˚ u jak jiˇz bylo uvedeno v´ yˇse. I kv˚ uli tomu, ˇze sbˇernice CAN je v ˇr´ıdic´ıch pr˚ umyslov´ ych oblastech hojnˇe vyuˇz´ıvána, je pouˇzit´ı procesoru s jádrem Cortex-M3 vhodné. Podrobnˇejˇs´ı informace o jednotliv´ ych procesorov´ ych ˇradách, samotn´ ych procesorech, aplikac´ıch i srovn´ an´ı lze nalézt na internetov´ ych stránkách spoleˇcnosti ARM [7].


4.2.4

12

V´ ybˇ er vhodn´ eho mikrokontrol´ eru s j´ adrem ARM Cortex-M3

Pro v´ ybˇer vhodného procesoru tedy stanov´ıme základn´ı kritéria: • jádro ARM Cortex-M3 • intern´ı pamˇet FLASH alespoˇ n 128kB • intern´ı pamˇet RAM alespoˇ n 32kB • integrované periferie CAN a USB (USB Device) T´ımto s´ıtem neproˇsla nab´ıdka spoleˇcnosti Atmel, jelikoˇz v dobˇe psan´ı této práce nenab´ızela ˇz´ adn´ y Cortex-M3 s integrovan´ ym CAN. Tuto moˇznost nab´ızej´ı pouze u nˇekter´ ych procesor˚ u z rodiny ARM7 a ARM9. Spoleˇcnost Freescale stav´ı svoji nab´ıdku mikrokontrolér˚ u ARM pouze na j´ adrech Cortex-M0+ a Cortex-M4. Následuje struˇcn´ y pˇrehled nab´ıdek procesor˚ u od v´ yrobc˚ u: • NXP - tabulka 4.1 • STMicroelectronics - tabulka 4.2 • Texas Instruments - tabulka 4.3 • Fujitsu - tabulka 4.4 • Toshiba - 4.5 Jedná se sp´ıˇse o orientaˇcn´ı pˇrehled nˇekolika produkt˚ u pro rámcovou pˇredstavu, jelikoˇz celkov´ y v´ yˇcet by byl pˇr´ıliˇs rozs´ ahl´ y a nav´ıc by nepˇrináˇsel o moc vˇetˇs´ı vypov´ıdaj´ıc´ı hodnotu. Poloˇzku tabulky tvoˇr´ı n´ azev4 , maximáln´ı pracovn´ı frekvence, velikost intern´ıch pamˇet´ı Flash a RAM, poˇcet nez´ avisle vyuˇziteln´ ych CAN kanál˚ u, proveden´ı USB periferie5 a nakonec orientaˇcn´ı cena. Ta byla vˇzdy stanovena pro jeden konkrétn´ı produkt, dostupn´ y u amerického distributora Digi-Key Corporation. Pokud cena nen´ı uvedena, nepodaˇrilo se ji od distributora zjistit.

4 jedn´ a se o obecn´ y n´ azev ˇcipu, nikoliv o jméno specifické souˇca ´stky, jelikoˇz m˚ uˇze existovat proveden´ı s r˚ uzn´ ymi pouzdry a r˚ uzn´ ym poˇctem pin˚ u 5 existuje-li pouze podpora pro USB Device, ˇci nav´ıc pro USB Host pˇr´ıpadnˇe On-The-Go

13


Name

fmax (MHz)

FLASH (kB)

RAM (kB)

CAN

USB D, H, OTG

Price (USD/1ks)

LPC1754

100

128

32

1

D/H/OTG

8,25

LPC1756

100

256

32

2

D/H/OTG

8,48

LPC1758

100

512

64

2

D/H/OTG

10,63

LPC1759

120

512

64

2

D/H/OTG

10,63

LPC1764

100

128

32

2

D

8,13

LPC1768

100

512

64

2

D/H/OTG

11,25

LPC1769

120

512

64

2

D/H/OTG

11,75

LPC1774

120

128

40

2

D

8,93

LPC1778

120

512

96

2

D/H/OTG

12,13

LPC1788

120

512

96

2

D/H/OTG

13,09

Tabulka 4.1: NXP

Name

fmax (MHz)

FLASH (kB)

RAM (kB)

CAN

USB D, H, OTG

Price (USD/1ks)

STM32F105RC

72

256

64

2

D/H/OTG

9,89

STM32F107RB

72

128

48

2

D/H/OTG

8,25

STM32F215ZE

120

512

128

2

D/H/OTG

13,26

STM32F205VC

120

256

96

2

D/H/OTG

9,86

STM32F205RF

120

768

128

2

D/H/OTG

11,19

STM32F407VG

168

1024

192

2

D/H/OTG

12,78

Tabulka 4.2: STMicroelectronics

Name

fmax (MHz)

FLASH (kB)

RAM (kB)

CAN

USB D, H, OTG

Price (USD/1ks)

LM3S5632

50

128

32

1

D/H

11,38

LM3S5G51

80

384

64

2

D/H/OTG

14,19

LM3S5C56

80

512

64

1

D/H/OTG

14,52

LM3S9B95

80

256

96

2

D/H/OTG

17,49

LM3S9C97

80

512

64

2

D/H/OTG

18,70

LM3S9D90

80

512

96

2

D/H/OTG

19,40

Tabulka 4.3: Texas Instruments

14


Name

fmax (MHz)

FLASH (kB)

RAM (kB)

CAN

USB D, H, OTG

Price (USD/1ks)

MB9BF504N/R

80

256

32

2

D/H

8,60

MB9BF505N/R

80

384

48

2

D/H

-

MB9BF506N/R

80

512

64

2

D/H

9,00

MB9BF514N/R

144

288

32

2

D/H

-

MB9BF515N/R

144

414

48

2

D/H

-

MB9BF516N/R

144

544

64

2

D/H

-

MB9BF516T/S

144

512

64

2

D/H

-

MB9BF517T/S

144

768

96

2

D/H

-

MB9BF518T/S

144

1024

128

2

D/H

-

Tabulka 4.4: Fujitsu

Name

fmax (MHz)

FLASH (kB)

RAM (kB)

CAN

USB D, H, OTG

Price (USD/1ks)

TMPM369FD

80

512

128

1

D/H

12,00

TMPM369FY

80

256

64

1

D/H

-

TMPM368FD

80

512

128

1

D/H

-

TMPM368FY

80

256

64

1

D/H

-

TMPM368FW

80

128

48

1

D/H

-

Tabulka 4.5: Toshiba

Kapitola 5

Firmware pˇ revodn´ıku CAN-USB 5.1

Anal´ yza u ´ kolu

C´ılem bylo vytvoˇrit firmware pro hardware realizovan´ y spoleˇcnost´ı PiKRON, kter´ y je zaloˇzen´ y na mikrokontroléru LPC1768. Z´ akladem firmware byly zdrojové kódy firmware pro starˇs´ı CAN-USB pˇrevodn´ık implementovan´ y v roce 2008 v rámci bakaláˇrské práce J. Kˇr´ıˇze s ˇ c sbˇernice CAN pˇripojený k PC pˇres sbˇernici USB 1 . Tento pˇrevodn´ık je zaloˇzen názvem Radiˇ na mikrokontroléru LPC2148, obsahuje extern´ı CAN ˇradiˇc SJA1000 a podporuje ho ovladaˇc LinCAN. V tomto starˇs´ım pˇrevodn´ıku byl pouˇzit extern´ı ˇradiˇc SJA1000, vycházlo se tedy z podpory ovladaˇce LinCAN pro PC pro ˇradiˇc SJA1000 pouˇz´ıvan´ y u PCI karet. Tato funkcionalita se poté adaptovala pro pouˇzit´ı ve vestavˇeném zaˇr´ızen´ı bez operaˇcn´ıho systému. Dále bylo také nutné vytvoˇrit emulaci propojovac´ı sbˇernice mezi ˇradiˇcem a GPIO piny mikroprocesoru. V textu práce J. Kˇr´ıˇz p´ıˇse, ˇze p˚ uvodnˇe byla dokonce snaha vyuˇz´ıt funkc´ı pro SJA1000 v ovladaˇci ˇ sen´ı vˇsak bylo velmi LinCAN a ˇc´ıst/zapisovat z/do jeho registr˚ u pˇr´ımo pˇres sbˇernici USB. Reˇ pomalé a od tohoto ˇreˇsen´ı se upouˇst´ı. Firmware tohoto starˇs´ıho pˇrevodn´ıku vyuˇz´ıvá mechanism˚ u LinCAN. To je znakov´ y ovladaˇc s d˚ umysln´ ym systémem vnitˇrn´ıch front pro specifické u ´ˇcely CAN komunikace. Tyto mechanismy svoj´ı strukturou odstiˇ nuj´ı samotnou funkcionalitu od závislosti na konkrétn´ıch typech HW a ˇradiˇc˚ u. Toho se d´ a dobˇre vyuˇz´ıt. Poˇzadavek tedy byl navázat na pˇredchoz´ı pˇrevodn´ık ve smyslu pˇrid´ an´ı podpory pro desku a CAN ˇradiˇc souˇcasného pˇrevodn´ıku a zároveˇ n provést co moˇzná nejmenˇs´ı zmˇeny ve zbylé funkcionalitˇe. Takto lze pak m´ıt jednotnou funkcionalitu pro r˚ uzné pˇrevodn´ıky a podle poˇzadovaného typu hardware lze mezi nimi snadno volit napˇr. podm´ınˇenou kompilac´ı.

5.2

ˇ Radiˇ c CAN

Intern´ı periferie CAN mikrokontroléru LPC1768 se skládá ze dvou ˇcást´ı. Prvn´ı je samotn´ y ˇradiˇc a druhou Acceptance Filter. Ten slouˇz´ı k hardwarovému filtrován´ı zpráv a tvoˇr´ı samostatn´ y modul. Blokové schéma ˇradiˇce lze vidˇet na obrázku 5.1 [4]. Struˇcn´ y popis: 1

pr´ ace je dostupn´ a z [8]

15

ˇ ÍKU CAN-USB KAPITOLA 5. FIRMWARE PREVODN

16

• Rozhran´ı k APB bus poskytuje pˇr´ıstup k registr˚ um. • Interface Management Logic (IML) interpretuje pˇr´ıkazy od CPU a poskytuje mu informace o stavech a pˇreruˇsen´ıch. • Transmit Buffer (TXB) pˇredstavuje trojici odes´ılac´ıch buffer˚ u a tvoˇr´ı rozhran´ı mezi IML a Bit Stream Processor (BSP). Kaˇzd´ y Transmit Buffer je schopen pojmout kompletn´ı CAN zpr´ avu urˇcenou pro odeslán´ı. Zápis ˇr´ıd´ı CPU, ˇcten´ı pak BSP • Receive Buffer (RXB) pˇredstavuje dvojic´ı pˇrij´ımac´ıch buffer˚ u pro pˇr´ıjem zpráv z CAN sbˇernice. Koncept dvou buffer˚ u dovoluje CPU zpracovávat jednu zprávu zat´ımco dalˇs´ı je zrovna pˇrij´ım´ ana. Zat´ımco u odes´ılán´ı mus´ı b´ yt specifikováno, kter´ y buffer se má zrovna pouˇz´ıt, u pˇr´ıjmu se o to stará ˇradiˇc a programátor toto ˇreˇsit nemus´ı. • Bit Stream Processor (BSP) je sekvencer, kter´ y ˇr´ıd´ı datov´ y proud mezi odes´ılac´ımi a pˇrij´ımac´ımi buffery a mezi CAN sbˇernic´ı. Stará se také o arbitraci, bit-stuffing a detekuje chyby. • Bit Timing Logic (BTL) se stará o ˇcasován´ı a synchronizaci sbˇernice. • Error Management Logic (EML) dostává oznámen´ı o chybách z BSP, zpracovává je a poskytuje BSP a IML informace o statistikách chyb.

Obr´ azek 5.1: Blokové schéma ˇradiˇce CAN Nastaven´ı registr˚ u mikrokontroléru pro správnou funkci periferie CAN je následuj´ıc´ı: • Zapnut´ı nap´ ajen´ı. To lze pˇres registr Power Control for Peripherals (PCONP) kde mus´ıme periferii povolit nastaven´ım pˇrisluˇsného bitu (PCCAN1, PCCAN2).


17

• Nastaven´ı hodinového sign´ alu. To lze pˇres registr Peripheral Clock Selection (PCLKSEL[0—1]). Jelikoˇz tato periferie spadá pod skupinu se sbˇernic´ı APB0, pouˇzijeme PCLKSEL0. V tomto registru pak sybolické jméno PCLK CAN1, PCLK CAN2 znaˇc´ı dvojici bit˚ u, jejichˇz hodnota urˇcuj´ıce dˇel´ıc´ı pomˇer frekvence jako zdroj hodinového signálu. Tedy napˇr. hodnota bit˚ u ’00’ = (CPU clock) / 4. Zde je nutné upozornit, ˇze PCLK CAN1 a PCLK CAN2 mus´ı b´ yt nastaveny stejnˇe. • Nastaven´ı pin˚ u procesoru. Pouˇzit´ y procesor je konkrétnˇe LPC1768FDB100. V datasheetu (odkaz)a schématu zapojen´ı lze zjistit, kter´ y pin procesoru mus´ıme nastavit: – pin 46 : P0.0/RD1/TXD3/SDA1 : RD1 - CAN1 receiver input – pin 47 : P0.1/TD1/RXD3/SCL1 : TD1 - CAN1 transmitter output Potˇrebujeme tedy nastavit dva nejspodnˇejˇs´ı piny brány 0. Pouˇzijeme registr PINSEL0, kter´ y ˇr´ıd´ı funkce spodn´ı poloviny brány 0. Zde jménu pinu opˇet odpov´ıdá dvojice bit˚ u, jejichˇz hodnota urˇcuje jeho funkci. Je tˇreba tedy nastavit: – jméno pinu P0.0 - prvn´ı alternativn´ı funkce hodnota ’01’ - RD1 – jména pinu P0.1 - prvn´ı alternativn´ı funkce hodnota ’01’ - TD1 Následnˇe je tˇreba nastavit reˇzim pin˚ u. To provedeme pomoc´ı dvojice registr˚ u. Prvn´ım je PINMODE0, kter´ y urˇcuj´ıce nastaven´ı pull-up/pull-down rezistor˚ u. Dvojice bit˚ u podle jména pinu odpov´ıd´ a: – jméno pinu P0.0 - hodnota ’00’ - povolen pull-up – jména pinu P0.1 - hodnota ’00’ - povolen pull-up Druh´ ym je PINMODE0 OD, kter´ y urˇcuj´ıce nastaven´ı reˇzimu open drain. Dvojice bit˚ u podle jména pinu odpov´ıd´ a: – jméno pinu P0.0 - hodnota ’00’ - normaln´ı (ne open drain) reˇzim – jména pinu P0.1 - hodnota ’00’ - normaln´ı (ne open drain) reˇzim • Definov´ an´ı ud´ alost´ı v CAN ˇradiˇci, které maj´ı vyvolat pˇreruˇsen´ı (pˇr´ıjem, odeslán´ı atd.). K tomuto slouˇz´ı CAN Interrupt Enable Register (CAN1IER, CAN2IER) 2 • Inializace registr˚ u ˇradiˇce. Pro fungován´ı je nakonec nutné v registru CAN Mode (CAN1MOD, CAN2MOD) nastavit stav ˇradiˇce z reset do operaˇcn´ıho stavu.

5.3 5.3.1

Implementace Funkcionalita a struktura LinCAN

Inicializaci ˇradiˇce popsanou v sekci 5.2 je tˇreba zpracovat do programového kódu. Stejnˇe tak ostatn´ı funkce, které pracuj´ı s registry ˇradiˇce tzn. odes´ılán´ı zpráv, pˇrij´ımán´ı zpráv, nastaven´ı ˇcasován´ı atd. Tuto funkcionalitu je pak tˇreba slouˇcit s koncepc´ı struktury pouˇzité v LinCAN. 2

Samotné povolen´ı pˇreruˇsen´ı od CAN periferie je tˇreba nastavit v NVIC.


18

V´ ysledkem je tak funkcionalita ovl´ adaj´ıc´ı dan´ y CAN ˇradiˇc se strukturou na bázi LinCAN. Toto ˇreˇsen´ı pak m˚ uˇze b´ yt s minim´ aln´ı zmˇenou pouˇzito v kódu pro starˇs´ı pˇrevodn´ık, kde tak vznikne jednotn´ y k´ od pro CAN-USB pˇrevodn´ık viz. 5.1. V zásadˇe nejvˇetˇs´ı zmˇenou je vol´ an´ı funkce pro nastaven´ı specifick´ ych operac´ı pro dan´ y hardware. V LinCAN je toto reprezentováno strukturou struct hwspecops t. Alokace této struktury jiˇz probˇehla a funkce dost´ avá ukazatel na ni jako parametr. Ve funkci pak pˇriˇrad´ıme ukazatel˚ um na funkce adresy n´ ami vytvoˇren´ ych funkc´ı. Pˇr´ıstup pak dále prob´ıhá pˇres tyto ukazatele. Tento pripcip je v LinCAN obecnˇe pouˇz´ıvan´ y. Funkce tedy m˚ uˇze vypadat: 1 int c a n 2 3 4 5 6 7 8 9 }

l m c 1 r e g i s t e r ( struct h w s p e c o p s t ∗ hwspecops ) { hwspecops−>i n i t h w d a t a = c a n l m c 1 i n i t h w d a t a ; hwspecops−>i n i t c h i p d a t a = c a n l m c 1 i n i t c h i p d a t a ; /∗ . . . ∗/ return 0 ;

Popis struktur i jejich poloˇzek lze naj´ıt v dokumentaci k LinCAN, která je dostupná z [8]. Zde pouze pro n´ azornost uvedeny: init hw data - vol´ ana pro inicialici struktury candevice t, která reprezentuje hardwarové zaˇr´ızen´ı s CAN. Zde se nastavuje poˇcet ˇradiˇc˚ u atd. Zjednoduˇsen´ y v´ ypis: 1 int c a n 2 3 4 5 6 7 }

l m c 1 i n i t h w d a t a ( struct c a n d e v i c e t ∗ candev ) { candev−>n r a l l c h i p s =1; candev−>f l a g s = 0 ; return 0 ;

init chip data - vol´ ana pro inicialici struktury canchip t, která reprezentuje CAN ˇradiˇc. Zde se nastavuje b´ azov´ a adresa registr˚ u, pracovn´ı frekvence atd. Tato funkce je také zodpovˇedn´ a za nastaven´ı specifick´ ych operac´ı pro dan´ y ˇradiˇc (canchip t->chipspecops). Tyto operace pak reprezentuj´ı samotnou funkcionalitu daného ˇradiˇce tak, jak byla popsána na zaˇcátku této sekce (odes´ılan´ı a pˇrij´ımán´ı zpráv aj.). Zjednoduˇsen´ y v´ ypis: 1 int c a n l m c 1 i n i t c h i p d a t a ( struct c a n d e v i c e t ∗ candev , int c h i p n r ) { 2 3 // used CAN1 p e r i p h e r i a l −> CAN1 r e g i s t e r s b a s e 4 candev−>c h i p [ c h i p n r ]−> c h i p b a s e a d d r = CAN1 REGS BASE ; 5 // c l o c k f o r CAN 6 candev−>c h i p [ c h i p n r ]−> c l o c k = s y s t e m f r e q u e n c y / 4 ; 7 8 l p c 1 7 x x f i l l c h i p s p e c o p s ( candev−>c h i p [ c h i p n r ] ) ; 9 10 return 0 ; 11 } 12 13 int l p c 1 7 x x f i l l c h i p s p e c o p s ( struct c a n c h i p t ∗ c h i p ) {


19

14 15 chip −>m a x o b j e c t s =1; 16 chip −>c h i p i r q = CAN IRQn ; 17 18 l p c 1 7 x x r e g i s t e r ( chip−>c h i p s p e c o p s ) ; 19 20 return 0 ; 21 } 22 23 int l p c 1 7 x x r e g i s t e r ( struct c h i p s p e c o p s t ∗ c h i p s p e c o p s ) { 24 25 c h i p s p e c o p s −>c h i p c o n f i g = l p c 1 7 x x c h i p c o n f i g ; 26 c h i p s p e c o p s −>p r e w r i t e c o n f i g = l p c 1 7 x x p r e w r i t e c o n f i g ; 27 c h i p s p e c o p s −>send msg = l p c 1 7 x x s e n d m s g ; 28 c h i p s p e c o p s −>wakeup tx = l p c 1 7 x x w a k e u p t x ; 29 c h i p s p e c o p s −>i r q h a n d l e r = l p c 1 7 x x i r q h a n d l e r ; 30 c h i p s p e c o p s −>s e t b i t t i m i n g = l p c 1 7 x x s e t b i t t i m i n g ; 31 32 return 0 ; 33 34 }

5.3.2

Uˇ zivatelsk´ e poˇ zadavky

Pro datov´ y pˇrenos CAN zpr´ av po USB se pouˇz´ıvaj´ı koncové body typu bulk. Pˇrenos ˇr´ıdic´ıch poˇzadavk˚ u pro konfiguraci (napˇr. nastaven´ı komunikaˇcn´ıch parametr˚ u sbˇernice) se pak provád´ı pˇres ˇr´ıdic´ı (control) koncov´ y bod tzv. EP0. Bliˇzˇs´ı popis je v sekci 7.4. C´ılem je poskytnout tomuto pˇrevodn´ıku podporu vytvoˇren´ ym s´ıt’ov´ ym ovladaˇcem pro GNU/Linux, kter´ y je zaloˇzen na SocketCAN. Pro tento u ´ˇcel musela b´ yt implementována podpora dvou nov´ ych ˇr´ıdic´ıch poˇzadavk˚ u, specifikovan´ ych makry: • USBCAN VENDOR GET BITTIMING CONST - T´ımto poˇzadavkem si ovladaˇc ˇr´ıká o zasl´ an´ı hodnot, kter´ ych m˚ uˇze ˇradiˇc nab´ yvat pro u ´ˇcely ˇcasován´ı. • USBCAN VENDOR SET BITTIMING - T´ımto poˇzadavkem ovladaˇc nastavuje konkrétn´ı parametry ˇcasov´ an´ı (Bit timing registr).

Kapitola 6

SocketCAN SocketCAN je projekt implementuj´ıc´ı aplikaˇcn´ı rozhran´ı pro pˇr´ıstup na sbˇernici CAN a model ovladaˇc˚ u pro j´ adro Linux. Od jádra 2.6.25 je souˇcást´ı mainline. SocketCAN vyuˇz´ıvá BSD Socket API, Linuxov´ y s´ıt’ov´ y stack a zpˇr´ıstupˇ nuje zaˇr´ızen´ı CAN jako s´ıt’ová rozhran´ı. API pro user-space aplikace je tedy koncipováno tak, aby se v´ yvoj tˇechto aplikac´ı co nejv´ıce ’ pˇribl´ıˇzil obecnˇe zn´ amému s´ıt ovému programován´ı pro TCP/IP protokoly pomoc´ı socket˚ u. V´ yvoj ovladaˇc˚ u pak vych´ az´ı z tvorby s´ıt’ov´ ych ovladaˇc˚ u pro ˇsiroce rozˇs´ıˇren´ y model ovladaˇc˚ u s´ıtˇe Ethernet.

6.1

Linux a jeho s´ıt’ov´ y subsyst´ em

S´ıt’ov´ y substystém Linuxu je znaˇcnˇe flexibiln´ı. Jeho rozdˇelen´ı po vrstvách s pˇr´ıkladem rodiny protokol˚ u PF INET, kter´ a implementuje TPC/IP, m˚ uˇzeme vidˇet na obrázku 6.1 v ˇcásti a (pˇrevzatého z [3]). Z pohledu aplikaˇcn´ı vrstvy zde existuje standardn´ı POSIX socket API, které tvoˇr´ı rozhran´ı j´ adra. User-space aplikace mohou tedy pouˇz´ıvat standardn´ı systémová volán´ı socket(), bind(), read(), write() apod. Dále následuje protokolová vrstva. Tu tvoˇr´ı rodiny protokol˚ u. Kaˇzd´ a rodina protokol˚ u m˚ uˇze implementovat r˚ uzné mnoˇzstv´ı rozliˇcn´ ych protokol˚ u. Zde v pˇr´ıpadˇe PF INET jde o protokoly TCP, UDP, apod. Dále se nacház´ı vrstva, která má za u ´kol pakety pˇred´ avat pˇr´ısluˇsn´ ym ovladaˇc˚ um s´ıt’ov´ ych zaˇr´ızen´ı. Ovladaˇce tvoˇr´ı spodn´ı u ´roveˇ n a maj´ı za u ´kol data fyzicky odeslat.

20

KAPITOLA 6. SOCKETCAN

21

Obr´ azek 6.1: S´ıt’ov´ y subsytém Linuxu a funkce PF CAN

6.2

CAN a s´ıt’ov´ y pˇ r´ıstup

Koncept SocketCAN stav´ı na zavedené Linuxové s´ıt’ové infrastruktuˇre, ovˇsem sbˇernice CAN je charakterem odliˇsn´ a od s´ıt’ov´ ych standard˚ u, které vyuˇz´ıvaj´ı TCP/IP. Zásadn´ı je absence adresace, jakou zn´ ame napˇr. ze s´ıtˇe Ethernet. Nelze tedy pˇr´ımo adresovat pˇr´ıjemce. Sbˇernice CAN funguje na principu broadcast, tedy rozeslán´ı zprávy vˇsem ostatn´ım pˇripojen´ ym uzl˚ um. Nen´ı moˇzné jednotlivé CAN zpr´ avy adresovat konkrétn´ımu zaˇr´ızen´ı pˇr´ımo na fyzické/linkové u ´rovni. Kaˇzd´ a CAN zpr´ ava obsahuje identifikátor, kter´ y je pouˇzit k arbitráˇzi sbˇernice a kter´ y m˚ uˇzeme ch´ apat do jisté m´ıry jako adresu odes´ılatele. Srovnán´ı rámc˚ u z adresaˇcn´ıho hlediska je naznaˇceno na obr´ azku 6.2. ˇ Casto je totiˇz kaˇzdému zaˇr´ızen´ı pˇridˇelen identifikátor (nebo urˇcit´ y rozsah identifikátor˚ u), pod kter´ ym vys´ılaj´ı zpr´ avy na sbˇernici. Ostatn´ı zaˇr´ızen´ı jsou pak schopna podle tohoto identifikátoru zjistit, jestli zpr´ ava pˇricház´ı od zdroje, kter´ y patˇr´ı do oblasti jejich zájmu ˇci nikoliv. Mohou se tak rozhodnout, zda zprávu zpracovat ˇci ignorovat. K tomuto u ´ˇcelu byla vytvoˇrena nová rodina protokol˚ u PF CAN. Integrace této rodiny protokol˚ u do s´ıt’ového stacku Linuxu m˚ uˇze ˇcerpat ze stávaj´ıc´ıh rodin s´ıt’ov´ ych protokol˚ u, jako je DECnet, Appletalk nebo AX.25, které také vyuˇz´ıvaj´ı s´ıt’ovou infrastrukturu Linuxu

22


Ethernet Frame Preamble

DestAddr

SrcAddr

Type

DestAddr

SrcAddr

Data

CRC

8 Bytes

6 Bytes

6 Bytes

2 Bytes

6 Bytes

6 Bytes

max 1500 Bytes

4 Bytes

Media Access Control Header (MAC)

CAN Frame Preamble 1 Bit

CAN−Indentifier 11 Bit (SFF) / 29 Bit (EFF)

Remoteflag 1 Bit (RTR)

DLC 4 Bit

Data 0 − 8 Byte

CRC 16 Bit

ACK 2 Bit

EOM 7 Bit

CAN−Arbitrationfield

Obr´ azek 6.2: Rozd´ıln´ y koncept adresace u Ethernetu a CAN

s r˚ uzn´ ym hardwarem a r˚ uzn´ ymi protokoly [2].

6.3 6.3.1

Rodina protokol˚ u PF CAN Struktura

Jádro (core) SocketCANu tvoˇr´ı jadern´ y modul (kernel module), kter´ y implementuje rodinu protokol˚ u PF CAN. Samotné transportn´ı protokoly jsou implementovány opˇet jako jaderné moduly, které jsou podle potˇreb dynamicky nahrávány za bˇehu. Samotn´ y modul jádra SocketCANu tedy nem˚ uˇze b´ yt pouˇzit, aniˇz by nebyl nahrán alespoˇ n jeden protokolov´ y modul.

6.3.2

Local loopback

Rodina protokol˚ u PF CAN a jej´ı protokol CAN RAW podporuj´ı tzv. multi-application access, tedy moˇznost zpˇr´ıstupnit jedno CAN rozhran´ı v´ıce aplikac´ım souˇcasnˇe. Mus´ı tedy platit, ˇze informace o veˇskerém dˇen´ı na tomto rozhran´ı mus´ı b´ yt nˇejak´ ym zp˚ usobem sd´ılené, tedy pˇr´ıstupné vˇsem aplikac´ım. Pokud se jedná o pˇr´ıjem, pˇrijat´ y CAN rámec je pˇrenesen ke vˇsem aplikac´ım. Ovˇsem pokud jedna aplikace vyˇsle CAN zprávu, mus´ı se to ostatn´ı aplikace bˇeˇz´ıc´ı na stejném systému dozvˇedˇet, jako kdyby bˇeˇzely na jin´ ych systémech propojen´ ych CAN sbˇernic´ı s vlastn´ımi CAN rozhran´ımi. Existuje tedy mechanismus tzv. local loopback, kdy jsou o vysl´ an´ı CAN zpr´ avy na sbˇernici jednou aplikac´ı informovány ostatn´ı. Obvykle se tak stane v obsluze pˇreruˇsen´ı vyvolané pˇri u ´spˇeˇsném pˇrenosu zprávy, a to uloˇzen´ım právˇe odeslané zpr´ avy do pˇrij´ımac´ı fronty. Je to z d˚ uvodu zachován´ı správného poˇrad´ı CAN zpráv. Kdyˇz by prob´ıhala tato signalizace ihned po odeslán´ı, tak napˇr. CAN zpráva s n´ızkou prioritou (vysoké ID), by mˇela velk´ y problém s arbitrac´ı sbˇernice. Mezit´ım by rozhran´ı mohlo klidnˇe pˇrijmout jiné zpr´ avy s vyˇsˇs´ı prioritou, neˇz by doˇslo k samotnému fyzickému odeslán´ı zprávy na sbˇernici a poˇrad´ı by tak bylo nesprávné. Pˇr´ıjem CAN r´ amce na stejném soketu, ze kterého byl odeslán je standardnˇe vypnut´ y. Lze to samozrˇejmˇe zmˇenit. Stejnˇe tak lze zmˇenit nastaven´ı socketu (kaˇzdého) v reakci na


23

loopback funcionalitu. Tato a mnoh´ a jiná nastaven´ı se provád´ı pˇr´ımo z uˇzivatelské aplikace, pomoc´ı systémového vol´ an´ı setsockopt().

6.3.3

Datov´ a cesta

Pro fungov´ an´ı datové cesty CAN zpráv je nutná identifikace datov´ ych buffer˚ u a s´ıt’ov´ ych zaˇr´ızen´ı. Packet scheduler je totiˇz sd´ılen´ y prostˇredek vˇsech s´ıt’ov´ ych zaˇr´ızen´ı, at’ jiˇz se jedná o CAN, ˇci Ethernet. Je-li socket buffer oznaˇcen jako ETH P CAN, znamená to, ˇze obsahuje CAN zprávy. S´ıt’ovému zaˇr´ızen´ı je nastaven ARPHRD CAN jako typ hardwarového rozhran´ı. Identifikujeme tak s´ıt’ové zaˇr´ızen´ı, které bude zpracovávat datové buffery oznaˇcené jako ETH P CAN. Oboj´ı je nutné provést v ovladaˇci daného s´ıt’ového zaˇr´ızen´ı. Touto identifikac´ı je doc´ıleno toho, ˇze rodina protkol˚ u PF CAN bude zodpovˇedná za zpracován´ı datov´ ych buffer˚ u, oznaˇcen´ ych jako ETH P CAN, tedy nesouc´ıch CAN zprávy.

Kapitola 7

Ovladaˇ c pˇ revodn´ıku CAN-USB 7.1

Jadern´ e moduly

Linux je modul´ arn´ı monolitické j´ adro operaˇcn´ıho systému. Zachovává architektonick´ y koncept monolitického j´ adra, tedy ˇze j´ adro bˇeˇz´ı v jednom spoleˇcném oddˇeleném pamˇet’ovém prostoru (tzv. kernel space). D´ ale vˇsak umoˇzn ˇuje zavádˇet speciáln´ı moduly do systému pˇr´ımo za bˇehu. Tento jadern´ y modul m˚ uˇze reprezentovat ovladaˇc zaˇr´ızen´ı, podporu souborového systému atd. Pˇr´ımo v j´ adˇre pak b´ yv´ a zakompilována vˇetˇsinou pouze funkcionalita d˚ uleˇzitá pro bˇeh systému a vˇsechno ostatn´ı si systém ˇci uˇzivatel m˚ uˇze nahrát za bˇehu podle potˇreby. To vede k zmenˇsen´ı n´ arok˚ u na systémové zdroje a znaˇcné flexibilitˇe. Pˇr´ıklad nejjednoduˇsˇs´ıho jaderného modulu (pˇrevzat´ y z [1]): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include #include MODULE LICENSE( ” Dual BSD/GPL” ) ; s t a t i c int h e l l o i n i t ( void ) { p r i n t k (KERN ALERT ” H e l l o , world \n” ) ; return 0 ; } s t a t i c void h e l l o e x i t ( void ) { p r i n t k (KERN ALERT ” Goodbye , c r u e l world \n” ) ; } module init ( h e l l o i n i t ) ; module exit ( h e l l o e x i t ) ;

1 - 2 → Vkl´ ad´ an´ı hlaviˇckov´ ych soubor˚ u s deklaracemi potˇrebn´ ymi pro tvorbu modulu. 3 → Makro oznaˇcuj´ıc´ı licenci, pod kterou modul spadá. 5 - 9 → Funkce, kter´ a se m´ a zavolat po nahrán´ı modulu do jádra. 11 - 14 → Funkce, kter´ a se m´ a zavolat pˇri odstanˇen´ı modulu z jádra. 16 - 17 → Makra, kter´ a oznaˇcuj´ı roli tˇechto dvou funkc´ı.

24

ˇ PREVODN ˇ ÍKU CAN-USB KAPITOLA 7. OVLADAC

25

7, 13 → Funkce pro v´ ypis informac´ı do logu jádra. Pouˇzit´ı je obdobné jako u funkce printf() ze standardn´ı knihovny C pro programy z uˇzivatelského prostoru. Pokud bychom chtˇeli provést pˇreklad tohoto triviáln´ıho pˇr´ıkladu do podoby jaderného modulu a ten n´ aslednˇe zavést do j´ adra, postupovali bychom v následuj´ıc´ıch kroc´ıch: Vytvoˇr´ıme si pro tento u ´ˇcel pracovn´ı adresáˇr a v nˇem vytvoˇr´ıme soubor s názvem hello world.c, jehoˇz obsahem bude pˇr´ıklad uveden´ y v´ yˇse. Dále v adresáˇri vytvoˇr´ıme soubor Makefile, kter´ y bude obsahovat pouze jedinou ˇr´ adku: obj-m = hello_world.o Pak zavol´ ame sestavovac´ı program make s následuj´ıc´ımi parametry: $ make -C /lib/modules/$(uname -r)/build M=$(pwd) modules T´ımto ˇr´ık´ ame, ˇze program make naˇcte Makefile z adresáˇre se zdrojov´ ymi kódy aktuálnˇe bˇeˇz´ıc´ıho jádra. Pomoc´ı promˇenné M ˇrekneme, ˇze se modul nacház´ı v aktuáln´ım adresáˇri a slovo modules na konci znamen´ a, ˇze chceme, aby se zkompilovaly pouze moduly. V´ ystup pˇrekladu m˚ uˇze vypadat takto: make: Entering directory ‘/usr/src/linux-headers-2.6.32-35-generic’ CC [M] /tmp/hello/hello_world.o Building modules, stage 2. MODPOST 1 modules CC /tmp/hello/hello_world.mod.o LD [M] /tmp/hello/hello_world.ko make: Leaving directory ‘/usr/src/linux-headers-2.6.32-35-generic’ V adres´ aˇri n´ am pak kromˇe jiného vzniknul pˇreloˇzen´ y jadern´ y modul hello world.ko. Ten m˚ uˇzeme do j´ adra zavést n´ asledovnˇe: $ sudo insmod ./hello_world.ko Zkontrolovat, ˇze se modul zavedl do jádra, m˚ uˇzeme z v´ ypisu programu lsmod, kter´ y zobrazuje informace o stavech modul˚ u v Linuxu: $ lsmod | head -2 Module hello_world

Size 680

Used by 0

Náˇs modul obsahoval z´ akladn´ı funkcionalitu pro ovˇeˇren´ı funkˇcnosti, tedy v´ ypis Hello world po zaveden´ı do j´ adra. Z v´ ypisu jádra m˚ uˇzeme zkontrolovat (vypisujeme pouze posledn´ı ˇrádku): $ dmesg | tail -1 [ 8233.547864] Hello, world


26

Modul m˚ uˇzeme pak z j´ adra odstranit: $ sudo rmmod hello_world a opˇet se m˚ uˇzeme pˇresvˇedˇcit o korektn´ım odstranˇen´ı modulu z v´ ypisu jádra: $ dmesg | tail -1 [ 8819.150167] Goodbye, cruel world

7.2

Ovladaˇ ce

Podle [1] lze j´ adro rozdˇelit do nˇekolika ˇcást´ı podle u ´lohy, jakou v systému pln´ı. To je moˇzné vidˇet na obr´ azku 7.1. Z uvedeného rozdˇelen´ı je patrné, ˇze existuje nˇekolik typ˚ u zaˇr´ızen´ı, tedy i nˇekolik typ˚ u ovladaˇc˚ u. Z´ aroveˇ n je vidˇet, ˇze nezávisle na typu lze ovladaˇc implementovat jako jadern´ y modul, popsan´ y v pˇredcházej´ıc´ı sekci 7.1.

Obr´ azek 7.1: Rozdˇelen´ı jádra V Linuxu tedy existuj´ı 3 z´ akladn´ı typy zaˇr´ızen´ı:


27

• Znakov´ a zaˇ r´ızen´ı - Pˇr´ıstup k takovému zaˇr´ızen´ı je jako k posloupnosti byt˚ u (znak˚ u) obdobnˇe jako v souborech. Obvykle poskytuj´ı pouze sekvenˇcn´ı pˇr´ıstup a nepouˇz´ıvaj´ı buffery. Jsou pˇr´ıstupn´ a ze systému soubor˚ u pˇres adresáˇr /dev. Typick´ ym pˇr´ıkladem m˚ uˇze b´ yt sériov´ y port (napˇr. /dev/ttyS0), textová konzole (/dev/console) atd. • Blokov´ a zaˇ r´ızen´ı - U blokového zaˇr´ızen´ı obecnˇe prob´ıhá zápis i ˇcten´ı po bloc´ıch dat. Typick´ ym zastupitelem m˚ uˇze b´ yt pevn´ y disk (blok 512 byt˚ u). Linux vˇsak umoˇzn ˇuje aplikac´ım pˇr´ıstup k blokov´ ym zaˇr´ızen´ım stejnˇe jako ke znakov´ ym. Liˇs´ı se pouze zp˚ usobem, jak´ ym jsou data internˇe spravována jádrem. Tedy rozhran´ı jádra pro blokové a znakové ovladaˇce jsou zcela odliˇsn´ a. Stejnˇe jako u znakov´ ych jsou bloková zaˇr´ızen´ı pˇr´ıstupná ze systému soubor˚ u pˇres adres´ aˇr /dev. Rozd´ılné je také to, ˇze k blokov´ ym zaˇr´ızen´ım m˚ uˇze b´ yt pˇripojem systém soubor˚ u. • S´ıt’ov´ a rozhran´ı - Kaˇzd´ a s´ıt’ová komunikace prob´ıhá pˇres s´ıt’ové rozhran´ı, coˇz je zaˇr´ızen´ı zodpovˇedné za pˇr´ıjem a odes´ılan´ı datov´ ych paket˚ u. Nejˇcastˇeji zastupuje reálné hardwarové zaˇr´ızen´ı, m˚ uˇze vˇsak b´ yt pouze na softwarové bázi (napˇr. loopback). Vyuˇz´ıvá s´ıt’ového subsystému j´ adra. Pˇr´ıstup k rozhran´ı je umoˇznˇen pˇridˇelován´ım unikátn´ıch jmen jednotliv´ ym rozhran´ım (napˇr. eth0), nen´ı zde vˇsak moˇzn´ y pˇr´ım´ y pˇr´ıstup pˇres systém soubor˚ u z /dev ani odjinud. Komunikace mezi jádrem a ovladaˇcem s´ıt’ov´ ych zaˇr´ızen´ı je zcela odliˇsn´ a od té ve znakov´ ych a blokov´ ych ovladaˇc´ıch. Pokud budeme mluvit o USB ovladaˇci, tak základ kaˇzdého je USB modul, kter´ y pracuje s USB subsystémem j´ adra. Samotné zaˇr´ızen´ı se pak v systému m˚ uˇze prezentovat jako znakové zaˇr´ızen´ı (napˇr. USB serial port), blokové zaˇr´ızen´ı (napˇr. USB ˇcteˇcka pamˇet’ov´ ych karet) ’ nebo s´ıt ové rozhran´ı. Pr´ avˇe posledn´ı zm´ınˇené je náˇs pˇr´ıpad v tomto ovladaˇci CAN-USB pˇrevodn´ıku, jelikoˇz vyuˇz´ıv´ ame SocketCAN, coˇz je implementace pro s´ıt’ová rozhran´ı. Na ovladaˇce a jaderné moduly obecnˇe jsou kladeny zvláˇstn´ı nároky na správnost. Aplikace v uˇzivatelském prostoru maj´ı sv˚ uj oddˇelen´ y pamˇet’ov´ y prostor a pˇri chybˇe jsou ukonˇceny operaˇcn´ım systémem. U modul˚ u nic takového neplat´ı, funguj´ı v rámci jednoho pamˇet’ového prostoru jádra (kernel space). Chybn´ y modul proto m˚ uˇze zp˚ usobit nestabilitu celého systému, v horˇs´ım pˇr´ıpadˇe poˇskozen´ı dat. V ovladaˇc´ıch se nepouˇz´ıvaj´ı globáln´ı promˇenné. Nam´ısto toho promˇenné pouˇzitelné z v´ıce m´ıst ovladaˇce utvoˇr´ı jednu strukturu, která pak tvoˇr´ı privátn´ı data ovladaˇce.

7.3

USB ovladaˇ ce

Linux rozliˇsuje dva typy ovladaˇc˚ u USB zaˇr´ızen´ı a to: • USB Device drivers - ovladaˇce pro hostitelsk´ y systém (obvykle osobn´ı poˇc´ıtaˇc), které ovl´ adaj´ı jednotliv´ a perifern´ı zaˇr´ızen´ı k nˇemu pˇripojená • USB Gadget drivers - ovladaˇce v perifern´ıch zaˇr´ızen´ıch (obvykle nˇejak´ y vestavˇen´ y systém), kter´ a jsou pˇripojov´ ana k hostitelskému systému Tyto term´ıny vznikly pro rozliˇsen´ı pojm˚ u. V kontextu USB protokolu je pak device driver ˇ a je totiˇz situace, kdy máme nˇejaké vestavˇené master a gadget driver je pak slave. Cast´


28

(embedded) zaˇr´ızen´ı, které disponuje ˇradiˇcem USB Device a bˇez´ı na nˇem embedded Linux. Zde pak existuje USB Device controller driver, coˇz je ovladaˇc, kter´ y obsluhuje zm´ınˇen´ y ˇradiˇc USB Device. Zprostˇredkov´ av´ a samotn´ y pˇr´ıstup ˇcipu ke sbˇernici a je tedy platformovˇe závisl´ y. Poskytuje ale rozhran´ı zm´ınˇené platformovˇe nezávislé vrstvˇe ovladaˇc˚ u USB Gadget drivers. Jako pˇr´ıklad pouˇzit´ı m˚ uˇze b´ yt Storage gadget, umoˇzuj´ıc´ı hostovi pˇr´ıstup jako k pamˇet’ovému zaˇr´ızen´ı. M˚ uˇzeme tak napˇr. pˇripojit digitáln´ı kameru k PC a ta se zpˇr´ıstupn´ı jako USB ´ storage device. Ukolem v této pr´ aci je vˇsak poskytnout podporu konkrétn´ımu perifern´ımu zaˇr´ızen´ı v hostitelském systému, tedy implementovat USB Device driver. Dále bude tedy popisován tento typ ovladaˇce.

7.3.1

Struktura USB ovladaˇ c˚ u

Struktura pro hostitelsk´ y systém je znázornˇena na obrázku 7.2 (pˇrevzatého z [9]). Spodn´ı vrstvu tvoˇr´ı USB Host controller drivers, tedy platformovˇe závislé ovladaˇce r˚ uzn´ ych hardwarov´ ych ˇradiˇc˚ u. Nad n´ı je vrstva USB Core, coˇz je subsystém jádra nezávisl´ y na architektuˇre, kter´ y implementuje samotnou specifikaci sbˇernice USB a poskytuje rozhran´ı ovladaˇc˚ um USB zaˇr´ızen´ı pro pˇr´ıstup k hardwaru bez nutnosti zaob´ırat se niˇzˇs´ı vrstvou. Vrchn´ı vrstva je tvoˇrena samotn´ ymi ovladaˇci specifick´ ych zaˇr´ızen´ı.

Obr´ azek 7.2: Struktura USB ovladaˇc˚ u v Linuxu

7.3.2

USB v j´ adˇ re Linux

Hierarchie USB zaˇr´ızen´ı device → configirations → intefraces → endpoints byla vysvˇetlena v sekci 3.


7.3.2.1

29

Koncov´ e body (Endpoints)

V jádˇre jsou koncové body pops´ any strukturou struct usb host endpoint. V n´ı nalezneme strukturu struct usb endpoint descriptor, která jak uˇz z názvu vypl´ yvá reprezentuje deskriptor koncového bodu. Obsahuje tedy poloˇzky dané USB specifikac´ı, které pro pˇrehlednost nesou stejné jméno 1 . M˚ uˇzeme tam naj´ıt tedy napˇr.: bEndpointAddress Adresa specifického koncového bodu a informace o jeho smˇeru2 . bmAttributes Urˇcuje typ koncového bodu. Lze pouˇz´ıt bitovou masku USB ENDPOINT XFERTYPE MASK a urˇcit tak, zda je o control (USB ENDPOINT XFER CONTROL), bulk (USB ENDPOINT XFER BULK), interrupt (USB ENDPOINT XFER INT) ˇci isochronous (USB ENDPOINT XFER ISOC) endpoint. wMaxPacketSize Udavá maxim´ aln´ı velikost paketu v bytech, se kterou m˚ uˇze koncov´ y bod manipulovat3 .

7.3.2.2

Rozhran´ı (Interfaces)

Mnoˇzina koncov´ ych bod˚ u tvoˇr´ı rozhran´ı, které reprezentuje základn´ı funkcionalitu zaˇr´ızen´ı. USB driver je tedy sv´ az´ an s rozhran´ım. Jedno fyzické zaˇr´ızen´ı m˚ uˇze poskytovat i v´ıce funkc´ı, z ˇcehoˇz vyp´ yv´ a, ˇze pro jedno zaˇr´ızen´ı m˚ uˇze b´ yt potˇreba v´ıce ovladaˇc˚ u. Napˇr. USB reproduktor m˚ uˇze b´ yt sloˇzen ze dvou logick´ ych ˇcást´ı - ovládac´ı tlaˇc´ıtka a zvukov´ y stream. Tedy bude potˇreba dvou r˚ uzn´ ych ovladaˇc˚ u. Jedeno rozhran´ı m˚ uˇze m´ıt v´ıce odliˇsn´ ych nastaven´ı parametr˚ u tzv. alternate settings s t´ım, ˇze pro kaˇzdé rozhran´ı m˚ uˇze b´ yt v jeden okamˇzik aktivn´ı vˇzdy pouze jedno nastaven´ı. Pouˇzit´ı m˚ uˇze b´ yt napˇr. r˚ uzné nastaven´ı ˇs´ıˇrky pásma u audio zaˇr´ızen´ı. Jednotlivá nastaven´ı jsou ˇc´ıslov´ ana (od 0) a jsou reprezentována strukturou struct usb host interface. Ve v´ ychoz´ım stavu je aktivn´ı vˇzdy prvn´ı nastaven´ı (s ˇc´ıslem 0). USB rozhran´ı je v j´ adˇre reprezentováno strukturou struct usb interface. Právˇe tuto strukturu pˇred´ av´ a USB core konkrétn´ımu USB ovladaˇci, ˇcili za tuto funkcionalitu je pak ovladaˇc zodpovˇedn´ y. D˚ uleˇzité ˇc´ asti této struktury pak jsou: struct usb host interface *altsetting; Pole alternativn´ıch nastaven´ı dostupn´ ych pro toto rozhran´ı. Struktura struct usb host interface obsahuje mnoˇzinu koncov´ ych bod˚ u (struct usb host endpoint *endpoint) pro dané nastaven´ı. unsigned num altsetting; 1

Tyto n´ azvy neodpov´ıdaj´ı schématu pojmenov´ av´ an´ı promˇenn´ ych v j´ adˇre Linux pod stejnou adresou mohou vytupovat dva r˚ uzné koncové body rozsliˇsené smˇerem - IN nebo OUT 3 Data s vˇetˇs´ı velikost´ı jsou rozdˇelena a pˇrenesena na v´ıcekr´ at 2


30

Poˇcet alternativn´ıch nastaven´ı struct usb host interface *cur altsetting; Ukazatel do pole altsetting, odkazuj´ıc´ı na momentálnˇe aktivn´ı nastaven´ı. int minor; Minor ˇc´ıslo pro dané rozhran´ı pˇridˇelené od USB core po zavolán´ı usb register dev()

7.3.2.3

Konfigurace (Configurations)

Rozhran´ı jsou sv´ az´ ana do konfigurac´ı. V jádˇre pak USB konfiguraci popisuje struktura struct usb host config. V jeden okamˇzik m˚ uˇze b´ yt aktivn´ı pouze jedna konfigurace. Samotn´ y USB ovladaˇc s touto strukturou vˇetˇsinou neoperuje, je zde zm´ınˇena pro u ´plnost. 7.3.2.4

Zaˇ r´ızen´ı (Devices)

Celé USB zaˇr´ızen´ı popisuje struktura struct usb device. S touto strukturou operuje USB core, které ovladaˇci pˇred´ av´ a pouze strukturu reprezentuj´ıc´ı rozhran´ı. Lze vˇsak pouˇz´ıt funkci interface to usbdev() pro z´ısk´ an´ı struct usb device z struct usb interface. 7.3.2.5

USB Request Blocks

V jádˇre prob´ıh´ a USB komunikace mezi ovladaˇci a zaˇr´ızen´ımi asynchronnˇe pomoc´ı objekt˚ u zvan´ ych URB (USB Request Block). URB je vyuˇz´ıván k zaslán´ı ˇci pˇrijet´ı dat do nebo od konkrétn´ıho USB koncového bodu. Jsou podobné paket˚ um v s´ıt’ové komunikaci. O vytvoˇren´ı URB se star´ a ovladaˇc. Ten m˚ uˇze v´ıce URBs pˇriˇradit k jednomu konkrétn´ımu koncovému bodu nebo m˚ uˇze jeden URB pouˇz´ıt opakovanˇe pro r˚ uzné koncové body. Kaˇzd´ y koncov´ y bod si drˇz´ı URBs ve frontˇe, m˚ uˇze b´ yt proto odesláno v´ıce URBs na jeden koncov´ y bod. Typick´ y ˇzivotn´ı cyklus pro URB je pops´ an v [1] takto: • Vytvoˇren ovladaˇcem USB zaˇr´ızen´ı. • Pˇriˇrazen konkrétn´ımu koncovému bodu konkrétn´ıho zaˇz´ızen´ı. • Pˇred´ an ovladaˇcem do USB core. • Pˇred´ an USB core danému ovladaˇci USB ˇradiˇce (USB host controller driver) konkrétn´ıho zaˇr´ızen´ı. • Zpracov´ an ovladaˇcem ˇradiˇce, kter´ y provede samotn´ y datov´ y pˇrenos. • Kdyˇz je dokonˇcen, ovladaˇc ˇradiˇce upozorn´ı ovladaˇc zaˇr´ızen´ı.


31

Upozornˇen´ı spoˇc´ıv´ a v zavol´ an´ı pˇredem definované dokonˇcovac´ı funkce v kontextu pˇreruˇsen´ı, kde ovladaˇc pˇreb´ır´ a zpˇet kontrolu nad dokonˇcen´ ym URB. Ten pak m˚ uˇze URB bud’ smazat, nebo ho znovu pouˇz´ıt tˇreba i pro jin´ y koncov´ y koncov´ y bod. URB je realizov´ an strukturou struct urb. Jeho vytvoˇren´ı se provád´ı zavolán´ım funkce usb alloc urb(). To je nutné kv˚ uli mechanismu poˇc´ıtán´ı referenc´ı, kter´ y vyuˇz´ıvá USB core. Alokace URB tedy nen´ı staticky, ani pˇres kmalloc(). Deklarace funkce vypadá: 1 struct urb ∗ u s b a l l o c u r b ( 2 int i s o p a c k e t s , 3 g f p t mem flags 4 );

2 → Poˇcet izochronn´ıch paket˚ u. 3 → Standardn´ı alokaˇcn´ı omezen´ı (viz. kmalloc() - GFP KERNEL, GPF ATOMIC). Pˇr´ıklad vytvoˇren´ı URB pak m˚ uˇze vypadat: struct *urb u = usb_alloc_urb(0, GFP_KERNEL); Smazán´ı pak prob´ıh´ a analogicky pˇres funkci: void usb_free_urb(struct urb *urb); Dále mus´ı b´ yt URB incializov´ an a pˇriˇrazen specifickému koncovému bodu. Toto se pak provádn´ı pˇres funkce odpov´ıdaj´ıc´ı jednotliv´ ym typ˚ um pˇrenos˚ u. Napˇr. pro bulk se pouˇz´ıvá funkce usb fill bulk urb(). Deklarace funkce vypadá: 1 void u s b f i l l b u l k u r b ( 2 struct urb ∗ urb , 3 struct u s b d e v i c e ∗ dev , 4 unsigned int pipe , 5 void ∗ t r a n s f e r b u f f e r , 6 int b u f f e r l e n g t h , 7 u s b c o m p l e t e t complete , 8 void ∗ c o n t e x t 9 );

2 → Ukazatel na jiˇz vytvoˇren´ y URB, kter´ y chceme inicializovat. 3 → USB zaˇr´ızen´ı, kterému m´ a b´ yt tento URB zaslán. 4 → Specifick´ y koncov´ y bod USB zaˇr´ızen´ı, kterému bude URB zaslán. Pro z´ıskán´ı této hodnoty slouˇz´ı specifické funkce, z´ avisej´ıc´ı na typu a smˇeru komunikace. Pˇrehled pˇrináˇs´ı obrázek 7.3 (pˇrevzat´ y z [9]): 5 → Ukazatel na datov´ y buffer, kter´ y obsahuje odes´ılaná data v pˇr´ıpadˇe odes´ılán´ı a pˇrijatá data v pˇr´ıpadˇe pˇr´ıjmu. Tento buffer mus´ı b´ yt vytvoˇren dynamicky pomoc´ı kmalloc() nebo s pˇredmapov´ an´ım pro DMA (usb buffer alloc()), nikoliv staticky. 6 → Délka datového bufferu na kter´ y se odkazuje ukazatel transfer buffer. 7 → Ukazatel na dokonˇcovac´ı funkci, která je volána pokud je poˇzadavek na URB vyˇr´ızen.


32

Obr´ azek 7.3: Vytváˇren´ı pipes

8 → Ukazatel na volitelnou datovou strukturu v ovladaˇci, která m˚ uˇze b´ yt vyuˇzita v dokonˇcovac´ı funkci kdyˇz je URB po pˇredán´ı do USB core pˇredán zpˇet ovladaˇci. Inicializaˇcn´ı funkce pro ostatn´ı typy pˇrenos˚ u maj´ı obdobnou strukturu4 , maj´ı vˇsak nav´ıc nˇekteré parametry odpov´ıdaj´ıc´ı jejich typu. Zde byl zm´ınˇen pro názornost pouze typ bulk, informaci o ostatn´ı typech lze nalézt bud’ v [1], nebo pˇr´ımo ve zdrojovém kódu jádra v souboru /include/linux/usb.h pˇr´ıstupném z [10]. Pokud je URB vytvoˇren a korektnˇe inicializován, pˇredá ho ovladaˇc do USB core volán´ım funkce usb submit urb(). Funkce je deklarována následovnˇe: 1 int u s b s u b m i t u r b ( 2 struct urb ∗ urb , 3 g f p t mem flags 4 );

Návratová hodnota rovna 0 znamen´ au ´spˇech, záporná hodnota znaˇc´ı chybu. 2 → Ukazatel na c´ılen´ y URB. 3 → Standardn´ı alokaˇcn´ı omezen´ı (viz. kmalloc()). K zruˇsen´ı jiˇz pˇredaného URB existuj´ı dvˇe funkce. Konkrétnˇe k zruˇsen´ı bez ˇcekán´ı slouˇz´ı int usb_unlink_urb(struct urb *urb); a k zruˇsen´ı s ˇcek´ an´ım na potvrzen´ı o dokonˇcen´ı: int usb_kill_urb(struct urb *urb); 4

kromˇe typu interrupt, pro kter´ y obdobn´ a funkce nen´ı dostupn´ a


33

kde parametr urb je analogicky k pˇredchoz´ım funkc´ım ukazatel na URB, kter´ y má b´ yt zruˇsen. Pokud zavol´ ame nˇekterou z tˇechto funkc´ı na URB, kter´ y nebyl pˇredán ke zpracován´ı, dostaneme chybovou n´ avratovou hodnotu. Jak jiˇz bylo zm´ınˇeno dokonˇcovac´ı funkce je callback volan´ y pˇri dokonˇcen´ı URB. Tato funkce m˚ uˇze vˇsak b´ yt vyvol´ ana i v pˇr´ıpadˇe, ˇze doˇslo k chybˇe pˇri datovém pˇrenosu, nebo byl potvrzen´ y URB zruˇsen. Funkce dost´ avá jako argument ukazatel struct urb* podle kterého se rozliˇsuje v kontextu kterého URB byl callback zavolán. Struktura struct urb obsahuje poloˇzku int status, kter´ a obsahuje informaci o stavu URB. Pokud je status roven 0, datov´ y pˇrenos byl korektnˇe dokonˇcen. U z´ aporn´ ych hodnot pak mohou b´ yt rozliˇseny dalˇs´ı pˇr´ıˇciny vyvolán´ı dokonˇcovac´ı funkce. Napˇr. -ECONNRESET znamená, ˇze URB byl zruˇsen vyvolán´ım usb unlink urb().

7.3.3

USB v GNU/Linux

Z uˇzivatelského prostoru lze nejjednoduˇseji zobrazit informace o USB sbˇernic´ıch v systému a zaˇr´ızen´ıch k nim pˇripojen´ ych zad´ an´ım pˇr´ıkazu lsusb. Pˇr´ıklad, jak m˚ uˇze v´ ypis vypadat: Bus 007 Device 002: ID Interface [Integrated Bus 007 Device 001: ID Bus 006 Device 002: ID Bus 006 Device 001: ID Bus 005 Device 003: ID Bus 005 Device 001: ID Bus 004 Device 001: ID Bus 003 Device 001: ID Bus 002 Device 003: ID Bus 002 Device 001: ID Bus 001 Device 001: ID

03f0:171d Module] 1d6b:0001 08ff:2580 1d6b:0001 1669:1011 1d6b:0001 1d6b:0001 1d6b:0001 04f2:b015 1d6b:0002 1d6b:0002

Hewlett-Packard Wireless (Bluetooth + WLAN) Linux Foundation 1.1 root hub AuthenTec, Inc. AES2501 Fingerprint Sensor Linux Foundation 1.1 root hub PiKRON Ltd. [hex] Linux Foundation 1.1 root hub Linux Foundation 1.1 root hub Linux Foundation 1.1 root hub Chicony Electronics Co., Ltd VGA 24fps UVC Webcam Linux Foundation 2.0 root hub Linux Foundation 2.0 root hub

Podrobn´ y v´ ypis informac´ı o konkrétn´ım zaˇr´ızen´ı lze doc´ılit pˇrep´ınaˇcem -v, --verbose a specifikován´ım c´ıleného zaˇr´ızen´ı pˇrep´ınaˇcem -s [[bus]:][devnum] popˇr. -d [vendor]:[product]. Kontrétnˇe tedy k zobrazen´ı informac´ı o pˇr´ıtomném pˇrevodn´ıku (vztaˇzeno k pˇredeˇslému v´ ypisu): $ lsusb -v -s 5:3 popˇr´ıpadˇe $ lsusb -v -d 1669:1011 Jiná moˇznost je pˇr´ıstup do systému soubor˚ u sysfs. To je virtuáln´ı souborov´ y systém, jehoˇz obsah nen´ı fyzicky uloˇzen na disku, ale je za bˇehu generován jádrem a zpˇr´ıstupnˇen v uˇzivatelském prostoru. Sysfs obsahuje informace o zaˇr´ızen´ıch a ovladaˇc´ıch a v adresáˇrové


34

struktuˇre je pˇr´ıstupn´ y pˇres /sys. Lze pomoc´ı nˇej také modifikovat funkcionalitu zaˇr´ızen´ı5 , vyuˇz´ıvá jej napˇr. spr´ avce zaˇr´ızen´ı udev. Informace o jednotliv´ ych USB zaˇr´ızen´ıch se pak nacházej´ı ve sloˇzce /sys/bus/usb/devices. Tato struktura odráˇz´ı pˇr´ısluˇsnost zaˇr´ızen´ı k jednotliv´ ych sbˇernic´ım6 , vlastn´ı obsah vˇsak tvoˇr´ı symbolické odkazy do struktury podadresár˚ u v /sys/devices/, kter´ a odr´ aˇz´ı vlastn´ı fyzické rozvrˇzen´ı. V sysfs pak nalezneme jak samotné USB zaˇr´ızen´ı (reprezentováno struct usb device), tak jednotlivá USB rozhran´ı (reprezentovány struct usb interface). V pˇr´ıpadˇe pˇrevodn´ıku, kter´ y obsahuje jediné USB rozhran´ı pak v sysfs m˚ uˇze USB zaˇr´ızen´ı odpov´ıdat: /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 a jeho USB rozhran´ı, se kter´ ym je spjat ovladaˇc: /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2/5-2:1.0 Prvn´ım u ´dajem (v naˇsem pˇr´ıpadˇe usb5) je tzv. root hub, tedy USB ˇradiˇc. Ten má specifické ˇc´ıslo pˇridˇelené od USB core odpov´ıdaj´ıc´ı tomu, jak byly jednotlivé ˇradiˇce postupnˇe registrovány do systému. Jméno zaˇr´ızen´ı se skláda z tohoto ˇc´ısla následovaného pomlˇckou a ˇc´ıslem portu, ke kterému je dané zaˇr´ızen´ı pˇripojeno. V naˇsem pˇr´ıpadˇe má tedy pˇrevodn´ık jako USB zaˇr´ızen´ı jméno 5-2. Jméno jeho USB rozhran´ı je pak dáno jménem tohoto zaˇr´ızen´ı následovan´ ym dvojteˇckou, ˇc´ıslem konfigurace, teˇckou a ˇc´ıslem rozhran´ı. V naˇsem pˇr´ıpadˇe 5-2:1.0, jelikoˇz je to prvn´ı konfigurace a má rozhran´ı s ˇc´ıslem 0. Podle [1] pak lze schéma pojmenován´ı USB rozhran´ı zobecnit jako root hub-hub port:config.interface pˇr´ıpadnˇe root hubhub port-hub port:config.interface. Ovˇsem takto nelze zjistit napˇr. nastaven´ı koncov´ ych bod˚ u daného rozhran´ı. Existuje vˇsak soubor generovan´ y j´ adrem, kter´ y obsahuje vˇsechny tyto informace. Do verze jádra 2.6.31 existoval systém soubor˚ u usbfs, pˇr´ıstupn´ y z adresáˇre /proc/bus/usb/. Uveden´ y soubor se pak nacházel v /proc/bus/usb/devices. Od verze jádra 2.6.31 doˇslo k defaultn´ımu zákazu usbfs, nicménˇe uveden´ y soubor lze nalézt v systému soubor˚ u debugfs, konkrétnˇe se jedná o /sys/kernel/debug/usb/devices.

5 6

napˇr´ıklad podle potˇreby mˇenit aktivn´ı USB konfigurace stejnˇe tak napˇr. pro PCI zaˇr´ızen´ı existuje adres´ aˇr /sys/bus/pci/devices


7.4

35

Imlementace ovladaˇ ce pˇ revodn´ıku

Koncepˇcnˇe vych´ az´ı struktura obsluhy komunikace s pˇrevodn´ıkem z USB implementace ovladaˇce LinCAN. Pro datov´ y pˇrenos existuj´ı dva koncové body typu bulk, které se liˇs´ı smˇerem komunikace. Jeden je pˇrij´ımac´ı (IN) a druh´ y odes´ılac´ı (OUT). Pˇrenos ˇr´ıdic´ıch poˇzadavk˚ u pro konfiguraci (napˇr. nastaven´ı komunikaˇcn´ıch parametr˚ u sbˇernice) se pak provád´ı pˇres ˇr´ıdic´ı (control) koncov´ y bod. Datov´ y pˇrenos pˇres USB prob´ıh´ a ve formˇe odeslán´ı nebo pˇr´ıjmu datového bloku, kter´ y reprezentuje samotnou CAN zpr´ avu. Struktura tohoto bloku je pevnˇe dána, pouˇz´ıvá ji jak pˇrevodn´ık tak LinCAN. V´ yznam jednotliv´ ych byt˚ u je moˇzné vidˇet na obrázku 7.4. K pˇrenosu se pouˇz´ıvá form´ at little-endian, takˇze pˇri pˇr´ıstupu do bytového pole, které tento datov´ y blok reprezentuje, ovladaˇc pouˇz´ıv´ a pˇrevodová makra. Pro ukladán´ı napˇr. cpu to le32() a pˇri ˇcten´ı napˇr. le32 to cpu(). Pˇrenos ˇr´ıdic´ıch poˇzadavk˚ u prob´ıhá také ve formˇe pˇrenosu bytového pole ve form´ atu little-endian, ovˇsem zde je struktura závislá na typu poˇzadavku.

Obr´ azek 7.4: Struktura datového bloku pro pˇrenos CAN zprávy po USB Poznámka: V textu d´ ale budou uv´ adˇeny fragmenty zdrojového k´ odu ovladaˇce pro vˇetˇs´ı n´ azornost. Je potˇreba si uvˇedomit, ˇze maj´ı m´ıt sp´ıˇse informativn´ı význam (jako pseudok´ od). Neobsahuj´ı tedy nutnˇe veˇskerou funkcionalitu, netestuj´ı se n´ avratové hodnoty funkc´ı na zjiˇstˇen´ı chyb atd. V ˇz´ adném pˇr´ıpadˇe tedy nejde o ekvivalent se skuteˇcným zdrojovým k´ odem.

7.4.1

Registrace

USB je specifick´ a sbˇernice z d˚ uvodu moˇznosti pˇripojen´ı zaˇr´ızen´ı za bˇehu systému (tzv. hotplug) bez nutnosti dalˇs´ı konfigurace ˇci restartu. Tomu mus´ı samozˇrejmˇe odpov´ıdat i podpora operaˇcn´ıho systému. Ovladaˇce jako takové maj´ı samozˇrejmˇe nároky na systémové zdroje. Zavádˇet ovladaˇce potenci´ alnˇe pˇripojiteln´ ych USB zaˇr´ızen´ı jiˇz pˇri startu systému, kdyˇz nen´ı jasné kdy a jestli v˚ ubec bude konkrétn´ı zaˇr´ızen´ı pˇripojeno, by bylo znaˇcnˇe neefektivn´ı. V Linuxu proto existuje mechanismus registrace, kdy jadern´ y modul reprezentuj´ıc´ı ovladaˇc nejprve pˇres speci´ aln´ı funkce zaregistruje do USB subsystému j´ım podporovaná zaˇr´ızen´ı (pˇres ID v´ yrobce a produktu). Na z´ akladˇe tˇechto informac´ı7 je pak pˇri fyzickém pˇripojen´ı zaˇr´ızen´ı USB subsystém schopen rozhodnout, kter´ y ovladaˇc danému zaˇr´ızen´ı pˇr´ısluˇs´ı a zavést jej. Proveden´ı tˇechto u ´kon˚ u bude vysvˇetleno na programovém fragmentu ovladaˇce CAN-USB pˇrevodn´ıku: 7

zjiˇst’uj´ı se od zaˇr´ızen´ı pˇri jeho enumeraci


36

Listing 7.1: Register to USB subsystem 1 2 3 4 5 6 7 8 9 10

#define CTU USBCAN VENDOR ID #define CTU USBCAN PRODUCT ID

0 x1669 0 x1011

/∗ t a b l e o f d e v i c e s t h a t work w i t h t h i s d r i v e r ∗/ s t a t i c struct u s b d e v i c e i d c t u u s b c a n t a b l e [ ] = { { USB DEVICE(CTU USBCAN VENDOR ID, CTU USBCAN PRODUCT ID) } , { } /∗ Terminating e n t r y ∗/ }; MODULE DEVICE TABLE( usb , c t u u s b c a n t a b l e ) ;

1 - 2 → Definujeme ID v´ yrobce a produktu daného USB zaˇr´ızen´ı. 5 - 8 → Informace pro subsystém popisuje struktura struct usb device id. Tyto struktury se sjednocuj´ı do pole, které m´ a podobu viditelnou na tˇechto ˇrádc´ıch. V tomto pˇr´ıpadˇe pˇrevodn´ık obsahuje tabulku s jedinou poloˇzku. K jej´ımu naplnˇen´ı slouˇz´ı makro USB DEVICE (vendor, product), které na z´ akladˇe zadan´ ych parametr˚ u vytvoˇr´ı strukturu struct usb device id. 10 → Pomoc´ı makra MODULE DEVICE TABLE(type, name) pak exportujeme u ´daje do uˇzivatelského prostoru. Argumenty specifikujeme usb substystém8 a tabulku s hodnotami. Listing 7.2: Register to USB subsystem 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

s t a t i c int c t u u s b c a n p r o b e ( struct u s b i n t e r f a c e ∗ i n t f , const struct u s b d e v i c e i d ∗ i d ) { /∗ l a t e r ∗/ } s t a t i c void c t u u s b c a n d i s c o n n e c t ( struct u s b i n t e r f a c e ∗ i n t f ) { /∗ l a t e r ∗/ } /∗ usb s p e c i f i c o b j e c t needed t o r e g i s t e r t h i s d r i v e r w i t h t h e usb s u b s y s t e m ∗/ s t a t i c struct u s b d r i v e r c t u u s b c a n d r i v e r = { . name = ” c t u u s b c a n ” , . id table = ctu usbcan table , . probe = ctu usbcan probe , . disconnect = ctu usbcan disconnect , };

24 - 29 → Z´ akladn´ı ˇc´ ast ovladaˇce USB zaˇr´ızen´ı je struktura struct usb driver. Ovladaˇc ji mus´ı vytvoˇrit a vyplnit nezbytné poloˇzky, tedy promˇenné a callback funkce, které budou následnˇe (po registraci) pouˇz´ıv´ any USB core. V pˇr´ıkladu pˇrevodn´ıku je to: 25 → N´ azev pod kter´ ym bude ovladaˇc v systému vystupovat. 26 → Ukazatel na tabulku tvoˇrenou strukturami struct usb device id, která je definována na ˇr´ adc´ıch 5-8 a kter´ a obsahuje v´ yˇcet zaˇr´ızen´ı podporovan´ ych ovladaˇcem. 8

toto makro pouˇz´ıvaj´ı i jiné subsystémy, napˇr. pci, pcmcia atd.


37

27 → Ukazatel na funkci probe(). To je callback funkce, kterou volá USB core v pˇr´ıpadˇe, ˇze bylo pˇripojeno nˇekteré USB zaˇr´ızen´ı a ovladaˇc by mˇel b´ yt schopen obslouˇzit jeho specifické USB rozhran´ı pˇredané jako argument (struktura struct usb interface). Zde pˇredáváme ukazatel na funkci jej´ıˇz definice zaˇc´ıná na ˇrádku 11, detailnˇeji bude popsána pozdˇeji. 28 → Ukazatel na funkci disconnect(). To je callback funkce, kterou volá USB core v pˇr´ıpadˇe, kdy by ovladaˇc jiˇz d´ ale nemˇel m´ıt kontrolu nad rozhran´ım. Napˇr. pokud dojde k odpojen´ı zaˇr´ızen´ı. Zde pˇred´ av´ ame ukazatel na funkci jej´ıˇz definice zaˇc´ıná na ˇrádku 17, detailnˇeji bude pops´ ana pozdˇeji. Listing 7.3: Register to USB subsystem 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

s t a t i c int i n i t c t u u s b c a n i n i t ( void ) { int r e s u l t ; p r i n t k (KERN INFO ”CTU USBCAN k e r n e l d r i v e r l o a d e d \n” ) ; /∗ r e g i s t e r t h i s d r i v e r w i t h t h e USB s u b s y s t e m ∗/ r e s u l t = u s b r e g i s t e r (& c t u u s b c a n d r i v e r ) ; if ( result ) e r r ( ” u s b r e g i s t e r f a i l e d . E r r o r number %d” , r e s u l t ) ; return r e s u l t ; } s t a t i c void e x i t c t u u s b c a n e x i t ( void ) { p r i n t k (KERN INFO ”CTU USBCAN k e r n e l d r i v e r unloaded \n” ) ; /∗ d e r e g i s t e r t h i s d r i v e r w i t h t h e USB s u b s y s t e m ∗/ u s b d e r e g i s t e r (& c t u u s b c a n d r i v e r ) ; } module init ( ctu usbcan init ) ; module exit ( ctu usbcan exit ) ;

Tyto ˇr´ adky obsahuj´ı témˇeˇr totoˇznou funkcionalitu, jako v pˇr´ıpadˇe základn´ıho jaderného modulu v sekci 7.1. 30 - 42 → Funkce, kter´ a se m´ a zavolat po nahrán´ı modulu do jádra. 37 → Vol´ an´ı funkce usb register(), která registruje ovladaˇc do USB subsystému. Jako argument pˇred´ av´ ame ukazatel na strukturu struct usb driver definovanou na ˇrádc´ıch 2429. 44 - 50 → Funkce, kter´ a se m´ a zavolat pˇri odstanˇen´ı modulu z jádra. 49 → Vol´ an´ı funkce usb deregister(), která odhlás´ı strukturu struct usb driver z jádra. T´ımto doch´ az´ı k logickému odpojen´ı vazeb mezi ovladaˇcem a USB rozhran´ım jehoˇz funkcionalitu zajiˇst’uje. Tud´ıˇz je pro toho rozhran´ı volána funkce disconnect()9 , v tomto pˇr´ıpadˇe definovan´ a od ˇradku 17. 9

pokud jiˇz nen´ı zaˇr´ızen´ı fyzicky odpojeno


7.4.2

38

Priv´ atn´ı data

Jak jiˇz bylo zm´ınˇeno v sekci 7.2, v ovladaˇc´ıch se nepouˇz´ıvaj´ı globáln´ı promˇenné, ale nam´ısto toho promˇenné pouˇzitelné z v´ıce m´ıst ovladaˇce utvoˇr´ı jednu strukturu, která pak tvoˇr´ı privátn´ı data ovladaˇce. V impementaci pˇrevodn´ıku vypadá tato struktura následovnˇe: Listing 7.4: Struktura privátn´ıch dat 1 /∗ S t r u c t u r e t o h o l d a l l o f our d e v i c e s p e c i f i c s t u f f ∗/ 2 struct c t u u s b c a n u s b { 3 4 /∗ CAN common p r i v a t e d a t a ∗/ 5 struct c a n p r i v can ; /∗ must be t h e f i r s t member ∗/ 6 /∗ CAN hardware−d e p e n d e n t b i t −t i m i n g c o n s t a n t ∗/ 7 struct c a n b i t t i m i n g c o n s t b t c ; 8 /∗ CAN system c l o c k f r e q u e n c y i n Hz ∗/ 9 u32 c a n c l o c k ; 10 11 /∗ t h e usb d e v i c e f o r t h i s d e v i c e ∗/ 12 struct u s b d e v i c e ∗ udev ; 13 /∗ t h e n e t d e v i c e f o r t h i s d e v i c e ∗/ 14 struct n e t d e v i c e ∗ netdev ; 15 16 /∗ t h e a d d r e s s o f t h e b u l k i n e n d p o i n t ∗/ 17 u8 b u l k i n e n d p o i n t A d d r ; 18 /∗ t h e a d d r e s s o f t h e b u l k o u t e n d p o i n t ∗/ 19 u8 b u l k o u t e n d p o i n t A d d r ; 20 21 /∗ URBs w a i t i n g f o r d a t a r e c e i v e ∗/ 22 struct l i s t h e a d r x p e n d l i s t ; 23 /∗ URBs w i t h v a l i d r e c e i v e d d a t a ∗/ 24 struct l i s t h e a d r x r e a d y l i s t ; 25 /∗ URBs p r e p a r e d t o h o l d Tx messages ∗/ 26 struct l i s t h e a d t x i d l e l i s t ; 27 /∗ URBs h o l d i n g Tx messages i n p r o g r e s s ∗/ 28 struct l i s t h e a d t x p e n d l i s t ; 29 /∗ URBs w i t h y e t c o n f i r m e d Tx messages ∗/ 30 struct l i s t h e a d t x r e a d y l i s t ; 31 32 /∗ l i s t l o c k ∗/ 33 spinlock t list lock ; 34 /∗ usb communication k e r n e l t h r e a d ∗/ 35 struct t a s k s t r u c t ∗ comthread ; 36 37 v o l a t i l e long f l a g s ; 38 } ;

V´ yznam jednotliv´ ych poloˇzek by mˇel b´ yt srozumiteln´ y z komentáˇr˚ u. Máme zde promˇenné 10 ’ t´ ykaj´ıc´ı se USB i s´ıt ového subsystému, adresy koncov´ ych bod˚ u , spojové seznamy pro pˇr´ıchoz´ı i odchoz´ı zpr´ avy (vysvˇetleny pozdˇeji) a promˇenné t´ ykaj´ıc´ı se samotného CAN zaˇr´ızen´ı. Ty jsou pouˇzity pro spoˇcten´ı a nastaven´ı ˇcasov´ ych parametr˚ u sbˇernice. 10

Pouˇz´ıv´ ame jeden IN BULK a jeden OUT BULK koncov´ y bod pro datové pˇrenosy


7.4.3 7.4.3.1

39

Pˇ ripojen´ı a odpojen´ı zaˇ r´ızen´ı Funkce probe()

Jak jiˇz bylo ˇreˇceno v pˇredchoz´ı sekci, probe() je callback funkce, kterou volá USB core v pˇr´ıpadˇe, ˇze bylo pˇripojeno nˇekteré USB zaˇr´ızen´ı a ovladaˇc by mˇel b´ yt schopen obslouˇzit jeho specifické USB rozhran´ı pˇredané jako argument (struktura struct usb interface). Ukazatel na tuto funkci definovanou v ovladaˇci se pˇredává pˇri registraci ovladaˇce. Deklarace tohoto ukazatele na funkci vypad´ a n´ asledovnˇe: int (*probe) (struct usb_interface *intf, const struct usb_device_id *id); Vid´ıme, ˇze jako argument je pˇredán i ukazatel na strukturu struct usb device id, na základˇe které USB core provedl vol´ an´ı. Pokud ovladaˇci náleˇz´ı obsluha daného USB rozhran´ı, vrac´ı honotu 0. Z´ aporn´ a n´ avratov´ a hodnota znaˇc´ı ne´ uspˇech. V této funkci ovladaˇc obvykle inicializuje svoje datové struktury. Typické je zjiˇstˇen´ı adres a velikost´ı buffer˚ u koncov´ ych bod˚ u, které budou pouˇzity pro komunikaci. Tato funkce je volána v kontextu vl´ akna USB rozboˇcovaˇce, tud´ıˇz je moˇzné volat funkce, které m˚ uˇzou zp˚ usobit usnut´ı. Obecnˇe se ale doporuˇcuje provést pouze nejnutnˇejˇs´ı funkcionalitu a vˇetˇsinu práce prov´ adˇet aˇz pˇri otevˇren´ı zaˇr´ızen´ı uˇzivatelem. Je to kv˚ uli tomu, ˇze pˇridáván´ı a odeb´ırán´ı zaˇr´ızen´ı prob´ıh´ a pouze v jednom vl´ aknˇe. Mohlo by tak b´ yt zp˚ usobeno napˇr. zpomalen´ı detekce zaˇr´ızen´ı systémem. Zjednoduˇsená funkce probe() pro CAN-USB pˇrevodn´ık vypadá následovnˇe: Listing 7.5: Funkce probe() 1 s t a t i c int c t u u s b c a n p r o b e ( struct u s b i n t e r f a c e ∗ i n t f , 2 const struct u s b d e v i c e i d ∗ i d ) 3 { 4 struct n e t d e v i c e ∗ netdev ; 5 struct c t u u s b c a n u s b ∗ dev ; 6 7 netdev = a l l o c c a n d e v ( s i z e o f ( struct c t u u s b c a n u s b ) , 8 USBCAN TOT TX URBS ) ; 9 dev = n e t d e v p r i v ( netdev ) ; 10 11 dev−>udev = i n t e r f a c e t o u s b d e v ( i n t f ) ; 12 dev−>netdev = netdev ; 13 14 netdev−>n e t d e v o p s = &c t u u s b c a n n e t d e v o p s ; 15 netdev−>f l a g s |= IFF ECHO ; 16 17 /∗ s e t up t h e e n d p o i n t i n f o r m a t i o n ∗/ 18 /∗ . . . ∗/ 19 20 u s b s e t i n t f d a t a ( i n t f , dev ) ; 21 SET NETDEV DEV( netdev , &i n t f −>dev ) ; 22 23 i f ( g e t b i t t i m i n g c o n s t a n t s ( dev ) ) { 24 e r r ( ” Could not g e t b i t t i m i n g c o n s t a n t s \n” ) ;


25 26 27 28 29 30 31 32 33 34 35 e x i t : 36 37 }

40

goto e x i t ; } dev−>can . c l o c k . f r e q = dev−>c a n c l o c k ; dev−>can . b i t t i m i n g c o n s t = &dev−>b t c ; dev−>can . d o s e t b i t t i m i n g = c t u u s b c a n s e t b i t t i m i n g ; dev−>can . d o s e t m o d e = c t u u s b c a n s e t m o d e ; e r r = r e g i s t e r c a n d e v ( netdev ) ; return 0 ;

7 → Alokuje a nastav´ı strukturu reprezentuj´ıc´ı CAN jako s´ıt’ové zaˇr´ızen´ı. Argumenty jsou velikost struktury pro priv´ atn´ı data a poˇcet URBs pro odes´ılán´ı. 9 → Z´ıskán´ı ukazatele na strukturu privátn´ıch dat. 11 → Uloˇzen´ı ukazatele na USB zaˇr´ızen´ı z´ıskaného z USB rozhran´ı. 12 → Uloˇzen´ı ukazatele na s´ıt’ové zaˇr´ızen´ı. 14 → Pˇred´ an´ı struktury s ukazateli na ˇr´ıdic´ı funkce s´ıt’ového rozhran´ı. 15 → Nastaven´ı informace, ˇze ovladaˇc podporuje local loopback. 18 → Z´ısk´ an´ı informac´ı o koncov´ ych bodech a uloˇzen´ı do struktury privátn´ıch dat ze struktury struct usb interface 20 → Poskytnut´ı priv´ atn´ıch dat USB rozhran´ı. 21 → Nastav´ı sysfs referenci fyzického zaˇr´ızen´ı s´ıt’ovému logickému zaˇr´ızen´ı. 23 → Vol´ an´ı funkce, kter´ a m´ a za u ´kol z pˇrevodn´ıku zjistit parametry CAN ˇradiˇce pro následn´ y v´ ypoˇcet ˇcasov´ ych parametr˚ u. Bude vysvˇetlena pozdˇeji. 28 - 31 → Pokud probˇehlo z´ısk´ an´ı parametr˚ u korektnˇe (ˇrádka 23 ), docház´ı k jejich pˇredán´ı do struktury struct can priv v privátn´ıch datech. Z hodnot v n´ı totiˇz vycház´ı funkcionalita v´ ypoˇctu ˇcasov´ ych parametr˚ u CAN sbˇernice, která je volána pˇri povolován´ı zaˇr´ızen´ı uˇzivatelem prostˇrednictv´ım n´ astroj˚ u z iproute2. 33 → CAN zaˇr´ızen´ı je zaregistrov´ ano do s´ıt’ového subsystému. Po pˇr´ıpojen´ı zaˇr´ızen´ı a proveden´ı funkce probe() by jiˇz v systému mˇelo b´ yt zaˇr´ızen´ı zobrazeno jako CAN rozhran´ı (napˇr. can0), coˇz je moˇzné ovˇeˇrit zavolán´ım: $ cat /proc/net/dev Zat´ım vˇsak z˚ ust´ av´ a neaktivn´ı. Je nutné mu nastavit parametry a následnˇe ho povolit. 7.4.3.2

Funkce disconnect()

Jak jiˇz bylo ˇreˇceno, disconnect() je callback funkce, kterou volá USB core v pˇr´ıpadˇe, kdy by ovladaˇc jiˇz d´ ale nemˇel m´ıt kontrolu nad rozhran´ım (napˇr. pokud dojde k odpojen´ı zaˇr´ızen´ı). Ukazatel na tuto funkci definovanou v ovladaˇci se pˇredává pˇri registraci ovladaˇce. Zjednoduˇsen´ a funkce disconnect() pro CAN-USB pˇrevodn´ık vypadá následovnˇe:


41

Listing 7.6: Funkce disconnect() 1 s t a t i c void c t u u s b c a n d i s c o n n e c t ( struct u s b i n t e r f a c e ∗ i n t f ) 2 { 3 struct c t u u s b c a n u s b ∗ dev = u s b g e t i n t f d a t a ( i n t f ) ; 4 u s b s e t i n t f d a t a ( i n t f , NULL ) ; 5 6 i f ( dev ) { 7 u n r e g i s t e r n e t d e v ( dev−>netdev ) ; 8 f r e e c a n d e v ( dev−>netdev ) ; 9 } 10 }

3 → Z´ıskán´ı ukazatele na strukturu privátn´ıch dat. 4 → Nastaven´ı ukazatele na priv´ atn´ı data USB zaˇr´ızen´ı na NULL k zabránˇen´ı dalˇs´ıch (chybn´ ych) pˇr´ıstup˚ u k tˇemato dat˚ um. 7 → Odebr´ an´ı zaˇr´ızen´ı z j´ adra. 8 → Uvolnˇen´ı z pamˇeti (pokud existuje pouze jedna reference).

7.4.4

Funkce s´ıt’ov´ eho rozhran´ı

Ve v´ ypisu 7.5 funkce probe() byla na ˇrádku 14 zm´ınˇena velmi d˚ uleˇzitá vˇec. Jde o vyplnˇen´ı poloˇzky netdev ops struktury struct net device, coˇz je ukazatel na strukturu struct net device ops. Tato struktura definuje ukazatele na ˇr´ıdic´ı funkce s´ıt’ov´ ych rozhran´ı a mus´ı b´ yt vyplnˇena pˇred registrac´ı zaˇr´ızen´ı do s´ıt’ového subsystému. CAN zaˇr´ızen´ı obvykle implementuje pouze tˇri funkce, které lze vidˇet na kódu pˇrevodn´ıku: static const struct net_device_ops ctu_usbcan_netdev_ops = { .ndo_open = ctu_usbcan_open, .ndo_stop = ctu_usbcan_close, .ndo_start_xmit = ctu_usbcan_start_xmit, }; Prvn´ı poloˇzka struktury je ukazatel na funkci ndo open(), která se volá pˇri povolován´ı zaˇr´ızen´ı. Druh´ y je ukazatel na funkci ndo stop(), která se volá pˇri zakazován´ı zaˇr´ızen´ı. Posledn´ı je ukazatel na funkci ndo start xmit(), která se volá v pˇr´ıpadˇe potˇreby pˇrenosu paketu. Packet scheduler m´ a pro kaˇzdé s´ıt’ové zaˇr´ızen´ı odes´ılac´ı frontu. Pˇri aktivaci zaˇr´ızen´ı (ndo open()) mus´ı b´ yt tato fronta spuˇstˇena. Poté m˚ uˇze packet scheduler volat funkci ndo start xmit() (v kontextu softIRQ) v pˇr´ıpadˇe potˇreby pˇrenosu paketu [3].

7.4.5

Nastaven´ı, povolen´ı a zak´ az´ an´ı CAN zaˇ r´ızen´ı

CAN zaˇr´ızen´ı lze nastavovat pˇres netlink rozhran´ı pomoc´ı programu ip z iproute2, coˇz je kolekce nástroj˚ u t´ ykaj´ıc´ıch se spr´ avy s´ıt’ové oblasti. Pomoc´ı ip lze povolit/zakázat zaˇr´ızen´ı, nastavovat ˇcasové parametry ˇci zobrazovat statistiky. Podrobn´ y pˇrehled lze nalézt v dokumentaci k SocketCAN v sekci 6.5 (soubor Documentation/networking/can.txt).


7.4.5.1

42

Nastaven´ı

Parametry ˇcasov´ an´ı komunikace CAN sbˇernice mohou b´ yt vˇzdy vyjádˇreny v hardwarovˇe nezávislém form´ atu jak plyne ze specifikace. SocketCAN obsahuje funkcionalitu, která umoˇzn ˇuje tyto parametry vypoˇc´ıst pro c´ılen´ y CAN ˇradiˇc na základˇe poˇzadované komunikaˇcn´ı rychlosti, pracovn´ı frekvence ˇradiˇce a interval˚ u moˇzn´ ych hodnot, jak´ ymi m˚ uˇze b´ yt ˇradiˇc nastaven. Nastaven´ı CAN zaˇr´ızen´ı se z´ amˇerem komunikovat rychlost´ı 1 Mb/s pak m˚ uˇze vypadat: $ ip link set can0 type can bitrate 1000000 Zde specifikujeme poˇzadovanou rychlost, ostatn´ı parametry pro v´ ypoˇcet vˇsak mus´ı b´ yt jiˇz k dispozici. Pr´ avˇe jejich z´ısk´ an´ı se provád´ı ve funkci probe() popisované v sekci 7.4.3.1, konkrétnˇe ve v´ ypisu 7.5 na ˇr´ adc´ıch 23-31. Zde se tedy nejprve volá funkce, která má za u ´kol z pˇrevodn´ıku zjistit parametry CAN ˇradiˇce. Pokud probˇehne korektnˇe, docház´ı k pˇredán´ı parametr˚ u do struktury struct can priv v privátn´ıch datech. Konkrétnˇe frekvence ˇradiˇce a ukazatel na strukturu struct can bittiming const, která obsahuje zm´ınˇené intervaly moˇzn´ ych hodnot, kter´ ymi m˚ uˇze b´ yt ˇradiˇc nastaven. Pokud pak dojde k poˇzadavku o nastaven´ı jako v pˇr´ıkladu v´ yˇse, dojde k proveden´ı funkcionality pro v´ ypoˇcet parametr˚ u pro nastaven´ı CAN ˇradiˇce a poté k zavolán´ı funkce definované pˇres ukazatel na funkci s prototypem: int (*do_set_bittiming)(struct net_device *dev); Tedy ve v´ ypisu 7.5 na ˇr´ adku 30. Dan´ a funkce má pak zajistit samotné nastaven´ı CAN ˇradiˇce pˇrevodn´ıku podle vypoˇcten´ ych parametr˚ u. Ty lze z´ıskat z privátn´ıch dat opˇet ze struktury a disponuje poloˇzkou struct can bittiming. Jej´ı poloˇzky obsahuj´ı struct can priv, kter´ právˇe vypoˇctené parametry. 7.4.5.2

Povolen´ı

Po nastaven´ı komunikaˇcn´ıch parametr˚ u lze CAN zaˇr´ızen´ı povolit. To se provád´ı jako povolen´ı kteréhokoliv jiného s´ıt’ového zaˇr´ızen´ı, tedy napˇr.: $ ip link set can0 up Pˇri povolen´ı zaˇr´ızen´ı vyvol´ a s´ıt’ov´ y subsystém callback funkci open(), registrovanou dˇr´ıve. V této funkci mus´ı ovladaˇc dokonˇcit konfiguraci a po jej´ım proveden´ı mus´ı b´ yt schopen pˇrij´ımat a odes´ılat CAN zpr´ avy. V naˇsem pˇr´ıpadˇe tato funkce zavolá funkci open candev() coˇz je obecn´ a funkce, kter´ a je vol´ ana pˇri povolen´ı zaˇr´ızen´ı. Dále je tˇreba povolit odes´ılán´ı samotn´ ych zpr´ av, tedy umoˇznit vyˇsˇs´ım vrstvám volat odes´ılac´ı funkci. To provedeme pˇres netif start queue(). Obˇe zm´ınˇené funkce se volaj´ı s argumentem s´ıt’ového zaˇr´ızen´ı, tedy s ukazatelem na strukturu struct net device a ten dostává jako argument volaná funkce open(). Jej´ım posledn´ım krokem je spuˇstˇen´ı vlákna, které bude m´ıt na starosti obsluhu veˇskeré komunikace.


7.4.5.3

43

Zak´ az´ an´ı

Zákaz CAN zaˇr´ızen´ı lze provést jako zakázán´ı kteréhokoliv jiného s´ıt’ového zaˇr´ızen´ı, tedy napˇr.: $ ip link set can0 down Pˇri zak´ az´ an´ı zaˇr´ızen´ı vyvol´ a s´ıt’ov´ y subsystém callback funkci close(), registrovanou dˇr´ıve. V této funkci se provedou kroky analogické k povolen´ı, pouze s opaˇcn´ ym efektem. Tedy nejprve poˇzadavek na ukonˇcen´ı obsluˇzného vlákna, dále zastaven´ı odes´ılac´ı fronty pˇres netif stop queue() a nakonec funkce close candev().

7.4.6

Obsluˇ zn´ e vl´ akno a fronty

Dále existuje oddˇelené vl´ akno, které se o pr˚ ubˇeh komunikace stará. Toto vlákno je spuˇstˇeno ve funkci ctu usbcan open() pˇri povolen´ı rozhran´ı a zastaveno ve funkci ctu usbcan close() pˇri zakázán´ı rozhran´ı. Ve funkci, kterou vlákno vykonává, docház´ı k alokaci a nastaven´ı prostˇredk˚ u USB komunikace zvan´ ych URB. Jejich obecné pouˇzit´ı bylo vysvˇetleno v sekci 7.3.2.5. V systému se pak pracuje s komunikaˇcn´ımi objekty, které reprezentuje struktura: struct usbcan_message { struct urb *u; struct ctu_usbcan_usb *dev; u8 msg[USBCAN_TRANSFER_SIZE]; u32 echo_index; u8 dlc; struct list_head list_node; }; V n´ı je tedy odkaz na souvisej´ıc´ı URB a také na privátn´ı data. Dále bytové pole pro pˇrenáˇsená data (msg), délka samotné CAN zprávy (dlc), pro odes´ılané zprávy index pro local loopback funkcionalitu (echo index) a posledn´ı je poloˇzka pro potˇreby um´ıstˇen´ı objektu do front (list node). Existuje pak nˇekolik front tˇechto objekt˚ u, které urˇcuj´ı jejich ˇzivotn´ı cyklus. Pro pˇr´ıjem jsou to: • rx pend list - URB tˇechto objekt˚ u je poskytnut do USB core a ˇceká na pˇr´ıjem dat • rx ready list - URB tˇechto pˇrij´ımac´ıch objekt˚ u byl vyˇr´ızen, maj´ı k dispozici platná pˇrijat´ a data Pro odes´ıl´ an´ı jsou to: • tx idle list - Objekty pˇripravené k pouˇzit´ı pro odeslán´ı zprávy • tx pend list - URB poskytnut do USB core k odeslán´ı platn´ ych dat


44

• tx ready list - URB tˇechto odes´ılac´ıch objekt˚ u byl vyˇr´ızen, obsahuj´ı dosud potvrzené odeslané zpr´ avy Z pouˇzit´ı front je patrné, ˇze docház´ı k alokaci nˇekolika tˇechto odes´ılac´ıch a pˇrij´ımac´ıch blok˚ u pˇred zaˇc´ atkem komunikace a následnˇe jsou pouze pˇrem´ıst’ovány v rámci front. Jejich poˇcet je definov´ an na z´ akladˇe maker USBCAN TOT RX URBS a USBCAN TOT TX URBS. Tento zp˚ usob sniˇzuje reˇzii na alokaci struktur oproti moˇznému dynamickém vytváˇren´ı pˇri potˇrebˇe pˇrenosu. Pˇr´ıklad alokace v n´ asleduj´ıc´ım fragmentu: Listing 7.7: Alokace a nastaven´ı komunikaˇcn´ıch objekt˚ u 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

/∗ dev −> p o i n t e r t o p r i v a t e d a t a ( s t r u c t c t u u s b c a n u s b ∗ dev ) ∗/ struct u s b c a n m e s s a g e ∗m; struct urb ∗u ; /∗ Prepare t r a n s m i t u r b s ∗/ f o r ( i =0; i dev = dev−>udev ; m−>u = u ; m−>dev = dev ; m−>e c h o i n d e x = i ; u s b f i l l b u l k u r b ( u , dev−>udev , u s b s n d b u l k p i p e ( dev−>udev , dev−>b u l k o u t e n d p o i n t A d d r ) , m−>msg , USBCAN TRANSFER SIZE, c t u u s b c a n t x c a l l b a c k , m) ; l i s t a d d t a i l (&m−>l i s t n o d e , &dev−> t x i d l e l i s t ) ; }

Po alokaci a nastaven´ı pˇrij´ımac´ıch a odes´ılac´ıch komunikaˇcn´ıch prostˇredk˚ u vlákno zaˇc´ıná provádˇet nekoneˇcnou smyˇcku, kter´ a vyˇrizuje komunikaci. Pokud neprob´ıhá pˇrenos zpráv, je vlákno usp´ ano a k jeho opˇetovnému vzbuzen´ı docház´ı v mechanismech dokonˇcovac´ıch callback funkc´ı po vyˇr´ızen´ı URB poˇzadavku. Pokud pˇrijde poˇzadavek na ukonˇcen´ı vlákna, ukonˇc´ı a uvoln´ı vˇsechny j´ım alokované prostˇredky (komunikaˇcn´ı objekty, URBs).

7.4.7

Pˇ r´ıjem

Pˇri pˇr´ıjmu doch´ az´ı k vyvol´ an´ı callback funkce definované pˇri nastavován´ı URB viz. sekce 7.3.2.5. Zjiˇstˇen´ı, kterého komunikaˇcn´ıho objektu se vyvolán´ı t´ yka a zda byl pˇr´ıjem dat u ´spˇeˇsn´ y, lze vidˇet v n´ asleduj´ıc´ım fragmentu kódu: Listing 7.8: rx callback 1 s t a t i c void c t u u s b c a n r x c a l l b a c k ( struct urb ∗ urb )


2 { 3 4 5 6 7 8 9 10 11 12 13 }

45

struct u s b c a n m e s s a g e ∗m = urb−>c o n t e x t ; i f ( urb−>s t a t u s != 0 ) { e r r ( ”RX c a l l b a c k : e r r o r ” ) ; return ; } /∗ . . . ∗/

Dalˇs´ı funkcionalitou, kter´ a je zaznaˇcena teˇckami na ˇrádku 11 je nastaven´ı pˇr´ıznaku platn´ ych pˇrijat´ ych dat USBCAN DATA OK, na základˇe kterého je vzbuzeno vlákno staraj´ıc´ı se o komunikaci a pˇresun komunikaˇcn´ıho objektu z rx pend list do rx ready list. Vlákno obsluhuje pˇr´ıjem tak, ˇze testuje obsazenost právˇe rx ready list. Dokud nen´ı fronta prázdn´ a, vol´ a usbcan kthread read handler(), kterému pˇredává komunikaˇcn´ı objekt z vrcholu fronty. Tato funkce pˇredstavuje samotné zpracován´ı pˇrijaté CAN zprávy a poskytuje následné pˇred´ an´ı vyˇsˇs´ım s´ıt’ov´ ym vrstvám v pˇr´ısluˇsné formˇe. Pro pˇredstavu následuje fragment k´ odu: Listing 7.9: Funkce vlákna obsluhuj´ıc´ı pˇr´ıjem 1 void u s b c a n k t h r e a d r e a d h a n d l e r ( struct c t u u s b c a n u s b ∗ dev , 2 struct u s b c a n m e s s a g e ∗m) 3 { 4 5 struct c a n f r a m e ∗ c f ; 6 struct s k b u f f ∗ skb ; 7 struct n e t d e v i c e s t a t s ∗ s t a t s = &dev−>netdev−>s t a t s ; 8 9 skb = a l l o c c a n s k b ( dev−>netdev , &c f ) ; 10 11 /∗ . . . t o c f from m−>msg . . . ∗/ 12 13 n e t i f r x ( skb ) ; 14 15 s t a t s −>r x p a c k e t s ++; 16 s t a t s −>r x b y t e s += c f −>c a n d l c ; 17 18 /∗ . . . ∗/ 19 20 }

5 → Struktura struct can frame je základn´ı podoba CAN rámce, se kterou SocketCAN pracuje. 6 → Struktura struct sk buff popisuje socket buffer v s´ıt’ovém subsystému. 9 → Alokuje socket buffer, kter´ y bude oznaˇcen jako nositel CAN zprávy (viz. 6.3.3) a nastav´ı (cf) jako ukazatel do jeho datové oblasti. 11 → Naznaˇceno vyplnˇen´ı struktury (cf) hodnotami z datového bufferu pˇrenesen´ ych dat


46

(m->msg). 13 → Pˇred´ an´ı paketu vyˇsˇs´ı vrstvˇe - packet scheduler (obrázek 6.1 ˇcást b). ´ 15 - 16 → Uprava pˇrij´ımac´ıch statistik. 18 → Dalˇs´ı funkcionalitou je pˇresun komunikaˇcn´ıho objektu do rx pend list a opˇetovné poskytnut´ı jeho URB do USB core k pˇrijmu dalˇs´ı zprávy. Takto vypad´ a cyklus pˇrijet´ı zpr´ avy ovladaˇcem. Ve struˇcnosti zprostˇredkovává pˇr´ıjem od niˇzˇs´ı vrstvy (USB subsystém) a pˇredává vyˇsˇs´ı vrstvˇe (s´ıt’ová vrstva - SocketCAN).

7.4.8

Odes´ıl´ an´ı

Cyklus odesl´ an´ı zpr´ avy zaˇc´ın´ a zavolán´ım funkce ctu usbcan start xmit() registrované dˇr´ıve. To znaˇc´ı poˇzadavek na odesl´ an´ı CAN zprávy. Listing 7.10: Odes´ılán´ı zprávy 1 s t a t i c n e t d e v t x t c t u u s b c a n s t a r t x m i t ( struct s k b u f f ∗ skb , 2 struct n e t d e v i c e ∗ netdev ) 3 { 4 struct c t u u s b c a n u s b ∗ dev = n e t d e v p r i v ( netdev ) ; 5 struct c a n f r a m e ∗ c f = ( struct c a n f r a m e ∗ ) skb−>data ; 6 7 struct u s b c a n m e s s a g e ∗m; 8 m = l i s t f i r s t e n t r y (&dev−> t x i d l e l i s t , t y p e o f ( ∗m) , l i s t n o d e ) ; 9 10 /∗ . . . from c f t o m−>msg . . . ∗/ 11 12 /∗ p u t on s t a c k − l o c a l echo ∗/ 13 c a n p u t e c h o s k b ( skb , netdev , m−>e c h o i n d e x ) ; 14 15 /∗ . . . ∗/ 16 17 /∗ s l o w down t x p a t h i f needed ∗/ 18 i f ( l i s t e m p t y (&dev−> t x i d l e l i s t ) ) 19 n e t i f s t o p q u e u e ( netdev ) ; 20 21 return NETDEV TX OK; 22 }

Vid´ıme, ˇze se n´ am zde logicky objevuj´ı stejné struktury jako pˇri pˇrijmu, tedy struct can frame reprezentuj´ıc´ı CAN r´ amec SocketCAN a sk buff reprezentuj´ıc´ı socket buffer slouˇz´ıc´ı k pˇrenosu paket˚ u s´ıt’ovou vrstvou. 5 → Datov´ a oblast skb->data reprezentuje CAN rámec (struct can frame) 8 → Prvn´ı komununikaˇcn´ı objekt z tx idle list tedy volnˇe pouˇziteln´ y k odeslán´ı zprávy 10 → Naznaˇceno vyplnˇen´ı hodnot datového bufferu odes´ılan´ ych dat (m->msg) ze struktury (cf). Tedy analogicky opaˇcn´ y proces k pˇr´ıjmu. 13 → Buffer je uloˇzen pro u ´ˇcely local loopack (viz. 6.3.2) 15 → Dalˇs´ı funkcionalitou je pˇresun komunikaˇcn´ıho objektu do tx pend list a poskytnut´ı jeho URB do USB core k odesl´ an´ı zprávy. 18 - 19 → Pokud jiˇz nen´ı ˇz´ adn´ y voln´ y komunikaˇcn´ı objekt v tx idle list, mus´ıme zastavit odes´ılac´ı frontu a znemoˇznit tak dalˇs´ı volán´ı ctu usbcan start xmit().


47

Pokud doˇslo k u ´spˇeˇsnému vyˇr´ızen´ı URB a tedy odeslán´ı zprávy na sbˇernici, docház´ı k vyvolán´ı callback funkce ctu usbcan tx callback() obdobnˇe jako u pˇr´ıjimac´ı callback funkce popsané v pˇredchoz´ı sekci. Struktura a funkcionalita je obdobná, pouze komunikaˇcn´ı objekt je pˇresunut do fronty pˇr´ısluˇsej´ıc´ı odes´ılán´ı (tx ready list). Nav´ıc jsou zde pouze upraveny odes´ılac´ı statistiky a zavolána funkce can get echo skb(), kdy je socket buffer vyzvednut zpˇet ze z´ asobn´ıku pro u ´ˇcely local loopback a je tak vytvoˇreno ”echo”právˇe odeslané zprávy. Vlákno dokonˇcuje odesl´ an´ı tak, ˇze testuje obsazenost tx ready list. Dokud nen´ı fronta prázdná, vol´ a usbcan kthread write handler(), kterému pˇredává komunikaˇcn´ı objekt z vrcholu fronty. Princip tedy opˇet analogick´ y k pˇr´ıjmu. V této funkci vˇsak docház´ı pouze ke dvˇema u ´kon˚ um. Prvn´ım je pˇresunut´ı komunikaˇcn´ıho objektu do tx idle list, kde bude tedy opˇet volnˇe pouˇziteln´ y pro odes´ılán´ı dalˇs´ıch zpráv. Dále pokud je zastavena odes´ılac´ı ´ fronta, mus´ıme ji opˇet spustit pro umoˇznˇen´ı volán´ı ctu usbcan start xmit(). Ukony u ´pravy odes´ılac´ıch statistik a echo by se jistˇe daly provádˇet i v této funkci. V dokonˇcovac´ı callback funkci jsou um´ıstˇeny pouze pro logickou vazbu s upozornˇen´ım na fyzické odeslán´ı. Listing 7.11: Funkce vlákna dokonˇcuj´ıc´ı cyklus odes´ılán´ı 1 void u s b c a n k t h r e a d w r i t e h a n d l e r ( struct c t u u s b c a n u s b ∗ dev , 2 struct u s b c a n m e s s a g e ∗m) 3 { 4 u s b c a n u s b m e s s a g e m o v e l i s t ( dev , m, &dev−> t x i d l e l i s t ) ; 5 6 i f ( n e t i f q u e u e s t o p p e d ( dev−>netdev ) ) 7 n e t i f w a k e q u e u e ( dev−>netdev ) ; 8 }

Takto vypad´ a cyklus odesl´ an´ı zprávy ovladaˇcem. Ve struˇcnosti zprostˇredkovává pˇr´ıjem od vyˇsˇs´ı vrstvy (s´ıt’ov´ a vrstva - SocketCAN) a pˇredává niˇzˇs´ı vrstvˇe (USB subsystém).

Kapitola 8

Testov´ an´ı V´ yvoj i testov´ an´ı prob´ıhaly s re´ aln´ ym vyuˇzit´ım sbˇernice CAN. Druh´ y prvek na sbˇernici, se kter´ ym pˇrevodn´ık prostˇrednictv´ım CAN komunikoval, byl starˇs´ı CAN-USB pˇrevodn´ık ˇ c sbˇernice implementovan´ y v roce 2008 v r´ amci bakaláˇrské práce J. Kˇr´ıˇze s názvem Radiˇ 1 CAN pˇripojený k PC pˇres sbˇernici USB . Tento pˇrevodn´ık je zaloˇzen na mikrokontroléru LPC2148, obsahuje extern´ı CAN ˇradiˇc SJA1000 a podporuje ho ovladaˇc LinCAN. Sestavu je moˇzné vidˇet na obr´ azku 8.1. Pˇrevodn´ık navrˇzen´ y v této práci (s LPC1768) byl pak pˇripojen k notebooku s frekvenc´ı procesoru 2GHz. Starˇs´ı pˇrevodn´ık (s LPC2148) byl pak pˇripojen k PC s frekvenc´ı procesoru 2,8GHz. Oba poˇc´ıtaˇce maj´ı architekturu IA-32 a operaˇcn´ı systém GNU/Linux Ubuntu 10.04 se standardn´ım jádrem 2.6.32-35. Jelikoˇz komunikaˇcn´ı protokol po USB sbˇernici mezi obˇema pˇrevodn´ıky a poˇc´ıtaˇcem je velmi podobn´ y 2 , podaˇrilo se s nˇekolika drobn´ ymi u ´pravami ovladaˇce zaloˇzeného na SocketCAN poskytnout starˇs´ımu pˇrevodn´ıku podporu t´ımto ovladaˇcem 3 . Takto mohly b´ yt v rámci jednoho testov´ an´ı pokryty veˇskeré poˇzadavky ze zadán´ı. Tedy konkrétnˇe: • Otestovat souˇcinnost implementace firmware pˇrevodn´ıku s ovladaˇcem pro USB zaˇr´ızen´ı LinCAN. • Otestovat souˇcinnost implementace firmware pˇrevodn´ıku s vyvinut´ ym ovladaˇcem pro USB zaˇr´ızen´ı zaloˇzeném na SocketCAN. • Porovnat vlastnosti s´ıtového ovladaˇce zaloˇzeného na SocketCAN se znakov´ ym ovladaˇcem LinCAN 4 .

8.1

Pr˚ ubˇ eh test˚ u

Samotné testov´ an´ı vych´ az´ı z ˇcl´ anku [6], kter´ y se zab´ yvá ˇcasovou anal´ yzou Linuxov´ ych ovladaˇc˚ u pro CAN. Byl mˇeren tzv. round trip time tedy ˇcas mezi odeslán´ım zprávy druhému 1

pr´ ace je dostupn´ a z [8] z´ amˇernˇe - kv˚ uli budouc´ımu slouˇcen´ı funkcionality pro jednoduchou volbu podle aktu´ alnˇe poˇzadového typu hardware 3 pouze pro u ´ˇcely tohoto testov´ an´ı, k plné podpoˇre se mus´ı upravit firmware pˇrevodn´ıku 4 bud’ obˇe zaˇr´ızen´ı vyuˇz´ıvaj´ı LinCAN, nebo obˇe zaˇr´ızen´ı vyuˇz´ıvaj´ı ovladaˇc zaloˇzen´ y na SocketCAN 2

48

´ Í KAPITOLA 8. TESTOVAN

49

Obr´ azek 8.1: Sestava hardware pro v´ yvoj a testován´ı

uzlu a jej´ım n´ asledném opˇetovném pˇrijet´ı. K tomu byl vyuˇzit nástroj canping 5 . Tato aplikace umoˇzn ˇuje odes´ılat zpr´ avy a mˇeˇrit ˇcas, kter´ y uplyne, neˇz dostane odpovˇed’. Dalˇs´ı zpráva je odeslána aˇz po obdrˇzen´ı odpovˇedi na pˇredchoz´ı odeslanou zprávu. Aplikace se spouˇst´ı z pˇr´ıkazové ˇr´ adky a pomoc´ı pˇrep´ınaˇc˚ u lze specifikovat r˚ uzná nastaven´ı jako poˇcet vláken, poˇcet odes´ılan´ ych zpr´ av, ˇcasovou prodlevu mezi zprávami atd. Namˇeˇrené ˇcasy jsou statisticky zpracov´ any mohou z nich b´ yt vytvoˇreny histrogramy. K pˇr´ıstupu k oboum typ˚ um ovladaˇc˚ u canping pouˇz´ıv´ a knihovnu VCA (Vitual CAN API). Ta je souˇcást´ı projektu OrtCAN (OCERA Real-Time CAN) a informace o n´ı lze nalézt na [11]. Bylo provedeno nˇekolik test˚ u s promˇenn´ ymi parametry poˇctu odes´ılac´ıch/pˇrij´ımac´ıch vláken a ˇcasové prodlevy mezi odes´ıl´ an´ım jednotliv´ ych zpráv. V kaˇzdém testu bylo kaˇzd´ ym vláknem odesl´ ano 10 000 zpr´ av. Rychlost sbˇernice (bitrate) byla nastavena na 1 Mb/s. Z namˇeˇren´ ych dat byly vytvoˇreny grafy. Kaˇzd´ y graf zobrazuje tzv. latency profile. To je kumulativn´ı histogram s pˇrevr´ acenou vertikáln´ı osou v logaritmickém mˇeˇr´ıtku. Horizontáln´ı osu pak tvoˇr´ı uplynul´ y ˇcas. Z tohoto grafu je pak moˇzné dobˇre vidˇet pˇresn´ y poˇcet zpráv s nejhorˇs´ı latenc´ı6 . Tyto grafy je moˇzné vidˇet na obrázc´ıch, které budou následovat. Pouze 5

http://rtime.felk.cvut.cz/gitweb/canping.git Obyˇcejné histogramy nejsou pro zjiˇstˇen´ı maxim´ aln´ıho zpoˇzdˇen´ı vhodné, jelikoˇz ho vˇetˇsinou reprezentouje pouze velmi mal´ y poˇcet zpr´ av. Hodnotu tohoto maxima je pak v grafu tˇeˇzké odhalit 6


50

na obrázku 8.3 je pro zaj´ımavost moˇzné vidˇet pˇrehled historie round trip time vˇsech zpráv daného testu. Obr´ azek 8.2: Round trip time - 1 vlákno, nulová prodleva

Obr´ azek 8.3: Round trip time historie - 1 vlákno, nulová prodleva


Obr´ azek 8.4: Round trip time - 3 vlákna, nulová prodleva

Obr´ azek 8.5: Round trip time - 1 vlákno, prodleva 0, 1 a 2 ms

51

52


Pro zaj´ımavost je zde jiˇz pouze textovˇe uveden v´ ypis z testován´ı s deseti paraleln´ımi vlákny s nulovou prodlevou. Pro SocketCAN je to: $ sudo ./vca_canping -m 10 -d Summary statistics: Id 1000: count = 10000 mean = Id 1002: count = 10000 mean = Id 1004: count = 10000 mean = Id 1006: count = 10000 mean = Id 1008: count = 10000 mean = Id 1010: count = 10000 mean = Id 1012: count = 10000 mean = Id 1014: count = 10000 mean = Id 1016: count = 10000 mean = Id 1018: count = 10000 mean =

socketcan:can0 -c 10000 -w 0 3988.86 3987.05 3984.19 3989.89 3995.95 3984.37 4017.68 4009.11 3979.38 3991.75

stddev stddev stddev stddev stddev stddev stddev stddev stddev stddev

= = = = = = = = = =

611.34 607.88 600.74 618.49 637.82 648.53 686.59 663.80 632.11 629.80

min min min min min min min min min min

= = = = = = = = = =

1911 1913 1924 1884 1952 1896 1272 1926 1869 1896

max max max max max max max max max max

= = = = = = = = = =

8127 8010 7961 8123 8500 8924 8997 8974 8051 7986

[us] [us] [us] [us] [us] [us] [us] [us] [us] [us]

loss loss loss loss loss loss loss loss loss loss

= = = = = = = = = =

0% 0% 0% 0% 0% 0% 0% 0% 0% 0%

(0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

min min min min min min min min min min

= = = = = = = = = =

1821 1863 1664 1632 1832 1781 1854 988 1862 1804

max max max max max max max max max max

= = = = = = = = = =

5294 4866 6905 6390 5453 5431 7414 6392 7867 6339

[us] [us] [us] [us] [us] [us] [us] [us] [us] [us]

loss loss loss loss loss loss loss loss loss loss

= = = = = = = = = =

0% 0% 0% 0% 0% 0% 0% 0% 0% 0%

(0) (0) (0) (0) (0) (0) (0) (0) (0) (0)

Pro LinCAN pak v´ ypis vypad´ a n´ asledovnˇe: $ sudo ./vca_canping -m 10 -d Summary statistics: Id 1000: count = 10000 mean = Id 1002: count = 10000 mean = Id 1004: count = 10000 mean = Id 1006: count = 10000 mean = Id 1008: count = 10000 mean = Id 1010: count = 10000 mean = Id 1012: count = 10000 mean = Id 1014: count = 10000 mean = Id 1016: count = 10000 mean = Id 1018: count = 10000 mean =

8.2

/dev/can0 -c 10000 -w 0 2784.20 2785.21 2806.85 2802.88 2796.48 2792.73 2797.77 2789.41 2798.49 2779.17

stddev stddev stddev stddev stddev stddev stddev stddev stddev stddev

= = = = = = = = = =

588.65 575.36 567.81 582.11 573.86 582.16 582.17 566.51 594.89 587.14

Zhodnocen´ı

Bylo otestov´ ano korektn´ı chov´ an´ı jak firmware pˇrevodn´ıku, tak s´ıt’ového ovladaˇce zaloˇzeného na SocketCAN. Bˇehem testov´ an´ı nedoˇslo ke ztrátˇe ˇzádné zprávy. Z uvedeného srovnán´ı je patrné, ˇze vˇetˇs´ıho zpoˇzdˇen´ı na standardn´ım jádru dosahuje SocketCAN. To je vcelku oˇcekávateln´ y v´ ysledek, jelikoˇz SocketCAN stav´ı na obecné Linuxové s´ıt’ové infrastruktuˇre, naproti tomu LinCAN je se svoj´ı vnitˇrn´ı strukturou front navrˇzen pro specifické potˇreby CAN komunikace. Dalˇs´ı testy i s real-time jádry je moˇzné naj´ıt v ˇclánku [6].

Kapitola 9

Z´ avˇ er V rámci této diplomové pr´ ace byl implentován firmware pro CAN-USB pˇrevodn´ık s mikrokontrolérem LPC1768, kter´ y vyuˇz´ıvá zdrojov´ ych kód˚ u projektu LinCAN. Dále byl pro tento pˇrevodn´ık vytvoˇren s´ıt’ov´ y ovladaˇc do operaˇcn´ıho systému GNU/Linux. Tento ovladaˇc vyuˇz´ıvá SocketCAN, coˇz je souˇcasn´ y CAN subsystém Linuxového jádra. V pr˚ ubˇehu v´ yvoje byly obˇe funkcionality postupnˇe vylepˇsovány a testovány. To vyvrcholilo závˇereˇcn´ ym testován´ım, kde byla ovˇeˇrena korektnost obou ˇreˇsen´ı. Zároveˇ n bylo provedeno základn´ı srovnán´ı ovladaˇce LinCAN a vytvoˇreného ovladaˇce zaloˇzeného na SocketCAN. SocketCAN obsahuje funkcionalitu pro v´ ypoˇcet parametr˚ u d˚ uleˇzit´ ych pro nastaven´ı ˇcasov´ an´ı CAN komunikace. K tomu vˇsak potˇrebuje znát intervaly moˇzn´ ych hodnot tˇechto parametr˚ u, kter´ ych m˚ uˇze ˇradiˇc CAN nab´ yvat. Prvn´ı interakc´ı mezi ovladaˇcem a pˇripojen´ ym pˇrevodn´ıkem je tak poˇzadavek ovladaˇce na zjiˇstˇen´ı tˇechto inteval˚ u. Následnˇe je také nutná funkcionalita pro nastaven´ı ˇradiˇce na vypoˇctené hodnoty ˇcasován´ı. Oba tyto konfiguraˇcn´ı poˇzadavky byly implementov´ any. Po tomto nastaven´ı jiˇz m˚ uˇze prob´ıhat samotn´ y pˇrenos dat mezi ovladaˇcem a pˇrevodn´ıkem. Vylepˇsen´ım by urˇcitˇe byla implemetace nˇekter´ ych dalˇs´ıch konfiguraˇcn´ıch poˇzadavk˚ u. Ze srovn´ an´ı v kapitole testov´ an´ı je patrné, ˇze vˇetˇs´ıho zpoˇzdˇen´ı na standardn´ım jádru dosahuje SocketCAN. To je vcelku oˇcekávateln´ y v´ ysledek, jelikoˇz SocketCAN stav´ı na obecné Linuxové s´ıt’ové infrastruktuˇre, naproti tomu LinCAN je se svoj´ı vnitˇrn´ı strukturou front navrˇzen pro specifické potˇreby CAN komunikace. Urˇcitˇe by dále mˇelo smysl provést obdobné testován´ı na real-time Linuxovém j´ adru nebo se zv´ yˇsen´ım priorit vláken v systému.

53

Literatura [1] J. Corbet, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers. O’Reilly Media, Inc., 3rd edition, 2005. http://lwn.net/Kernel/LDD3/. [2] O. Hartkopp. The CAN networking subsystem of the Linux kernel. In Proceedings of the 13th iCC, 2012. [Online]. Available: http://www.can-cia.org/fileadmin/cia/files/icc/13/hartkopp.pdf. [3] M. Kleine-Budde. SocketCAN – The official CAN API of the Linux kernel. In Proceedings of the 13th iCC, 2012. [Online]. Available: http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf. [4] LPC17xx User manual. Rev. 2, NXP Semiconductors, 19 August 2010. [Online]. Available: http://www.nxp.com/documents/user_manual/UM10360.pdf. [5] J. Nov´ ak. CAN bus a jeho aplikace ve vozidlech. Materiály k pˇredmˇetu Sbˇer a pˇrenos dat. http://measure.feld.cvut.cz/node/443, stav z 3. 5. 2012. [6] M. Sojka and P. P´ıˇsa. Timing Analysis of Linux CAN Drivers. In Proceedings of the 11th Real Time Linux Workshop, 2009. [Online]. Available: http://lwn.net/images/conf/rtlws11/papers/proc/p30.pdf. [7] Processors – ARM. http://www.arm.com/products/processors, stav z 19. 4. 2012. [8] CAN at Real-Time Systems group, DCE FEE CTU. http://rtime.felk.cvut.cz/can/, stav z 3. 5. 2012. [9] Linux USB drivers - Free Electrons. http://free-electrons.com/docs/linux-usb/, stav z 26. 4. 2012. [10] LXR - The Linux Cross Reference. http://lxr.linux.no/. [11] Webové str´ anky projektu OrtCAN. http://ortcan.sourceforge.net/, stav z 3. 5. 2012.

54

Pˇ r´ıloha A

Seznam pouˇ zit´ ych zkratek API Application Programming Interface BSD Berkeley Software Distribution CAN Controller Area network DSP Digital Signal Processor FPGA Field-Programmable Gate Array GPIO General Purpose Input/Output IP Internet Protocol ISA Instruction Set Architecture MAC Media Access Control MCU Microcontroller Unit POSIX Portable Operating System Interface RISC Reduced Insttruction Set Computer TCP Transmission Control Protocol UDP User Datagram Protocol USB Universal Serial Bus

55

Pˇ r´ıloha B

Obsah pˇ riloˇ zen´ eho CD . |-| | |-| | | | | ‘--

docs |-- lmc_cb1-mcu-core-sch.pdf ‘-- vanekjir.pdf lincan |-- build-embedded.sh |-- build-lincan.sh |-- embedded |-- lincan ‘-- omk socketcan-devel

sch´ ema zapojen´ ı HW text t´ eto diplomov´ e pr´ ace inicializaˇ cn´ ı skript pro pˇ reklad pˇ revodn´ ıku inicializaˇ cn´ ı skript pro pˇ reklad LinCAN zdrojov´ e k´ ody pˇ revodn´ ıku zdrojov´ e k´ ody LinCAN adres´ aˇ r sestavovac´ ıho n´ astroje OMK zdrojov´ e k´ ody projektu SocketCAN i s vytvoˇ ren´ ym ovladaˇ cem

56

Linux

Recommend Documents