Download pdf - SPREMLJANJE LOKACIJE VOZILA IN NJEGOVE STATISTIKE …Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del 3 3 OBDII 3.1 Kaj je OBDII OBD je standard

Matej Zorko

SPREMLJANJE LOKACIJE VOZILA IN

NJEGOVE STATISTIKE MOTORJA PREKO

DLANČNIKA – STROJNI DEL

Diplomsko delo

Maribor, maj 2012

SPREMLJANJE LOKACIJE VOZILA IN NJEGOVE

STATISTIKE MOTORJA PREKO DLANČNIKA – STROJNI

DEL

Diplomsko delo

Študent: Matej Zorko

Študijski program: UN SP Računalništvo in informacijske tehnologije

Smer: /

Mentor: red. prof. dr. Matjaž Colnarič

Somentor: asist. mag. Rok Ostrovršnik

i

ii

ZAHVALA

Zahvaljujem se mentorju Matjažu Colnariču za

izkazano pomoč in vodenje pri opravljanju

diplomskega dela. Prav tako se zahvaljujem

somentorju Roku Ostrovršniku.

Posebna zahvala staršem, ki so mi omogočili študij.

iii

Spremljanje lokacije vozila in njegove statistike

motorja preko dlančnika – strojni del

Ključne besede: sledenje, GPS, Bluetooth, dlančnik, OBDII, mikrokrmilnik, ARM,

Cortex-M3, GCC, OpenOCD, statistika motorja, GPRS, vgrajeni sistemi, C++, brezžična

komunikacija, zajemanje podatkov, USB, VCP, microSD.

UDK: 629.11:621.395.44+004.45(043.2)

Povzetek

Delo podrobno predstavi razvoj prototipnega strojnega vmesnika za spremljanje lokacije

vozila in njegove statistike motorja. Podrobno opiše strojne značilnosti, samo aplikacijo,

uporabljena razvojna okolja in knjižice, vmesnike ter implementacije vseh protokolov, ki so

potrebni za komunikacijo v takšnem sistemu.

Sistem je zgrajen okrog ARM-ovega mikrokrmilnika Cortex-M3, ki podatke iz avtomobila

pridobiva preko standardiziranega vmesnika OBDII. Sistem podatke obdela in jih

posreduje dlančniku preko brezžične povezave Bluetooth, po mobilnem omrežju GPRS za

sledenje vozilu v realnem času, jih beleži na spominsko kartico microSD ali posreduje po

vmesniku USB.

iv

Tracking a vehicle’s location and its engine

statistics via PDA – hardware part

Key words: Tracking, GPS, Bluetooth, PDA, OBDII, microcontroller, ARM, Cortex-

M3, GCC, OpenOCD, engine staticstics, GPRS, embedded systems, C++, wireless

communication, data acquisition, USB, VCP, microSD.

UDK: 629.11:621.395.44+004.45(043.2)

Abstract

This diploma thesis presents the development of a prototype hardware device that

interfaces with a vehicle via an OBDII interface and is able to collect engine statistics and

track its location. The thesis thoroughly describes the hardware features of the device, the

application, used development tools and libraries, and presents all the interfaces and

implementations required for communication in such a system.

The system is built around an ARM Cortex-M3 microcontroller, which acquires data from

a vehicle through the standardized OBDII interface. The system processes the data and

forwards it to the PDA via Bluetooth, mobile network for tracking in real-time, records

them on the microSD memory card or transfers them through USB.

v

VSEBINA

1 UVOD ..................................................................................................................... 1

2 PREGLED STANJA ............................................................................................. 2

3 OBDII ..................................................................................................................... 3

3.1 KAJ JE OBDII .......................................................................................................... 3

3.2 KAKO DELUJE .......................................................................................................... 4

3.3 PROTOKOLI IN VMESNIKI .......................................................................................... 5

4 STROJNA OPREMA ........................................................................................... 7

4.1 TISKANO VEZJE IN BLOK SHEMA............................................................................... 7

4.2 POSAMEZNI GRADNIKI ........................................................................................... 10

4.2.1 Osrednji procesor ARM Cortex-M3 .............................................................. 10

4.2.2 Diamex DXM – vmesnik OBDII .................................................................. 11

4.2.3 Bluetooth ....................................................................................................... 11

4.2.4 GPS ................................................................................................................ 12

4.2.5 GPRS ............................................................................................................. 13

4.2.6 USB 2.0 ......................................................................................................... 13

4.2.7 Spominska kartica microSD .......................................................................... 14

4.2.8 Napajanje SMPS ............................................................................................ 15

5 RAZVOJNO OKOLJE ...................................................................................... 16

5.1 PROGRAMSKA IN STROJNA OPREMA ....................................................................... 16

5.2 VZPOSTAVITEV RAZVOJNEGA OKOLJA ................................................................... 18

5.2.1 Nameščanje orodij ......................................................................................... 18

5.2.2 Minimalno izvršilno okolje za C++ ............................................................... 23

5.2.3 Povezovalna skripta – Linker script .............................................................. 27

5.2.4 Eclipse ........................................................................................................... 29

6 PROGRAMSKA OPREMA (ANGL. FIRMWARE) ...................................... 33

vi

6.1 OPERACIJSKI SISTEM .............................................................................................. 33

6.2 PRIDOBIVANJE PODATKOV PREKO VMESNIKA OBDII IN POVEZAVA Z DLANČNIKOM

.............................................................................................................................. 38

6.3 USB IN NAVIDEZNA KOMUNIKACIJSKA VRATA – VCP ........................................... 41

7 REZULTATI IN TESTIRANJE ....................................................................... 45

8 SKLEP ................................................................................................................. 47

9 VIRI, LITERATURA ......................................................................................... 48

10 PRILOGE ............................................................................................................ 50

10.1 SEZNAM SLIK ......................................................................................................... 50

10.2 SEZNAM TABEL ...................................................................................................... 51

10.3 NASLOV ŠTUDENTA................................................................................................ 52

10.4 KRATEK ŽIVLJENJEPIS ............................................................................................ 52

10.5 ZGOŠČENKA Z IZVORNO KODO IN NAČRTI .............................................................. 52

vii

UPORABLJENI SIMBOLI

V volt (enota za napetost)

A amper (enota za tok)

Hz herz (enota za frekvenco)

KHz kiloherz (enota za frekvenco)

MHz megaherz (enota za frekvenco)

viii

UPORABLJENE KRATICE

ADC analogno-digitalni pretvornik (angl. Analog to Digital Converter)

ARM napredne naprave RISC (angl. Advanced RISC Machines)

AT ukazni nabor

CAN protokol za sporazumevanje v omrežju (angl. Controller Area Network)

CDC komunikacijski razred za naprave (angl. Communication Device Class)

CPU centralno-procesna enota (angl. Central Processing Unit)

EOBD evropski OBD

EPA Agencija za zaščito okolja (angl. Environmental Protection Agency)

FAT32 datotečni sistem, tabela za dodeljevanje datotek (angl. File Allocation

Table)

FLASH bliskovni pomnilnik

GCC zbirka razvojnih orodji GNU (angl. GNU Compiler Collection)

I2C protokol za serijsko komunikacijo (angl. Inter-Integrated Circuit)

IDE integrirano razvojno okolje (angl. Integrated Development Environment)

JTAG industrijsko združenje (angl. Joint Test Action Group)

LDO napetostni regulator z nizkim padcem (angl. Low Drop-Out Regulator)

LED svetleča dioda (angl. Light Emitting Diode)

ix

MPU enota za zaščito spomina (angl. Memory Protection Unit)

NMEA Nacionalno pomorsko združenje elektronikov (National Marine

Electronics Association)

OBD On-Board Diagnostics

PID identifikacijska številka parametra (angl. Parameter ID)

PLL fazno ujeta zanka (angl. Phase Locked Loop)

RAM delovni pomnilnik (angl. Random Access Memory)

ROM bralni pomnilnik (angl. Read-Only Memory)

RS-232 standard za serijsko komunikacijo med napravami (angl. Recommended

Standard 232)

SAE Društvo avto-moto inženirjev (angl. Society of Automotive Engineers)

SD spominska kartica Secure Digital

SID servisna identifikacijska številka (angl. Service ID)

SIRF podjetje SiRF Technology

SMPS preklopni napajalnik (angl. Switch-Mode Power Supply)

SPI Serial Peripheral Interface Bus

SRAM statični RAM (angl. Static RAM)

SSP sinhrono zaporedna vrata (angl. Synchronous Serial Port)

x

TAP testni odcep JTAG (angl. Test Access Port)

UART univerzalni asinhroni sprejemnik in oddajnik (angl. Universal

Asynchronous Receiver-Transmitter)

USB vsestransko zaporedno vodilo (angl. Universal Serial Bus)

VCP navidezna komunikacijska vrata (angl. Virtual COM Port)

Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del

1

1 UVOD

Vsakdanjika si več ne znamo predstavljati brez avtomobila. Je naš redni spremljevalec in

obenem prevozno sredstvo, s katerim lažje premagujemo razdalje. Vsak povprečen človek

preživi vsaj del svojega vsakdana v avtomobilu in prevozi na tisoče kilometrov na leto. Po

drugi strani ima z razvojem tehnologije in sodobnim trendom razvite družbe vsakdo dostop

do vsaj ene pametne naprave. Te so postale skoraj tako nepogrešljive kot jekleni konjički.

Z združitvijo teh sodobnih naprav se nam odprejo vznemirljive nove možnosti. Ob

vsakodnevni vožnji nam lahko tak kombiniran sistem analizira vsak prevoženi kilometer,

posreduje podatke o podrobnem delovanju jeklenega konjička, od najbolj osnovnih, kot so

hitrost, obrati motorja, obremenitev in temperatura, do bolj podrobnih, kot so položaj

pedalk, trenutna in povprečna poraba goriva, količina goriva v rezervoarju, pritisk vbrizga,

temperatura vsrkanega zraka in mešanica, navor motorja. S pomočjo GPS-a ustvari profil

terena, ki ga vsakodnevno prevozimo, in nam lahko ponudi najoptimalnejšo rešitev za čim

manjšo porabo goriva in posledično okolju in denarnici prijaznejšo vožnjo. V povezavi z

mobilnim omrežjem dovoli spremljanje vozila in lokacije v realnem času in tako omogoča,

da ob vsakem trenutku vemo, kje se vozilo nahaja in v kakšnem stanju je. Preko povezave

Bluetooth je zagotovljena povezljivost s skorajda vsako pametno napravo in spremljanje

stanja motorja je lahko prikazano v živo.

V tem delu bo predstavljen način izdelave strojnega vmesnika z opisom, kako delujejo vse

bistvene komponente, in njihovo vlogo v celotni zasnovi. Opisan bo postopek razvoja

vgrajene programske opreme, njene zgradbe, implementacije in delovanja v

mikrokrmilniku.


2

2 PREGLED STANJA

Trg kaže zanimanje za izdelke, ki pridobivajo podatke iz avtomobila. Obstajajo že rešitve,

ki so domače ali hobi, masovne in profesionalne. Prevladujejo rešitve za mobilno

platformo Android in iOS s cenenimi kitajskimi vmesniki, saj uporabnik naloži program

avtorja, priključi vmesnik in stvar deluje. Rešitev ima svoje pomanjkljivosti. Manjka ji

kakovosti, prilagodljivosti in je manj odzivna. Programska oprema je polovičarska, zelo

ozko usmerjena in po navadi služi točno določenem namenu, naj si bo prikazu števca,

branju kod ali kot dirkaški pripomoček.

Profesionalne rešitve so prisotne in najbolj izmed teh izstopa ameriško podjetje Kiwi, ki

nudi lastno razvit sistem z možnostjo dokupa prikazovalnikov, ki se namestijo v avtomobil.

ScanGauge ponuja podobne usluge kot prej omenjeno ameriško podjetje, vendar jih trži

kot kompakten avtomobilski računalnik.

Z vidika programske opreme za pametne telefone izstopa aplikacija za Android Torque.

(a)

(b)

(c)

Slika 2.1: Rešitve podjetja PLX (a), Torque za Android (b) in ScanGauge (c)


3

3 OBDII

3.1 Kaj je OBDII

OBD je standard za diagnostiko in spremljanje stanja vozila. Pojavil se je že v 70. in 80.

letih prejšnjega stoletja. Proizvajalci so ga uporabljali predvsem za regulacijo in

spremljanje emisij vozil in diagnozo najrazličnejših težav, povezanih z motorji. S časom se

je nadzor nad motorji razvil močno nad samo osnovno regulacijo in zdaj zajema skoraj

popolni nadzor, spremlja stanje ostalih kritičnih in podpornih delov vozil, kot so zavorni

sistemi, pogonski sistemi, karoserija in ostale naprave.

Z ustanovitvijo agencije EPA (Environmental Protection Agency) leta 1970 so se začeli

uveljavljati standardi, ki so postopno omejevali dovoljene meje izpustov vozil, kar je pri

proizvajalcih sprožilo vgrajevanje senzorjev in regulacijo motorjev za najoptimalnejšo

izgorevanje in posledično nižanje emisij. Leta 1988 je organizacija SAE spisala

dokumente, ki so prvi predlagali standardni vmesnik in delovanje diagnostičnih sistemov

za vozila. EPA je večino teh standardov in priporočil sprejela in prilagodila. Tako se na

začetku leta 1996 pojavi prvi standard za diagnostiko in vzdrževanje vozil OBDII.

Pojavi se tudi EOBD, ki je evropska različica zgoraj omenjenega ameriškega standarda. Z

začetkom 1. januarja 2001 po evropski direktivi

postane OBD obvezen v vseh vozilih, prodanih

na evropskem tržišču, ki za pogon uporabljajo

bencinske motorje, in obvezen za vsa vozila z

motorjem na dizelski pogon z začetkom leta

2004. Na ameriškem tržišču postane obvezen

mnogo prej skupaj z najavo prvega standarda leta

1996.

Slika 3.1: EOBD


4

3.2 Kako deluje

Slika 3.2: Blokovni prikaz potovanja podatkov iz avtomobila preko OBDII do

naprave


5

3.3 Protokoli in vmesniki

OBDII standard sestavlja množica dokumentov, ki predpisujejo in opisujejo vse od oblike

in mer priključkov, električnih signalov, napetosti, protokolov in aplikacijskega sloja do

tega, kje na vozilih naj se nahaja priključek.

Fizični sloj sestavlja standardiziran 16-polni priključek. Tukaj se nahajajo priključki za

napajanje, maso in devet signalnih žic, ki nudijo dostop petim standardiziranim

protokolom, po katerih steče komunikacija z vozilom. Kateri protokol je uporabljen, je

povsem odvisno od proizvajalca vozila, in če želimo imeti dostop do vseh vozil, moramo

implementirati vse protokole, ki so zajeti v standardu, ali samo tistega, za katerega vemo,

da ga potrebujemo.

(a)

(b)

OBDII protokoli

1 PWM

2 VPWM

3 KWP2000

4 CAN 1.1/2.0 250 kbit

5 CAN 1.1/2.0 500 kbit

(c)

Slika 3.3: OBD-priključek (b) z razporeditvijo priključnih sponk (a) in podprti

protokoli (c)


6

Ko vemo, kateri protokol podpira vozilo, lahko stopimo korak višje. V aplikacijskem sloju

so zajeta pravila, kako in na kak način je možna komunikacija med vozilom in njegovimi

podsklopi z diagnostično napravo – torej nami. Predpisana so sporočila, ki se izmenjajo,

njihova oblika, značilnosti protokola z določenim ravnanjem ob napakah, predpisanimi

odzivnimi časi in podobno.

Kot v fizičnem sloju tudi tukaj ni obvezno, katera sporočila podpira vozilo. Spet je vse na

proizvajalcu, da se prosto odloči, kaj bo ponudil. Posledica tega je, da se pojavljajo velike

razlike, saj med tem, ko en model vozila dovoli izpis stanja hitrosti, obratov motorja in

nekaterih drugih postavk, bo drugi model ponudil še informacije o količini goriva, položaju

pedala, trenutni porabi itd.


7

4 STROJNA OPREMA

4.1 Tiskano vezje in blok shema

Zasnovo strojne opreme kaže spodnji diagram. Osnova je mikrokrmilnik LPC1764,

zasnovan na ARM-ovem jedru Cortex-M3. Napajanje, ki se dovaja neposredno iz

avtomobila preko OBDII-priključka, je potrebovalo posebno pozornost. Zaradi majhnosti,

visoke in nepredvidljive vhodne napetosti – ta pri avtomobilih lahko niha, večjega toka in

dveh izhodnih napetosti je bil uporabljen preklopni regulator, ki napetost sprva spusti na

4,5 V, primerno za GPRS-modul, ter nato preko LDO-regulatorja na 3,3 V, primernih za

ostale nizko-napetostne komponente.

Slika 4.1: Blok shema naprave


8

Vezje je bilo narisano v programu za risanje in projektiranje vezij Altium Designer. Altium

Designer je profesionalno orodje za risanje, simuliranje, programiranje ter vizualizacijo

tiskanih vezij in naprav, ki pridejo nanjo.

Tiskano vezje smo izdelali v domači delavnici s fotopostopkom in vse elemente prispajkali

ročno. Zaradi tehničnih omejitev je bilo treba tiskano vezje v prenekaterih segmentih

prilagoditi, npr. pri spajkanju mostičkov, ki povezujejo zgornjo in spodnjo plast tiskanine,

pri postavitvi elementov in podobno, kot pa da bi bilo vezje industrijsko izdelano.

Spodnje slike prikazujejo vezje.

Slika 4.2: Naprava v škatlici z delno prosojnim pokrovom


9

Slika 4.3: 3D-upodobitev vezja, zgornja stran

Slika 4.4: 3D-upodobitev vezja, spodnja

stran

Slika 4.5: Vezje, zgornja stran

Slika 4.6: Vezje, spodnja stran


10

4.2 Posamezni gradniki

4.2.1 Osrednji procesor ARM Cortex-M3

Slika 4.7: Čip mikrokrmilnika v SMD ohišju

Moč 32-bitnega procesorja, visoka stopnja integracije, širok izbor in skromna poraba so

odlike procesorjev ARM. ARM sam ne proizvaja procesorjev, marveč jih licencira

proizvajalcem. Za našo uporabo smo se odločili za NXP-jevo serijo LPC1764

mikrokrmilnika. Je močan procesor, ki se nahaja v 100-pinskem čipu, teče do zavidljivih

100 MHz, je grajen na harvardski

arhitekturi, kar pomeni ločen in hkraten

dostop do programskega in podatkovnega

spomina, 3-stopenjski cevovod in še

dodatno tretjo vodilo za periferijo, s

katero doseže veliko stopnjo

vzporednosti. Vgrajena zaščita kritičnih

odsekov (MPU - Memory Protection

Unit), determinističen odzivni čas

prekinitev, DMA za razbremenitev jedra,

sledilni modul in podpora za lažje

diagnosticiranje in razvoj (JTAG).

Vgrajenih ima 128 KB flash spomina, 32

KB delovnega spomina, USB, Ethernet,

CAN, ADC, I2C, SSP, UART in še bi

lahko naštevali.

Slika 4.8: Blok shema mikrokrmilnika


11

4.2.2 Diamex DXM – vmesnik OBDII

Pri opisu standarda OBDII je bilo povedano, da je treba za uspešno komunikacijo z

vozilom implementirati vsaj en fizičen protokol, če ne več, preden se lahko dokopljemo do

želenih podatkov iz vozila. To je lahko izredno zamudno ter mukotrpno in ne bi prineslo

rezultatov, saj naš cilj ni bil na novo interpretirati in implementirati teh obsežnih

protokolov. Zato smo segli po vmesniku, ki poskrbi za pravilno komunikacijo po podprtem

protokolu avtomobila, kateri koli že je, in tega predstavi na preprost, konsistenten način

preko serijskega vmesnika.

Slika 4.9: Diamex DXM

Komunikacija z modulom teče po običajnem asinhronem serijskem vmesniku (RS-232) z

AT-ukaznim naborom. Modul nas reši fizičnega sloja, ne pa tudi aplikacijskega.

4.2.3 Bluetooth

Kadar je treba komunicirati z dlančniki, pametnimi telefoni ali kakšnimi drugimi

napravami, je samoumevno, da ti podpirajo brezžični način komuniciranja preko Bluetooth

vmesnika.

Da naši napravi dovolimo svobodo brezžičnega komuniciranja, smo izbrali modul, ki

omogoča transparentno komunikacijo z drugimi napravami preko standardnega serijskega

profila (SPP). Modul deluje tako, da ustvari navidezen brezžičen kanal do povezane

naprave in nevidno pretaka poslane podatke med njima. Nastavitev in priprava modula

tečeta preko standardnega serijskega vmesnika (RS-232) z ukaznim naborom AT. Po

uspešni vzpostavitvi povezave pa se poslani podatki neposredno prenašajo med povezano

napravo in modulom.


12

4.2.4 GPS

Global Positioning System ali krajše GPS je sistem za določanje položaja na Zemlji s

pomočjo navigacijskih satelitov. Kljub temu da večina pametnih naprav dandanes že

vsebuje GPS, smo se jo kljub temu odločili vključiti kot samostojen del. GPS-naprave, ki

pridejo z napravami, so lahko nadvse muhaste in imajo različne karakteristike, slab signal

in drugo. Bolj kot to je odtehtalo dejstvo, da naprava ne bi bila več samostojna in bi bila

odvisna od vsega, kar bi bilo priključeno nanjo.

Slika 4.10: GPS modul

Navigacijske posle opravlja Fastraxov ITrax 300 modul, ki se hvali z majhno porabo,

izjemno občutljivostjo in je grajen na osnovi SiRFstarIII platforme. Nudi natančnost

položaja do 1,8 metra natančno in merjenje hitrosti do 0,1 metra na sekundo natančno. Za

delovanje potrebuje anteno, saj ta ni vgrajena. Izbrana je bila aktivna zunanja antena

nasproti cenejšim pasivnim antenam. Razlog je boljša imunost na motnje, z iskanjem

idealnega položaja antene ni težav in zato tudi kakovost odčitkov ne trpi preveč.

Modul je s procesorjem povezan preko standardne serijske povezave (RS-232),

sporazumevanje pa poteka preko binarnega SiRF-vmesnika. Za razliko od tekstovnega

vmesnika NMEA, je binarni SiRF-vmesnik bolj robusten in nudi večji nabor ukazov.


13

4.2.5 GPRS

Napravi dostop do mobilnega interneta omogoča GSM-modul SIM340 podjetja Simcom z

vgrajeno podporo protokolu TCP/IP, ki je osnova interneta. Dostop poteka preko

prvogeneracijskega GPRS (General Packet Radio Service) vmesnika. Spremljanje lokacije

vozila in statistike motorja ni stvar, ki bi potrebovala široko prepustnost, ravno obratno. Po

Sloveniji je pokritost s prvogeneracijsko mobilno mrežno skoraj stoodstotna pri vseh

ponudnikih, kar ne velja za druge generacije mrež.

Slika 4.11: GPRS modul

Modul ne omogoča samo dostopa do mobilnega interneta, ima tudi številne

funkcionalnosti. Pošilja lahko SMS- in MMS-sporočila, izvede klic ali ga sprejeme ter

brska po SIM-kartici kot navaden mobilni telefon. Vse to ima svojo ceno. Nabor ukazov je

ogromen, za delovanje pa okrog sebe postavlja kar nekaj omejitev. Te se vrstijo od

napetostni, tokovnih ter signalnih, in za uspešno priključitev k mobilnemu ponudniku

storitev zahteva SIM-kartico. Ob aktivni povezavi modul zahteva na primer povprečno

0,5 A, v danih trenutkih pa tudi do 2 A toka.

4.2.6 USB 2.0

USB je nastopil kot rešitev težave vseh mogočih priključkov naprav prejšnje generacije.

Standardiziral je priključke, način komuniciranja in rešil težavo zunanjega napajanja

priključenih naprav ter ponudil dodajanje in odstranjevanje naprav med delovanjem. Danes

je USB standard za priključitev raznoraznih naprav na osebne računalnike.

USB-povezavo je naša naprava prvenstveno uporabljala za komunikacijo z računalnikom

med razvojem, saj se predstavi kot navidezna komunikacijska vrata (VCP), na katera se


14

lahko povežemo s terminalom in tako spremljamo dogajanje v napravi ali na njo tudi

vplivamo.

4.2.7 Spominska kartica microSD

Spominska kartica nudi ogromno količino spomina za malo denarja v še manjši velikosti.

Mikrokrmilnik na njo ves čas beleži dnevnik, trenutno pot, statistiko motorja in ostale

stvari.

Slika 4.12: Spominska kartica microSD

Implementiran je FAT32 datotečni sistem, kar pomeni, da lahko kartico vtaknemo v

računalnik in iz nje v trenutku dostopamo do zapisanih podatkov, saj so vsi dnevniki

zapisani kot navadne tekstovne datoteke.


15

4.2.8 Napajanje SMPS

Napajanje avtomobila se črpa iz 12-voltnega akumulatorja. To je dostopno naravnost iz

priključka OBDII, vendar ga je treba regulirati na današnjim čipom bolj uporabnih 3,3

volta.

Večina vezji reguliranje doseže s t. i. linearnimi regulatorji – ti so preprosta vezja, ki

napetost regulirajo tako, da sami nase prevzamejo razliko med vhodno in želeno izhodno

napetostjo. Ta značilnost jih dela zelo potratne, saj se izgublja ogromno moči, ki nato ni

koristno uporabljena, ker ta nikoli ne pride do bremena. Z višanjem napetostne razlike in

večanjem toka do bremena se te izgube samo večajo.

Slika 4.13: Blok shema osnovnega preklopnega regulatorja z grafom izhodne

napetosti in tokov preko tranzistorja in diode

Preklopni regulator, ki smo ga uporabili mi, doseže izkoristke od 80 odstotkov in naprej.

Preklopni element v preklopnih regulatorjih za razliko od linearnih regulatorjev ne deluje v

linearnem režimu, kjer se zgublja ogromno moči, temveč deluje v preklopnem režimu –

preklopni element je popolnoma odprt ali popolnoma zaprt, s čimer se popolnoma izogne

linearnemu delovanju. Ker se med preklopi zgubi odločno manj energije, so izkoristki

primerno boljši.


16

5 RAZVOJNO OKOLJE

Pri razvoju vgrajenih sistemov so potrebna tako programska kot strojna razvojna orodja.

Razvojno okolje je razdeljeno na gostiteljski sistem in ciljno platformo. Celoten ekosistem

je prikazan spodaj.

Slika 5.1: Prikaz celotnega ekosistema

Razvoj je potekal na prosto dostopnih odprtokodnih rešitvah, tako programskih kot strojnih

orodij.

5.1 Programska in strojna oprema

Programski jezik – programiranje je potekalo s programskim jezikom C++, ki je

nekakšen standard za razvijanje v vgrajenih sistemih. C++ je izjemno neposreden

in močan jezik, ki programerju daje izjemno kontrolo nad dogajanjem v programski


17

kodi. Novejši jeziki se pretvarjajo v vmesno izvršilno kodo, olajšajo in

razbremenijo programerja »trivialnih« stvari, kot je alokacija spomina, in ga ščitijo

pred samim seboj, zato pogosto ne dovolijo posegov v nižje nivoje. V primerih, v

katerih je procesorska moč obilna in spomin navidezno neomejen, najdejo svoje

mesto. Vgrajeni sistemi imajo v nasprotju z zunanjimi zelo omejene vire in so

pogosto potrebni nizkonivojski posegi do strojne opreme in čim manj motoviljenja

in omejevanja s strani programskega jezika. C++ je nadgradnja programskega

jezika C in doda objektno programiranje, bolj zahtevno preverjanje tipov (angl.

type-safety) in predvsem predloge (angl. templates), ki so zelo uporabne tudi v

vgrajenih sistemih.

Prevajalnik – izbira tukaj ni težka. Najbolj razširjena in uporabljena je zbirka

programov in orodji za razvoj GCC (GNU Compiler Collection). Ta zbirka je

zmožna proizvesti kodo za več arhitektur in procesorjev, PC, AVR, Itanium,

najbolj pomembno pa je, da omogoča prevajanje kode za ARM-ovo Cortex-M3-

jedro. Večja izbira se pokaže pri vnaprej pripravljenih kompletih, t. i. »bundlih«.

To so programski paketi, ki vsebujejo predpripravljen prevajalnik in njegova orodja

s knjižicami, tipično je to standardna C-knjižica ali bolj znana kot stdlib, za točno

določeno ciljno arhitekturo in razvojni operacijski sistem. V našem primeru je

ciljna arhitektura ARM in razvojni operacijski sistem Microsoft Windows. Odločili

smo se za komplet Yagarto, ki v času pisanja vsebuje najnovejši prevajalnik in

orodja z osnovnimi knjižicami.

Razvojno okolje (IDE) – za razvojno okolje je bil izbran programski paket

Eclipse. Eclipse je zelo znan odprtokodni programski projekt, ki je v osnovi zgrajen

na Javi in teče na vseh večjih operacijskih sistemih. Zaradi izjemne prilagodljivosti

in široke podpore skupnosti je zelo priljubljen in preko vtičev podpira vse večje in

tudi manjše programske jezike in orodja. Z nameščenim dodatkom CDT se

spremeni v odlično zastonjsko razvojno okolje za programski jezik C/C++, ki smo

ga uporabili tudi mi.

Programator oz. Debugger – vsi ARM-ovi mikroprocesorji imajo odlično

podporo za razhroščevanje. To poteka preko standardnega priklopa, imenovanega

JTAG (Joint-Test-Action-Group). S tem zagotavljajo interoperabilnost vseh naprav,

ki se držijo tega standarda, in omogočajo, da je možno naprave med seboj verižiti


18

ter do vseh dostopati in jih manipulirati med razvojem z enim samim priklopom.

Program, ki podpira komunikacijo na tak način, je OpenOCD. OpenOCD je

vmesnik med strojnim debuggerjem in razvojnim okoljem na računalniku, t. i.

»frontendom« (slov. ospredje). Ta pretvarja ukaze razvojnega okolja (Eclipse) v

ukaze, ki jih razume strojni vmesnik, ta pa te ukaze nato pretvori v električne

signale, ki jih razume kos silicija na procesorju in omogoča razhroščevanje in

vpogled v stanje celotnega procesorja.

5.2 Vzpostavitev razvojnega okolja

V tem poglavju bo predstavljen način vzpostavitve celotnega razvojnega okolja za

mikroprocesor LPC1764. Opisan bo postopek namestitve orodji, programov na računalnik

in priklop ter nastavitev strojnih orodji za programiranje preko razvojnega okolja Eclipse.

Za konec bo prikazan kratek program, ki vzpostavi minimalno delujoče okolje za

programski jezik C++ z vsemi implementiranimi sistemskimi klici in povezovalnimi

skriptami (angl. linker script). Rezultat bo izvršilna datoteka, ki jo bo nato možno

sprogramirati na čip.

5.2.1 Nameščanje orodij

Eclipse je grajen na Javi, zato potrebuje izvršilno okolje Java. Najprej namestimo Java

Run-time Environment (JRE) ali Java Development Kit (JDK) Standard Edition. Pozorni

moramo biti na različico. Če je Eclipse za 32-bitno platformo, naj bo Java tudi, v

nasprotnem primeru nastopi več nepričakovanih težav. V našem primeru smo uporabili

32-bitni različici obeh.

Slika 5.2: Razvojna orodja


19

Nadaljujemo s kompletom prevajalnika in orodij Yagarto [6]. Pomembno je, da namestimo

paket na pot brez vsebovanih presledkov, saj večina orodij dela preko ukazne vrstice in

dodatni presledki napačno porazdelijo podane argumente ter orodja potemtakem ne

delujejo pravilno.

Po nameščenem prevajalniku je treba namestiti enega izmed pomembnejših orodij

razvijalca, to je debugger, ter v našem primeru tudi programator. OpenOCD je tisti, ki je

vez med prej nameščenimi razvijalskimi orodji in ciljno strojno opremo, procesorjem

ARM. V osnovi OpenOCD izvira iz okolja Linux in je razširjen v obliki izvorne kode, kot

večina odprtokodnih projektov njegovega tipa, vendar ga je mogoče uporabiti tudi na OS

Windows. Za to je potrebno vmesno okolje Cygwin ali vsaj njegove podporne knjižice –

možno si ga je predstavljati kot prej omenjeno Java izvršilno okolje. V času pisanja ni bilo

zadostne podpore Cortexovemu M3-jedru oz. je bilo v razvojnih različicah takrat

odpravljenih mnogo napak, najnovejša stabilna različica pa je krepko zastarela, zato je bilo

treba orodje iz izvorne kode prevesti. Kako se to stori in katere knjižice so za to potrebne,

je opisano na uradni strani [5]. Trenutno je že na voljo posodobljena različica in jo je

možno dobiti brez lastnega prevajanja iz izvorne kode, v obliki izvršilne datoteke za

Windows.

Predenj se lahko OpenOCD priključi in sporazumeva s strojno opremo na vezju, je treba

opisati, kaj se vse nahaja za tistim priključkom na vezju. JTAG so zasnovali tako, da je

lahko vsak fizično prispajkan čip, ki podpira ta standard, vezan v isto verigo in tako lahko

na vezju za vsak procesor različnih proizvajalcev kompleksno programirljivo vezje CPLD

in FPGA, flash spomin dostopa preko enakega vtiča. Ti razni čipi so v JTAG-standardu

poimenovani kot »TAPs«. OpenOCD za vsak kos strojne opreme potrebuje takšen opis,

kjer določimo lastnosti vmesnika, po katerem se sporazumeva, kje se kaj nahaja in kateri

čip je tisti, ki ga želimo manipulirati. Opisani so v t. i. nastavitveni datoteki –

»configuration file«, ki jo podamo ob zagonu programa. Priložene so nastavitve za par

širše znanih razvojnih ploščic in procesorjev. V slednjih smo našli tudi naš mikroprocesor

LPC1764. Naša nastavitvena datoteka je predstavljena v nadaljevanju.

1. set CCLK 12000 2. 3. # mrw: "memory read word", returns value of $reg 4. proc mrw {reg} {


20

5. set value "" 6. mem2array value 32 $reg 1 7. return $value(0) 8. } 9. 10. telnet_port 4444 11. gdb_port 3333 12. 13. interface ft2232 14. ft2232_device_desc "Amontec JTAGkey" 15. ft2232_layout jtagkey 16. ft2232_vid_pid 0x0403 0x6010 17. 18. #ft2232_latency 25 19. 20. # NXP LPC1764 Cortex-M3 with 128kB Flash and 16kB+16kB Local On-Chip SRAM, 21. 22. # LPC17xx chips support both JTAG and SWD transports. 23. # Adapt based on what transport is active. 24. #source [find target/swj-dp.tcl] 25. 26. proc swj_newdap {chip tag args} { 27. set tran [transport select] 28. if [string equal $tran "jtag"] { eval jtag newtap $chip $tag $args} 29. if [string equal $tran "swd"] { eval swd newdap $chip $tag $args } 30. } 31. 32. if { [info exists CHIPNAME] } { 33. set _CHIPNAME $CHIPNAME 34. } else { 35. set _CHIPNAME lpc1764 36. } 37. 38. # After reset the chip is clocked by the ~4MHz internal RC oscillator. 39. # When board-specific code (reset-init handler or device firmware) 40. # configures another oscillator and/or PLL0, set CCLK to match; if 41. # you don't, then flash erase and write operations may misbehave. 42. # (The ROM code doing those updates cares about core clock speed...) 43. # 44. # CCLK is the core clock frequency in KHz 45. if { [info exists CCLK ] } { 46. set _CCLK $CCLK 47. } else { 48. set _CCLK 4000 49. } 50. if { [info exists CPUTAPID ] } { 51. set _CPUTAPID $CPUTAPID 52. } else { 53. set _CPUTAPID 0x4ba00477 54. } 55. 56. #delays on reset lines 57. adapter_nsrst_delay 200 58. jtag_ntrst_delay 200 59. 60. reset_config trst_and_srst separate 61. 62. #jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID 63. swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID 64. 65. set _TARGETNAME $_CHIPNAME.cpu 66. target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME 67. 68. # LPC1764 has 16kB of SRAM In the ARMv7-M "Code" area (at 0x10000000) 69. # and 16K more on AHB, in the ARMv7-M "SRAM" area, (at 0x2007c000). 70. $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x4000 71. 72. # LPC1764 has 128kB of flash memory, managed by ROM code (including a 73. # boot loader which verifies the flash exception table's checksum). 74. # flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum] 75.


21

76. set _FLASHNAME $_CHIPNAME.flash 77. flash bank $_FLASHNAME lpc2000 0x0 0x20000 0 0 $_TARGETNAME \ 78. lpc1700 $_CCLK calc_checksum 79. 80. # Run with *real slow* clock by default since the 81. # boot rom could have been playing with the PLL, so 82. # we have no idea what clock the target is running at. 83. jtag_khz 100 84. 85. $_TARGETNAME configure -event reset-init { 86. # Do not remap 0x0000-0x0020 to anything but the flash (i.e. select 87. # "User Flash Mode" where interrupt vectors are _not_ remapped, 88. # and reside in flash instead). 89. # 90. # See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit

description 91. # Bit Symbol Value Description Reset 92. # value 93. # 0 MAP Memory map control. 0 94. # 0 Boot mode. A portion of the Boot ROM is mapped to address 0. 95. # 1 User mode. The on-chip Flash memory is mapped to address 0. 96. # 31:1 - Reserved. The value read from a reserved bit is not defined. NA 97. # 98. # http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user 99. 100. mww 0x400FC040 0x01 101. 102. jtag_khz 500 103. } 104. 105. $_TARGETNAME configure -event gdb-detach { 106. 107. echo "gdb mi je rekel papa, jaz tut!" 108. 109. shutdown 110. 111. } 112. 113. # gdb setup 114. 115. #gdb_memory_map enable 116. #gdb_flash_program enable 117. 118. # be done with configuration 119. # 120. 121. init

V 1. vrstici povemo, da naš čip teče z osnovno frekvenco 12 MHz. Videti je malo, ampak

je to frekvenco mogoče pomnožiti s pomočjo vgrajenega PLL-množilnika vse do največje

dovoljene, ki jo čip premore. Ta vrednost je bila izbrana tudi zato, ker USB potrebuje 48-

megaherčni takt za delovanje in je točen 4-kraten množilnik naše osnovne frekvence.

Vrstici 10 in 11 narekujeta OpenOCD-ju, naj posluša na vratih 4444 in 3333 za promet

telnet in povezavo razhroščevalnika gdb, ki ga podpira Eclipse in bo prikazan pozneje.

Od vrstice 13 do 70 nastavimo vmesnik tipa FT2232, po katerem poteka komunikacija do

mikroprocesorja in je čip podjetja FTDI, ki preko USB-vmesnika podpira komunikacijo


22

preko JTAG-protokola, in kakšno razporeditev signalov na tem čipu naj pričakuje. V tem

primeru je naše orodje združljivo z Amontecovim JTAGkey-jem.

Vrstici 77 in 78 opišeta flash pomnilnik, ki se nahaja na mikroprocesorju in omogoči

sprotno računanje varnostne kode programa pred programiranjem, saj naš program v

nasprotnem primeru ne bi tekel na mikroprocesorju. NXP je vnesel v čip zaščitni

mehanizem, ki napačno naloženim ali pokvarjenim programom preprečuje izvedbo in v

tem primeru preide iz uporabniškega programa na vgrajen bootloader, ki omogoča

programiranje čipa preko serijskih vrat. Naše razvojno okolje samodejno ne podpira

računanja te varnostne kode, zato pustimo, da za to nevšečnost poskrbi OpenOCD.

Vrstica 83 pove, naj komunikacija sprva teče s taktom 100 KHz.

Vrstici 105 do 111 določata dogodek, ki ob primeru zaključka »debug« seje v razvojnem

okolju preneha razhroščevanje na mikroprocesorju in ga fizično ponastavi – »resetira«.

Zadnja, 121. vrstica je zelo pomembna. Vse zgoraj opisane nastavitve uveljavi in se poveže

na čip.

S to nastavitveno datoteko se lahko uspešno povežemo na mikroprocesor in začnemo z

delom.


23

5.2.2 Minimalno izvršilno okolje za C++

Da lahko programski jezik pravilno začne izvajati glavni program, večinoma poznan kot

vstopna točka »main«, zapisan v izvorni kodi, zahteva nekaj predpriprav. Okolje pričakuje,

da veljajo določene predpostavke. Te so:

nastavitev kazalca sklada;

spremenljivke, ki so jim bile določene začetne vrednosti, naj bodo inicializirane,

to so predvsem statične globalne spremenljivke in konstante;

spremenljivke, ki naj imajo začetno vrednost nič, to so predvsem statične globalne

spremenljivke brez eksplicitno določene vrednosti;

zagnati konstruktorje globalnih statičnih objektov.

Poleg tega pristavi procesor Cortex-M3 dodatne zahteve:

inicializacijska vrednost sklada naj se pojavi v prvi besedi programskega spomina;

za skladom naj bo tabela petdesetih kazalcev na funkcije, ki se naj izvršijo ob

določenih prekinitvah, t. i. vektorska tabela prekinitev.

Temu naštetemu po navadi rečemo zagonsko okolje ali »startup environment«. Dosti krat

je to izvorna koda, pisana v zbirniku, vendar jo je prav lahko napisati tudi v golem C++.

1. #include "system_defs.h" 2. 3. //----------------------------------------------------------------------------- 4. 5. extern "C" { 6. 7. #define WEAK __attribute__((weak)) 8. 9. extern unsigned int _data; 10. extern unsigned int _edata; 11. extern unsigned int _etext; 12. extern unsigned int __bss_start; 13. extern unsigned int __bss_end__; 14. extern unsigned int start_ctors; 15. extern unsigned int end_ctors; 16. 17. extern unsigned int _stack; 18. 19. extern int __libc_init_array(); 20. 21. extern int main(); 22. 23. //----------------------------------------------------------------------------- 24. 25. void INTERRUPT Default_Handler(); 26. 27. void INTERRUPT Reset_Handler(); 28. void WEAK INTERRUPT NMI_Handler(); 29. void WEAK INTERRUPT HardFault_Handler();


24

30. ... 73. void INTERRUPT CANActivity_IRQHandler(); 74. 75. //----------------------------------------------------------------------------- 76. // Vector tabela 77. //----------------------------------------------------------------------------- 78. typedef void (INTERRUPT * const INTR_FUNCTION)(); 79. 80. extern "C" INTR_FUNCTION vector_table[] __attribute__((section(".__cortex_vectors"))) USED

= 81. { 82. (INTR_FUNCTION)(&_stack), 83. Reset_Handler, 84. NMI_Handler, /* NMI, Handler */ 85. HardFault_Handler, /* Hard, Fault Handler, */ 86. ... /*...izrezano...*/ 133. USBActivity_IRQHandler, /* 49: USB, Activity

*/ 134. CANActivity_IRQHandler /* 50: CAN, Activity

*/ 135. }; 136. 137. //----------------------------------------------------------------------------- 138. 139. void Reset_Handler() 140. { 141. // prekopiraj vrednosti inicializiranega razdelka .data v ram 142. // 143. unsigned int *src = &_etext; 144. unsigned int *dest = &_data; 145. unsigned int *end = &_edata; 146. 147. if(dest != src) 148. { 149. while(dest != end) 150. { 151. *dest++ = *src++; 152. } 153. } 154. 155. // postavi .bss na 0 156. // 157. dest = &__bss_start; 158. end = &__bss_end__; 159. 160. while(dest != end) 161. { 162. *dest++ = 0; 163. } 164. 165. // pokliči c'torje 166. // 167. //__libc_init_array(); 168. 169. for(unsigned int *cp = &start_ctors; cp < &end_ctors; cp++) 170. { 171. ((void (*)())*cp)(); 172. } 173. 174. 175. // gremo v main! 176. // 177. main(); 178. 179. // nikoli ne bi smeli sem, ampak.. 180. 181. while(true) 182. { 183. nop(); 184. } 185. }


25

186. 187. //----------------------------------------------------------------------------- 188. 189. void NMI_Handler() 190. { 191. while(true) 192. { 193. nop(); 194. } 195. } 196. 197. //----------------------------------------------------------------------------- 198. 199. void HardFault_Handler() 200. { 201. uint32_t sp; 202. 203. asm volatile( 204. "TST LR, #4\n\t" 205. "ITE EQ\n\t" 206. "MRSEQ %0, MSP\n\t" 207. "MRSNE %0, PSP\n\t" 208. : "=r"(sp) 209. ::); 210. 211. uint32_t *hardfault_args = (uint32_t *)sp; 212. 213. volatile unsigned int stacked_r0 = ((unsigned long) hardfault_args[0]); 214. volatile unsigned intstacked_r1 = ((unsigned long) hardfault_args[1]); 215. volatile unsigned intstacked_r2 = ((unsigned long) hardfault_args[2]); 216. volatile unsigned intstacked_r3 = ((unsigned long) hardfault_args[3]); 217. volatile unsigned intstacked_r12 = ((unsigned long) hardfault_args[4]); 218. volatile unsigned intstacked_lr = ((unsigned long) hardfault_args[5]); 219. volatile unsigned intstacked_pc = ((unsigned long) hardfault_args[6]); 220. volatile unsigned intstacked_psr = ((unsigned long) hardfault_args[7]); 221. 222. while(true) 223. { 224. nop(); 225. } 226. } 227. 228. //----------------------------------------------------------------------------- 229. 230. void Default_Handler() 231. { 232. while(true) 233. { 234. nop(); 235. } 236. } 237. 238. //----------------------------------------------------------------------------- 239. // Aliasi 240. //----------------------------------------------------------------------------- 241. 242. #pragma weak MemManage_Handler = Default_Handler 243. #pragma weak BusFault_Handler = Default_Handler 244. #pragma weak UsageFault_Handler = Default_Handler 245. #pragma weak SVC_Handler = Default_Handler 246. ... 284. #pragma weak USBActivity_IRQHandler = Default_Handler 285. #pragma weak CANActivity_IRQHandler = Default_Handler 286. 287. //----------------------------------------------------------------------------- 288. };

Sprva vključimo datoteko »system_defs.h«, ki vsebuje standardne tipe in funkcije, ki smo

jih uporabili v našem programu, in definiramo atribut »WEAK«. Ta atribut pove


26

povezovalniku, da v primeru definirane funkcije kje drugje v programu z istim imenom ne

pride do napake, ampak se prejšnja povezava pozabi in obvelja močnejša, tista brez

šibkega atributa.

Od 9. do 21. vrstice iz povezovalne skripte, ki bo predstavljena kasneje, izvozimo

spremenljivke, kje se začnejo določeni odseki programa in kam so bili dodeljeni. Definira

se še nekaj funkcij, predvsem je to vstopna točka »main«.

Od 25. do 73. vrstice smo definirali prekinitvene funkcije.

Pri vrsticah 80 do 135 sestavimo polje kazalcev na funkcije, ki se bodo izvršile ob

določenih vpadnih točkah ob prekinitvah. To je t. i. vektorska tabela. Postavljena je bila v

svoj odsek programa in bila označena kot uporabljena ali »used«, ker jedro

mikroprocesorja zahteva, da se ta tabela nahaja na začetku programskega spomina in ne

sme manjkati. To bo uresničeno s pomočjo povezovalnika.

Z začetkom 139. vrstice je definirana funkcija, ki se izvrši ob vklopu mikroprocesorja. V

njej vzpostavimo osnovno okolje za delovanje programa. Prekopiramo inicializirane

vrednosti spremenljivk iz programskega spomina flash na mesto, kjer se te spremenljivke

nahajajo v delovnem pomnilniku, podobno storimo za neinicializirane statične

spremenljivke ali tiste, ki imajo začetno vrednost nič, nato pa še pokličemo vse

konstruktorje globalnih objektov in jih tako inicializirajo.

V 177. vrstici smo poklicali vstopno funkcijo uporabniškega programa »main«.

Vrstice 189, 199 in 230 določijo funkcije ob kritičnih prekinitvah jedra. Te si ob možnosti

zapišejo vzrok za napako in ustavijo izvedbo programa.

Na koncu, od 243. vrstice naprej smo določili vse prekinitve kot šibke dvojnike privzete

prekinitvene funkcije. To storimo za primer, kjer pride do izvršitve prekinitve in uporabnik

ni vnaprej določil funkcije, ki bi obdelala to prekinitev. Program nam v takšnem primeru

lahko odtava v neznano in sproži nenavadno delovanje, ki ga je zelo težko izslediti.

Privzeta funkcija program zaustavi in lažje sklepamo, kje je vzrok napake.


27

5.2.3 Povezovalna skripta – Linker script

Povezovalnik ali »linker« je orodje, ki več izvršljivih objektov poveže in jih sestavi v eno

izvršljivo celoto – program. To povezovanje izvede po vnaprej pripravljenem receptu,

povezovalni skripti, tako da natanko ve, kaj naj izloči iz posamezne izvršilne datoteke in

kje naj konča ta kos v končni izvršljivi celoti oz. našem programu.

1. /***********************************************************************/ 2. /* */ 3. /* ROM.ld: Linker Script File */ 4. /* */ 5. /***********************************************************************/ 6. ENTRY(vector_table) 7. 8. /* Memory Definitions */ 9. MEMORY 10. { 11. ROM (rx) : ORIGIN = 0, LENGTH = 0x00020000 12. RAM (rw) : ORIGIN = 0x10000000, LENGTH = 0x00004000 13. } 14. 15. STACK_LOC = (0x10000000 + 0x00004000); 16. 17. /* Section Definitions */ 18. SECTIONS 19. { 20. /* first section is .text which is used for code */ 21. .text 0x0000000 : 22. { 23. KEEP(*startup-*.o (.__cortex_vectors)) /* Startup vectors first*/ 24. *startup-*.o (.text .text.*) /* Startup code */ 25. *(.text .text.*) /* remaining code */ 26. *(.gnu.linkonce.t.*) 27. *(.glue_7) 28. *(.glue_7t) 29. *(.gcc_except_table) 30. *(.rodata) /* read-only data (constants) */ 31. *(.rodata*) 32. *(.gnu.linkonce.r.*) 33. } > ROM 34. 35. . = ALIGN(4); 36. 37. /* .ctors .dtors are used for c++ constructors/destructors */ 38. /* added by Martin Thomas 4/2005 based on Anglia Design example */ 39. .ctors : 40. { 41. PROVIDE(start_ctors = .); 42. KEEP(*(.init_array)) 43. KEEP(*(.ctor*)) 44. PROVIDE(end_ctors = .); 45. } >ROM 46. 47. .dtors : 48. { 49. PROVIDE(start_dtors = .); 50. KEEP(*(.fini_array)) 51. KEEP(*(.dtor*)) 52. PROVIDE(end_dtors = .); 53. } >ROM 54. 55. . = ALIGN(4); 56. /* mthomas - end */ 57. 58. /* .ARM.exidx is sorted, so has to go in its own output section. */


28

59. 60. PROVIDE(__exidx_start = .); 61. 62. .ARM.exidx : { 63. *(.ARM.exidx* .gnu.linkonce.armexidx.*) 64. } >ROM 65. 66. PROVIDE(__exidx_end = .); 67. 68. 69. _etext = . ; 70. PROVIDE (etext = .); 71. 72. /* .data section which is used for initialized data */ 73. .data : AT (_etext) 74. { 75. _data = .; 76. *(.data) 77. *(.data.*) 78. *(.gnu.linkonce.d*) 79. SORT(CONSTRUCTORS) /* mt 4/2005 */ 80. } > RAM 81. 82. . = ALIGN(4); 83. _edata = . ; 84. PROVIDE (edata = .); 85. 86. /* .bss section which is used for uninitialized data */ 87. .bss (NOLOAD) : 88. { 89. __bss_start = . ; 90. __bss_start__ = . ; 91. *(.bss) 92. *(.gnu.linkonce.b*) 93. *(COMMON) 94. . = ALIGN(4); 95. } > RAM 96. 97. . = ALIGN(4); 98. __bss_end__ = . ; 99. PROVIDE (__bss_end = .); 100. 101. heap_end = .; 102. 103. _end = . ; 104. PROVIDE (end = .); 105. 106. .stack STACK_LOC : 107. { 108. PROVIDE (_stack = .); 109. } > RAM 110. 111. /* Stabs debugging sections. */ 112. ... 113. ... 114. }

Skripta ima nekoliko čudno obliko, vendar ima začetek in konec.

Skripta je sestavljena iz odsekov in znotraj nje se nahajajo ukazi. Ti so lahko tudi prosto

zunaj nje. Skripta po korakih opiše, katere stvari sodijo kam in kateri simboli se naj

pojavijo in definirajo v končni povezani datoteki. Končna izvršilna datoteka bo imela

takšen videz, kot je navedeno v skripti.


29

Odsek »MEMORY« v 9. vrstici navede dve regiji – to je prostor, ki ima naveden začetek

in konec na nekem mestu v naslovljivem prostoru naprave. Ti sta ROM in RAM ali

programski in delovni spomin. Določi njeni dolžini in mesti.

15. vrstica določi začetek sklada v spominu.

V 18. vrstici so navedeni odseki končnega programa, ki bo sestavljen iz vseh manjših

vhodnih izvršljivih objektov. Začne se s prej predpostavljenimi prekinitvenimi vektorji, ki

so bili navedeni v zagonu okolja C++. Ti bodo dani na začetek programskega spomina na

naslov nič, nato sledi ostala izvršljiva koda brez določenega zaporedja.

Tem sledi odsek »ctors« ali daljše C++ konstruktorji in »dtors« ali destruktorji pri vrstici

39 in 47. Imena so poljubna, vendar splošno znana. Vsebuje naslove vseh funkcij, ki jih je

treba izvesti ob zagonu okolja.

Sledijo odseki za inicializacijo spremenljivk, uporabljenih v programu, »bss« in »data«, in

njihova mesta v delovnem spominu ter naslovi, kje se nahajajo. Hkrati se rezervira prostor

v delovnem pomnilniku, da jih je nato možno v zagonskem okolju pravilno postaviti in

inicializirati.

5.2.4 Eclipse

V razvojnem okolju smo ustvarili nov projekt za drugo ciljno arhitekturo, pod menijem

»File«, »New...«, »Project...«, »C++« in izberemo »C++ Project« in nato »Cross GCC

Project«. V lastnostih projekta je treba nastaviti naš prevajalnik in orodja, poti, zastavice in

parametre.


30

Slika 5.3: Eclipse, ustvarjanje novega projekta

Pod lastnostmi projekta, meni »Project«, nato »Properties« pojdimo na levem delu okna k

»C/C++ Build« in »Settings«. Pod jezičkom »Tool Settings« izberemo »Cross Settings« in

vnesemo predpono prevajalniških orodij in pot do njih.

Nastavitve so razdeljene in ločijo med seboj kodo, spisano za C in C++. Nastavitve so za ta

razlog dvojne, za »Cross GCC Compiler« in »Cross G++ Compiler«. Med seboj se ločijo v

samo nekaterih pogledih. Priporočeno je, da ob spremembi nastavitev za simbole, iskalne

poti in predprocesor iz enega prevajalnika hkrati spremenijo tudi za drugega in obratno.

Optimizacije naj bodo vklopljene skupaj z najvišje možnim nivojem za razhroščevanje –

»Optimization – Optimize More -O2« ter »Debugging – Debug Level Maximum«.

Optimizacijo smo izklopili le ob iskanju napak in podobnih nevšečnostih, v nasprotnem

primeru obseg generirane kode hitro preseže svoje mere. Višji nivo za razhroščevanje le

vključi več informacij v program za razhroščevalnik in se ne pozna v končnem programu,

ki je naložen na čip.

Slika 5.4: Eclipse, nastavitve projekta

Za pravilen prevod je nujno nastaviti dodatne zastavice pod »Miscellaneous«, dodali smo:

1. -mcpu=cortex-m3 –mthumb –std=gnu99 ; pod C prevajalnik 2. -mcpu=cortex-m3 -mthumb -std=gnu++0x-fno-exceptions -fno-rtti ; pod C++ prevajalnik


31

Te povedo, za katero arhitekturo in s kakšnimi ukazi naj prevajalnik prevede kodo. Za C++

smo uporabili nov standard C++0x, ki nudi nekaj novih konstruktov, ki so bili uporabljeni

v izvorni kodi.

Pomembno je izključiti vse zagonske in standardne knjižice, ki jih prevajalnik sam vključi

v program. Te knjižice niso namenjene za naš vgrajen sistem in strojno opremo.

Pomembno je, da sta uporabljena naše prej predstavljeno minimalno zagonsko okolje za

C++ in povezovalna skripta. V nasprotnem primeru prevajalnik v program vključi obilico

nepotrebne in nepomembne kode in zlahka presežemo kapaciteto programskega spomina

mikrokrmilnika, ki je zelo omejen.

Izklopiti je treba:

standardne knjižice,

standardne zagonske datoteke,

C++ izjeme,

RTTI – Run-Time Type Information.

Pod »Cross G++ Linker« in »General« je treba obkljukati »No startup or default libs

(-nostdlib)«. S tem izločimo vse standardne knjižice, ki bi jih povezovalnik avtomatično

vključil v naš program. S tem razlogom smo morali sami določiti, katere knjižice bomo

povezali v program. Katere smo dodali pod možnostjo »Libraries«, predstavljamo v

nadaljevanju – vrstni red je pomemben.


32

Slika 5.5: Eclipse, nastavitev knjižic povezovalnika

Tako kot prej za prevajalnik je treba nastaviti dodatne zastavice pod »Miscellaneous«.

1. -mcpu=cortex-m3 -mthumb -T${ProjDirPath}/LPC1764-flash.ld

Prvi par navede enake pogoje kot pri prevajalniku, zadnji pa določi, naj povezovalnik

ravna po naši prej predstavljeni povezovalni skripti.

Za lažje in hitrejše programiranje smo v Eclipse vključili OpenOCD kot zunanje orodje v

orodni vrstici.

Slika 5.6: Uspešno prevajanje programa Slika 5.7: Programiranje na čip


33

6 PROGRAMSKA OPREMA (ANGL. FIRMWARE)

6.1 Operacijski sistem

Vgrajeni sistemi si ne morejo privoščiti zelo zahtevnih operacijskih sistemov in

kompleksnega modela razvrščanja opravil. Zahteve so zelo različne – v našem primeru ni

potrebe po izrecni realno-časovni izvedbi, koda je namenoma prilagojena tako, da

izkorišča načelo sodelovalnega načina in ne potrebuje prekinitev za delovanje. To je

olajšalo veliko stvari in preskočilo veliko težav. Ni treba skrbeti za posamezne niti in

deljenje virov, to pa ne pomeni, da lahko na vse takoj pozabimo. V realnosti sta vedno

aktivni dve navidezni niti, prva nit je naš uporabniški program v normalnem teku in

izvršuje opravila, ki niso časovno kritična, druga pa so prekinitve, ki jih pošlje jedro ali

periferija ob raznih dogodkih – npr. sprejetje podatkov na serijskih vratih, potek

sistemskega časovnika, potrebna intervencija z USB-napravo itd.

S pravilno sinhronizacijo in pazljivim ščitenjem kritičnih odsekov proti nepričakovanim

prekinitvam uspešno nadziramo položaj. Ta preprostost ima svojo ceno, saj se lahko ob

istem času izvaja le eno opravilo, in če to potrebuje čas ali čaka na kakšno operacijo, je ta

zapravljen. Pogosto je veliko časa zapravljenega v zakasnilnih funkcijah pri krmiljenju

zunanjih naprav ali periferije, kjer bi se med tem časom lahko izvajalo drugo opravilo.

Hitrejše kot je jedro, več je mrtvega, zapravljenega časa in trpi učinkovitost. Do določene

meje je mogoče te stvari omiliti s prekinitvami, npr. ob sprejemu podatkov od periferije se

ta nabira v vmesnih »rezervoarjih« ali »bufferjih« in se zakasnitve vključijo samo v

primeru, da se ti zapolnijo.

Naš sistem vsebuje zelo preprost razvrščevalnik opravil. Opravila so spravljena v seznamu,

po katerem se ta izvajajo zaporedno, ko pride na konec, se spet izvede prvo opravilo v

vrsti. Tak sistem je splošno znan kot »round-robin« ali krožno razvrščanje. Ni nikakršnih

prioritet. Opravilo pa ima možnost razvrščevalniku dinamično sporočati, čez koliko časa


34

naj bo spet sproženo. Ta razširitev sistemu nudi izredno preprostost in lahko obvladovanje

proženja opravil, saj ta z vpetjem v čas ni več nekaj abstraktnega, ampak je merljiv in del

opravila.

Slika 6.1: Delovanje razvrščevalnika

Vsako opravilo je objekt, ki nosi svoje spremenljivke, in je samostojno. S tem je ločeno od

podrobnosti razvrščevalnika in njegovega delovanja ter sistema izvajanja. Edini pogoj, ki

ga razvrščevalnik zahteva, je glavna izvršilna točka opravila, ki mora biti definirana, da bo

razvrščevalnik opravilo sprejel in razvrščal. Ta vstopna točka je funkcija brez parametrov

in vrača število, ki pove, čez koliko časa naj razvrščevalnik znova zažene opravilo.

Negativna vrednost opravilo odstrani iz nadaljnjega razvrščanja, pozitivna zamakne

njegovo naslednje izvajanje za najmanj toliko milisekund, vrednost nič pa pokliče opravilo

ob naslednjem najhitrejšem možnem času brez zakasnitve.

Naslednje opravilo v seznamu

Preverjanje stanja opravila

Opravilo pripravljeno na izvršitev

• ni zakasnitve ali je potekla

Opravilo izvršeno

• vrne novo stanje, odstranitev ali čakanje


35

Slika 6.2: Struktura in vpetost razvrščevalnika opravil z opravili in podsklopi

Slika 6.2 prikazuje približen oris vpetosti operacijskega sistema in njegovih podsklopov v

celotno okolje, ter prikazuje njihovo medsebojno povezanost in odvisnost - drugi gradniki

so bili odstranjeni zaradi preglednosti.

class Class Model

Scheduler

- gs_Instance: Scheduler

- m_Tasks: SchedulerTask* ([max_tasks])

- max_tasks: uint = 10 {readOnly}

- Add(SchedulerTask*) : bool

+ GetInstance() : Scheduler *

- Remove(SchedulerTask*) : void

+ Run() : void

- Scheduler()

- ~Scheduler()

SchedulerTask

# run_at: Time::time_t

# slot: int

+ IsRunnable() : bool

+ IsScheduled() : bool

+ operator()(void) : int

+ Remove() : void

+ RunIn(Time::time_t) : void

+ Schedule(uint) : bool

+ SchedulerTask()

+ ~SchedulerTask()

SysNVIC

+ Disable(IRQn) : void

+ Enable(IRQn) : void

+ SetPriority(IRQn, Priority) : void

+ SysNVIC()

+ ~SysNVIC()

«enumeration»

SysNVIC::Priority

Extreme = 0

Normal = 15

Idle = 31

High = (Normal - 1)

Higher = (High - 1)

Highest = (Higher - 1)

Low = (Normal + 1)

Lower = (Low + 1)

Lowest = (Lower + 1)

System

- m_ClockSourceInfo: ClockSource_t

+ NORETURN: int

+ NORETURN: int

+ SysTick_Period: int = 10 {readOnly}

+ Boot() : void

+ Die(char*) : void

+ Die() : void

+ GetInstance() : System *

+ SetClock(ClockSource, uint, ushort, PLLConfig_t*) : HRESULT

- SetPeripheralClocks() : void

- StopMainPLL() : void

- System()

+ ~System()

«struct»

System::ClockSource_t

+ ClockDiv: int

+ ClockHz: int

+ FlashClocks: byte

+ PLL: PLLConfig_t

+ PLLValid: bool

+ Source: ClockSource

«struct»

System::

PLLConfig_t

+ M: int

+ N: int

«enumeratio...

System::

ClockSource

InternalRC = 0

MainOsc = 1

RTCOsc = 2

Time

- m_TimeMill iseconds: volatile time64_t

+ Delta(time_t) : time_t

+ GetInstance() : Time *

+ Now() : time_t

+ Now32() : time32_t

+ Now64() : time64_t

- Tick(int) : void

- Time()

- ~Time()

«friend»

- SysTick_Handler() : void

LEDBlinkyTask

- m_Set: bool

+ LEDBlinkyTask()

+ ~LEDBlinkyTask()

+ operator()() : int

BlueLinkTask

- aquisition_table: uint ([10][2])

- aquisition_table_count: uint

- m_BLBuffer: smartbuf<byte, 64>

- m_Connected: bool

+ BlueLinkTask()

+ ~BlueLinkTask()


+Source+PLL

-m_ClockSourceInfo

-m_Tasks


36

Potek zagona napraveO

per

acijs

ki s

iste

mSi

stem

Up

ora

bn

iško

o

kolje

Main() BootC++ zagonsko okolje

Nastavitev takta, notranjih naprav, zunanjih vrat, ipd...

Zagon uspel Zaustavi delovanjeNE

Zagon operacijskega sistema

DA

Postavitev razreda Time

in ostalih odvisnih

komponent

Dodajanje uporabniških opravil

Izvrševanje opravil

USB Virtual COM Port

OBDII, Bluetooh, GPS in ostale

naprave

Slika 6.3: Potek zagona naprave

Naprava se ob zagonu začne izvajati v t. i. »reset vektorju«, to je posebno mesto v

procesorju, kjer se ob vklopu prične izvajanje vprogramirane kode, in vzpostavi minimalno

zagonsko okolje, ki je potrebno za programski jezik C++.

Pot nadaljuje do vstopne točke »main«, v kateri se sistem prvič vzpostavi preko funkcije

»Boot«. V njej se zgodi najnižja inicializacija strojne opreme, kjer se dodelijo privzeti

parametri za celoten sistem – sem spadajo osnovni in periferni takt, takt branja iz

notranjega flash pomnilnika, notranjih naprav, zunanjih vrat oz. »portov«. Vzpostavijo se

zunanje naprave in VCP-protokol preko USB-vrat.

Zagon operacijskega sistema poteka hitro, saj je zelo lahek z ne veliko odvisnosti. Vklopijo

se sistemska ura in podsklopi, ki se jih koristi za sledenje realnemu času (angl. »wall

clock«) in razvrščanju opravil.

Nato sistem preide v zadnjo fazo, kjer se dodajo uporabniška opravila za izvajanje in

požene razvrščevalnik.


37

Slika 6.4: Osrednja opravila in razvrščevalnik

V sistemu živijo štiri osrednja opravila, ki skrbijo za delovanje sistema. Opravilo, ki čaka

in opravlja z zunanjo povezavo na napravo preko vmesnika Bluetooth, je »BlueLinkTask«.

Zraven tega skrbi za pridobivanje, tolmačenje in pošiljanje podatkov iz avtomobila preko

vmesnika Bluetooth k povezanem dlančniku. V to opravilo je vpeto največ naprav in

dogajanja. Spodnja slika prikazuje povezave med njimi.

Slika 6.5: Sestava in odvisnosti opravila BlueLinkTask

class Class Model

SchedulerTask

BlueLinkTask

- aquisition_table: uint ([10][2])

- aquisition_table_count: uint

- m_BLBuffer: smartbuf<byte, 64>

- m_Connected: bool

+ BlueLinkTask()

+ ~BlueLinkTask()


IOInterface

- m_IORead: IOReadCallback

- m_IOWrite: IOWriteCallback

- m_Param: void*

+ IOInterface()

+ ~IOInterface()

# IORead(char*, int) : int

# IOReadWrapper(char*, int, void*) : int

# IOWrite(char*, int) : int

# IOWriteWrapper(char*, int, void*) : int

+ SetCallbacks(IOReadCallback, IOWriteCallback) : void

+ SetReadCallback(IOReadCallback) : void

+ SetWriteCallback(IOWriteCallback) : void

«property get»

+ GetParam() : void *

«property set»

+ SetParam(void*) : void

SchedulerTask

LEDBlinkyTask

- m_Set: bool

+ LEDBlinkyTask()

+ ~LEDBlinkyTask()


SchedulerTask

TestTask

- m_BTOk: bool

- m_BTTimeout: int

- m_FlushTime: int

- m_GpsLogFile: FileStream

- m_OBDLogFile: FileStream

- m_TextLogFile: FileStream


+ TestTask()

+ ~TestTask()

FileStream

- m_Access: Access

- m_File: FIL

- m_FileSize: uint

- m_IsOpen: bool

- m_Mode: Mode

- RETRIES: uint = 1 {readOnly}

+ Close() : void

+ FileStream()

+ FileStream(char*, Mode, Access)

+ ~FileStream()

+ Flush() : void

- Initialize() : void

+ IsOpen() : bool

+ Open(char*, Mode, Access) : bool

+ Read(void*, int) : int

+ Seek(int, SeekPosition) : int

+ Size() : uint

+ Tell() : uint

+ Write(void*, int) : bool

+ WriteString(char*) : bool

SDCard

+ ADDR_ERR: byte = (1 << 5) {readOnly}

+ CRC_ERR: byte = (1 << 3) {readOnly}

+ DATA_ERROR_TOKEN_MASK: byte = 0x0F {readOnly}

+ ERASE_ERR: byte = (1 << 4) {readOnly}

+ ERASE_RESET: byte = (1 << 1) {readOnly}

+ IDLE_STATE: byte = (1 << 0) {readOnly}

+ ILL_CMD: byte = (1 << 2) {readOnly}

+ m_Initialized: bool

- m_Interface: SDInterfaceSPI

+ m_SDHC: bool

+ m_SDResponse: byte ([8])

+ m_SDVersion: byte

+ PARAM_ERR: byte = (1 << 6) {readOnly}

+ SD_BLOCK_SIZE: uint = 512 {readOnly}

+ SD_TIMEOUT: byte = 0xFF {readOnly}

+ SD_TIMEOUT_VALUE: int = 0xFFFF {readOnly}

+ START_BIT: byte = (1 << 7) {readOnly}

+ START_BLOCK: byte = 0xFE {readOnly}

- DummyClocks(int) : void

+ GetInfo() : SDCardInfo_t &

+ GetInstance() : SDCard *

- GetResponse(SDResponse) : byte

+ IsCardPresent() : bool

+ IsReady() : bool

+ Read(SD_BLOCK, uint) : bool

- ReadDataBlock(byte*, int) : SDDataBlockStatus

+ Reset() : void

- SDCard()

+ ~SDCard()

- SendCommand(SDCommand, uint32_t, SDResponse) : byte

- SendCommand(SDAppCommand, uint32_t, SDResponse) : byte

+ Write(SD_BLOCK, uint) : bool

- WriteDataBlock(byte*, int) : SDDataBlockStatus

«enumeratio...

SDCard::

SDCommand

CMD0 = 0

CMD8 = 8

CMD9 = 9

CMD10 = 10

CMD16 = 16

CMD17 = 17

CMD24 = 24

CMD55 = 55

CMD58 = 58

CMD59 = 59

«union»

SDChecksum::<anonymous>

+ m_Checksum: uint

+ m_Checksum16: uint16_t

+ m_Checksum8: byte

SDDiskDriv e

- m_FATFS: FATFS

+ ChDir(char*) : bool

+ GetInstance() : SDDiskDrive *

+ IsMounted() : bool

+ ListDir(char*) : bool

+ Pwd(char*, int) : void

- SDDiskDrive()

+ ~SDDiskDrive()

SDInterface

+ ChipSelect(bool) : void


+ SDInterface()

+ ~SDInterface()

+ Write(void*, int) : int

SDInterfaceSPI

- m_SSP: LPC_SSP_TypeDef*

+ HighSpeed() : void

+ LowSpeed() : void


+ SDInterfaceSPI()

+ ~SDInterfaceSPI()

- SetupSPI(int) : void

+ Write(void*, int) : int

Accelerometer

- m_Address: uint8_t = 0x1C {readOnly}

- m_I2C: LPC_I2C_TypeDef*

- Accelerometer()

+ ~Accelerometer()

+ GetInstance() : Accelerometer *

- ReadRegister(AcceleroReg, void*, int) : bool

+ ReadSensor() : void

- TransferRegister(AcceleroReg, char*, int, bool) : bool

- WriteRegister(AcceleroReg, void*, int) : bool

ATCommandInterp

- m_EOL: stringbuf<5>

- m_EOLAlt: stringbuf<5>

- m_LineBuf: smartbuf<char, 120>

- m_LineLen: int

- m_ResponseBuf: smartbuf<char, 120>

- m_SCResponseList: smartlist<response_entry, 4>

# m_VerboseOutput: bool

+ ATCommandInterp(char*, char*)

+ ~ATCommandInterp(void)

# FlushBackBuffer() : void

+ LastLine() : char *

+ NextLine() : char *

+ SendCommand(char*, response_list*, int) : int

+ SendCommand_RegisterResponse(char*, stringutil::StringMatch) : void

+ WriteLine(char*) : bool

BluetoothDev ice

- CON_PIN: uint = 12 {readOnly}

- CON_PORT: uint = 2 {readOnly}

- m_CommandMode: bool

- m_State: BTState

- m_Timeout: int

- m_UART: LPC_UART_TypeDef*

- m_UARTRxBuf: CFifoBuffer<byte, uint, 64>

- MODE_PIN: uint = 26 {readOnly}

- MODE_PORT: uint = 1 {readOnly}

- RESET_PIN: uint = 25 {readOnly}

- RESET_PORT: uint = 1 {readOnly}

- AutoBaud() : void

- BluetoothDevice()

+ ~BluetoothDevice()

+ Connected() : bool

- DetectDisconnect(char*, int) : void

- GetCurrentState(response_list*) : BTState

+ GetInstance() : BluetoothDevice *

+ GetMode() : bool

+ GetVersion() : char *

# IOReadWrapper(char*, int, void*) : int

# IOWriteWrapper(char*, int, void*) : int

+ IsConnected(bool) : bool

+ Pairable() : bool

+ RecieveData(char*, int) : int

+ Reset() : void

+ SendCommand(char*, response_list*, int) : int

+ SendData(char*, int) : bool

- SetupUART(int) : void

+ SwitchMode(bool) : void

- WaitForBT() : bool

«property get»

+ GetState(response_list*) : BTState

«friend»

- UART2_IRQHandler() : void

SchedulerTask

CommandShell

- m_InputBuffer: smartbuf<char, 128>

- CommandShell()

+ ~CommandShell()

+ DeviceInput(char*, int) : void

- DeviceOutput(char*, int) : void

+ GetInstance() : CommandShell *

+ HandleCommand(char*) : void


- Print(char*, ...) : void

- Print(char*, int) : void

SchedulerTask

GpsDev ice

- FAULT_PIN: uint8_t = 19 {readOnly}

- FAULT_PORT: uint8_t = 1 {readOnly}

- m_Info: GpsInfo_t

- m_SiRF: SiRFProtocol


- ON_PIN: uint8_t = 20 {readOnly}

- ON_PORT: uint8_t = 1 {readOnly}

- RESET_PIN: uint8_t = 18 {readOnly}

- RESET_PORT: uint8_t = 1 {readOnly}

- s_RxBuffer: smartbuf<byte, 50>

+ GetGPSInfo() : GpsInfo_t

+ GetInstance() : GpsDevice *

- GpsDevice()

+ ~GpsDevice()

- NMEASend(char*) : void


- ParseSiRFMessage() : void

+ Reset() : void

+ TurnOff() : void

+ TurnOn() : void

«friend»


OBDDev ice

- m_OBDDump: FileStream


- RESET_PIN: uint = 21 {readOnly}

- RESET_PORT: uint = 1 {readOnly}

- s_RxBuffer: CFifoBuffer<byte, uint, 120>

- DeviceReady() : bool

# FlushBackBuffer() : void

+ GetBatteryVoltage() : int

+ GetInstance() : OBDDevice *

+ IOReadWrapper(char*, int, void*) : int

+ IOWriteWrapper(char*, int, void*) : int

+ OBDDevice()

+ ~OBDDevice()

+ Reset() : void

+ SendOBDCommand(char*, byte*, int) : int

- SetupUART(int) : void

«friend»


SiRFProtocol

- m_Buffer: SiRFBuffer

- m_LastError: SiRFError

- m_Message: SiRFMessage

- MAX_MESSAGE_SIZE: uint = 120 {readOnly}

- CalculateChecksum(byte*, int) : ushort

+ Compose(SiRFMessage*, smartbuf_base<char>&) : int

+ Digest(byte*, uint) : int

+ SiRFProtocol()

+ ~SiRFProtocol()

«property get»

+ GetLastError() : SiRFError

+ GetMessage() : SiRFMessage &

-m_OBDDump

-m_SiRF

-m_Interface


38

Naslednje opravilo je kot dnevnik. »LoggerTask« si zapisuje opravljeno pot, stanje

naprave in avtomobila ter jih sproti shranjuje na vstavljeno SD pomnilniško kartico, iz

katere je možno te podatke nato pridobiti v obliki navadnih tekstovnih datotek iz katere

koli bralne naprave, saj se podatki zapisujejo na standardni datotečni sistem FAT32.

Za povezavo preko vmesnika USB je ob živem izpisu dogajanja na napravi na voljo

osnovna konzola, s pomočjo katere je možno brskati po vstavljeni SD spominski kartici in

z njo manipulirati do osnovne mere. Te naloge nase prevzame »CommandShellTask«.

Najosnovnejšo nalogo pa kljub temu opravlja »LEDBlinkTask«, ki nam vizualno ob

različnih stanjih naprave enako različno sporoča te informacije preko preprostega utripanja

dvobarvne LED-diode. Preko tega utripanja lahko hitro ugotovimo, ali naprava deluje

pravilno.

6.2 Pridobivanje podatkov preko vmesnika OBDII in povezava z

dlančnikom

Za začetek poglejmo, kako v principu poteka komunikacija med našo napravo in

avtomobilom preko vmesnika OBDII.

ECU #1

ECU #2

ECU #3

čas

Poizvedbaod naprave

Odgovor

Odgovor

Odgovor

Poizvedbaod naprave

Poizvedbaod naprave

OBDII Protokol (KWP2000, CAN, VPWM, Kline, …)

Slika 6.6: Potek komunikacije po vmesniku OBDII


39

Komunikacija poteka po principu poizvedb. Naša naprava po podprtem protokolu pošlje

poizvedbo avtomobilu in ta v doglednem času odgovori. V primeru da odgovora ni po

določenem času, smatra, da poslana poizvedba ni podprta.

Na drugi strani komunikacijske linije v avtomobilu čaka vgrajen računalnik, ki razume in

se sporazumeva po standardu OBDII. Temu s krajšavo pravimo ECU ali angl. »Engine

Control Unit«. Kot je razvidno iz skice, jih po navadi na isti komunikacijski liniji sedi več,

saj avtomobil sestavlja več ločenih in na videz samostojnih podsklopov, ki so med seboj

povezani in komunicirajo v mreži. Ti računalniki imajo dostop do notranjih podatkov, ki se

pretakajo po avtomobilu in jih nato prevedejo v standardno obliko in pošljejo do naše

naprave, kot je predpisano po standardu OBDII.

Naša naprava uporablja vmesnik za interpretacijo nižjega sloja protokola OBDII in nam

vrača ter pošilja izluščene podatke. Preko vmesnika tako neposredno dostopamo do

aplikacijskega sloja protokola. Naprava z vmesnikom komunicira preko serijskih vrat z

znanim ukaznim naborom AT.

Aplikacijski sloj je dokaj preprost. Sestavljajo ga poizvedbe, te potujejo od testne naprave

– nas do vseh ECU-jev v avtomobilu, nato tisti, ki podpirajo takšno poizvedbo, odgovorijo.

Poizvedba je sestavljena iz t. i. »service ID-ja« in »parameter ID-ja«, okrajšano »SID« in

»PID«.

Tabela 6.1: Poizvedba OBDII

Byte 1

SID

Byte 2

PID

0x01 0x0C

S podatki iz zgornje tabele pošljemo poizvedbo v skupino podatkov za pogonski del in

diagnostiko ter zahtevamo podatke o vrtljajih motorja. Računalnik v avtomobilu to zahtevo

sprejeme in nam vrne podatke, predstavljene v tabeli 6.2.


40

Tabela 6.2: Odgovor na poizvedbo OBDII

Byte1

SID

Byte 2

PID

Byte 3

Data A

Byte 4

Data B

0x41 0x0C 0x0B 0xF5

Vrnil nam je odgovor o pogonskem delu in diagnostiki, kot kaže zgornja tabela. Prvi bajt

se razlikuje od poslanega le v šestem bitu, ki označuje odgovor. Drugi je identičen, zadnja

dva pa vsebujeta na dve polovici razdeljeno 16-bitno vrednost o obratih motorja. Da

izluščimo kodirano vrednost, je treba to razdeljeno vrednost združiti.

Vrednosti smo združili in jih delili s štiri, saj je vrednost kodirana kot tolikokrat večja od

dejanske, ter dobili končne obrate motorja. Komunikacija z vmesnikom za pridobitev te

zgoraj prikazane vrednosti je videti tako:

1. DIAMEX DXM1 v1.9 2. 3. >0100 4. SEARCHING... 5. >010C 6. 41 0C 0B F5

Modul se sprva prijavi s sporočilom, s katerim vemo, da je pripravljen. S prvim ukazom v

tretji vrstici požene notranjo prepoznavo OBDII komunikacijskega protokola avtomobila –

to se zgodi le prvič, za tem pa lahko sledijo naše poizvedbe neposredno k avtomobilu, saj

bo modul primerno prekodiral vso komunikacijo, ki teče med napravo in avtomobilom.


41

6.3 USB in navidezna komunikacijska vrata – VCP

USB je serijski protokol. Njegove največje prednosti so razširjenost, kompaktnost, nudi

hitro podatkovno povezavo tako kot napajanje v enem priključku, priključitev in odklop

naprave brez ponovnega zagona in je predvsem uporabniško prijazen.

Ta uporabniška prijaznost je za ceno kompleksnejše strukture in razvijanja iz razvijalske

plati mnogo zahtevnejša od prejšnjih tehnično preprostejših vmesnikov. Prejšnji vmesniki

so bili predpisani do največ fizičnega sloja, torej dimenzije priključkov in napetostni

nivoji, in so nadaljnje višje sloje prepuščali razvijalcem. USB je stopil korak in več dlje.

Predpisal je, kako naj poteka komunikacija – protokolarni del in standardiziral nekatere

najpogostejše aplikacijske sloje, kot so tipkovnice, miške, naprave za shranjevanje

podatkov ipd. Med njimi so tudi naša navidezna komunikacijska vrata. S tem je bilo

omogočeno, da naprave na različnih platformah ob prvem vklopu delujejo takoj brez

posebej potrebnih proizvajalčevih gonilnikov ali dodatne opreme.

Mikrokrmilnik, ki je bil uporabljen pri nas, že vsebuje nižjeravenski strojni vmesnik, ki je

potreben za sporazumevanje z gostiteljem, kot je USB-naprava.

Ta vmesnik skrbi za najosnovnejše operacije in omogoča:

popolno podporo specifikaciji USB 2.0,

podporo 32 fizičnim oz. 16 logičnim končnim točkam (angl. endpoints),

podporo večim tipom prenosov, Control, Bulk, interrupt in isochronous,

SoftConnect, DMA, dinamični pomnilniki za USB-pakete itn.

Slika 6.7: USB-naprava v LPC176x


42

USB deluje na osnovi pip in transakcij. Gostitelj, po navadi je to računalnik, pošilja

transakcije napravi ali napravam, ki so priključene nanj. Naprava ne more nikoli začeti

komunikacije z gostiteljem, temveč vedno le odgovarja na pozive, ki jih generira gostitelj.

Te se pošiljajo v okvirih, ki se ponavljajo vsako milisekundo. Če naprava ne sme začeti

nobene transakcije, kako potem spravi podatke k računalniku? Tu ločimo dva glavna tipa

transakcij, tip »IN« in tip »OUT«. S slednjo gostitelj pošlje podatke k napravi, s prvo pa

periodično povpraša napravo, ali ima kaj podatkov za poslati v smeri gostitelja. Kako

pogosto je možno poslati ali prejeti podatke in v kakšnem roku, je določeno s tipi

prenosov. Ti so lahko za veliko količino podatkov, ki niso časovno občutljivi, torej se par

milisekund več ali manj ne bo poznalo – te imenujemo prenosi tipa »bulk«. Za realno-

časovne, kot so avdio in video, se uporablja »isochronous«, za naprave, ki se prožijo in

obveščajo gostitelja o raznih dogodkih »interrupt« – sem spadajo tipkovnice, miške ipd.

Zadnji tip »control« je upravljalni kanal in je prvi tip komunikacije, ki je vzpostavljen med

gostiteljem in napravo. Po njej tečejo statusni podatki, prva enumeracija naprave in razne

nastavitve.

Slika 6.8: Pipe in končne točke Slika 6.9: Transakcije

Zelo pomemben korak je enumeracija naprave. Tukaj se naprava predstavi gostitelju s

posebno razvejano strukturo, ki lahko traja preko več transakcij in se imenuje »device

descriptor«. Ta vsebuje podatke, ki se tičejo podprte različice USB-standarda, ki se ga

naprava drži: proizvajalčeva identifikacijska koda, koda naprave in serijska številka (s temi

gostitelj naprava


43

je možno poslej napravi dopisati gonilnike s strani operacijskega sistema), od števila

konfiguracij, ki jih naprava podpira, ali je napajana s strani gostitelja ali ima samostojno

napajanje in koliko toka potrebuje, kakšna je naprava, v kateri razred spada, koliko ima

končnih točk in kakšnih tipov so itn.

Slika 6.10: Opis naprave gostitelju (angl. device descriptor)

Naša naprava se predstavi kot navidezna serijska vrata v posebnem razredu naprav,

imenovanem komunikacijski razred naprav ali angl. »Communications Device Class –

CDC«. Ta tip gonilnika je privzeto vključen v operacijski sistem Windows in druge. To

pomeni, da ni treba razvijati ločenih gonilnikov, da bi naprava delovala na teh operacijskih

sistemih – dodati je treba le posebno namestitveno datoteko »INF«, ki operacijskemu

sistemu pove, naj naši napravi dodeli gonilnik za navidezna serijska vrata.

Slika 6.11: Navidezna serijska vrata v upravitelju naprav

Naloga naše naprave za pravilno delovanje navideznih vrat je pravilno odzivanje na

zahteve, ki jih sproti pošilja gostitelj prek transakcij. Gostitelj bo napravi preko transakcije

»OUT« pošiljal podatke, ki so poslani serijskim vratom v operacijskem sistemu, in


44

periodično pošiljal povpraševanje po podatkih, ki jih želi naprava poslati na navidezna

serijska vrata v smeri operacijskega sistema, kjer bodo potem na voljo aplikacijam, ki tam

tečejo. Nadalje naprava dobi posebej določene zahteve, ki opisujejo način in karakteristike

serijske povezave, stanje serijske povezave in podobno.

Slika 6.12: Opis naprave za razred CDC

Po uspešno zadovoljenih zahtevah, tako tehničnih kot programskih, so rezultat nova

navidezna vrata v operacijskemu sistemu. Na njih se je možno priklopiti s katerim koli

terminalom ali preko programske kode odpreti serijska vrata ter se po njih sporazumevati z

napravo. Spodaj je prikaz izpisa konzole, ki med delovanjem naprave prikazuje statusna

sporočila in delovanje naprave v živo.

Slika 6.13: Izpis iz naprave v živo preko USB-vmesnika na terminalu


45

7 REZULTATI IN TESTIRANJE

Po dolgotrajnem razvoju, raziskovanju, pridobivanju znanja in zabavnem testiranju je bil

cilj dosežen. Naprava deluje tako, kot je bilo načrtovano. Uspelo nam je samostojno razviti

napravo, ki se je zmožna povezati na avtomobil katere koli znamke in pridobiti iz njega

relevantne podatke, jih pretolmačiti in poslati preko brezžičnega komunikacijskega

vmesnika Bluetooth na pametni telefon, ki jih uporabniku nato predstavi na primeren

način.

V napravo je bilo vključenih še veliko dodatnih naprav, ki posredujejo dodatne koristne

informacije in napravi dajo dodano vrednost. S samostojnim GPS-vmesnikom pridobiva

geolokacijske in površinske podatke in preko zunanje antene omogoča robustnejšo

delovanje ter večjo imunost na motnje. Povezava na mobilni internet preko GPRS-modula

odpre možnosti analize in sledenja avtomobila v realnem času. Povezljivost preko

standardnega in majhnega mikroUSB-vmesnika in podpora shranjevalnim pomnilniškim

karticam SD z implementiranim datotečnim sistemom FAT32 zaključita uporabniku

prijazno napravo, s katere je možno sneti pridobljene podatke in jih analizirati na več kot le

en način.

Testiranje je potekalo v več fazah. Zgrajena sta bila dva prototipa, narisanih obilo

podsklopov ter vezij in napisane veliko kode. Predenj smo lahko začeli testirati na

avtomobilih, je bilo treba načrtovati in narisati vezje v namenskem programu, to vezje

razviti in prispajkati. Naslednji korak je bil spoznati procesor in ustvariti trdno podlago za

nadaljnji razvoj programske opreme na čipu – minimalno zagonsko okolje ipd. Ker je

razvoj za pametni telefon potekal vzporedno, je bilo razvito pomožno vezje in spisan

program za računalnik, ki je do takrat simuliral napravo in pošiljal testne podatke na

dlančnik. To je zelo pospešilo razvoj. Po uspešno postavljenih temeljih smo lahko začeli z

drugo fazo, ki je bila najprijetnejša in najtežavnejša – realno testiranje na vozilih in delo na


46

terenu. Tam je bilo odpravljenih največ napak in porabljenih največ ur iskanja in

odpravljanja težav.

Razvoj je spremljalo število zapletov in težav, tako strojnih kot programskih, saj tako

obširen projekt, kot smo si ga zadali, nikoli ne mine brez težav. Z obilo volje in jasnim

ciljem nam je uspelo premagati vse ovire in dokončati tako napravo kot aplikacijo za

mobilni telefon.


47

8 SKLEP

Ob pisanju diplomske naloge smo pridobili veliko novih izkušenj in spoznanj. V veliki

meri je prispevala k razširjenju znanja, tako programerskega kot strojnega,

elektrotehničnega in razvojnega.

Spoznali smo nove arhitekture, poglobili svoje znanje o delovanju strojne opreme,

pridobili izkušnje z razumevanjem že dandanes samoumevnega protokola USB,

pomnilniških kartic SD in datotečnega sistema FAT32 itd.

Pri razvoju smo naleteli na številne prepreke. Začelo se je že pri risanju in načrtovanju

vezja ter izbiri komponent. Zaradi stroška smo se odločili, da prototipna vezja izdelamo in

prispajkamo sami, ne glede na dejstvo, da je vezje dvostransko in ga ni preprosto sestaviti.

Pri razvoju vgrajenih sistemov in delu na terenu nasploh je bilo potrebne veliko

kreativnosti. Včasih je bilo zelo preproste težave zelo težko rešiti, za druge je bilo

potrebnih več ur ali tudi nekaj dni. Implementacija prej naštetih protokolov, vmesnikov in

knjižnic je bila zelo težavna, vendar nam kljub temu ni žal, da smo izbrali ta projekt, saj so

znanje in izkušnje, ki smo jih s tem pridobili, vse odtehtali.


48

9 VIRI, LITERATURA

[1] Jan Axelson. USB Complete: The Developer's Guide, 2009.

[2] Joseph Yiu. The Definitive Guide to the ARM Cortex-M3, 2010.

[3] ARM Limited. Cortex-M3 Techical Reference Manual, 2010.

[4] Altium Designer, uradna spletna stran [Spletni vir]. Dostopno na:

http://www.altium.com [1. 12. 2011].

[5] OpenOCD, uradna spletna stran [Spletni vir]. Dostopno na:

http://openocd.sourceforge.net/ [1. 12. 2011].

[6] Yagarto, uradna spletna stran [Spletni vir]. Dostopno na:

http://www.yagarto.de/ [1. 12. 2011].

[7] NXP Semiconductor. LPC1764 Datasheet, Rev. 7–5. april 2011 [Spletni vir].

Dostopno na:

http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pd

f [1. 12. 2011].

[8] NXP Semiconductor. LPC1700 User Manual, Rev. 2–19. avgust 2010 [Spletni

vir]. Dostopno na: http://www.nxp.com/documents/user_manual/UM10360.pdf

[1. 12. 2011].

[9] Diamex DXM, različica 1.0. Dostopno na: DIAMEX-DXM1_english.pdf [1.

12. 2011].

[10] On-board diagnostics. Wikipedia – 19. april 2011 [Spletni vir]. Dostopno na:

http://en.wikipedia.org/wiki/On-board_diagnostics [1. 12. 2011].

[11] Bluetooth. Wikipedia – 10. marec 2011 [Spletni vir]. Dostopno na:

http://en.wikipedia.org/wiki/Bluetooth [1. 12. 2011].

[12] Rayson. BTM-222 – 11. oktober 2005 [Spletni vir]. Dostopno na:

http://www.vgj.pl/allegro/btm222_datasheet.pdf [1. 12. 2011].

[13] OpenOCD. User Guide – 1. april 2011 [Spletni vir]. Dostopno na:

http://openocd.berlios.de/doc/html/index.html [1. 12. 2011].

http://www.altium.com/

http://openocd.sourceforge.net/

http://www.yagarto.de/

http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf

http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf

http://www.nxp.com/documents/user_manual/UM10360.pdf

http://en.wikipedia.org/wiki/On-board_diagnostics

http://en.wikipedia.org/wiki/Bluetooth

http://www.vgj.pl/allegro/btm222_datasheet.pdf

http://openocd.berlios.de/doc/html/index.html


49

[14] YAGARTO. ARM GNU Toolchain – 18. marec 2011 [Spletni vir]. Dostopno

na: http://www.yagarto.de/ [1. 12. 2011].

[15] JTAG. Wikipedia – 8. marec 2011 [Spletni vir]. Dostopno na:

http://en.wikipedia.org/wiki/Joint_Test_Action_Group [1. 12. 2011].

[16] National Semiconductor. LM2734Y Buck Converter – 21. junij 2010 [Spletni

vir]. Dostopno na:

http://www.national.com/ds/LM/LM2734.pdf [1. 12. 2011].

[17] Amic Technology. SPI Flash A25L016 Rev. 1.4 – 27. oktober 2010 [Spletni

vir]. Dostopno na:

http://www.amictechnology.com/pdf/A25L016.pdf [1. 12. 2011].

[18] Serial Peripheral Interface Bus. Wikipedia – 12. marec 2011 [Spletni vir].

Dostopno na: http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus [1.

12. 2011].

[19] Universal Serial Bus. Wikipedia – 30. marec 2011 [Spletni vir]. Dostopno na:

http://en.wikipedia.org/wiki/Universal_Serial_Bus [1. 12. 2011].

[20] USB Connectors. microUSB AB – 10. november 2010 [Spletni vir]. Dostopno

na: http://www.lammertbies.nl/comm/cable/USB-connector.html [1. 12. 2011].

[21] USB in a Nutshell. BeyondLogic – 17. september 2010 [Spletni vir]. Dostopno

na: http://www.beyondlogic.org/usbnutshell/usb1.shtml [1. 12. 2011].

[22] Fastrax. GPS TI300 Technical Datasheet Rev. 1.6 – 1. oktober 2010 [Spletni

vir]. Dostopno na:

http://www.fastraxgps.com/showfile.cfm?guid=28986707-22f4-4cbd-aca7-

ef50755103a9 [1. 12. 2011].

[23] SiRF Technology. SiRF Binary Protocol Rev. 2.4 – november 2008 [Spletni

vir]. Dostopno na:

http://www.fastraxgps.com/showfile.cfm?guid=be6df04c-ae4d-415e-9e10-

8cb486bce233 [1. 12. 2011].

[24] Hayes Command Set. Wikipedia – 21. januar 2011 [Spletni vir]. Dostopno na:

http://en.wikipedia.org/wiki/Hayes_command_set [1. 12. 2011].

http://www.yagarto.de/

http://en.wikipedia.org/wiki/Joint_Test_Action_Group

http://www.national.com/ds/LM/LM2734.pdf

http://www.amictechnology.com/pdf/A25L016.pdf

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

http://en.wikipedia.org/wiki/Universal_Serial_Bus

http://www.lammertbies.nl/comm/cable/USB-connector.html

http://www.beyondlogic.org/usbnutshell/usb1.shtml

http://www.fastraxgps.com/showfile.cfm?guid=28986707-22f4-4cbd-aca7-ef50755103a9

http://www.fastraxgps.com/showfile.cfm?guid=28986707-22f4-4cbd-aca7-ef50755103a9

http://www.fastraxgps.com/showfile.cfm?guid=be6df04c-ae4d-415e-9e10-8cb486bce233

http://www.fastraxgps.com/showfile.cfm?guid=be6df04c-ae4d-415e-9e10-8cb486bce233

http://en.wikipedia.org/wiki/Hayes_command_set


50

10 PRILOGE

10.1 Seznam slik

Slika 2.1: Rešitve podjetja PLX (a), Torque za Android (b) in ScanGauge (c) .................... 2

Slika 3.1: EOBD .................................................................................................................... 3

Slika 3.2: Blokovni prikaz potovanja podatkov iz avtomobila preko OBDII do naprave ..... 4

Slika 3.3: OBD-priključek (b) z razporeditvijo priključnih sponk (a) in podprti protokoli

(c) ................................................................................................................................... 5

Slika 4.1: Blok shema naprave .............................................................................................. 7

Slika 4.2: Naprava v škatlici z delno prosojnim pokrovom .................................................. 8

Slika 4.3: 3D-upodobitev vezja, zgornja stran ...................................................................... 9

Slika 4.4: 3D-upodobitev vezja, spodnja stran ...................................................................... 9

Slika 4.5: Vezje, zgornja stran ............................................................................................... 9

Slika 4.6: Vezje, spodnja stran .............................................................................................. 9

Slika 4.7: Čip mikrokrmilnika v SMD ohišju ..................................................................... 10

Slika 4.8: Blok shema mikrokrmilnika ................................................................................ 10

Slika 4.9: Diamex DXM ...................................................................................................... 11

Slika 4.10: GPS modul ........................................................................................................ 12

Slika 4.11: GPRS modul ...................................................................................................... 13

Slika 4.12: Spominska kartica microSD .............................................................................. 14

Slika 4.13: Blok shema osnovnega preklopnega regulatorja z grafom izhodne napetosti in

tokov preko tranzistorja in diode ................................................................................. 15

Slika 5.1: Prikaz celotnega ekosistema ............................................................................... 16


51

Slika 5.2: Razvojna orodja................................................................................................... 18

Slika 5.3: Eclipse, ustvarjanje novega projekta ................................................................... 30

Slika 5.4: Eclipse, nastavitve projekta ................................................................................. 30

Slika 5.5: Eclipse, nastavitev knjižic povezovalnika ........................................................... 32

Slika 5.6: Uspešno prevajanje programa ............................................................................. 32

Slika 5.7: Programiranje na čip ........................................................................................... 32

Slika 6.1: Delovanje razvrščevalnika .................................................................................. 34

Slika 6.2: Struktura in vpetost razvrščevalnika opravil z opravili in podsklopi .................. 35

Slika 6.3: Potek zagona naprave .......................................................................................... 36

Slika 6.4: Osrednja opravila in razvrščevalnik .................................................................... 37

Slika 6.5: Sestava in odvisnosti opravila BlueLinkTask ..................................................... 37

Slika 6.6: Potek komunikacije po vmesniku OBDII ........................................................... 38

Slika 6.7: USB-naprava v LPC176x .................................................................................... 41

Slika 6.8: Pipe in končne točke ........................................................................................... 42

Slika 6.9: Transakcije .......................................................................................................... 42

Slika 6.10: Opis naprave gostitelju (angl. device descriptor) .............................................. 43

Slika 6.11: Navidezna serijska vrata v upravitelju naprav .................................................. 43

Slika 6.12: Opis naprave za razred CDC ............................................................................. 44

Slika 6.13: Izpis iz naprave v živo preko USB-vmesnika na terminalu .............................. 44

10.2 Seznam tabel

Tabela 6.1: Poizvedba OBDII ............................................................................................. 39

Tabela 6.2: Odgovor na poizvedbo OBDII ......................................................................... 40


52

10.3 Naslov študenta

Matej Zorko

Moše Pijada 23B

2000 Maribor

E-pošta: [email protected]

10.4 Kratek življenjepis

Rojen 28. 8. 1986 v Mariboru.

Šolanje:

OŠ Maksa Durjave, Maribor

SERŠ, Maribor

Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor

10.5 Zgoščenka z izvorno kodo in načrti

mailto:[email protected]


53


54


55