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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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)
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
4
3.2 Kako deluje
Slika 3.2: Blokovni prikaz potovanja podatkov iz avtomobila preko OBDII do
naprave
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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)
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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} {
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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();
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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. }
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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. */
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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()
+ operator()() : int
+Source+PLL
-m_ClockSourceInfo
-m_Tasks
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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()
+ operator()() : int
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()
+ operator()() : int
SchedulerTask
TestTask
- m_BTOk: bool
- m_BTTimeout: int
- m_FlushTime: int
- m_GpsLogFile: FileStream
- m_OBDLogFile: FileStream
- m_TextLogFile: FileStream
+ operator()() : int
+ 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
+ Read(void*, int) : int
+ SDInterface()
+ ~SDInterface()
+ Write(void*, int) : int
SDInterfaceSPI
- m_SSP: LPC_SSP_TypeDef*
+ HighSpeed() : void
+ LowSpeed() : void
+ Read(void*, int) : int
+ 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
+ operator()() : int
- 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
- m_UART: LPC_UART_TypeDef*
- 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
+ operator()() : int
- ParseSiRFMessage() : void
+ Reset() : void
+ TurnOff() : void
+ TurnOn() : void
«friend»
- UART3_IRQHandler() : void
OBDDev ice
- m_OBDDump: FileStream
- m_UART: LPC_UART_TypeDef*
- 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»
- UART0_IRQHandler() : void
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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.
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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].
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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].
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
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
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
53
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
54
Spremljanje lokacije vozila in njegove statistike motorja preko dlančnika – strojni del
55