FACULTATEA DE AUTOMATIC I CALCULATOARE

DEPARTAMENTUL CALCULATOARE

Sistem de monitorizare i comand pentru

vehicule electrice bazat pe microcontroller

LUCRARE DE LICEN

Absolvent:Lucian CRIAN

Coordonator tiinific: S.L.Dr.Ing Radu DNESCU

2012

VIZAT,

DECAN, DIRECTOR DEPARTAMENT,

Prof. dr. ing. Liviu MICLEAProf. dr. ing. Rodica POTOLEA

Absolvent: Lucian CRIAN

TITLUL LUCRRII DE LICEN

1. Enunul temei: Problema pe care lucrarea de fa o abordeaz se refer la conducerea unei maini n mod eficient, avnd ca i constrngeri o destinaie aflat la un anumit numr de kilometri sau/i o constrngere legat de timpul maxim pn la care se dorete ajungerea la destinaie. Se va folosi un microcontroller pentru achiziia datelor de la senzori i trimiterea lor la o tablet cu sistem de operare Android.

2. Coninutul lucrrii: Pagina de prezentare, Declaraie, Introducere, Obiectivele proiectului, Studiu bibliografic, Analiz i fundamentare teoretic, Proiectare de detaliu i implementare, Testare i validare, Manual de instalare i utilizare, Concluzii, Bibliografie, Anexe

3. Locul documentrii: Universitatea Tehnic din Cluj-Napoca, Departamentul Calculatoare

4. Consultani: S.L. Dr. Ing. Radu Dnescu, A.L. Dr. tefan Breban

5. Data emiterii temei: 1 noiembrie 2011

6. Data predrii: 29 Iunie 2012

Absolvent:_____________________________

Coordonator tiinific:_____________________________

Declaraie

Subsemnatul Lucian CRIAN, student al Facultii de Automatic i Calculatoare, Universitatea Tehnic din Cluj-Napoca, declar c ideile, analiza, proiectarea, implementarea, rezultatele i concluziile cuprinse n aceast lucrare de licen constituie efortul meu propriu, mai puin acele elemente ce nu mi aparin, pe care le indic i recunosc ca atare.

Declar de asemenea c, dup tiina mea, lucrarea n aceast form este original i nu a mai fost niciodat prezentat sau depus n alte locuri sau alte instituii dect cele indicate n mod expres de mine.

Data: 29 Iunie 2012

Absolvent: Lucian CRIAN

Numr matricol: 210842

Semntura:______________________

Cuprins

1. Introducere Contextul proiectului1

1.1 Contextul proiectului1

1.2 Domeniul temei de licen1

2. Obiectivele proiectului2

2.1 Msurarea tensiunii pe unt i pe divizorul de tensiune2

2.1.1 Asigurarea bazei de timp pentru achiziia de date2

2.1.2 Asigurarea voltajului de referin2

2.1.3 Ameliorarea variailor consumului de curent2

2.2 Comunicarea cu tableta3

2.2.1 Protocolul Android Open Accessory3

2.2.2 Alimentarea tabletei3

2.2.3 Posibilitatea nlocuiri tabletei3

2.3 Asigurarea independenei n comunicare3

2.3.1 Trimiterea parametrilor de configuraie ai microcontroller-ului4

3. Studiu bibliografic5

3.1 Variante alternative de conectare la microcontroller5

3.1.1 Hacking5

3.1.2 Bridge ntre USB i serial5

3.1.3 Bridge ntre BlueTooth i serial5

3.2 Android Open Accessory Protocol( ADK)6

3.2.1 Android@Home6

3.3 Sistem audio-video al mainii conectat la Android7

3.4 Conducerea eficient a vehiculelor electrice7

3.5 Roboi autonomi8

4. Analiz i fundamentare teoretic9

4.1 MPLAB X9

4.2 Microchip Application Library9

4.3 Componente hardware10

4.3.1 Circuitul de achiziie10

4.3.2 H-Bridge10

4.3.3 Motoarele de curent continuu11

4.4 Perifericele microcontroller-ului12

4.4.1 Timer12

4.4.2 Output Compare13

4.4.3 Input capture15

4.4.4 I2C16

4.4.5 ADC17

4.4.6 RTCC18

4.4.7 Controller-ul de ntreruperi19

4.5 Protocoale folosite20

4.5.1 I2C20

4.5.2 USB22

4.5.2.1 O scurt introducere22

4.5.2.2 Tipuri de transfer23

4.5.2.3 Modelul de comunicaie USB23

4.5.2.4 Descriptorii de USB24

4.5.2.5 Procesul de enumerare24

4.5.2.6 USB Embedded Host Stack25

4.5.2.6.1 Target Peripheral List( TPL)25

4.5.2.6.2 Arhitectura stivei26

4.5.2.6.3 Driver-ul client bazat pe evenimente27

4.5.3 Android Open Accessory Protocol27

4.6 Algoritmii propui28

4.6.1 Conversia din analogic n digital30

4.6.2 Msurarea turaiei31

4.6.3 Actualizarea datelor32

4.6.4 Calibrare motoare33

4.6.5 nlnuirea comenzilor pe USB 33

5. Proiectare de detaliu i implementare35

5.1 Modulul de DAC36

5.2 Modulul de Input Capture 37

5.3 Modulul de PWM39

5.4 Modulul de ADC 39

5.5 Modulul de RTCC40

5.6 Programul principal40

5.6.1 Structura comenziilor41

5.6.2 Trimiterea datelor ctre tablet42

5.6.3 Funcia de trimitere a datelor ctre Android43

5.6.4 Iniializarea comunicaiei pe USB i ADK43

5.6.5 USBTask()= keep the stack running44

5.6.7 Iniializarea plcii de dezvoltare44

5.7 Logica general a aplicaiei44

6. Testare i validare46

7. Manual de instalare i utilizare49

7.1. Instalare49

7.1.1 Instalare hardware49

7.1.2 Instalare software51

7.2 Manualul utilizatorului52

8. Concluzii53

8.1 Rezumat53

8.2 Rezultate obinute53

8.3 Posibile dezvoltri i mbuntiri ulterioare54

9. Bibliografie56

10. Anexe57

1. Introducere Contextul proiectului

1.1 Contextul proiectului

Lucrarea de fa este o component a mainii solare dezoltat n cadrul Universitii Tehnice din Cluj-Napoca i intitulat Solis.EV. Vehiculul se dorete a fi unul de tip autonom, a crui propulsie este de tip electric, alimentarea fcndu-se folosind acumulatori ncrcai de la panouri fotovoltaice.

Pentru preluarea informaiilor de la senzori se folosete un microcontroller, util i pentru acionarea motoarelor. Afiarea informaiilor i intepretarea lor se face folosind o tablet care are un sistem de operare de tip Android, n locul panoului central de bord.

1.2 Domeniul temei de licen

Problema pe care lucrarea de fa o abordeaz se refer la conducerea unei maini n mod eficient, avnd ca i constrngeri o destinaie aflat la un anumit numr de kilometri sau/i o constrngere legat de timpul maxim pn la care se dorete ajungerea la destinaie. Ca i model de main se va considera una de tip solar, cu alimentare electric de la acumulatori.

Comparativ cu circuitele analogice, un sistem de comanda si monitorizare bazat pe microcontroller permite o mai mare flexibilitate, i o adaptare mai bun la modificarea parametrilor. Pentru senzori i elemente de acionare se va folosi o adresare individual n locul unei magistrale comune.

n cadrul mainii solare un aspect important l reprezint monitorizarea bateriilor, deoarece folosirea lor peste limita permis poate produce distrugerea lor. Astfel se va monitoriza consumul de curent din circuit precum i gradul lor de descrcare. Cunoaterea acestor parametri permite o estimare a timpului rmas pn la descarcarea bateriilor, n ritmul de consum actual. Folosind curbele de descrcare se pot indica diverse moduri de prelungire a duratei de descrcare, n funcie de consumul de curent.

Un alt aspect important l constituie acionarea motoarelor. n urma testelor s-a constat c circuitele de acionare rspund n mod diferit la stimuli. Din aceast cauz este necesar ca atunci cnd se conecteaz un set nou de motoare s se fac o calibrare iniial a lor. n timpul funcionrii se folosete i o bucl de comand nchis, implementat n software, pentru a reduce diferenele ntre turaii.

Comunicarea cu senzorii, sau cu tableta se face folosind protocoale cum ar fi I2C respectiv USB. Datele circul n general ntr-o singur direcie de la senzori spre microcontroller, sau de la acesta spre elementele de acionare i n ambele sensuri pe USB.

2. Obiectivele proiectului

2.1 Msurarea tensiunii pe unt i pe divizorul de tensiune

Principalul obiectiv al acestei lucrri l constituie monitorizarea descrcrii unor acumulatori cnd sunt folosii cu un consum variabil. n acest sens s-a folosit un unt de 0.8 astfel nct msurnd cderea de tensiune s se poat afla consumul momentan de curent. Pentru msurarea lui s-a folosit puntea Wheatstone, datorit necesitii existenei unei precizii ridicate pentru msurarea unei rezistene de valoare mic.

Principiul prin care se afl intensitatea tiind cderea de tensiune pe unt este de a folosi legea lui Ohm: U= I* R. Voi folosi un scurt exemplu: la o valoare de tensiune msurat pe unt de 0.4V i rezistena de 0.8, folosind formula enunat anterior se ajunge la valoarea intensitii de 0.5A.

Astfel obiectivul principal presupune msurarea n fapt a dou tensiuni: una pe acumulatori, folosind un divizor i alta pe unt. S-a ales un unt de o valoare mic pentru a avea un consum minim de curent. Acest fapt face ca tensiunea msurat s nu depeasc 0.5V. Valoarea msurat pe divizor este de 3 ori mai mare, maximul fiind de 1.5V.

2.1.1 Asigurarea bazei de timp pentru achiziie date

Un alt aspect important n cadrul proiectului este de integrare n timp a celor dou valori msurate. Pentru aceasta este necesar ca achiziia datelor s se fac la intervale de timp foarte bine stabilite. Nu este att de important s se i trimit datele cu exact aceiai constan. Pentru aceasta s-a ales o baz de timp de 1Hz, care este asigurat de circuitul de RTCC. O variaie n generarea acestei baze de timp va duce n timp la rezultate eronate.

2.1.2 Asigurarea voltajului de referin

O alt parte esenial a msurrii tensiunilor o constituie meninerea referinei pentru ADC la o valoare constant. Pentru aceasta se vor folosi regulatorul de tensiune de pe plac n combinaie cu circuitul de DAC. Convertorul din analogic n digital va folosi o referin de 1.5V n locul celei e 3.25V folosindu-se mai eficient cei 10 bii ai rezultatului conversiei din analog i tot odat duce la o precizie ridicat la msurarea mV.

2.1.3 Ameliorarea variailor consumului de curent

Datorit modului de construcie al motoarelor i a faptului c sunt comandate n PWM apar variaii ale consumului de curent, de frecvena comenzii primite. Acest lucru se datoreaz rspunsului bobinelor la semnalul dreptunghiular. Pentru atenuarea efectului s-a folosit un condensator i o mediere a valoriilor msurate folosind software-ul. Asigurarea unei referine stabile pentru ADC nu este suficient. Baza de timp a convertorului trebui s fie de asemenea stabil. n acest sens oscilatorul intern al modului nu poate fi folosit, fiind nerecomandat la msurtori de precizie. Folosirea semnalului de ceas al perifericelor(care este divizat din oscilatorul principal) este o alternativ mult mai potrivit.

2.2 Comunicarea cu tableta

Datorit capacitii limitate de procesare i de afiare a microcontroller-ului se impune folosirea unei tablete pentru prelucrea informaiilor, salvarea i afiarea lor n timp real, utilizatorului uman. Acest lucru ridic cel puin dou probleme: trimitirea informaiilor la o frecven ridicat i posibilitatea alimentarii tabletei n acelai timp.

2.2.1 Protocolul Android Open Accessory

Este un protocol dezvoltat de Google care folosete USB-ul mpreun cu un mecanism de hand-shake permind comunicarea ntre un master i un slave. Trebuie avut n vedere c (momentan) tableta joac rolul de slave. Astfel codul necesar funcionrii comunicaiei cade n sarcina microcontroller-ului. Un alt dezavantaj ce trebuie avut n vedere este c doar ultimele versiuni de Android suport acest protocol.

2.2.2 Alimentarea tabletei

Obinerea alimentrii continue a tabletei este necesar deoarece dac se folosete ca i panou de bord, nu se poate ndeprta n timpul funcionrii pentru a se rencrca. Folosirea unei surse alternative de alimentare nu este o soluie general, deoarece de cele mai multe ori, nu exist o muf separat n acest scop.

Avantajul USB este acela c permite transferul datelor la viteze de ordinul MB/s permind i alimentarea slave-ului n acelai timp. Tensiunea de alimentare este de 5V la un curent maxim de 250mA, ceea ce n cazul de fa este suficient.

2.2.3 Posibilitatea nlocuiri tabletei

Se dorete folosirea unui protocol care s permit o nlocuire ct mai facil a unei tablete cu alta de acelai tip sau alt model. Soluiile de tip hacking pe ct sunt de interesante i de captivante presupun de cele mai multe ori desfacerea carcasei i cositorirea unor fire.

Folosirea soluiei prezentate n aceast lucrare, presupune doar ndeprtarea cablului de USB, schimbarea tabletei, ncrcarea pe aceasta a programului Android, apoi se reconecteaz cablul i se poate relua activitatea.

2.3 Asigurarea independenei n comunicare

Se dorete ca o schimbare fie a dispozitivului slave, fie a celui master s nu presupun i modificarea protocolului de comunicare. n acest sens s-a ales un protocol simplu, bazat pe trimiterea de octei. Astfel fiecare mesaj este precedat de un cod de identificare, urmat apoi de un numr fix de octei care reprezint argumentele.

Octet 1Octet 2....Octet n+1

Cod mesajArgument 1....Argument n

Tabelul 2.1: Formatul general al unui mesaj

n cazul n care o valoare ocup mai mult de un octet(ca de exemplu valoarea de la ADC care este pe 10 bii) se va trimite pe numrul necesar de octei, cu aliniere la dreapta n cadrul grupui de bytes.

2.3.1 Trimiterea parametrilor de configuraie ai microcontroller-ului

Fiecare microcontroller este influenat de hardware n ceea ce privete modul de reprezentare al rezultatelor i numrul de bii pe ci se reprezint acestea. Astfel este de preferat ca nainte de a se ncepe trimiterea de mesaje s se trimit configuraiile plcii de dezvoltare. Trebuie avut n vedere c i frecvena plcii poate s fie diferit, precum i frecvena de lucru pentru periferice.

3. Studiu bibliografic

Materialele folosite pentru realizarea acestei lucrri cuprind: data sheet, reference manual, aplication note, cri, lucrri de laborator, precum i numeroase pagini de pe internet. Acestea sunt n marea majoritate n limba englez cu cteva excepii n limba romn. Datorit noutii tehnologiei ADK, care a fost lansat n primvara anului 2011, nu se poate vorbi despre o bibliografie de mari dimensiuni.

3.1 Variante alternative de conectare la microcontroller

3.1.1 Hacking

Reprezint varianta cea mai riscant i n acelai timp i cea mai interesant de comunicare. Aa cum se arat n articolul [1] sunt dou abordri posibile: prima presupune folosirea unui bridge ntre USB i portul serial, iar a doua i cea mai dificil presupune gsirea i conectarea la portul serial direct de pe magistrala telefonului.

Principalul avantaj al ultimei metode l constituie costul. Dezavantajul major, l constituie faptul c fiecare dispozitiv cu Andoid, are pinii de la portul serial situai n alt locaie. Accesul la schemele hardware este dificil, i de cele mai multe ori acestea nu sunt fcute publice deoarece clientul nu are nevoie n mod normal de aceste informaii.

3.1.2 Bridge ntre USB i serial

Folosirea unui bridge ntre serial i USB este prezentat n resursa [2], n acest articol fiind prezentat modul concret de construire al acestui bridge. Avantajul abordrii curente i a celei precedente este reprezentat de faptul c pe partea de microcontroller se folosete comunicarea prin protocolul UART. Acesta este suportat nativ de ctre toate dispozitivele i de asemenea este un protocol uor de folosit.

Un bridge pentru microcontroller este explicat i n resursa [3], care spre deosebire de variantele anterioare bazate pe serial necesit i folosirea unei librrii mai complexe. De asemenea suportul pentru kit-ul de dezvoltare este oferit doar pentru Arduino, ceea ce limiteaz complexitatea programului ce poate fi ncrcat pe plac.

3.1.3 Bridge ntre BlueTooth i serial

Asupra variantelor wireless m-am oprit cu documentarea doar pe varianta de Bluetooth, datorit preului mai redus al shield-ului, i a protocolului care este mai simplu. Pentru aceasta se poate folosi [4], care nu este altceva dect o librrie tot pentru Arduino. Aceasta accept un numr mare de bridge-uri ntre UART i BlueTooth, att timp ct se seteaz baud rate-ul pentru comunicaia serial la o valoare prestabilit.

n tutorialul [5] se explic pe larg modul general de conectare ntre device-uri folosind un bridge de la BlueTooth la serial. Se ofer de asemenea att schemele de montaj construite n jurul unui Arduino i a unui bridge de la SparkFun, precum i codul pentru Android i paii necesari dezvoltrii aplicaiei pe microcontroller.

3.2 Android Open Accessory Protocol( ADK)

Fiecare telefon sau tablet poate folosi USB-ul mpreun cu protocolul ADB(care n mod normal este folosit pentru depanare) pentru trimiterea datelor, aa cum este prezentat n blog-ul [6]. O privire critic asupra ADK se gsete pe blog-ul lui Romfron [7], unde se combate vehement ADK-ul, fiind considerat ca lipsit de inovaie fa de ADB, deoarece limiteaz folosirea telefonului/tabletei precum i modele acceptate. ADK are totui avantajul c permite folosirea( momentan n dezvoltare) n paralel a funcie de depanare fie printr-un USB secundar sau prin wireless.

Singurele documentaii oficiale referitoare la ADK sunt cele oferite de Google, unde exist o scurt seciune dedicat [8], n cadrul ghidului pentru Android. Acestei documentaii i se altur documentaia oferit de ctre Microchip [9]. Ambele documentaii ns nu sunt destul de detaliate, oferind informaii foarte puine.

ADK folosete momentan telefonul pe post de slave i placa de dezvolatare pe post de master, USB-ul fiind un protocol asimetric. Decizia aceasta a fost luat, aa cum se arat n blog-ul oficial [10], deoarece momentan majoritatea telefoanelor nu au modul master i nici OTG, ci numai slave. De asemenea deoarece majoritatea suport ADB, au cel puin modul de slave, pentru a se conecta la PC i a realiza depanarea print-un cablu USB. Din aceast cauz, aa cum se remarc i n blog, este o situaie inversat, cu susul n jos: telefonul dei are putere de calcul mai mare acioneaz ca i slave, avnd de asemenea nevoie i de alimentare.

Pe viitor, aa cum se arat n blog-ul amintit mai sus, [10], se va ncerca s nu se mai ofere alimentare telefonului i s se suporte distribuirea de coninut audio peste USB( acest lucru nu este fezabil n varianta de fa, deoarece nu se suport transferul izocron). n cadrul Google I/O din 2011 [11] s-a lansat ideea chiar ca telefonul s fie host, ceea ce ar uura foarte mult munca dezvoltatorilor de embedded.

3.2.1 Android@Home

Conceptul a fost prezentat n cadrul Google I/O 2011 [12], ca fiind o extindere pentru Android Open Accessory Protocol pentru automatizarea unei ntregi locuine. Dispozitivul Android va trebui s foloseasc Android@Home Framework pentru a putea comunica cu senzorii folosind Wi-Fi.

Un protocol wireless, care folosete unde radio de 900MHz a fost dezvoltat pentru conectarea elementelor ce nu pot ngloba capacitiile de Wi-Fi. n acest sens a fost prezentat un bec bazat pe tehnologia LED i produs mpreun cu Light Science, care folosete acest protocol proprietar.

Oferta de produse compatibile cu Android@Home este momentan redus. Totui posibilitatea conectrii la internet ofer accesul la Google Cloud i toate serviciile asociate lui. Un alt exemplu prezentat a fost nglobarea serviciului Music Beta, care permite sincronizarea diverselor dispozitive care au Android, prin folosirea unui cont Google. Toat muzica se va afla salvat n cloud, astfel nct nu va ocupa spaiu pe disc.

3.3 Sistem audio-video al mainii conectat la Android

n resursa [13] se exemplific o implementare a protocolului ADK oferit de Harman, prin sistemul lor de audio-video instalat pe main. Telefonul sau tableta pot fi comandate de la comenziile de pe ecranul tactil, prin comand vocal, butoanele de pe volan sau direct din panoul central sistemului audio- video.

Se poate astfel s se trimit un sms sau e-mail folosind comanda vocal, sau s se redea coninutul unui mesaj primit n boxele mainii. Posibilitatea de a rspunde la telefon, sau de a apela un numr se poate face tot vocal, sau din butoanele de pe volan. Reele sociale, cum ar fi Facebook sau Twitter au fost i ele tratate de Harman. Coninutul text al oricrui post primit poate fi redat de ctre sistemul audio al mainii.

Aplicaiile de navigaie care se gsesc pe telefoane i tablete pot fi folosite pentru gsirea celei mai apropiate staii de alimentare cu carburani, sau pentru a descoperi restaurantele din zon. De asemenea pot fi redate i filme, pe panoul sistemului audio-video sau pe ecrane care pot fi montate n tetiere.

Totui sitemul audio-video oferit de firma Harman nu interfaeaz cu partea de control al parametrilor mainii(cu excepia volumului n difuzoare, i a coninutului unor ecrane), fiind mai mult o extindere a ecranului tactil al tabletei. Aici dispozitivul Android are rolul de gestionar pentru muzic, filme, apleuri i mesaje primite, sau postriile de pe reelele sociale.

3.4 Conducerea eficient a vehiculelor electrice

n lucrarea [14] se trateaz modul n care pot fi satisfcute cerinele clientului innd cont de resursele mainii. Abordarea adoptat n acest articol este ierarhic, i cuprinde 4 module.

Fiecare modul constituie o intrare pentru cel de nivel superior, astfel nct se transmit o colecie de soluii stagiului urmtor, acesta combinnd fiecare soluie primit cu cea proprie, pentru a obine tot o colecie de soluii. Un optim local unui nivel poate s nu fac parte i din soluia global, de aceea se trimit un set de soluii.

Soluia unui singur drum optimal, din punct de vedere al clientului, implic satisfacerea constrngerilor de timp i de consum energetic. La acestea se pot aduga costuri de rencrcare, timpi mori n care se face alimentarea, numrul de astfel de opriri i alte criterii.

Primul nivel tratat este cel al componentelor mainii, cu rol asupra confortului clientului sau asupra posibilitii efective de locomoie. La acest nivel strategiile sunt foarte simple, i sunt constituite n mare din compararea unor threshold-uri.

La nivelul urmtor, cel al cltoriei se iau n considerare punctele de alimentare i destinaiile, i modul n care se poate ajunge ct mai eficient la ele. Aici pentru elaborarea strategiilor se folosesc grafuri.

Nivelul cltoriei este format dintr-o serie de rute, i puncte de staionare/parcare reprezentate de destinaii intermediare sau finale. Pentru conectarea rutelor se folosete programarea dinamic, sau gsirea unui optim local.

Ultimul nivel este cel de asigurare a mobilitii, n care un client nu este legat n mod direct de un anumit mijloc de transport; poate folosi i mijloace de transport n comun, sau pe anumite poriuni poate s cltoreasc alturi de un cunoscut. n acest scop se folosesc algoritmi din teoria jocului.

Concluzia acestei lucrri este c nu doar costul unei cltorii poate fi mbuntit, dar chiar i timpul total poate fi mult mbuntit n paralel. Pentru susinerea acestei afirmaii s-a dezvoltat un cadru matematic prin care se studiaz complexitatea algoritmilor, i spaiu computaional al soluiilor. Este necesar s se renune la anumite variante n stagii ct mai incipiente, deoarece dac nu spaiul soluiilor poate ajunge la ordinul miilor, iar analiza lor va consuma foarte mult timp. De asemenea alegerea unei medii, n locul unui optim global poate s satisfac de cele mai multe ori cerinele clientului.

3.5 Roboi autonomi

n cartea [15] se prezint tipurile de roboi autonomi, mobilitatea lor, senzori i percepia mediului, localizarea i planificarea cltoriei.

Un robot care are 3 roi are avantajul stabilitii i de asemenea nu are nevoie de suspensie, deoarece un plan este determinat de 3 puncte i astfel fiecare roat are contact permanent cu solul. O alt condiie necesar este ca centrul de greutate s se gseasc n interiorul triunghiului format de cele 3 roi.

Pentru control direciei, puntea din fa se acioneaz independent, iar n spate se poate folosi o roat sferic sau una pivotant. Schimbarea direciei se face prin rotirea n jurul centrului de greutate, blocnd o roat i cealalt fiind acionat n sensul dorit. n locul blocrii se poate folosi acionarea n sens invers, ceea ce duce ca robotul s roteasc la punct fix. Dificultatea controlului const n faptul c turaiile celor dou roi motoare trebuie s fie identice pentru o deplasare n linie dreapt. Folosirea unei roi sferice sau a uneia pivotante n spate nu influeneaz n mod semnificativ manevrabilitatea robotului.

Pentru atingerea destinaiei se poate folosi o planificare fie n bucl deschis, fie n bucl nchis. Prima abordare presupune divizarea traseului n mai multe segmente de tipul liniilor sau arcelor de cerc. Aceast tehnic nu ia n calcul modificriile neprevzute n configuraia mediului, i de asemenea viteza de deplasare are fluctuaii mari datorit neregularitiilor ce apar n compunerea drumului ales.

Folosirea unei bucle nchise, prin analiza feed back-ului primit de la diveri senzori, constituie o abordare mai realist i uor adaptabil la schimbriile de mediu. Tehnica de baz const n alegerea unor puncte intermediare, care urmeaz s fie vizitate.

4. Analiz i fundamentare teoretic

4.1 MPLAB X

Mediul de dezvoltare MPLAB X v.1.10, asigur dezvoltarea facil a aplicaiilor pentru microcontroller-ele Microchip. Are funcii de programare a acestora folosind un cablu USB sau un programator, de citire a coninutului memoriei i de execuie a unui program pas-cu-pas.

Testarea aplicaiilor, n lipsa unei plci de dezvoltare, se poate face folosind simulatorul, care poate emula orice microcontroller suportat de mediul de dezvoltare. Are dezavantajul de a afia registrele n mod list, ordonate dup adres sau dup nume, n locul unei grupri dup perifericul de care aparin.

Dezvoltarea programelor se poate face, folosind fie limbajul de asamblare fie C. Prin folosirea directive pentru compilare, se permite introducerea de cod scris n alt limbaj dect cel ales de utilizator la crearea proiectului. Se ofer suport pentru limbajul de asamblare prin ASM iar prin C18/C30/C32 respectiv HI-TECH PICC/PICC-18 se ofer suport pentru C. Varietatea mare de compilatoare se explic prin multitudinea de arhitecturi suportate: de 8, 24 i 32 de bii precum i procesoare digitale de semnal.

Pe lng compilatoarele necesare, pentru rularea IDE-ului este nevoie i de instalarea unui JRE. n cazul n care este instalat i versiunea 8 de MPLAB este nevoie de un driver switch pentru conectarea la placa de dezvoltare. Switch-ul are rolul de a ncrca driver-ul corespunztor folosiri USB ca i programator pentru microcontroller; att versiunea 8 ct i versiunea X au driver propriu.

Mediul de programare fiind dezvoltat plecnd de la NetBeans ofer un grad ridicat de modularitate printr-un set de plug-in-uri. Unul foarte util este DMCI care permite vizualizarea diverselor tipuri de variabile, afiarea unui vector pe grafic sau modificarea unor valori folosind sliders sau butoane de tip on/off pentru booleans.

4.2 Microchip Application Library

Cuprinde o serie de librrii scrise n C pentru folosirea perifericelor de pe plac, a cror programare este mai dificil. Se ofer acces la stivele de TCP/IP, USB, Wireless, ecrane tactile, SD card i sisteme de fiiere. Aceste librri pot fi folosite individual sau pot fi combinate n cazul n care aplicaia este mai complicat.

Librria Android Accessory Framework, folosete i librria de USB pentru a oferi un API facil dezvoltrii aplicaiilor de tip ADK. Generarea fiierelor de configuraie pentru driver-ul de USB se poate face folosind programul USB Config, prin configurarea pas-cu-pas a fiecrei opiuni asociate comunicaiei seriale.

Librriile necesare pot fi incluse n proiectul curent n dou moduri: prin adugarea locaiei la include path ca i cale absolut, sau prin copierea lor n proiectul curent i referirea folosind calea relativ. Metoda a doua asigur nu doar portabilitate, dar mpiedic modificarea voluntar sau nu a fiierelor originale din librrie. Compilatorul folosete include path pentru a cuta dependenele proiectului, cum ar fi fiierele din librriile standard.

4.3 Componente hardware

4.3.1 Circuitul de achiziie

Circuitul de achiziie este prezentat n figura 4.1, n continuare fiind prezentate componentele constructive. Schema a fost realizat folosind: falstad.com/circuit/, un applet n Java, de tip drag-and-drop.

Acumulatorii sunt de tip rencrcabil, cu o tensiune la borne de 1.2V i o capacitate de 2450mAh. n locul acumulatorilor se pot folosi baterii obinuite de 1.5V. Cei 4 acumulatori sunt legai n serie, oferind astfel 4.8V, capacitatea rmnnd la valoarea de 2450mAh.

Circuitul de msur al voltajului la borne este format din 4 rezistene de 1K n serie, cu scopul de a forma un divizor de tensiune. Rezistenele pot fi de orice valoare, ct timp sunt de valori egale. Dac sunt de valori diferite tensiunea pe o rezisten va trebui calculat folosind proporiile aritmetice. n cazul folosiri a 4 rezistene, cderea de tensiune pe o rezisten este de 4 ori mai mic dect n tot circuitul serie. n cazul de fa s-a ales valoarea de 1K pentru a se reduce consumul de curent n circuit.

Condensatorul este de tip electrolitic i are o capacitate de 4.7mF, iar cele dou motoare sunt reprezentate pe schem ca i dou rezistene de 100, aflate n partea dreapt. Asupra rolului condensatorului voi reveni ntr-un capitol viitor, iar motoarele vor fi prezentate n continuare.

4.3.2 H-Bridge

Circuitul are rolul de a schimba direcia motorului, fr a fi necesar modificarea montajului. Pentru aceasta se folosesc patru tranzistori grupai n dou perechi: Q1/Q3 i Q2/Q4, comandai prin semnalele A, respectiv B.

Dac A are valoarea '1', iar B are valoarea '0', motorul se va roti n sensul acelor de ceasornic, iar dac A este '0' i B este '1', se va roti n sensul opus acelor de ceasornic. Pentru a se opri motorul, ambele semnale de control trebuie s fie la valoarea '0'. Dac ambele semnale sunt '1', comportamentul va fi nedefinit.

n figura 4.2 este prezentat un Pmod ce ndeplinete funcia descris mai sus, i schema general a circuitului de H bridge, folosit pentru exemplificarea funcionrii. Aa cum se poate observa circuitul de alimentare este separat de comand, astfel nct motoarele pot fi acionate la tensiuni i cureni mari.

4.3.3 Motoarele de curent continuu

Motoarele sunt de tip Igarashi IG22, cu o cutie de viteze ncorporat, ce are un raport de 1:19, funcionnd ca un reductor cu raport fix. Modelul de fa se poate alimenta la tensiuni de maxim 6V, curent continuu, iar consumul de curent are valoarea maxim de 125mA. n figura 4.3 este prezentat o privire de ansamblu asupra motorului, o vedere din spate a encoder-ului i ieirea n defazaj a celor doi senzori Hall.

n partea din spate a fiecrui motor se afl un encoder, bazat pe efect Hall, care msoar gradul de rotaie. Scopul acestui circuit este s determine turaia motorului, folosind doi senzori magnetici dispui la o anumit distan unul fa de cellalt. Magnetul folosit este unul obinuit, de tip Nord-Sud. Cei doi senzori ofer la ieire semnalele A i B, defazate cu 900, i cu un factor de umplere de 50%, aa cum se vede n partea dreapt jos.

Trebuie avut n vedere c senzorii msoar direct turaia rotorului, astfel valoarea obinut este de 19 ori mai mare dect ieirea din reductor, care acioneaz roile. Senzorul Hall poate fi folosit chiar dac motorul nu este alimentat. Valoarea gradului de rotaie este una relativ la momentul nceperii msurrii. Folosirea unei codificri Gray asociate acestui encoder ar fi permis cunoaterea n orice moment al gradului de rotaie.

4.4 Perifericele microcontroller-ului

n sectiuniile urmtoare sunt prezentate perifericele folosite n cadrul proiectului. Termenul de PB se refer la semnalul de ceas al perifericelor, iar SOSC la oscilatorul secundar. Ceasul general al sistemului, SYSCLK , este divizat pentru a se obine PB. Notaia 'x' din denumirea registrelor sau pinilor se refer la registrul/pinul asociat unei anumite instane a perifericului, ca de exemplu dac x este 1 n TxCK este pinul semnalului de ceas extern pentru Timer 1.

4.4.1 Timer

Am folosit ca i principal surs de informare Reference Manual [16]. Acest model de chip are un numar de 5 timere de 16 bii(T1- T5). Pentru a se obine un timer de 32 de bii se pot asocia T2 cu T3 sau T4 cu T5.

Se folosete termenul de Type A pentru cele care pot fi folosite doar ca i 16 bii, respectiv Type B pentru cele care pot fi folosite i ca 32 bii. n cazul B se folosesc notaiile de TimerX i TimerY, primul fiind considerat master(exemplu Timer 2) iar al doilea fiind considerat slave(exemplu T3). Masterul stabilete perioada i setriile de baz, registrele lui Y sunt folosite doar pentru setarea ntreruperilor.

Pot fi identificate mai multe moduri de operare:

Modul sincron care este asemntor pentru tipul A i B presupune folosirea Peripheral Bus Clock (PB) i eventual a unui prescaler.

Modul sincron cu ceas extern presupune folosirea unui pin(TxCK) unde este furnizat un ceas extern. Acesta este sincronizat cu ceasul sistemului.

Modul gated presupune folosirea unui semnal extern care valideaz numrarea.

Modul asincron. Acesta este singurul mod care apare doar la tipul A, spre deosebire de modurile de mai sus care apar la ambele tipuri. Se poate folosi ca i sursa T1CK sau oscilatorul secundar (SOSC). Se ofer mecanisme de sincronizare ntre PB clock i ceasul extern.

Fiecare timer are propria ntrerupere, a crei prioritate/subprioritate poate fi setat individual. Poate avea surse multiple cum ar fi atingerea valorii din PR sau, dac se folosete n modul gated, de un falling edge pe gate.

4.4.2 Output Compare

Principala surs de informare privind PWM a constituit-o Reference Manual[17].

Poate fi folosit doar cu Timer 2 sau cu Timer 3. Se pot folosi un numr de maxim 5 canale. n privina registrelor necesare, numrul acestora este mic:

OCxCON, folosit pentru configurarea modulului

OCxR i OCxRS folosite pentru compararea cu valori de 16 bii sau de 32 de bii dac se folosete i registrul secundar(OCxRS).

Din punctul de vedere al modurilor de funcionare se pot distinge:

modul Single compare, a crui ieire poate fi folosit pentru a avea high, low sau toggle, la potrivirea valorii din timer cu cea din output compare(OcxR).

Modul Dual compare, folosete ambele registre pentru comparare. De exmplu la atingerea valorii din primul registru va trece n starea low, apoi la atingerea valorii din registrul al doilea va trece n high.

Modul PWM. Perioada se stabilete prin setarea timer-ului, iar factorul de umplere prin setarea OcxR. OcxRS are aici rol de buffer, i se transfer n OcxR la overflow-ul timer-ului.

PWM poate fi folosit cu scopul de convertor digital-analogic. Modificnd factorul de umplere se modific i ieirea. La frecvene mari, de ordinul kHz, un factor de umplere de x%, va face ca ieirea s fie perceput ca fiind x% din valoarea maxim. n exemplul din figura 4.6 la un factor de umplere de 50%, ieirea este msurat ca fiind 5V, jumtate din cei 10V, ct reprezint valoarea high a semnalului dreptunghiular.

Fiecare canal are asociat o ntrerupere, astfel se pot seta individual prioritiile i subprioritiile.

4.4.3 Input capture

Este folosit pentru a se efectua msurtori ale frecvenei sau ale duratei unui impuls, aa cum se arat n Reference Manual [18].

Modulul are dou registre: unul pentru configurare ICxCON i unul de tip buffer ICxBuf. Prin intermediul acestui registru buffer poate fi citit stiva(FIFO). Dac stiva conine 4 valori atunci sunt necesare 4 citiri din ICxBUF. Stiva are un numr maxim de 4 cuvinte. Se poate folosi ca i baz de timp Timer 2, Timer 3 sau ambele pentru o baz de timp de 32 de bii.

Se poate folosi n urmtoarele moduri:

simple capture, mod n care se alege modul de rising/falling, iar ntreruperea va fi generat dup numrul de evenimente specificat n ICxCON.

prescaled capture, mod n care se va genera un eveniment tot la al 4-lea sau 16-lea eveniment.

Modul edge detect va detecta att tranziiile high-low ct i low-high. Modul interrupt-only se folosete pentru modul sleep i idle.

Modulul are dou ntreruperi: ICxIF, care apare dup numrul dorit de evenimente i ICxIE care apare n urma unei erori cum ar fi faptul ca nu se citete din FIFO i apare over run.

n figura 4.8, este prezentat conceptual funcionarea modului. Modul de folosire este de single capture, i evenimentele de interes sunt cele de tipul rising edge, marcate cu verde pe figur. Registrul se va incrementa cu frecvena ceasului folosit ca i baz pentru msurtoare. Dac apare un eveniment se genereaz o ntrerupere, se salveaz valoarea, apoi registrul se va reiniializa.

4.4.4 I2C

Cele mai importante caracteristici ale modulului sunt urmtoarele:

logic separat pentru partea de slave/master

posibilitatea de a lucra att cu adrese 7 bit ct i de 10 bit

posibilitatea arbitrri n sisteme de tip multimaster

poate lucra la frecvene de 100KHz, 400KHz sau 1MHz.

Registrele care controleaz modulul de I2C sunt prezentate n [19] i sunt urmtoarele:

I2CxCON, este registrul care va controla funcionarea I2C

I2CxSTAT, conine o serie de flags

I2CxADD, este registrul ce conine adresa n cazul n care funcioneaz ca i slave

I2CxMSK, este un registru de masc pentru adres, astfel nct s poat s rspund la mai multe adrese

I2CxBRG, folosit pentru baud rate

I2CxTRN, aici se vor pune datele care se doresc trimise

I2CxRCV, aici se vor depunde datele primite

ntreruperile asociate cu acest modul sunt difereniate pentru modul de folosire master, slave sau sunt comune(bus collision), sursele n fiecare caz fiind multiple. Pentru recepionarea datelor se folosete principiul de double buffer. Prima dat datele sunt deplasate folosind I2CxRSR iar apoi odat terminat operaia(dup primirea a 8 bii) se mut datele n I2CxRCV. Dac vechea valoare nu a fost citit din acest registru se va semnaliza prin flagul I2xCOV, iar valoarea nou se va pierde.

Funcia de reload automat pentru Baud Rate Generator are sens n contextul arbitrrii, pentru a determina o nou ncercare de obinere a magistralei. BRG se va decrementa ct timp SCL este low, iar apoi va ncerca s aduc SCL n starea high. Pierderea arbitrrii poate s apar la Start, Repeated Start, trimitere de date, adres, sau la Stop; i se va semnaliza prin setarea flag-ului de BCL.

In continuare voi prezenta unele particulariti pentru modulul de I2C n modul master. La iniializarea unui Start trebuie s se atepte terminarea lui, altfel se va semnaliza o coliziune pe bus. Pentru a se verifica dac bus-ul este idle(SCL este high) se mai poate verifica flagul de Stop. Pentru o abordare bazat pe ntreruperi este necesar construirea unui state machine deoarece, ntreruperea pentru modul master poate fi activat de mai multe surse.

4.4.5 ADC

Registrele folosite pentru programarea modului sunt urmtoarele:

AD1CON1, AD1CON2, AD1CON3, folosite pentru configurare

AD1CHS, folosit la selectarea pinilor ce vor fi conectai la SHA, prin cele dou multiplexoare

AD1PCFG, este folosit pentru configurarea pinilor ca i digital sau analogic

AD1CSSL, este folosit pentru alegerea piniilor ce vor fi folosii la scanare

ADC1BUF0- ADC1BUFF, constituie stiva unde vor fi depuse rezultatele

Pentru a se folosi un pin ca i intrare analogic mai nti se va marca ca i pin de intrare folosind registrul TRIS, apoi se va seta ca i analogic folosind AD1PCFG. Rezultatul conversie este de 10 bii, dar poate fi citit ca i un numr pe 16 sau pe 32 de bii att n format ntreg ct i n format fracional, cu semn sau fr. Numerele negative nu se obin n urma citiri unei valori negative, ci datorit faptului c sunt n prima jumtate a intervalului, n mijlocul intervalului fiind valoarea 0.

Setarea modului de conversie poate fi realizat n 4 feluri i anume: manual prin setarea bitului de sample; prin folosirea Timer2 i/sau Timer3; printr-o ntrerupere extern; sau n mod auto. Modul auto va seta la finalul conversie bitul de sample, ceea ce va duce la nceperea unei noi eantionri.

Se poate specifica numrul de conversii dup care se va genera o ntrerupere, acest numr fiind de maxim 16 sau 8 n funcie de Buffer Fill Mode. Rezultatele vor fi salvate n stiv ncepnd cu BUF0 i continund pn la maxim BUFF. Prin folosirea dual buffer stiva este mprit n dou zone: primele 8 BUF0- BUF7 i ultimele BUF8- BUFF. Astfel mai nti se scrie n prima zona, se genereaz ntrerupere, apoi se trece la a doua zon, i se genereaz ntrerupere, apoi rezultatele conversiei vor fi depuse din nou n prima zon. Generarea ntreruperii se face dup scrierea numrului indicat de valori, valoarea maxim n acest mod fiind de 8. Mai nti se va scrie n buffer-ul 0, apoi n 1,2 n prima zon; respectiv 8, 9, 10 pentru zona a doua. Astfel se permite o operaie de citire dintr-o zon, n timp ce se scriu rezultatele n alt zon, fr riscul de suprascriere a valorilor.

Perioada convertorului se numete TAD i este dat fie de un oscilator intern, fie de semnalul de ceas al perifericelor. Convertorul este unul de tipul sample and hold, fiind prezentat n figura 4.9 ca o zon punctat cu denumirea S/H. Funcionarea este prezentat n figura 4.10, valoarea analogic avnd culoarea gri, punctele de eantionare fiind prezentate cu linii punctate, i valoarea digitizat avnd culoarea roie pe grafic. Prima dat se face o ncrcare a condenstatorului, urmat de decuplarea ntreruptorului. Dup perioada de eantionare, urmeaz perioada de hold n care se face conversia valorii din condensator. Perioada de sample poate fi modificat de la 1 la 127 TAD , dar perioada de conversie este fixat la 12 TAD.

n sectiunia 17.5 din [20] se prezint modul de calcul al TAD i pentru a se obine o frecventa de eantionare de 1000ksps.

4.4.6 RTCC

RTCC este un circuit ce asigur pstrarea datei n format BCD, facilitnd astfel interpretarea ct mai rapid a datei fr a mai fi nevoie de prelucrri ulterioare. Se ofer posibilitatea de ntrerupere i toggle de output la intervale de o secund, un minut, o or i alte intervale mai mari. n mod intern perioada de lucru este de o jumtate de secund, dar pentru citire rezoluia este la o secund.

n ceea ce privete alarma ea poate fi setat ntr-un interval de la o jumtate de secund pn la un an i poate fi repetat de un numr de maxim 255 de ori. Dac se folosete opiunea de Chime se va repeta la nesfrit, detectnd atingerea numrului de 0 repetri contorul se va reiniializa.

Accesul la registrele pentru timp i pentru alarm se face doar dac bitul RTCSYNC, respectiv ALRMSYNC este zero. Acest interval de timp este de 32 de perioade de ceas, o citire sau o scriere n afara acestui interval producnd efecte nedefinite.

n figura 4.11 se prezint modul n care se incrementeaz registrul secundelor. Dup 32768 de perioade de ceas are loc incrementarea registrului.

n cazul n care se observ c referina nu are exact 32 768Hz se poate ajusta cu formula: (32 768- Frecven msurat)*60= Eroare. Acest valoare poate avea att valori pozitive ct i negative. Modulul va face coreciile necesare o dat la 1 minut, prin modificarea secundelor.

Pentru alarm se va seta data i timpul primei declanri, apoi se alege cnd(dup o secund, o zi, un an) se va declana i de cte ori se va repeta alarma la intervalul specificat. Data primei alarme este comparat cu o masc. De exemplu, dac se alege un interval de un minut nu se vor lua n considerare secundele pentru a se stabili perioada de declanare. La incrementarea registrului minutelor vom avea o alarm. n cazul extrem, de repetare la un interval de o secund, setarea datei primei alarme este inutil. Configuraia mti n acest caz face ca prima alarm s apar dup o secund de la setarea bitului de enable. Pentru nelegerea acestui modul recomand urmrirea [21]i [22].

4.4.7 Controller-ul de ntreruperi

Acest microcontroller are un numr de 46 vectori de ntrerupere i un numr de 58 de IRQ( surse de ntrerupere, inclusiv cele 5 externe). Att n modul single ct i n modul multi- vector se pot folosi registre de tip shadow(secondary register set).

Modul single vector : este modul default, n care va intra dup reset. Se va folosi aceiai adres indiferent de vectorul care a generat-o.

Modul multi vector : fiecare vector are asociat o adres unic calculat folosind o adres de baz i un deplasament.

ntreruperile pot avea prioritate ntre 1(minim) i 7(maxim). Prioritatea 0 se folosete pentru a inhiba ntreruperea. Controller-ul de ntreruperi va servi o ntrerupere de ordin superior, chiar dac exist una de ordin inferior n execuie. Aceiai ordonare i regul de servire apare i n cazul folosirii subprioritiilor ce au valori ntre 0(minim) i 3(maxim). Pe lng aceste reguli pentru ordonare se folosete i ordinea natural, unde 0 este maxim i vectorul 45 este minim. La intrarea n ISR(Interrupt service routine) este obligatoriu s se marcheze sursa care a generat ntreruperea pentru a evita ntreruperi de tip recursiv.

Registrele shadow(al doilea set de registre GPR) aduc o cretere a performanei deoarece nu mai este nevoie s se fac salvri de context pe stiv. Acestea sunt valabile pentru single vector, iar n multi vector sunt valabile doar pentru ntreruperile de nivel mai ridicat.

Tehnica TEMPORAL PROXIMITY INTERRUPT COALESCING, presupune folosirea unei cozi unde se pun ntreruperile, de grad egal sau mai mic cu un prag dat, i care vor fi apoi servite nlnuit. Se folosete un timer, care este declanat de apariia primei ntreruperi ce respect condiia de grad. Odat ajuns la zero, se vor procesa nlnuit toate acele ntreruperi care au respectat condiia de a intra n coada de ateptare. Pentru aceasta este nevoie s se ncarce pragul dorit n TPC i valoarea de unde se va decrementa n IPTMR( valoare pe 32 bii). Acest timer folosete direct SYSCLK, fr prescaler.

Se pot folosi de asemenea i pn la 5 intreruperi externe, care pot fi pe front cresctor sau descrector, i dou ntreruperi de tip soft, a cror declanare poate fi fcut exclusiv prin cod. Pentru nelegerea ntreruperilor recomand [23].

4.5 Protocoale folosite

4.5.1 I2C

Este un protocol de tipul master slave. Se folosesc dou linii pentru comunicare: una pentru date(SDA), i alta pentru semnalul de ceas(SCL). Ambele linii sunt de tipul open-drain, pentru a se putea modifica valoarea liniei din orice punct. Pe linia de SDA se pot ncrca datele fie de ctre master, fie de ctre slave; dar linia de SCL este permanent controlat de master, slave-ul putnd doar s prelungeasc timpul n care se gsete n starea '0'.

Liniile au valoarea default '1', datorit rezistenelor de pull-up Rp, care sunt conectate la Vdd, aa cum se poate vedea n figura 4.12. Pentru modificarea valorii la '0' se va conecta linia dorit la GND, fie din master, fie din slave.

Pentru a se modifica valoarea linie SDA, linia de SCL trebuie s fie n poziia low. Singurele exceptii de la aceast regul sunt condiiile de start i stop, n care datele trec din high n low i invers, dei linia semnalului de ceas are valoarea '1', aa cum se arat i n figura 4.13.

Datele transmise pe magistral au 8 bii n dimensiune, urmate apoi de bit de confirmare. n figura 4.14 se prezint schema general de transfer pe magistrala I2C. Repetarea startului apare pentru a nu se pierde arbitrarea atunci cnd se dorete s se transfere mai mult de 1 byte spre un dispozitiv.

Magistralele cu mai mult de un master au nevoie de arbitrare. n figura 4.15 s-a presupus c sunt conectate 2 astfel de dispozitive. Ambele verific linia de SCL i ncearc pornirea unui transfer, i implicit obinerea magistralei. Deoarece ambele au putut da startul, vor continua s pun datele n paralel, pn cnd Data1 este '1', ns SDA este '0', ceea ce nseamn c primul a pierdut magistrala, i astfel renun s mai pun date pe I2C.

Un mecanism similar celui de arbitrare apare i la semnalul de ceas i se numete 'clock streching'. Dac slave-ul mai are nevoie de timp pentru procesare va menine linia de clock la valoarea '0', exemplificat n figura 4.14, pentru a putea face procesriile necesare.

Protocolul I2C presupune trimiterea mai nti a adresei slave-ului de la care se dorete recepionarea/trimiterea datelor, nsoit de un bit de read/write, iar la final de ACK. n octeii urmtori se gsesc datele de la slave spre master, sau n sens invers. Cel care este destinatarul datelor trebuie s confirme transferul prin ACK. Asupra tipurilor de transfer voi reveni n capitolele urmtoare unde vor fi i exemplificate pentru DAC.

4.5.2 USB

Pentru aceast prezentare general a protocolului am folosit [24] i [25], precum i unele constatri experimentale.

4.5.2.1 O scurt introducere

Diferenele ntre funcionalitiile portului USB de pe placa de dezvoltare i cel de pe un PC sunt minime. Diferenele majore sunt urmtoarele: ofer suport doar pentru anumite clase sau dispozitive, poate suporta doar anumite tipuri de transfer, nu suport hub-uri, cantitatea de curent oferit este limitat.

Permite conectarea diverselor periferice la calculator prin folosirea unui cablu unic. ntr-un sistem coninnd o magistral USB, perifericele se pot conecta n serie sau ntr-o topologie sub form de stea pe mai multe nivele. Un avantaj important l reprezint conectarea de tip plug-and-play care nu necesit desfacerea carcasei sau repornirea sistemului.

Portul USB detecteaz adugarea unui nou periferic i determin n mod automat resursele necesare acestuia, inclusiv driver-ul software, rata de transfer i consumul de curent. Perifericele se pot afla la o distan de pn la 5 m unele fa de altele sau fa de un distribuitor(hub).

n configuraia de fa oferit de Microchip nu se poate folosi distribuitor. Din aceast cauz topologiile de tip stea nu pot fi implementate. De asemenea dei din punct de vedere al USB Host Stack se permite conectarea mai multor dispozitive in serie, placa de dezvoltare asigur un singur port de USB i astfel se poate conecta practic un singur periferic la un moment dat.

Fiecare funcie(periferic) conine informaii de configuraie care descriu posibilitile sale i resursele necesare. Aceste informaii sunt transmise calculatorului gazd ca rspuns la o tranzacie de control. naintea utilizrii unei funcii, aceasta trebuie configurat de calculatorul gazd. Aceast configurare presupune alocarea unei limi de band n cadrul magistralei USB i selectarea opiunilor specifice de configuraie.

4.5.2.2 Tipuri de transfer

Arhitectura USB permite patru tipuri de transferuri de date: de control, de ntrerupere, de date voluminoase i izocrone.

Transferurile de control se utilizeaz de driver-ele calculatorului gazd pentru configurarea dispozitivelor care sunt ataate la sistem.

Transferurile de ntrerupere se utilizeaz pentru date care trebuie transmise cu o ntrziere limitat. Transferul acestor date poate fi solicitat de un dispozitiv n orice moment, iar rata de transfer pe magistral nu poate fi mai redus dect cea specificat de dispozitiv. Tastatura sau mouse-ul pot folosi acest tip de transfer pentru notificarea apsrii unei taste, respectiv pentru trimiterea noilor coordonate ale cursorului.

Transferurile de date voluminoase (bulk) se utilizeaz cu periferice cum sunt memorii de mas, imprimante sau scanere. Aceste date sunt secveniale, i de dimensiuni mari. Fiabilitatea transferurilor este asigurat la nivel hardware prin utilizarea unui cod detector de erori i reluarea unui transfer cu erori de un anumit numr de ori. Rata de transfer poate varia n funcie de alte activiti de pe magistral.

Transferurile izocrone se utilizeaz pentru datele care trebuie furnizate cu o anumit rat de transfer constant i a cror sincronizare trebuie garantat. Un exemplu ar fi streaming-ul audio sau video, unde o eroare la transmiterea unui pachet duce la anularea retransmisiei i continuarea cu urmtorul din secvena de transfer.

n cazul aplicaiei dezvoltate se folosesc cu precdere transferuri de control i de ntrerupere, existnd suport i pentru bulk; transferurile izocrone nu sunt suportate.

4.5.2.3 Modelul de comunicaie USB

Protocolul USB este de tip asimetric, i folosete adresarea pentru identificarea dispozitivelor conectate. Spre deosebire de I2C magistrala nu este de tipul multimaster. Magistrala USB are 4 fire: VBUS i GND sunt folosite pentru alimentarea dispozitivelor iar D+ i D- se folosesc pentru transferul ntr-o singur direcie la un moment dat al datelor.

Comunicarea ntre host i periferic se face folosind fluxuri de comunicaie numite pipes, pentru realizarea legturii la nivel de end point-uri. End point-ul este folosit alturi de adresa device-ului pentru identificare. El este necesar deoarece la o adresa(la un dispozitiv) pot exista mai multe tipuri de transferuri fiecare fiind asociat cu un end point. Punctele terminale pot fi de intare sau de ieire, iar cel cu numr 0 este default fiind folosit pentru configurare.

Exist dou moduri de comunicaie printr-o conduct(pipe): ir sau mesaj. n modul ir, datele nu au o structur definit de specificaiile USB. Datele sunt transferate secvenial i au o direcie predefinit, de intrare sau de ieire. Conductele de tip ir permit transferuri de ntrerupere, bulk sau izocrone. n modul mesaj, datele au o anumit structur definit de specificaiile USB. Coninutul datelor transferate printr-o conduct de tip mesaj este interpretat de controller-ul USB. Aceste conducte sunt controlate de calculatorul gazd i permit doar transferuri de control, n ambele direcii, fiind folosite pentru configurarea dispozitivelor.

Punctele terminale conin buffere de intrare sau de ieire prin intermediul crora se realizeaz comunicaia ntre calculatorul gazd i dispozitivul USB. De exemplu, dac programul rulat pe calculatorul gazd transmite un pachet adresat unui anumit dispozitiv USB, acest pachet va fi depus n bufferul unui punct terminal de ieire al dispozitivului. Ulterior, controller-ul dispozitivului va citi din buffer pachetul recepionat. Dac dispozitivul trebuie s transmit date la calculatorul gazd, nu poate depune datele direct pe magistral, deoarece toate tranzaciile sunt iniiate de master. Dispozitivul va depune datele n buffer-ul unui punct terminal de intrare, iar aceste date vor fi transferate la cererea calculatorului printr-un pachet de intrare. Noiunile de intrare/ieire sunt relative la host. Master-ul a fost denumit alternativ calculator sau host. Pentru slave s-a folosit denumirea de dispozitiv.

4.5.2.4 Descriptorii de USB

Ierarhia de descriptori are ca rdcin la nivelul superior descriptorul de dispozitiv. La nivelul urmtor se afl descriptorii de configuraie; exist cte un asemenea descriptor pentru fiecare configuraie a dispozitivului. Pentru fiecare configuraie pot exista unul sau mai muli descriptori de interfa, n funcie de numrul de interfee ale configuraiei respective. n sfrit, pentru fiecare punct terminal al fiecrei interfee exist cte un descriptor al punctului terminal.

Descriptorul de dispozitiv este folosit pentru a oferi informaii generale despre dispozitiv: clasa/subclasa producator ID/produs ID, revizia de USB. Descriptorul de configuraie este folosit pentru a primi informaii legate de tipul alimentrii: proprii sau prin bus-ul de USB. n cazul n care un dispozitiv are asociate mai multe astfel de dispozitive, la un moment dat poate fi activat doar unul. Un numr oarecare de puncte terminale pot fi grupate logic ntr-un descriptor de interfa; care este folosit in cadrul dispozitivelor multifuncionale. La un moment dat pot fi activate mai muli asemenea descriptori. Conine informaii legate de numrul de puncte terminale i tipul de clas/subclas. Descriptori de end-point sunt folosii pentru a se stabili direcia, timpul de acces, laimea de band, adresa dispozitivului. Un alt descriptor opional dar care este implementat in USB Host Stack este cel de ir de caractere( string) folosit pentru a se obine informaii in plain text legate de capabilitiile dispozitivului.

4.5.2.5 Procesul de enumerare

Atunci cnd un dispozitiv este conectat/deconectat la magistrala USB, calculatorul gazd execut un proces numit enumerare pentru a determina modificrile aprute n configuraia sistemului USB. La conectarea unui dispozitiv USB la magistral, se execut urmtoarele operaii:

1. Calculatorul gazd folosind o rezisten determin conectarea unui nou dispozitiv.

2. Calculatorul gazd ateapt un timp de cel puin 100ms pentru ca tensiunea de alimentare a dispozitivului s devin stabil, dup care transmite o comand de validare i de resetare a portului. Folosind msurarea tensiunii pe liniile de date, se determin prezena rezistenelor de pull-up/pull-down, i astfel se determin viteza dispozitivului: vitez ridicat(480 Mbii/s) sau viteza normal (12 Mbii/s).

3. Dup terminarea procedurii de resetare, portul este validat. Dispozitivul se afl acum n starea implicit i poate absorbi un curent de maxim 100 mA de pe linia VBUS a magistralei. Dispozitivul va rspunde la tranzacii cu adresa implicit zero.

4. Calculatorul gazd solicit descriptorul de dispozitiv, iar dispozitivul transmite acest descriptor prin intermediul conductei implicite.

5. Calculatorul gazd asigneaz o adres unic dispozitivului.

6. Calculatorul gazd solicit descriptorii de configuraie, iar dispozitivul transmite calculatorului gazd aceti descriptori.

7. Pe baza informaiilor de configuraie, calculatorul gazd asigneaz o anumit configuraie dispozitivului. Dispozitivul se afl acum n starea configurat i toate punctele terminale ale acestei configuraii sunt configurate conform caracteristicilor specificate n descriptorii acestora.

Dispozitivul este pregtit pentru utilizare i poate absorbi de pe linia VBUS a magistralei curentul specificat pentru configuraia selectat.

Atunci cnd dispozitivul USB este deconectat de la un port USB, calculatorul gazd dezactiveaz portul respectiv i actualizeaz informaiile sale despre topologia magistralei.

4.5.2.6 USB Embedded Host Stack

n Application note [26] se face o scurt introducere a modului de funcionare a USB host adaptat pentru embedded. Articolul [27] vine ca i o completare a articolului precedent, insistndu-se mai mult pe partea de programare, cu multe exemple de cod.

4.5.2.6.1 Target Peripheral List( TPL)

Conine o descriere a dispozitivelor ce pot fi suportate de host fie pe baz de clas i de protocol (ca de exemplu tabelul 4.1 ) sau de VID-PID (ca de exemplu tabelul 4.2). n cazul microcontroller-ului, spre deosebire de PC, TPL rmne fix, putndu-se suporta doar dispozitivele declarate iniial.

DescriereNumele claseiCodul claseiCodul subclaseiProtocol

Flash DriveMass Storage0x080x060x50

Tabelul 4.1: Exemplu de TPL pentru Clas, Subclas i Protocol

DescriereProductorModelVID(vector ID)PID(product ID)

Device cu suport ADKGoogleTelefon/ tablet0x18D10x2D00

Tabelul 4.2: Exemplu de TPL pentru VID, PID

4.5.2.6.2 Arhitectura stivei

Este format din dou pri: maina de stri(pentru enumerarea dispozitivelor) i handler-ul de ntreruperi(pentru procese critice).

n figura 4.16 se prezint schema general pentru state machine. Iniializarea are rolul de a pregti controller-ul USB, i se realizeaz o singur dat dup reset, trecndu-se apoi n starea detached, n care se ateapt conectarea dispozitivelor. Un dispozitiv ataat trece din starea atached n starea de primire a unei adrese dac respect condiiile electrice specifice. Starea configured presupune pregtirea end point-urilor pentru a se realiza transferul bidirecional, printr-un apel al handler-ului de iniializare specific dispozitivului, folosind intrrile din TPL i Client Driver Table. La deconectare se trece din starea running n starea detached.

Stiva de firmware este o structur de tip ierarhic. Aplicaia( codul utilizatorului) reprezint ultimul nivel, USB Client Driver este folosit pentru iniializarea dispozitivului descoperit, iar USB Host Layer este librria care faciliteaz accesul la resursele hardware i ofer funcionalitatea de baz pentru modul: identificare, enumerare, managementul de drivere. Pot exista mai multe USB Client Driver dac se dorete oferirea suportului pentru un numr mai mare de dispozitive.

O organizare pe layers se folosete i pentru handler-ul de ntrerupere, avnd trei nivele: electric, mesaje USB i mesaje Android(ultimul nivel). Fiecare nivel trateaz evenimentele specifice, iar la ntlnirea unuia necunoscut se face o trimitere spre nivelele superioare pentru analiz.

4.5.2.6.3 Driver-ul client bazat pe evenimente

Aplicaia principal are rolul de a apela constant layer-ul de la nivelul cel mai sczut: USB host(sgeat #2). La terminarea unei activiti pe USB se va apela(#3) n client driver, iar dac este suportat, se va apela mai apoi aplicaia(#4). Apelurile, folosind structuri, trimit i informaii legate de surs i parametrii. Astfel tranziiile de la nivelele superioare, apar ca urmare a evenimentelor de pe USB, fiecare nivel avnd un state machine.

Layer-ul Host este influenat i de evenimetele ce apar pe magistral cum ar fi conectarea sau deconectarea unui dispozitiv. Apelul #2 are rolul de a permite tranziiile ntre sub-striile de la adresare sau configurare.

Se poate implementa driver-ul client i folosind polling. Diferena ntre cele dou metode apare la modul n care se face tranziia ntre stri, marcat prin folosirea de while loops ( polling) sau de ntreruperi i call backs( event based). Varianta cu ntreruperi este mai eficient. Exemple de call back sunt apelurile #3 i #4.

4.5.3 Android Open Accessory Protocol

Un USB host(accesoriul) va trebui s implementeze urmtorii pai:

ateapt i detecteaz conectarea device-ului cu Android

verific dac acest device suport modul accesoriu

dac nu este deja n acest mod va ncerca pornirea acestuia n modul amintit

stabilete comunicarea cu device-ul folosind protocolul amintit n subtitlu

Accesoriul verific la fiecare conectare a unui slave ca vendor ID device-ului s fie 0x18D1, i ID de produs s fie 0x2D00(ADK) sau 0x2D01(ADK i ADB). Dac nu se primesc aceste rspunsuri, microcontroller-ul va ncerca pornirea dispozitivului n mod accesoriu: trimite o comand de tip 51, de obinere a protocolului, iar device-ul va rspunde cu un numr nenul dac are implementat ADK.

Folosind comanda 52 se vor trimite pe rnd descrierile ctre accesoriu. Apoi se va trimite device-ului comanda 53 pentru a porni n modul accesoriu. Dup trimiterea comenzii 53, USB-ul de pe device se va reporni ceea ce duce la un nou proces de enumerare. De aceast dat vendor ID i product ID trebuie s fie cele corecte, n caz contrar, sau la orice eroare aprut pe parcurs, nseamn c device-ul nu cunoate protocolul cerut. Pentru mai multe detalii legate de structura acestor mesaje standard poate fi consultat seciunea 5.9. Comenzi USB din [25].

CommandRequest TypeRequestValueIndexLengthData(optional)

Get protocol

(5110)USB_Dir_out| USB_type_Vendor| USB_Device51002Get protocol

Send strings

(5210)USB_Dir_out| USB_type_Vendor| USB_Device5200... 5

String dimensionSend a string

Strart

(5310)USB_Dir_out| USB_type_Vendor| USB_Device53000Send Null

Tabelul 4.3: Comenzi de iniializare ADK

Dac ID-ul de productor este 0x2D00, atunci este o singur interfa cu dou endpoint-uri bulk, unul pentru intrare i altul pentru ieire. Dac primim ID 0x2D01, atunci sunt dou interfee(ADK i ADB) fiecare cu cte dou bulk endpoints. n tabelul 4.3 sunt prezentate schematic etapele protocolului, numerele fiind n baza zece. Valorile lui index pentru comanda 52 n ordine cresctoare sunt: productor, model, descriere, versiune, URI, i numr serial. URI se folosete pentru a se descrca aplicaia din Google Play n cazul n care nu este instalat pe telefon/tablet. Comenziile 52 i 53 nu se folosesc dac device-ul se afl deja n modul accesoriu.

4.6 Algoritmii propui

ntregul sistem poate fi privit ca i un sistem distribuit, deoarece fiecare modul i execut funcionalitatea independent de restul.

n figura 4.18 este prezentat schema general a aplicaiei. Codul de culori ofer o mai bun grupare vizual a componentelor. Perifericele productoare/consumatoare de date sunt colorate cu albastru, iar zonele partajate sunt de culoarea orange. Memoriile partajate pot fi privite ca i buffere, cu mai multe periferice care scriu i care citesc din aceste zone. Circuitele de USB i RTCC sunt colorate cu verde respectiv rou deoarece ndeplinesc funcionaliti speciale. RTCC se folosete pentru a controla procesul de actualizare a zonei comune vzut de USB, copierea datelor fcndu-se de la dreapta la stnga(sgeata de pe desen). Modulul USB este cel care comunic mai departe cu tableta. Direcia sgeilor arat modul de deplasare al datelor, fr a se insista pe tipul sau numele datelor care circul.

Datele care intr n ADC sunt de tip analogic, iar cele care intr, respectiv ies din IC i din PWM sunt de tip digital, de tip semnal dreptunghiular. RTCC este alimentat de o sinusoid de 32768Hz.

4.6.1 Conversia din analogic n digital

n figura 4.19 se prezint schema general de conversie din analogic n digital. Primul pas presupune eantionarea i conversia efectiv a celor dou tensiuni(canal 1 si canal 2). n funcie de ce zon folosim pentru salvare se va salva n zona 0 sau n 1. Valoriile pentru i sunt de la 0 la 7, iar pentru j sunt de la 8 la 15. Att i, ct i j se vor incrementa, iar dup ce au ajuns la 7 respectiv 15 se genereaz o ntrerupere i se reiniializeaz. n ntrerupere are loc citirea celor 8 valori din buffere, n funcie de zona de lucru i medierea lor. Eantionarea celor dou tensiuni se face n mod alternativ.

De exemplu, considerm c zona de lucru este 0. Se face conversia primei tensiuni i salvarea n buffer-ul 0, iar a doua tensiune se salveaz n bufferul 1. Se va continua cu salvarea canalului 1 n buffer-ul 2, i a canalului 2 n buffer-ul 3. Dup ce s-a scris i n bufferul 7 se genereaz ntreruperea. n ntrerupere se ine seama de zona curent de lucru i de alternana cu care se salveaz cele dou canale.

4.6.2 Msurarea turaiei

n figura 4.20 se prezint modul general n care se msoar frecvena unui semnal dreptunghiular. Ct timp nu apare un front cresctor se incrementeaz un timer. La apariia unui eveniment se genereaz o ntrerupere. n ntrerupere se verific dac a fost primul astfel de eveniment. n caz afirmativ se reiniializeaz timer-ul. La al doilea eveniment mai nti se va salva valoarea ceasului, apoi acesta se va reiniializa. Al treilea eveniment este considerat din nou ca fiind primul, aciunea algoritmului fiind similar.

n figura 4.21 se prezint cazul n care se msoar dou frecvene folosind un singur timer. Culoarea albastr reprezint primul canal, iar culoarea verde reprezint al doilea canal. n acest caz mai nti se analizeaz primul canal n ateptarea a dou fronturi de interes(F1 i F2). n acest timp orice eveniment pe al doilea canal este ignorat. Dup msurarea perioadei primului canal(T canal 1) acesta se ignor i se urmrete apariia a dou fronturi pe canalul 2. Ciclul apoi se reia cu primul canal. Pentru msurarea perioadei pe oricare canal se consider algoritmul prezentat n prima parte a seciunii.n mod similar, cazul de fa poate fi extins la orice numr de canale, creterea numrului ducnd la scderea ratei cu care se actualizeaz informaiile legate de frecvena lor.

4.6.3 Actualizarea datelor

Actualizarea datelor apare n figura 4.18 ca i un transfer ntre dou zone partajate. Actualizarea repezint o copiere a datelor din zona din partea dreapt n zona din partea stng.

n figura 4.22 sunt prezentate cele dou regimuri de funcionare a mecanismului de actualizare: normal i calibrarea motoarelor. n modul de funcionare normal se face o copiere a datelor la o frecven de 1Hz. Aceast frecven poate fi obinut folosind un circuit extern, un timer intern sau circuitul de RTCC. Circuitul de RTCC are avantajul c nu este folosit de alt component sau de ctre program.

n cazul n care se dorete o calibrare a motoarelor valoriile msurate vor fi transferate imediat ce au fost calculate. Pentru aceasta la fiecare modificare a factorului de umplere al PWM are loc un rspuns care cuprinde tensiuniile i frecvenele msurate.

4.6.4 Calibrare motoare

Procedura de calibrare presupune folosirea factorului de umplere al PWM care comand viteza motoarelor. Factorul de umplere va lua valoarea initial 100%, i va continua s scad att timp ct turaia motorului este diferit de zero. n cazul n care s-a ajuns la 0, motorul se consider oprit, i factorul de umplere se seteaz la zero. Procedura este evideniat n figura 4.23 i trebuie repetat pentru fiecare motor n parte.

Calibrarea are rolul de a stabili intervalul de valori pentru PWM care produce rotirea motorului. Ca i rezultat se elimin zonele cu factor de umplere mic, n care motorul are turaie 0.

n locul decrementrii factorului de umplere se poate porni de la valoarea zero, i apoi s se incrementeze ct timp turaia este zero. Aceast variant a algoritmului produce un prag al factorului de umplere mai mare dect varianta care presupune decrementarea. Explicaia const n faptul c pentru a se pune iniial n micare bobina rotorului este nevoie de un impuls de tensiune mai mare. Odat obinut micarea de rotaie, se poate reduce factorul de umplere cu cteva procente, fr a se constata oprirea motorului.

4.6.5 nlnuirea comenzilor pe USB

n figura 4.24 se prezint modul n care poate fi crescut performana transferurilor pe USB prin nlnuirea comezilor. Fiecare comand este identificat printr-un cod unic urmat de un numr cunoscut de argumente. n exemplul urmtor s-a considerat transmisia unui numr de 3 comenzi pe magistrala serial, fiecare comand fiind de dimensiune variabil. Fiecare dreptunghi are dimeunea de 1 octet. Se folosete un vector unde vor fi copiate comenziile, lungimea fiind egal cu suma dimensiunilor comenzilor n cazul maxim de nlnuire.n cazul extrem numr maxim de nlnuiri este egal cu numrul de comenzi de ieire pe magistrala serial. Numrul poate fi redus dac existena unor comenzi de ieire este exclusiv. Pointer-ul se folosete pentru a indica locaia urmtoare unde se poate copia informaia.

La primul pas se copiaz prima comand i se incrementeaz poziia pointerului cu 3, reprezentnd numrul de octei mutai. Aciuni similare se execut i pentru urmtoarele dou comenzi, pointer-ul indicnd la final locaia de dup argumentul comenzii 3. Operaia poate fi extins pn la copierea unui numr de 1023 de octei, dac se folsete modul bulk. Principalul avantaj al nlnuirii l constituie faptul c printr-un singur transfer de USB se vor transmite mai multe date. Un dezavantaj minor este reprezentat de logica de decodificare a mesajului, care presupune mprirea acestuia n tokens(comenzi) n funcie de codul aflat pe primul octet i manipularea individual a fiecrei comenzi.

Pentru a se trimite i date care nu constituie comenzi, sau a cror lungime este variabil, trebuie ca informaiile s fie mpachetate. n acest sens, se va folosi un cod de mesaj special, pentru a codifica informaiile care nu constituie comenzi. Pe urmtorul octet se va specifica numrul de bytes al mesajului, iar n urmtorii octei se vor copia datele efective. n acest caz pentru a se putea descifra mesajul este nevoie s se citeasc primi doi octei, primul este folosit pentru a marca un mesaj special, iar urmtorul pentru a specifica numrul de argumente componente.

O alt abordare pentru mesajele speciale presupune ncadrarea datelor ntre un cod special i un marcator de final(asemntor \n n C). Pentru a se include marcatorul de sfrit n corpul mesajului se va adopta o tehnic similar caracterelor escape din C. Lipsa marcatorului de final va permite citirea ntregului buffer de intrare al USB, ceea ce poate duce la pierderea comenziilor care nu vor mai fi interpretate.

Pentru introducerea mesajelor de dimensiune variabil, prima abordare este mai sigur i mai uor de implementat.

5. Proiectare de detaliu i implementare

n figura 5.1 se prezint schema general a aplicaiei. Microcontroller-ul(uC) este prezentat ca o component separat, cu rol n controlul traficului informaiei. Sgeiile indic direciile de circulaie ale datelor. Senzorii i elementele de acionare sunt prezentate ca i componente separate, dar o parte sunt uniti din interiorul uC, divizarea fiind fcut astfel doar pentru a evidenia rolul lor diferit n sistem.

n figura 5.2 se prezint structura aplicaiei din punct de vedere al depenenelor de componte hardware i software. Aplicaia de fa are ca i baz un exemplu oferit de Microchip, n care se folosete tableta pentru a controla 4 LED-uri, a citi 2 butoane i un poteniometru de pe plac. Codul de culori s-a folosit pentru a evidenia zonele care au presupus dezvoltare, sau care au avut nevoie doar de documentare i testare.

n partea superioar a imaginii sunt prezenate cu orange fiierele create pentru realizarea funcionalitilor propuse. Divizarea pe fiiere are rolul de a permite o grupare a algoritmilor folosii pentru ndeplinirea unui task. Fiierul mainDef.h conine o serie de variabile externe, vizibile din mai multe fiiere, precum i ncapsularea accesului pentru datele folosite de mai multe module prin folosirea de macro-uri. Pentru ndeplinirea unei funcionaliti se folote perechea de fiiere .h i.c. n fiierul header sunt redefinii regitrii folosii(pentru o denumire uniform) i parametrii de configurare. n fiierul surs se gsete codul efectiv. Main.c este fiierul principal, i folosete funcionaliti din restul modulelor. Conine iniializriile modulelor i bucla principal.

Android Accessory Framework i USB Stack sunt cele dou librrii care realizeaz comunicarea pe protocolul Andoid Open Accessory. Aplicaia folosete cele dou librrii amintite, mpreun cu Microchip Peripheral Library(MPL), care este folosit pentru accesul la modulele de baz ale microcontroller-ului. MPL folosete cod scris n ASM sau n C. Toate librriile au fost folosite ca atare, fiind nevoie doar integrarea lor n proiect i testarea funcionalitilor.

Folosirea modulelor a presupus analiza modului de operare i a interdependenelor existente, pentru a se folosi ct mai eficient un numr minim de astfel de componente. Partea de hardware a presupus design-ul folosind unelte cum ar fi falstad.com/circuit, prototipizarea pe breadboard i mprimarea efectiv a montajului pe o plac.

5.1 Modulul de DAC

Acest modul are o adres fix 0x60, pinii de A0- A2 find lipii la GND. Acest modul este un convertor pe 12 bii asigurnd astfel un interval de 4096 de valori. Ieirea este proporional cu intrarea, din aceast cauz este sensibil la valoarea intrrii.

S-au implementat funciile de scriere n registru i n EEROM precum i de citire a registrului i a memoriei. Memoria nevolatil poate fi folosit pentru a se programa o singur dat modulul, pentru ca apoi acesta s pstreze valoriile i dup o repornire a sistemului.

Semnturile celor dou funcii de scriere void writeDACRegister(unsigned int DACValue, unsigned short PowerDownOption) i respectiv a void writeDACRegisterAndEEPROM(unsigned int DACValue, unsigned int PowerDownOption) sunt identice, prima valoare fiind un numr ntre 0- 4095, iar cea dea doua valoare reprezint opiunea de power down, pentru a se obine high impedance dac se dorete. Implementarea acestor metode urmrete Reference Manual-ul de la productor.

Funcia de citire din DAC nu este folosit, semntura ei fiind BOOL readDACRegisterANDEEPROM (BYTE i2cbyte[]), i returneaz un boolean pentru a semnaliza dac operaia s-a executat sau nu cu succes, iar rezultatul este depus n i2cbyte[].

n figura 5.3 se prezint modul n care se poate scrie n registrele circuitului de DAC, fr salvarea n EEPROM. n primul octet se precizeaz adresa dispozitivului, mpreun cu tipul operaiei, n acest caz este una de scriere. n octetul al doilea i al treilea se prezint valoriile care trebuie ncrcate n registre, de interes fiind DAC Register, care va reprezenta valoarea ieirii; tipul operaiei se specific prin Fast Mode Command. Fiecare byte se va confirma(Ack) de ctre DAC. Pentru a se salva n EEPROM, n locul bitului de stop se repet coninutul octeiilor 2 i 3 de pe figur.

5.2 Modulul de Input Capture

S-a ales folosirea Timer 2 ca i baz de timp pe 16 bii, cu un prescaler de 16, i a ntreruperilor de la canalul 2, respectiv 3 de la Input Capture. Am ales folosirea unei abordri de tip state machine state pentru a se permite msurarea ct mai exact a dou frecvene folosind un singur timer.

Se definesc macro-urile pentru prima surs sampleIC2Start i sampleIC2Stop , respectiv sampleIC3Start i sampleIC3Stop, pentru a doua surs de frecven i se folosete o variabil care va trece prin cele 4 stri. Ca i exemplificare se folosete tabelul 5.1, abordarea fiind similar cu cea propus n seciunea 4.6.2.

Pentru msurarea lui IC2, variabila va lua mai nti valoarea sampleIC2Start, odat cu primul rising edge; la urmtorul eveniment pe IC2 va trece n sampleIC2Stop. n timpul n care variabila a avut una din cele dou valori enumerate mai sus, orice eveniment de pe IC3 va fi pur i simplu ignorat. n sampleIC2Stop, doar un eveniment pe IC3 va determina tranziia n sampleIC3Start, evoluia fiind similar pentru IC3.

Detecia opririi unuia dintre motoare se face folosind detectarea condiiei de overflow de la baza de timp, caz n care se verific dac variabila este sampleIC2Start sau sampleIC3Start , pentru a se determina sursa. Se va trece apoi la canalul urmtor n starea de start, pentru a se evita blocarea algoritmului.

stare actualrising edge stare urmtoareObservaii

sampleIC2StartIC2sampleIC2Stopreseteaz Timerul

IC3pstraz starea actual

sampleIC2StopIC3sampleIC3Startpreia valoarea din Timer i l reseteaz

IC2pstraz starea actual

sampleIC3StartIC2pstraz starea actual

IC3sampleIC3Stopreseteaz Timerul

sampleIC3StopIC3pstraz starea actual

IC2sampleIC2Startpreia valoarea din Timer i l reseteaz

Tabelul 5.1: Evoluia strilor pentru implementarea input capture

n continuare voi prezenta codul pentru ISR de input capture pentru primul canal:

1 | #if CaptureMotor1INTLevel == IC_INT_PRIOR_4

2 | void __ISR(CaptureMotor1INTVector, ipl4)

InputCapture2Routine(void){

3 | INTClearFlag(INT_IC2);

4 | bufferTemp= CaptureMotor1ReadCapture()& 0xFFFF;

5 | if(sampleICx== sampleIC2Start){

6 | TimerValueReg= 0; // reset the timer

7 | sampleICx= sampleIC2Stop; // go to next state

8 | }else

9 | if(sampleICx== sampleIC2Stop){

10| val1IC2= bufferTemp; TimerValueReg= 0; sampleICx=

11|

sampleIC3Start;}

12| if(CaptureMotor1ControlReg.ICOV)

13| val1IC2= InCapOVFL;

14| }

15| #endif

, i codul pentru ISR a timer-ului:

1 | void __ISR(_TIMER_2_VECTOR, ipl1) Timer2Routine(void){

2 | INTClearFlag(INT_T2);

3 | if((sampleICx== sampleIC2Start) ||(sampleICx== sampleIC2Stop)){

4 | sampleICx= sampleIC3Start; val1IC2= TimerOVFLInCap;

5 | }else

6 | if((sampleICx== sampleIC3Start) ||(sampleICx== sampleIC3Stop)){

7 | sampleICx= sampleIC2Start; val1IC3= TimerOVFLInCap;

8 | }

9 | }

5.3 Modulul de PWM

n cadrul acestui modul, spre deosebire de celelalte, nu sunt alte funcii dect cea de set up, nefiind necesare ntreruperi, totul fiind controlat de hardware.

Codul pentru funcia de set-up este urmtorul:

1 |MotorsDirectionConfigPins();

2 | MotorSpeedPWMConfigPins();

3 | setMotorsDirection(1);

4 | PWM_PRReg_FREQ= getPR_For_PWM(PWM_desired_freq, 1);

5 | OpenTimerForMotors(MotorConfigs, PWM_PRReg_FREQ);

6 | OpenOCMotor1(Motor1Configs, 0,0);//PWM motor 1

7 | OpenOCMotor2(Motor2Configs, 0,0);//PWM motor 2

Pinii de output ai modului de PWM trebuie marcai ca fiind de ieire.n funcia de mai sus se seteaz doar frecvena bazei de timp, factorul de umplere pentru motoare fiind fixat la zero.

5.4 Modulul de ADC

Active bufferIndexValoare

00channel4mas1

1channel8mas1

2channel4mas2

3channel8mas2

4channel4mas3

5channel8mas3

6channel4mas4

7channel8mas4

18channel4mas1

19channel8mas1

110channel4mas2

111channel8mas2

112channel4mas3

113channel8mas3

114channel4mas4

115channel8mas4

Tabelul 5.2: Folosirea buffer-elor de la ADC

n figura 5.2 se prezint modul n care sunt folosite cele 15 buffere pentru eantionarea alternativ a dou canale. Ordinea se salvare a celor dou canale eantionate este alternativ. La un moment dat se poate lucra cu o singur zon, fiind disponibile fie registrele 0- 7, fie 8- 15. n ntrerupere se citesc cele 4 valori pentru fiecare canal din zona activ, valoarea canalului fiind media lor. Modulul nu se poate folosi n cazul de fa la valoarea maxim, deoarece produce blocarea restului perifericelor, chiar dac are o prioritate mai mic dect restul.

5.5 Modulul de RTCC

n continuare se prezint o parte a void setUpRTCC_1secINT(), care realizeaz configurarea modulului i codul handler-ului de ntrerupere void __ISR(_RTCC_VECTOR, ipl7SRS) RtccIsr(void).

1|RtccInit();

2|while(RtccGetClkStat()!= RTCC_CLK_ON);

3|RtccChimeEnable();

4|RtccSetAlarmRptCount(255);

5|RtccSetAlarmRpt(RTCC_RPT_SEC);

6|RtccAlarmEnable();

n acest cod are loc o iniializare a modului de RTCC, urmat prin while-ul care testeaz dac este conectat oscilatorul extern. Urmtoarele 4 instruciuni sunt folosite pentru a seta alarm i repetarea ei nedefinit( funcia de chime).

1 | #if RTCCLevel== INT_PRIORITY_LEVEL_7

2 | void __ISR(_RTCC_VECTOR, ipl7SRS) RtccIsr(void)

3 | {

4 | INTClearFlag(INT_RTCC);

5 | SetInputCapture1(GetFreqMotor1());

6 | SetInputCapture2(GetFreqMotor2());

7 | SetVoltageBatt(GetChannel4Batt());

8 | SetVoltageSunt(GetChannel8Sunt());

9 | mLedRTCCToggle();

10| rtcc_1secINTR= TRUE;

11| }

12| #endif

Handler-ul de ntrerupere al RTCC este cel care controleaz schimbul de date de la i spre USB. Acest lucru se realizeaz prin cele 4 apeluri de macro i marcarea flag-ului rtcc_1secINTR cu TRUE. Variabila boolean se folosete n bucla principal din main pentru ncrcarea efectiv a datelor pe magistral. Pentru a se obine o frecven mai mare va trebui modificat repetarea alarmei la RTCC_RPT_HALF_SEC, ceea ce va dubla frecvena de trimitere a datelor. Toggle-ul LED-ului are scop de verificare vizual.

5.6 Programul principal

n continuare voi prezenta programul principal prin evidenierea zonelor importante pentru nelegerea algoritmului. Buciile de cod pot s fie diferite fa de cele din codul aplicaiei, deoarece unele linii de cod au fost nlturate pentru a se putea urmrii mai uor logica aplicaiei.

5.6.1 Structura comenziilor

Comenziile sunt definite folosind o enumerare, n locul unor typedef/macro pentru o grupare vizual mai eficient.

1 |typedef enum _ACCESSORY_DEMO_COMMANDS

2 |{

3 | COMMAND_getConfig_ADC = 0x01,

4 | COMMAND_getConfig_Fuses_PWM = 0x02,

5 | COMMAND_getConfig_InputCapture = 0x03,

6 | COMMAND_getValue_InputCapture = 0x04,

7 | COMMAND_getValue_Voltage = 0x05,

8 | COMMAND_setValue_PWM = 0x06,

9 | COMMAND_shutDown = 0x07,

10| COMMAND_initialPWMConfig = 0x08,

11| COMMAND_finishedPWMConfig = 0x09,

12| COMMAND_getConfig_MotorsID = 0x0A,

13| COMMAND_setDirectionMotor = 0x0B,

14| COMMAND_APP_CONNECT = 0xFE,

15| COMMAND_APP_DISCONNECT = 0xFF

16|} ACCESSORY_DEMO_COMMANDS;

, iar lungimiile sunt fixe:

1 | #define Command_getValue_Voltage_Size 4

ComandArg 1Arg 2Arg 3Arg 4Arg 5Arg 6Arg 7Arg 8

1ADC Size[Vref]{Vref}

2Freq procFPLLMULFPLLDIVFPLLODIVFPBDIVOC sizeFreq OCOC presc

3IC prescIC sizeEvent size

4HFreq IC 1LFreq IC 1HFreq IC 2LFreq IC 2

5HU untLU untHU batteryLU battery

6HDuty motor 1LDuty motor 1HDuty motor 2LDuty motor 2

7

8

9

10ID motor 1ID motor 2

11Dir motors

254

255

Tabelul 5.3: Comenziile trimise ntre tablet i uC

n tabelul 5.3 se prezint structura comenziilor. O parte a acestor comenzi sunt de tipul flag, i nu au argumente, contnd doar ID lor, cum ar fi 7,8,9. Pentru parametrii care ocup mai mult de un octet s-a folosit HArg respectiv LArg pentru partea superioar respectiv inferioar a argumentului. Comenziile au structur i lungime fix.

Pachetele de intrare i de ieire nu sunt altceva dect un ir de bytes, lucru evideniat prin codul care urmeaz:

1| typedef struct __attribute__((packed))

2| {

3| BYTE command;

4| BYTE data[MAX_COMMAND_DATA_Size];

5| }ACCESSORY_APP_PACKET outgoing_packet;;

Structura precedent poate fi folosit ca atare sau se poate considera c este format dintr-un vector de bytes, aa cum se folosete n codul urmtor:

1 |errorCode = AndroidAppRead(device_handle, (BYTE*)&command_packet, (DWORD)sizeof(command_packet));

2 |switch(command_packet->command)

3 |{

4 |

case COMMAND_setValue_PWM:5 |

commandSize= Command_setValue_PWM_Size+ 1;

6 |

if(initialPWMconfig== TRUE){

7 |

rtcc_1secINTR= TRUE;

8 |

SetInputCapture1(GetFreqMotor1());

9 |

SetInputCapture2(GetFreqMotor2());

10|

SetVoltageBatt(GetChannel4Batt());

11|

SetVoltageSunt(GetChannel8Sunt());

12|

}

13|

break;

14|

case COMMAND_initialPWMConfig:

15|

break;

16|

case COMMAND_finishedPWMConfig:

17|

break;

18|

case COMMAND_setDirectionMotor:

19|

break;

20|

case COMMAND_shutDown:

21|

break;

22|

case COMMAND_APP_DISCONNECT:

23|

break;

24|

default:

//Error, unknown command

25|

DEBUG_ERROR("Error: unknown command received");

26|

break;

27|}

n timpul citiri cu AndroidAppRead, pe magistrala USB pot exista mai multe comenzi nlnuite. Prin verificarea primului octet, care indic lungimea primei comenzi, se determin numrul de bytes rmai pentru procesare i adresa din cadrul vectorului de unde se va continua procesarea.

1| size-= commandSize;

2| relativeAddressInCommandPacket+= commandSize;

3| if(size!= 0)

4| memcpy(command_packet,&read_buffer[relativeAddress],size);

5.6.2 Trimiterea datelor ctre tablet

n cazul n care se trimit mesaje la vitez maxim, fr a folosi ntrzierea de o secund se produce nclzirea tabletei. Pentru a se limita numrul de mesaje trimise n bucla principal din main se verific dac a trecut o secund de la ultima transmisie:

1| if(rtcc_1secINTR== FALSE)

2| continue;

Se verific dac sunt i alte operaii de scriere n ateptare, iar n caz negativ se va putea trimite mesajul dorit. Pentru a crete eficiena n coada de mesaje pot fi puse mai multe mesaje, fiecare de dimensiune definit.

1| if(writeInProgress == FALSE){

2|outgoing_packet.command = COMMAND_getValue_InputCapture;

3|outgoing_packet.data[0]= ....

4|memcpy(&write_buffer[adresaWrite], (BYTE*)&outgoing_packet, Command_getValue_InputCapture_Size+ 1);

5|adresaWrite+= Command_getValue_InputCapture_Size+ 1;

6| }

n final are loc i scrierea propriuzis, precum i marcarea faptului c a avut loc o scriere(writeInProgress ):

1| if(writeInProgress== FALSE){

2| rtcc_1secINTR= FALSE;

3|writeInProgress= TRUE;

4|errorCode = AndroidAppWrite(device_handle, write_buffer, adresaWrite);

5| }

5.6.3 Funcia de trimitere a datelor ctre Android

n continuare se va prezenta modul n care se trimit datele ctre tableta Android, fiind evideniate i fiierele n care sunt definite funciile respective, pentru a se putea urmrii nivelurile multiple de redirectri care apar ca urmare a existenei layer-urilor.

usb_host_android.c:: AndroidAppRead(void* handle, BYTE* data, DWORD size) . Se face o parcurgere a numrului de dispozitive Android i fiecare va fi notificat. Parametrul handle reprezint informaia primit la conectara dispozitivului, iar data este un buffer unde va fi depozitat informaia. Dac la acest nivel se face verificarea de device la nivel de Android, la urmtorul nivel de redirectare se va face verificarea de adresa, RX/TX busy, stare:

usb_host_android_protocol_v1.c::AndroidAppRead_Pv1(void* handle, BYTE* data, DWORD size). Se folosete o redirectare la:

usb_host.c::BYTE USBHostRead( BYTE deviceAddress, BYTE endpoint, BYTE *pData, DWORD size ), unde se va verifica la nivel de tip de endpoint i starea ultimului transfer. Se va face o nou redirectare la o metod din acelai fiier

void _USB_InitRead( USB_ENDPOINT_INFO *pEndpoint, BYTE *pData, WORD size ) care va face ncrcarea efectiv a registrelor cu valorile necesare.

5.6.4 Iniializarea comunicaiei pe USB i ADK

Se folosesc funciile: USBHostInit(unsigned long flag) i AndroidAp