SPECIALIZAREA: AUTOMATICĂ ȘI INFORMATICĂ APLICATĂ PROIECT DE DIPLOMĂ Modul CAN-USB pentru testarea dispozitivelor conectate într-o rețea CAN… [610438]

UNIVERSITATEA TEHNICĂ „GHEORGHE ASACHI” DIN IAȘI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DOMENIUL: INGINERIA SISTEMELOR
SPECIALIZAREA: AUTOMATICĂ ȘI INFORMATICĂ APLICATĂ
PROIECT DE DIPLOMĂ
Modul CAN-USB pentru testarea
dispozitivelor conectate într-o rețea
CAN
Coordonator șt iințific
Conf.dr.ing. Mihai Postolache
Partener Absolvent: [anonimizat], 2018

DECLARAȚIE DE ASUMARE A AUTENTICITĂȚII
LUCRĂRII DE DIPLOMĂ
Subsemnatul(a) CONSTANTIN ABĂCEOAE ,
legitimat(ă) cu seria XT nr. 595725, CNP [anonimizat]
autorul lucrării MODUL CAN-USB PENTRU TESTAREA DISPOZITIVEL OR CONECTATE
ÎNTR-O REȚEA CAN
elaborată în vederea susținerii examenului de finalizare a studiilor de licență
organizat de către Facultatea de Automatică și Calculatoare din cadrul Universității
Tehnice „Gheorghe Asachi” din Iași, sesiunea IULIE-2018 a anului universitar
2017-2018, luând în considerare conținutul Art. 34 din Codul de etică universitară al
Universității Tehnice „Gheorghe Asachi” din Iași (Manualul Procedurilor, UTI.POM.02 –
Funcționarea Comisiei de etică universitară), declar pe proprie răspundere, că această
lucrare este rezultatul propriei activități intelectuale, nu conține porțiuni plagiate, iar
sursele bibliografice au fost folosite cu respectarea legislației române (legea 8/1996) și a
convențiilor internaționale privind drepturile de autor.
Data Semnătura
20-06-2018

Cuprins
Introducere…………………………………………………………………………………………………………………….. 1
Capitolul 1. Magistralele protocoalelor de comunicație ………………………………………………………. 4
1.1. Rețeaua Controller Area Network (CAN) ……………………………………………………………….. 4
1.1.1. Avantajele rețelei CAN ………………………………………………………………………………….. 4
1.1.2. Formatul cadrelor …………………………………………………………………………………………. 5
1.1.2.1. Cadrul de date ……………………………………………………………………………………….. 5
1.1.2.2. Cadrul de cerere …………………………………………………………………………………….. 6
1.1.2.3. Cadrul de eroare și de supraîncărcare ……………………………………………………….. 6
1.2. Universal Serial Bus (USB) ………………………………………………………………………………….. 7
1.2.1. Tipuri de transfer ………………………………………………………………………………………….. 7
1.2.2. Tipuri de conectori ………………………………………………………………………………………… 8
1.2.3. Versiuni USB ……………………………………………………………………………………………….. 8
Capitolul 2. Tehnologiile Hardware și Software folosite ……………………………………………………… 9
2.1. Placa de dezvoltare STM32F407G – DISCOVERY …………………………………………………. 9
2.1.1. Organizarea memoriei și arhitectura magistralei interne …………………………………… 10
2.1.2. Modulul CAN …………………………………………………………………………………………….. 11
2.1.2.1. Recepționarea mesajelor ……………………………………………………………………….. 11
2.1.2.2. Transmiterea mesajelor …………………………………………………………………………. 12
2.1.3. Modulul DMA ……………………………………………………………………………………………. 13
2.1.4. Modulul USB OTG_FS ……………………………………………………………………………….. 14
2.1.4.1. Transmiterea mesajelor …………………………………………………………………………. 14
2.1.4.2. Recepționarea mesajelor ……………………………………………………………………….. 14
2.2. Adaptorul PCAN -USB ………………………………………………………………………………………. 14
2.3. Transceiverele CAN MCP2552 …………………………………………………………………………… 15
2.4. STM32CUBE IDE, Eclipse IDE și PCAN-view ……………………………………………………. 15
Capitolul 3. Descrierea aplicației realizate ………………………………………………………………………. 17
3.1. Interfața grafică …………………………………………………………………………………………………. 17
3.1.1. Conectarea aplicației cu placa de dezvoltare …………………………………………………… 18
3.1.2. Configurarea canalelor de CAN ……………………………………………………………………. 19
3.1.3. Transmiterea mesajelor de date din interfață …………………………………………………… 20
3.1.4. Recepția mesajelor în interfață ……………………………………………………………………… 22
3.1.5. Filtarea mesajelor de CAN …………………………………………………………………………… 23
3.2. Aplicația de pe placa de dezvoltare ………………………………………………………………………. 25
3.2.1. Planificatorul ……………………………………………………………………………………………… 25
3.2.2. Recepția mesajelor în adaptor trimise din interfață ………………………………………….. 27
3.2.3. Transmiterea mesajelor de CAN …………………………………………………………………… 27
3.2.4. Recepția mesajelor pe CAN și transmiterea pe USB ……………………………………….. 28
Capitolul 4. Testarea aplicațiilor și rezultatele experimentale …………………………………………….. 30
Capitolul 5. Concluzii …………………………………………………………………………………………………… 33
Bibliografie………………………………………………………………………………………………………………….. 34
Anexe………………………………………………………………………………………………………………………….. 35
Anexa 1. Recepția mesajelor USB în întrerupere …………………………………………………………. 35
Anexa 2. Intreruperea de 10us …………………………………………………………………………………… 35

Anexa 3. Task-ul de 1ms …………………………………………………………………………………………… 36
Anexa 4. Task-ul de 2ms …………………………………………………………………………………………… 37
Anexa 5. Funcția de trimitere a mesajelor pe CAN ………………………………………………………. 38
Anexa 6. Funcția de inițializare a filtrelor de CAN pentru toate mesajele ………………………..39
Anexa 7. Funcția de impachetare a mesajelor de CAN primite ………………………………………. 39
Anexa 8. Rutina de tratare a intreruperii DMA …………………………………………………………….. 41
Anexa 9. Rutina de tratare a intreruperii de recepție a mesajelor de CAN ………………………..41
Anexa 10. Funcția de pregătire a mesajelor de pe USB …………………………………………………. 42
Anexa 11. Thread-ul de recepție a mesajelor USB in interfața grafică …………………………….. 48

Introducere
Introducere
De la inventarea sa de către Robert Bosch în anul 1986 și până la lansarea oficială în anul
1986 [1], rețeaua Controller Area Network (CAN) a trecut prin mai mulți pași de modernizare
(CAN2.0 în 1991) și standardizare (ISO1898 în 1993). Un pas important a fost trecerea în anul
2012 de la formatul clasic la formatul CAN cu date flexibile (CAN FD), care poate extinde
câmpul de date de la 8 la 64 de octeți și are opțiunea de a schimba rata de transmisie a datelor, în
timp ce rămâne compatibil cu cadrele CAN 2.0 [2]. Acest nou format crește capacitatea de
transfer a rețelei și a împins câmpul de date al cadrelor CAN dincolo de limita de 1Mbps a
cipurilor CAN de mare viteză.
În ultimii ani s-a ajuns ca într-un automobil să fie folosite aproximativ 70 de dispozitive
electronice de control (ECU). Aceste dispozitive cresc prețul automobilului, deoarece fiecare
dispozitiv se ocupă cu o anumită funcționalitate în cadrul acestuia. Un ECU este un calculator
încorporat care asigură motorului și celorlalte componente ale automobilului toate comenzile
calculate pe baza datelor primite de la senzori. De exemplu, la ultimele modele de mașini apărute
un ECU este folosit pentru a controla forța de frânare, el ajustând această forță în funcție de
diversele situații apărute. De aseemenea, astfel de dispozitive pot fi folosite și pentru controlul
luminilor, ștergătoarelor ușilor, sistemele multimedia, GPS etc. [3]
Controller Area Network(CAN) este cel mai utilizat protocol folosit pentru comunicația
dintre ECU-uri. Mai mult de atât, există mai multe implementări ale rețelelor industriale bazate
pe CAN, adică CANopen și DeviceNet, care au extins chiar mai mult domeniul de automatizare
industrială.
Creșterea numărului și a
complexității sistemelor electronice din
automobile a impus utilizarea sistemelor
de comunicație multiplexate, cum este și
CAN. Numărul de unități de control ce
pot fi conectate la magistrală variază în
funcție de viteza și de numărul
parametrilor ce trebuie transmiși. [4]
După crearea primelor chip-uri CAN separate, produse de către Intel și Phillips în 1987,
controlerele CAN au fost aproape incluse de toate familiile de micocontrolere atât pentru piețele
auto cât și pentru cele industriale.
Adaptoare CAN-USB au fost create în scop comercial pentru dispozitivele mobile de
CAN, care sunt disponibile ca soluții de tip black-box, dar care nu au flexibilitate și nu pot fi
personalizate pentru aplicații care au anumite cerințe.
1
Figura 1.Numărul redus de conexiuni datorat rețelei CAN

Constantin Abăceoae
Adaptoarele CAN-USB pot fi foarte ușor implementate utilizând microcontrolere cu scop
general conectate la controlere CAN și USB externe din punct de vedere al costurilor sistemului.
Microcontrolerele pe 8 biți precum AT89S51 [5] sau AT89C52 [6] se conectează la controlere
USB externe cum ar fi PDIUSBD12 [5] și respectiv FT245BM [6], și folosind controlerului
CAN SJA1000 se crează un adaptor personalizat USB-CAN (Fig. 3).
În [7] este propus un design al unui convertor CAN-USB, care permite ca portul USB să
fie utilizat pentru controlul dispozitivului CAN. A fost dezvoltată o interfață grafică (GUI) în
scopuri de testare, care se bazează pe o biblioteca API (Application programming Interface)
pentru acces la portul serial virtual.
În scopul realizării adaptorului (Fig. 4) este folosit un microcontroler pe 32 biți cu
procesor ARM Cortex – M4. Controlerul de CAN și cel de USB integrate deja pe placa de
dezvoltare și software-ul personalizat, ajută la crearea acestui adaptor USB- CAN, care poate fi
ușor portat pe majoritatea plăcilor oferite de cei de la STMicroelectronics. Spre deosebire de [7],
PC-ul gazdă rulează o interfață grafică dezvoltată utilizând bibliotecile standard furnizate de
sistemul de operare Windows.
2
Figura 2.Utilizarea unui adaptor USB-CAN pentru monitorizarea rețelei
CAN
Figura 3.Adaptor CAN-USB care utilizează controlere USB și CAN separate

Introducere
Un astfel de adaptor CAN-USB poate fi un instrument util în ceia ce privește modul de
acces pentru fiecare dispozitiv care are un port USB. Acesta poate fi folosit în majoritatea
aplicațiilor destinate monitorizării rețelei CAN, sau a nodurilor CAN configurate la distanță, sau
măsurarii și calibrării exact ca în [8]. Astfel dispozitivul și interfața grafică aduc un plus în,
comparație cu produsele aflate deja în circulație, prin costul redus, flexibilitatea portării codului
pe o gamă largă de microcontrolere, dar și usurința prin care un utilizator poate extrage mesajele
de pe o rețea CAN.
În următoarele secțiuni vor fi prezentate modul de funcționare a celor două protocoale de
comunicație folosite, resursele hardware și software folosite, precum și modul de realizare a
celor două aplicații. Utilizatorul poate vedea în timp real, cu ajutorul interfeței grafice și a
unei plăci de dezvoltare cu rol de adaptor USB-CAN, mesajele care sunt transmise de alte
noduri din rețeaua. Pe lângă faptul că poate recepționa mesaje din rețea, utilizatorul poate
și să transmită propriile mesaje, care pot fi interpretate în mai multe moduri la recepția lor
pe adaptorul USB-CAN. Astfel, acestea pot fi interpretate ca mesaje de filtrare, de
configurare canale de CAN, dar și ca mesaje de date obișnuite. Mesajele de configurare
sunt necesare pentru a inițializa adaptorul astfel încât să corespundă cu viteza de
comunicație a ECU-ul testat. Filtrarea mesajelor este necesară deoarece pe utilizator s-ar
putea să nu îl intereseze numărul mare de mesaje recepționate, el astfel poate alege exact
ce ID-uri să fie vizualizate. Software-ul pentru placa de dezvoltare STM32F4DISCOVERY și
desigur pentru interfața grafică va fi cu ușurintă descris prin diverse scheme logice create. În
final se vor pune în evidență testele experimentale, rezultatele dar și o serie de concluzii.
3
Figura 4: CAN-USB adaptor utilizând periferice CAN și USB
integrate

Constantin Abăceoae
Capitolul 1. Magistralele protocoalelor de comunicație
1.1. Rețeaua Controller Area Network (CAN)
CAN este o magistrală standardizată serială, de broadcast, dezvoltată de BOSCH și este
folosită în domeniul automotive pentru conectarea mai multor module ECU (Electronic Control
Unit). Unul din avantajele pe care aceasta magistrală le aduce este costul redus, întrucât pentru a
realiza comunicația sunt necesare doar 2 fire. Comunicația diferențială face ca semnalul electric
să fie transferat pe propriul lui canal, astfel face magistrala CAN potrivită pentru medii cu
interferențe electromagnetice și voltaj scăzut.
Protocolul este unul cu acces multiplu și cu mecanism propriu de detecție a coliziunilor și
arbitraj în funcție de ID-ul mesajului (CSMA/CD + AMP). CSMA (Carrier Sense Multiple
Acces) semnifică faptul că fiecare nod dintr-o rețea trebuie sa aștepte o anumită perioadă înainte
să inceapă să transmită un mesaj. CD + AMP (Collision Detection + Arbitration on message
priority) înseamnă că arbitrarea mesajelor în rețea se realizează printr-un mecanism destul de
simplu, nodul cu identificatorul cel mai mic câstigă mereu accesul pe magistrală.
În rețelele CAN, spre deosebire de alte rețele, precum USB sau Ethernet, în care
conexiunile sunt punct-la-punct cu pachete de dimensiune mare, se trimit pachete mici de date
către toate nodurile rețelei (transmisie de tip broadcast), ceea ce asigura consistența datelor în
fiecare nod. În cazul altor protocoale prezența câmpurilor nod-sursă și nod-destinație este
obligatorie, dar în cazul acestui protocol prezența acestor câmpuri ar fi inutilă.
Protocolul CAN a fost creat pentru transferuri de date sigure, astfel el include cinci
metode de verificare a erorilor: două la nivelul biților și trei la nivelul mesajului. Dacă un mesaj
ridică una dintre cele 5 erori atunci mesajul nu este acceptat și este generat un cadru de eroare
pentru nodul de primire. Dacă nodul care încearcă să transmită mesajul eronat de un anumit
număr de ori, controlerul CAN poate să blocheze accesul la magistrală pentru acel nod. [9]
1.1.1. Avantajele rețelei CAN
Cost redus
CAN este o rețea ieftină și durabilă care ajută la conectarea mai multor dispozitive CAN
între ele. Pentru fiecare dispozitiv de control electronic se pot înlocui porturile de intrare/ieșire
analogice și digitale cu o interfață CAN. Realizând acest lucru se reduce greutatea totală și costul
unul automobil.
Comunicație Broadcast
Într-o comunicație broadcast un mesaj este trimis către toate nodurile dintr-o anumită
rețea. La recepția mesajului de un anumit nod, acesta are s arcina să decidă ce mesaje sunt
relevante și să le filtreze pe restul. Această structură permite modificarea rețelelor CAN fără
întreruperea funcționării acestora, cu impact minim asupra funcționalității și performanțelor. Pot
fi eliminate noduri sau pot fi introduse noduri noi în rețea fără a fi necesare schimbări hardware
sau software în celelalte noduri.
4

Capitolul 1. Magistralele protocoalelor de comunicație
Priorități
Atunci când două noduri doresc să transmită un mesaj, cel mai prioritar va transmite
mesajul iar celălalt va aștepta până va primi și el acces la magistrală. Această arbitrare este sigură
și duce la transmisia fără întreruperi a mesajelor mai prioritare. De asemenea permite rețelelor
să respecte constrângeri de timp deterministe.
Detecție/Corecție Erori
Specificația CAN include un cod de redundanță ciclică (CRC) pentru a efectua
verificarea erorilor pe conținutul fiecărui cadru. Frame-urile cu erori sunt ignorate de toate
nodurile și poate fi transmis un cadru de eroare pentru a semnala eroarea în rețea. Erorile globale
și locale sunt diferențiate de către controler, iar dacă sunt detectate prea multe erori, nodurile
individuale pot opri transmiterea erorilor sau se pot deconecta complet de la rețea.
Imunitate crescută la perturbații
Daca transmisia se realizează pe 2 fire torsadate, orice perturbație electromagnetică va
afecta în egală măsură ambele fire. Datorită transmisiei diferențiale pe cele 2 fire, la capătul
receptor al comunicației se realizează scăderea celor 2 semnale, ceea ce accentuează semnalul
util și anulează zgomotul de fond. [4]
1.1.2. Formatul cadrelor
Protocolul pune la dispoziție 4 tipuri de mesaje, în funcție de conținutul și rolul acestora:
cadrul de date, cadrul de cerere, cadrul de eroare și cadrul de supraîncărcare .
1.1.2.1. Cadrul de date
Cadrul de date este cel folosit efectiv pentru a transmite informații între mai multe
noduri. La un moment dat un singur nod poate transmite informații, în timp ce celelalte noduri
așteaptă informațiile. Fiecare nod este responsabil pentru datele pe care le primește. În funcție de
ID-ul recepționat acesta decide dacă informațiile primite sunt relevante pentru el.
Toate aceste mesaje pot fi împachetate în două formate: formatul standard (cu 11 biți de
ID) și formatul extins (cu 29 biți de ID). Iar fiecare câmp din acest format este definit în felul
următor:
SOF ( Start Of Frame): marchează începutul cadrului, și constă într-un singur bit de nivel
logic 0;
Câmpul de arbitrare: format din ID și din câmpul RTR;
RTR (Remote Transmission Request ): bit recesiv pentru cadrele de date;
IDE (ID extended): un bit pe nivelul logic 1 indică faptul că ID-ul este în format extins și
că mai urmează incă 18 biți de ID;
r: bit rezervat;
DLC (Data Length Code) : specifică lungimea câmpului de date;
Câmpul de date: informațiile transmise;
CRC (Cyclic Redundancy Check): folosit pentru detecția erorilor;
ACK (Acknowledge): fiecare nod care primește mesajul va forța bitul recesiv primit într-
5

Constantin Abăceoae
un bit dominant, dacă nu se va întâmpla acest lucru se va semnala o eroare;
EOF (End Of Frame): marchează sfârșitul mesajului;
SRR (Substitute Remote Request): este un bit recesiv folosit pentru a asigura o arbitrare
corectă în caz că este transmis în același timp un frame standard și un frame extins;
IFS (InterFrame Space): distanța dintre doua frame-uri;
r0: bit rezervat.
1.1.2.2. Cadrul de cerere
Cu ajutorul câmpului RTR, un nod poate cere transmisia unui mesaj. Formatul cadrului
de cerere este asemănător cu a celui de date, doar că are anumite caracteristici: nu există câmp de
date, bitul RTR trebuie să fie recesiv iar prin ID se specifică ce mesaj se dorește a fi primit.
1.1.2.3. Cadrul de eroare și de supraîncărcare
Cadrul de eroare este un mesaj special transmis atunci când un nod detectează o eroare
într-un mesaj. Un sistem elaborat de contoare de eroare nu permite transmițătorului cu eroarea
să ocupe magistrala prin incercările repetate de transmitere a mesajului. Cadrul de supraîncărcare
este similar cu cadrul de eroare cu privire la format și este transmis de un nod care devine prea
ocupat. Oferă în primul rând o întârziere suplimentară transferului dintre mesaje. [9]
6
Figura 1.1: Formatul câmpului standard si extins

Capitolul 1. Magistralele protocoalelor de comunicație
1.2. Universal Serial Bus (USB)
Magistrala USB a fost creată de un grup de firme sub denumirea unei asociații USB
Implementers Forum (USB-IF). Asociația cuprindea următoarele firme: Compaq, Digital, IBM,
Intel, Microsoft, NEC și Northern Telecom. [10]
Universal Serial Bus e ste un standard industrial care definește cabluri, conectori și
protocoale de comunicații pentru conectare, comunicație și alimentare între calculatoare și
dispozitive.
USB a fost conceput pentru a standardiza conectarea perifericelor computerelor (inclusiv
tastaturi, dispozitive de indicare, camere digitale, imprimante, playere media portabile, unități de
disc și adaptoare de rețea) la computerele personale, atât pentru a comunica, cât și pentru a
furniza energie electrică. În mare parte, a înlocuit o varietate de interfețe anterioare, cum ar fi
porturile seriale și porturile paralele, precum și încărcătoare separate pentru dispozitive portabile,
astfel a devenit un lucru obișnuit pe o gamă largă de dispozitive. Acest standard funcționează cu
până la 10 Gbps și se găsește în peste 15 miliarde de PC-uri, electronice de consum și dispozitive
mobile. [11]
1.2.1. Tipuri de transfer
1.Transferurile de control sunt utilizate pentru operațiunile de comandă și stare. Sunt
utilizate pentru configurarea dispozitivelor USB Alte drivere pot utiliza transferuri de
control în moduri specifice implementării. Lungimea pachetelor de control pe anumite
dispozitive poate fi de maxim 8 octeți, dimensiunea pachetului poate crește până la 64 de
octeți în cazul dispozitivelor de mare viteză.
2.Transferurile de întrerupere sunt utilizate atunci când datele trebuie să fie transferate
cu o anumită intârziere. Pentru a se putea realiza transferul rata de transfer pe magistrală
trebuie să fie aceiași cu cea specificată de dispozitiv.
3.Transferurile de date voluminoase (“bulk”) se utilizează pentru periferice cu o
necesitate mare de transfer de date, cum sunt imprimantele sau scanerele. Aceste date
sunt secvențiale. Acest tip de transfer oferă și un mod de corecție a erorilor sub forma
unui câmp CRC16 (Cyclic redundacy check), care asigură transmiterea și primirea
datelor fără erori. Rata de transfer poate varia în funcție de alte activități de pe magistrală.
Transferurile bulk utilizează lațimea de bandă pe magistrală după ce toate celelalte
tranzacții au fost alocate. Aceste tipuri de transferuri sunt acceptate numai de
dispozitivele de mare viteză. Dimensiunea maximă a acestor buffere poate fi de maxim
64 de octeți. Un transfer bulk poate fi considerat complet după ce a transferat cantitatea
exactă de date solicitate.
4.Transferurile izocrone (isos – egal, chronos – timp) se utilizează pentru datele care
trebuie furnizate cu o anumită rată de transfer constantă și a căror sincronizare trebuie
garantată. Conțin informații sensibile în timp, de exemplu cu ar fi cele audio sau video,
care sunt necesare să fie transferate în timp real. Acestea trebuie să fie generate cu rata cu
care au fost trimise deoarece doar astfel se poate păstra sincronizarea dintre date.
7

Constantin Abăceoae
Dimensiunea maximă a buffere-lor de transmisie poate fi de maxim 1024 octeți în cazul
dispozitivelor de mare viteză . [10]
1.2.2. Tipuri de conectori
În momentul de față conectori USB se găsesc în trei formate:
•formatul standard destinat echipamentului desktop sau portabil, de tip A și B;
•mini destinat echipamentelor mobile;
•micro pentru echipamentele mobile cu profil redus, cum ar fi telefoanele mobile și
tabletele.
1.2.3. Versiuni USB
Versiunea 1.0 publicată în 1996 cu o rată de transfer maximă de 12 Mbiți/s. O versiune
1.1 a fost adoptată 2 ani mai târziu.
Versiunea 2.0 publicată în anul 2000 cu o rată de transfer de la 12 Mbiți/s până la 480
Mbiți/s. Pentru dispozitivele mobile a fost elaborat versiunea USB OTG („ On-the-Go”),
ca o versiune îmbunătațită a versiunii 2.0 care permite conectarea dispozitivelor fără un
calculator gazdă.
Vesiunea 3.0 a fost finalizată în anul 2008 care permite transferuri de până la 5 Gbiți/s. O
versiune 3.1 a fost adoptată câțiva ani mai târziu, care permite transferuri de până la 10
Gbiți/s. [10]
8
Figura 1.2: Tipurile de conectori USB

Capitolul 2. Tehnologiile Hardware și Software folosite
Capitolul 2. Tehnologiile Hardware și Software folosite
2.1. Placa de dezvoltare STM32F407G – DISCOVERY
Kitul STM32F4DISCOVERY utilizează capabilitățile microcontrolerelor STM32F407 de
înaltă performanță, pentru a permite utilizatorilor să dezvolte cu ușurință aplicații.
Caracteristicile plăcii STM32F407G-DISCOVERY :
ARM® Cortex®-M4 pe 32 de biți, memorie Flash 1-Mbyte, memorie RAM de 192
Kbyte într-un pachet LQFP100;
Alimentare externă 3V sau 5V;
Alimentare directă prin magistrala USB;
MP45DT02 senzor audio ST-MEMS cu microfon digital omni-direcțional;
DAC audio CS43L22 cu driver difuzor integrat de clasă D ;
8 leduri și două butoane ;
USB OTG FS cu conector micro-AB;
DMA controler;
Controlere CAN și USB integrate.[12]
9
Figura 2.1: Placa de dezvoltare- STM32F407G-DISCOVERY

Constantin Abăceoae
2.1.1. Organizarea memoriei și arhitectura magistralei interne
Placa de dezvoltare dispune de o magistrală internă pe 32 biți multistrat care
interconectează următoarele elemente:
8 MASTERE:
➢Cortex M4 cu FPU (Floting-point unit) core,
➢Magistrala de memorie DMA1,
➢Magistrala de memorie DMA2,
➢Magistrala perifericelor DMA2,
➢Magistrala ethernet DMA,
➢Magistrala USB OTG HS DMA.
7 SLA VE-URI
➢Magistrala memoriei interne flash Icode,
➢Magistrala memoriei interne Dcode,
➢Magistrala internă principală SRAM1,
➢Magistrala internă secundară SRAM2,
➢Perifericele AHB1 și AHB2,
➢FMSC.
Matricea magistralei prezentate oferă acces de la un master la slave și atunci când mai
multe periferice de mare viteză incearcă să funcționeze simultan. Memoria RAM nu face parte
din această matrice a magistralei și poate fi accesată doar prin procesor.
10
Figura 2.2: Arhitectura magistralei interne

Capitolul 2. Tehnologiile Hardware și Software folosite
Memoria program, memoria de date, registrele și porturile de intrare/ieșire sunt
organizate în aceiași zonă de adrese. Octeți sunt codificați în memorie în formatul little endian.
Cel mai mic octet numărat este considerat ca fiind cel mai puțin semnificativ al cuvântului. Iar
octetul cel mai mare numerotat este considerat ca fiind cel mai semnificativ. Spațiul de memorie
adresabil este împărțit în 8 blocuri principale. Toate zonele de memorie care nu sunt alocate
pentru memoriile de pe cip și periferice sunt considerate rezervate.
Interfața memoriei flash implementează operațiile de ștergere și programare a memoriei
Flash, dar și mecanismele de protecția de citire și scriere a memoriei. Memoria Flash dispune de
un bloc principal de memorie împărțit în sectoare. [12]
2.1.2. Modulul CAN
Modulul CAN integrat în controler denumit bxCAN, este cel care interfațează rețeaua
CAN. Acesta suportă versiunile protocolului CAN 2.0A și B, este capabil să recepționeze un
număr ridicat de mesaje cu o încărcare a procesorului minimă. În aplicațiile CAN de astăzi,
numărul de noduri dintr-o rețea crește și de multe ori mai multe rețele sunt conectate impreună
prin gateway-uri.
Deoarece numărul de mesaje este din ce în mai mare, pentru gestiunea mesajelor din
rețea este necesar un mecanism de filtrare.
O coadă FIFO este necesară pentru aplicațiile care sunt necesare să primească un număr
semnificativ de mesaje pe o perioadă mai lungă de timp fără a pierde mesajele. [12]
Controlerul CAN pentru a realiza recepția și transmisia mesajelor trebuie să se afle în
modul normal. După inițializarea din software, intrarea în modul normal se face prin ștergerea
bitului INRQ din registrul CAN_MCR. Astfel modului este pregătit de recepția și transmisia
mesajelor. Hardware-ul confirmă intrarea în modul normal prin ștergerea bitului INAK din
registrul CAN_MSR.
2.1.2.1. Recepționarea mesajelor
Pentru recepția mesajelor sunt furnizate trei buffere organizate ca o coadă de mesaje
11
Figura 2.3: Topologia reței CAN

Constantin Abăceoae
FIFO. În măsura în care dorim să salvăm încărcarea procesorului, simplificarea soft-ului și să
garantăm consistența datelor, coada de mesaje este gestionată complet de hardware.
Aplicația accesează mesajele stocate în coada de mesaje prin buffer-ul de ieșire FIFO. Un
mesaj recepționat este considerat valid atunci când, conform protocolului CAN, îndeplinește
toate regulile stabilite (nici o eroare până după ultimul bit trimis de mesaj, câmpul EOF).
Cu primirea unui mesaj în coada FIFO, o întrerupere de recepție a mesajelor este automat
ridicată dacă bitul FMPIE în registrul CAN_IER este setat. Atunci când mesajele nu sunt extrase
din coadă bitul FULL din registrul CAN_RFR este setat iar o întrerupere care indică acest lucru
este automat generată dacă bitul FFIE în registrul CAN_IER este setat. [12]
2.1.2.2. Transmiterea mesajelor
Pentru a putea transmite un mesaj, aplicația trebuie să selecteze un buffer de transmisie
gol, să seteze identificatorul,codul lungimii datelor(DLC) și datele. Înainte de a cere transmisia
trebuie setat bitul TXRQ corespunzător registrului CAN_TlxR. Odată ce buffer-ul nu mai este
gol, prin software nu mai avem acces de scriere în registrele acestuia.
Imediat după ce bitul TXRQ a fost setat, buffer-ul intră în starea de așteptare și așteaptă
să devină buffer-ul cu cea mai mare prioritate. Imediat ce buffer-ul are cea mai mare prioritate
12
Figura 2.4: Stările prin care trec mesajelor recepționate

Capitolul 2. Tehnologiile Hardware și Software folosite
va fi programat pentru transmitere.
Transmiterea mesajului din buffer-ul programat va porni atunci când magistrala CAN nu
mai funcționează. Odată ce buffer-ul a fost transmis cu succes, acesta va deveni din nou gol.
Hardware-ul indică o transmisie reușită prin setarea biților RQCP și TXOK în registrul
CAN_TSR.
O transmisie poate fi abandonată de utilizator dacă este setat bitul ABRQ în registrul
CAN_TST.[12]
2.1.3. Modulul DMA
Accesul direct la memorie (DMA) este utilizat pentru a oferi transfer de date de mare
viteză între periferice și memorie sau între memorie și memorie. Datele pot fi mutate rapid de
controlerul DMA fără nici o acțiune a CPU-ului. Acesta menține resursele CPU libere pentru alte
operații. Controlerul DMA combină o arhitectură duală puternică cu magistrală duală AHB FIFO
independentă pentru optimizarea lățimii de bandă a sistemului, pe baza unei matrici complexe de
arhitectură a magistralei. Cele două controlere DMA au 16 fluxuri de date în total (8 pentru
fiecare controler), fiecare dedicat gestionării cererilor de acces la memorie de la unul sau mai
multe periferice. Fiecare flux poate avea până la 8 solicitări în total. Și fiecare are un arbitru
pentru a se ocupa de prioritatea între cererile DMA. [12]
13
Figura 2.5: Stările mesajelor transmise pe CAN

Constantin Abăceoae
2.1.4. Modulul USB OTG_FS
OTG_FS este un controler care este perfect compatibil cu specificațiile versiunii USB
2.0. Poate fi configurat doar ca gazdă sau ca device controler. În modul gazdă, modulul suportă
viteza maximă 12 Mbits/s și viteza minimă de 1.5 Mbit/s, în timp ce în modul device, poate
suporta viteza maximă de 12 Mbit/s.
2.1.4.1. Transmiterea mesajelor
Core-ul are un singur buffer dedicat pentru fiecare punct de transmisie. Aplicația
configurează dimensiunile buffer e-lor prin scrierea registrului OTG_FS_TX0FSIZ.
Dimensiunea maximă a buffer-ului de transmisie poate fi de 65 de octeți, dar pentru
aplicația realizată au fost folosiți doar 62 de octeți.
2.1.4.2. Recepționarea mesajelor
Modului utilizează un singur buffer de primire. Pachetele primite sunt stivuite până când
spațiul liber este disponibil în buffer-ul de recepție. Dimensiunea buffer-ului este configurată în
registrul GRXFSIZ. La fel ca buffer-ul de transmisie acesta are o dimensiune maximă de 65 de
octeți. Mesajele în momentul actual pot fi recepționate doar pe bază de interogare deoarece nu a
fost permisă recepția pe bază de apariție de evenimente. [12]
2.2. Adaptorul PCAN -USB
Adaptorul PCAN-USB permite conectarea simplă la rețelele CAN. Carcasa compactă din
plastic o face potrivită pentru aplicații mobile.
14
Figura 2.6: Diagrama bloc a modulului OTG_FS

Capitolul 2. Tehnologiile Hardware și Software folosite
Specificații tehnice:
•Adaptor pentru conexiunea USB
(modul Full Speed, compatibil cu
USB 1.1, USB 2.0 și USB 3.0).
•Conexiune CAN de mare viteză (ISO 11898-2).
•Viteza de la 5 kbit / s până la 1 Mbit / s.
•NXP PCA82C251 CAN transceiver.
•Furnizarea de tensiune prin USB.
2.3. Transceiverele CAN MCP2552
Dispozitivul MCP2552 servește ca interfață între controlerul de CAN și magistrala fizică.
Acesta oferă transmisie și recepție diferențială pentru controlerul de CAN integrat pe placa de
dezvoltare, și este perfect compatibil cu standardul ISO-11898. Funcționează la viteze de până la
1 Mb/s. Fiecare nod dintr-o rețea CAN trebuie sa aibă un asemenea dispozitiv pentru conversia
semnalelor digitale generate de controlerul CAN.
2.4. STM32CUBE IDE, Eclipse IDE și PCAN-view
Eclipse este un mediu de programare popular și gratuit ce suportă o serie de limbaje de
programare printre care și limbajul C. Ținând cont de faptul că placa de dezvoltare
STM32F407G-DISCOVERY are un procesor ARM® Cortex®-M4, s-a folosit compilatorul
GCC pentru ARM.
Cu STM32Cube, STMicroelectronics oferă un instrument software complet, reducând
semnificativ eforturile de dezvoltare, timpul și costul.STM32Cube include STM32CubeMX, un
instrument grafic de configurare software care permite generarea codului de inițiere C.
15
Figura 2.7: Dispozitivil PCAN-USB
Figura 2.8: Interfața grafică STM32cubeMX

Constantin Abăceoae
Interfața PCAN-View pentru Windows® este un simplu monitor CAN pentru
vizualizarea, transmiterea și înregistrarea traficului de date CAN. Mesajele pot fi transmise
manual și periodic la o rată de biți determinată de utilizator. În timpul procesului sunt afișate
erorile de sistem ale bus-ului și depășirea memoriei în hardware-ul CAN. Funcția de urmărire
poate fi utilizată pentru a înregistra și a salva traficul de date CAN.
PCAN-View este livrat cu fiecare produs hardware PC PCAN și permite pornirea rapidă
și ușoară. Toate interfețele PEAK CAN disponibile sunt listate în dialogul de conectare. După
selectarea hardware-ului și a ratei de biți, utilizatorul poate accesa toate funcțiile software,
setările specifice hardware-ului și informațiile.
16
Figura 2.9: Interfața grafică PCAN-view

Capitolul 3. Descrierea aplicației realizate
Capitolul 3. Descrierea aplicației realizate
3.1. Interfața grafică
Interfața grafică este realizată cu ajutorul funcțiilor disponibile în sistemele de operare
Windows. Aceste funcții denumite Windows API oferă utilizatorului o mare parte din serviciile
de bază ale sistemului de operare.
Programarea cu ajutorul acestor facilități înseamnă primirea, interpretarea, trimiterea de
mesaje către „ferestre” sau „controale” (obiecte controlabile – ex. ToolBox, EditBox, Button,
Text, CheckBox) .
Ca în orice program care are nevoie de o buclă în care trebuie să realizeze anumite task-
uri, și această aplicație are în funcția principală (main – WINAPI WinMain) cu o buclă internă.
În aceasta buclă sunt apelate funcțiile de prelucrare și traduse mesajele trimise de către utilizator.
Mesajele sunt interpretate și trimise mai departe către fereastra activă .
17
Figura 3.1: Interfața grafică realizată

Constantin Abăceoae
Pentru a dispune de interfețele necesare realizării comunicației USB cu placa de
dezvoltare, aplicația are nevoie de un fisier .dll (dynamic link libraries ). Acest fisier conține
funcțiile care realizează conexiunea cu placa și, desigur, cele care transmit și recepționează
mesajele USB.
Funcția pentru crearea ferestrelor de ecran (HWND WINAPI CreateWindow) se află în
Windows (32biți) în user32.dll. În versiunile de Windows comenzile de bază se află în
comctl32.dll, impreună cu Common Control Library.
3.1.1. Conectarea aplicației cu placa de dezvoltare
Toate acțiunile efectuate în aplicație pot fi realizate doar dacă aplicația este conectată cu
placa de dezvoltare. Acest lucru este posibil prin apăsarea butonului de CONNECT, disponibil în
interfață.
La apăsarea butonul este inițiat un mesaj de comandă (WM_COMMAND) pe ramura
destinată butonului cu id-ul corespunzător, în care este apelată funcția de conectare.
Conectarea este posibilă prin apelarea funcției rawhid_open (Fig.3.2). Această funcție
primește ca parametri VID (vendor ID) and PID (product ID), care trebuie să fie aceiași
parametri cu care a fost configurat modului USB al plăcii de dezvoltare.
18
Figura 3.2: Conectarea interfeței cu placa de dezvoltare

Capitolul 3. Descrierea aplicației realizate
3.1.2. Configurarea canalelor de CAN
Interfața grafică pune la dispoziția utilizatorului o modalitate prin care acesta poate
configura pe ce canal sa trimită datele și desigur rata de transmisie a informațiilor. La apăsarea
butonul CONFIGURATION CAN apare o noua fereastră grafică (Fig.3.3) în care pot fi introduse
datele necesare configurării canalului selectat de CAN.
Dacă adaptor-ul nu este configurat să aibă aceiași rată de transmisie a datelor ca
dispozitivul cu care se dorește a se conecta atunci transferul datelor va eșua.
Un număr de două canale pot fi
individual configurate. Viteza de transmisie a
datelor poate fi calculată folosind valorile de
Prescaler, TQ_BS1 și TQ_BS2 în concordață cu
relația (2).
Valoare de prescaler este necesară pentru
a seta quanta de timp (TQ) derivată din frecvența
oscilatorului intern de 42 MHz conform relației
(1). Valoare RJW (Resyncronization Jump Width)
este folosită de controlerul de CAN pentru
resincronizarea hardware.
(1)
(2)
După completarea câmpurilor necesare configurării canalelor, este împachetat automat un
mesaj de USB sub forma prezentată în Fig.3.4.
Valoare de prescaler introdusă în editbox trebuie să fie o valoare cuprinsă intre 1 și 1024.
Interfața grafică doar impachetează buffer-ul extrăgând datele din elementele de control și cu
ajutorul funcției rawhid_send trimite datele pe USB. Ajuns pe adaptor mesajul este despachetat
și este realizată configurarea efectivă a dispozitivului.
În momentul extragerii datelor din câmpurile ferestrei de control, se verifică și
corectitudinea informațiilor introduse sau necompletarea acestora. Un mesaj de eroare apare
19
Figura 3.3: Fereastra pentru configurarea canalelor
de CAN
Figura 3.4: Formatul mesajului USB de configurare canale de CANTQ=1
42MHz
PrescalerValue
BaudRate=TQ+TQBS1×TQ+TQBS2×TQ

Constantin Abăceoae
imediat în care i se solicită utilizatorului să verifice din nou datele introduse.
3.1.3. Transmiterea mesajelor de date din interfață
Pentru a transmite un mesaj de CAN din interfață este necesară introducerea datelor în
20
Figura 3.5: Erori apărute in urma apăsarii butonului de Initializare
Figura 3.6: Transmiterea mesajului de configurare

Capitolul 3. Descrierea aplicației realizate
fereastra destinată transmiterii de mesaje. Acest lucru este posibil prin apăsarea butonului ADD
MSG din fereastra grafică principală. Datele introduse sunt preluate pentru a fi împachetate într-
un buffer (Fig. 3.7) care este automat setat într-o secțiune grafică și pregătit pentru transmisie.
În partea din stânga a regiunii în care se pot afișa mesajelor apare un checkbox( coloana
SEND). De fiecare dată când este bifat se trimite automat un mesaj pe USB cu formatul precizat
mai sus. De altfel orice mesaj poate fi editat atunci când este selectat și este apăsat butonul Edit
Message.
Utilizatorului îi este permis să steargă mesajele selectate sau toate mesajele introduse în
acea secțiune grafică cu ajutorul a două butoane disponibile în fereastra principală a aplicației.
Pentru mesajele care necesită trimise cu recurență pe CAN trebuie mai întâi deselectat checbox-
ul deoarece modulul CAN-USB este cel care asigură recurența dorită. Iar în momentul în care nu
se mai dorește transmiterea acestora, un mesaj cu o comandă specială este trimis pe USB pentru
a avertiza modulul de intenția utilizatorului.
21Figura 3.7: Formatulul mesajului de CAN impachetat pe USB
Figura 3.8: Mesaj nou de transmisie și secțiunea grafică de afișare a mesajelor

Constantin Abăceoae
3.1.4. Recepția mesajelor în interfață
Mesajele primite pe USB sunt preluate cu ajutorul unor thread-uri (fire de execuție). Un
thread de recepție se ocupă cu preluarea mesajelor de pe USB și stocarea acestora într-o coadă de
dimensiune foarte mare. Dimensiunea mare a cozii asigură siguranța preluării mesajelor de către
celelalte thread-uri.
Alte două thread-uri se ocupă în același timp cu preluarea mesajelor din coadă, pentru a fi
afișate într-o secțiune din interfața grafică.
Pentru afișare au fost folosite două thread-uri deoarece dacă rulăm aplicația pe un
calculator cu o putere de calcul mai scăzută și dorim sa primim mesaje la o rată de 1ms, un
singur thread nu ar face față și afișarea ar rămâne mult în urmă. Acest lucru a fost observat după
ce s-au realizat teste pe un calculator cu performanțe mult mai scăzute. Astfel, atunci când un
thread nu se ocupă de afișarea mesajelor se ocupă celălalt, crescând astfel semnificativ
performanțele. Thread-ul care realizează recepția mesajelor rulează în buclă infinită. Funcția
rawhid_recv care realizează recepția nu poate genera un event în care sa știm cu exactitate când
mesajul a sosit. Astfel această funcție dacă returnează o valoare mai mare ca zero vom ști cu
exactitate dacă a fost recepționat un mesaj valid.
Un alt thread extrage și el mesajele dintr-o coadă. Acest lucru este necesar deoarece s-a
dorit salvarea tutoror mesajelor care sosesc într-un fișier .xml. Odată recepționat primul mesaj în
acest thread se deschide un fișier în care se începe introducerea mesajelor. Dacă un interval de
timp nu au mai fost recepționate mesaje fișierul se închide până la primul mesaj din nou
recepționat. De fiecare dată utilizatorul trebuie să își salveze în altă zonă de memorie fișierul
unde s-au salvat datele deoarece acesta va fi de fiecare dată suprascris.
Mesajele primite de pe USB sunt configurate să aibă o dimensiune de 62 de octeți. Într-
un asemenea buffer pot să fie recepționate maxim 3 mesaje de CAN împachetate de modulul
CAN-USB.
22 Figura 3.9: Formatul mesajului de
ștergere
Figura 3.10: Formatul mesajului recepționat

Capitolul 3. Descrierea aplicației realizate
Adaptorul este cel care împachetează, în funție de câte mesaje găseste în coada de
recepție, un număr maxim de 3 mesaje în buffer-ul USB.
3.1.5. Filtarea mesajelor de CAN
Apăsarea butonul FILTER MESSAGES deschide o noua fereastră în care se poate selecta
ce tip de ID să fie respins (standard sau extins), ID-ul respins dar desigur și anularea filtrului pe
ID-ul respectiv.
Filtrarea mesajelor este necesară deoarece pe utilizator s-ar putea să nu îl
intereseze numărul mare de mesaje care se găsesc în momentul respectiv în rețeaua CAN,
el astfel poate alege exact ce ID-uri să fie recepționate.
În interfața grafică nu a fost necesar să fie implementată o modalitate de filtare a
mesajelor deoarece modulul CAN-USB este cel care preia ID-ul din mesajul de filtare.
Pentru fiecare ID trimis spre a fi filtrat este activat un filtru pe placa de dezvoltare.
23
Figura 3.11: WinMain gestionare thread-uri si acțiune utilizator

Constantin Abăceoae
Mesajul împachetat pentru a fi trimis pe USB conține ca date relevante ID-ul mesajului
filtrat, ce tip de ID este (standard sau extins) dar și un identificator separat pentru ca modulul să
recunoască că este mesaj de filtare.
24
Figura 3.13: Fereastra de filtrare mesaje
Figura 3.12: Trimitere
ID pe USB

Capitolul 3. Descrierea aplicației realizate
3.2. Aplicația de pe placa de dezvoltare
Aplicația a fost dezvoltată cu ajutorul mediului de dezvoltare Eclipse, pe o placă de
dezvoltare de la STMicroelectronics, ce folosește un microcontroler ARM Cortex M4 care
rulează la o frecvență de 168 MHz. Microcontrolerul este conectat la două canale de CAN prin
intermediul transceiverelor de mare viteză MCP2552. Configurațiile necesare plăcii de
dezvoltare STM32F4-DISCOVERY au fost realizate în STM32cubeMX. Acesta este un IDE în
care pot fi configurate anumite funcționalități ale modulelor disponibile plăcii.
Interfața PCAN-view și dispozitivul PCAN sunt folosite pentru a testa funcționalitățile
celor doua aplicații.
3.2.1. Planificatorul
Folosind IDE-ul aferent plăcii STM32cubeMX a fost configurat un timer care generează
o întrerupere la fiecare 10μs. În această întrerupere, în funcție de numărul de task-uri dorite se
apelează funcția de tratare a fiecărui task. În acest caz, planificatorul gestionează două task-uri:
unul de 1ms și celălalt de 2ms.
Task-ul de 1ms este cel care gestionează recepția mesajelor de pe USB și realizează rata
dorită pentru mesajele de CAN care se doresc a fi trimise. Task-ul de 2ms este cel care se ocupă
de copierea mesajelor primite pe CAN introduse într-o coadă. Acesta preia în funcție de câte
25
Figura 3.14: Conectarea resurselor hardware necesare aplicației

Constantin Abăceoae
mesaje sunt în coadă un număr de maxim 3 mesaje și realizează copierea acestora într-un buffer
cu ajutorul modulului DMA (direct memory acces). În acest task se verifică câte mesaje se
găsesc în coadă, dacă se găsesc mai mult de 3 mesaje, atunci sunt copiați 60 de octeți. Dacă
numărul este mai de mic de 3 mesaje atunci sunt utilizați doar 40 de octeți din cei 60 disponibili
pentru date. Atunci când copierea s-a efectuat cu succes este automat generată o întrerupere în
care este trimis conținutul buffer-ului respectiv pe USB.
26
Figura 3.15: Rutina de tratare a intreruperii de 10us

Capitolul 3. Descrierea aplicației realizate
3.2.2. Recepția mesajelor în adaptor trimise din interfață
La recepția unui mesaj pe USB se activează întreruperea CUSTOM_HID_OutEvent_FS.
În funcția de tratare, inițial se verifică tipul de mesaj primit. Dacă mesajul este fără repetiție
atunci el va fi pregătit aici pentru transmiterea pe CAN.
Funcția de pregătire a mesajelor verifică dacă mesajul primit este de tip comandă sau de
date. Dacă este de tip comandă atunci se indică modul în care va fi inițializat canalul de CAN.
Dacă mesajul este de tip date, atunci buffer-ul primit de la USB este despachetat pentru a
fi extrase datele necesare configurării frame-ului de date CAN. În fiecare mesaj USB mai sunt
prevăzuți octeți în care se indică timpul scurs între 2 mesaje de CAN succesive.
Toate mesajele primite pe USB au o poziție rezervată în buffer-ul de 62 de octeți în care
este precizat tipul de mesaj primit. Dacă index-ul special primit pe acea poziție este 0xC0
modulul trebuie să realizeze configurarea canalelor de CAN. Pentru a realiza configurarea este
necesară mai întâi deinițializarea registrelor necesare configurării canalelor de CAN. După ce s-a
realizat deinițializarea în funcție de de canalul selectat din interfață, se despachetează mesajul
primit de pe USB în structura definită de tipul CAN_HandleTypeDef. Valorile necesare realizării
configurării sunt SJW, BS1, BS2 și valoarea de prescaler. Inițializarea canalelor de CAN se
realizează prin apelul funcției HAL_CAN_Init având ca parametru structura cu valorile primite.
Chiar dacă canalul de CAN a fost configurat, controlerul nu este pregătit incă să primească
mesajele de CAN sau să le trimită. După configurare este necesară crearea un filtru de CAN care
a fost inițializat să primească toate mesajele cu ID-ul standard sau extins.
Mesajele care sosesc pe USB mai sunt trimise din interfață și în scopul filtrării mesajelor
de CAN. Aest lucru se realizează prin configurarea unor filtre CAN. Prin definirea unei variabile
de tipul CAN_FilterConfTypeDef avem posibilitatea să definim exact în ce interval să filtrăm
mesajele, sau putem filtra mesaje în funcție de ID-ul introdus. La fel ca la mesajele de
configurare și mesajele de filtrare au un index special, 0x0F . Și pentru mesajele standard și
pentru cele cu ID extins se folosește același mecanism de filtrare. Mesajul primit de pe USB este
despachetat, se blochează mai întâi recepția tutoror mesajelor, ca apoi în funcție de valoarea
primită să fie permisă recepția mesajelor cu ID-ul respectiv. Pentru fiecare ID primit în mesajul
de filtrare se configurează un nou filtru. Resetarea filtrelor poate fi facută din interfața grafică
atunci când se reconfigurează canalele de CAN.
Recepția mesajelor de USB care conțin datele necesare formării mesajelor de CAN sunt
preluate în aceiași funcție pe ramura destinată mesajelor de date. Aici este despachetat octet cu
octet buffer-ul primit și este configurată structura de stocare a mesajelor care urmează a fi trimise
pe CAN. Pentru a se indica sfârșitul impachetării mesajelor în structura de transmisie, un flag
indică recepția completă.
3.2.3. Transmiterea mesajelor de CAN
Așa cum a fost precizat mai sus, task-ul de 1ms și întreruperea de recepție a mesajelor pe
USB se ocupă cu pregătirea mesajelor de CAN.
Dacă mesajele au fost primite și au fost validate prin intermediul flag-ului de recepție
27

Constantin Abăceoae
completă, atunci ele sunt pregătite pentru a fi transmise pe CAN.
În întreruperea de USB sunt pregătite mesajele care nu necesită transmisia acestora decât
o singură dată pe CAN. Odată primită validarea din partea flag-ului, în bucla infinită din cadrul
microcontrolerului se verifică structura în care sunt stocate mesajele validate, și cu ajutorul
funcției HAL_CAN_Transmit acestea sunt trimise pe CAN.
În task-ul de 1ms sunt pregătite mesajele care necesită retransmisia pe CAN la anumite
intervale, astfel datorită valorii introduse din interfață cu ajutorul planificatorului putem să
transmitem acel mesaj pe CAN la diferite recurențe atât timp cât checkbox-ul corespunzător
mesajului este bifat.
La fel ca mesajele care sunt transmise o singură dată, acestea au și ele propriul flag de
validare care astfel îi comunică funcției de trimitere a mesajelor când acestea sunt pregătite.
3.2.4. Recepția mesajelor pe CAN și transmiterea pe USB
Mesajele de pe CAN sunt recepționate într-o functie de întrerupere. Pentru a fi asigurată
recepția tuturor mesajelor a fost creată o coadă de mesaje de dimensiune foarte mare.
Dimensiunea cozii este de 1024 de elemente, dar după mai multe verificări, atât timp cât
datele sunt extrase din acea zonă coada nu va fi plină niciodată.
Din structura recepționată putem extrage tipul de ID recepționat, standard sau extins, ID-
ul, lungimea datelor și desigur datele. Pe lânga aceste informații structura respectivă pune la
dispoziție flag-uri de eroare în caz ca sunt probleme cu recepția și transmisia mesajelor.
În task-ul de perioadă 2ms se verifică numărul de mesaje din coadă. În funcție de acest
număr, cu ajutorul modului DMA (direct memory acces), configurat din tool-ul STM32cubeMx,
se realizează o copiere a unui număr maxim de 3 mesaje în buffer-ul DMA. Acest lucru este
necesar deoarece în interfața grafică nu ar mai ajunge același număr de mesaje. Finalizarea
copierii duce la generarea unei întreruperi în care se transmite acel buffer pe USB.
Pe lângă trimiterea mesajului pe USB, în întreruperea de USB se verifică și starea cozii în
ceea ce privește gestiunea dimensiunii acesteia. Se verifică dacă coada a utilizat toate pozițiile
alocate în memorie și dacă numărul de mesaje din coadă a ajuns la zero. Acest lucru este necesar,
deoarece acei indecși prin care introducem și extragem elemente din coadă trebuie resetați.
Funcțiile de extragere și introducere sunt implementate cu un mecanism de tip coadă
circulară, dar pentru siguranță la fiecare generare de întrerupere DMA indecșii pot fi resetați fără
a cauza pierderi de mesaje.
28
Figura 3.16: Formatul trimis pe USB

Capitolul 3. Descrierea aplicației realizate
29
Figura 3.17: Trimiterea mesajelor pe CAN

Constantin Abăceoae
Capitolul 4. Testarea aplicațiilor și rezultatele experimentale
În interfața cu utilizatorul au fost introduse mai multe mesaje cu ajutorul fereastrei de
adaugare mesaje, fereastra disponibilă(fig.4.4) în urma apăsării butonul ADD MSG. Acestea
pentru a fi vizualizate sunt afișate într-un listview (Fig.4.1) .
Pentru a putea trimite pe USB mesajele introduse în listview trebuie bifat checkbox-ul
din fața fiecarui mesaj. Mesajul este automat trimis pe USB.Pe placa de dezvoltare mesajul este
despachetat din buffer-ul primit pe USB în scopul transmiterii ulterioare pe CAN.
Mesajul trimis pe CAN poate fi vizualizat în interfața grafică PCAN-view (Fig 4.3).
30
Figura 4.1: Adăugarea mesajelor de transmisie
Figura 4.2: Afișarea mesajelor in interfața grafică
Figura 4.3: Recepționarea mesajelor CAN setate in interfața grafică

Capitolul 4. Testarea aplicațiilor și rezultatele experimentale
Pentru a testa recepția mesajelor în interfața grafica au fost introduse în PCAN-view un
număr de 4 mesaje.
Interfața grafică dezvoltată, după configurarea canalelor de CAN, este capabilă sa
primească toate mesajele din rețeaua CAN cu care este conectat modulul.
Pentru testarea filtrării de mesaje, în fereastra grafică destinată acestui lucru s-a trimis id-
ul 56.
31Figura 4.4: Transmiterea mesajelor CAN din PCAN-view
Figura 4.5: Recepția mesajelor de CAN in interfața grafică
Figura 4.6: Setarea unui filtru din interfața grafică

Constantin Abăceoae
În Fig.4.7 Se observă că interfața PCAN-view a trimis toate cele 4 mesaje, iar acest lucru
este vizibil în coloana Count.
Astfel în Fig.7.8 numărul mesajelor din coloana Count s-a schimbat doar în cazul
mesajului cu ID-ul 56.
32
Figura 4.7: Transmiterea mesajelor pentru testarea filtrării
Figura 4.8: Primirea mesajului cu ID-urile filtrate

Capitolul 5. Concluzii
Capitolul 5. Concluzii
Aplicațiile realizate au fost concepute în scopul testării dispozitivelor conectate la o rețea
CAN. Multe aplicații au fost realizate de-a lungul timpului și nenumărate companii din domeniul
automotive le folosesc pentru a-și testa produsele. In general costul unui astfel de device se
ridică la câteva sute de euro iar impreună cu licența necesară aplicației de monitorizare a
mesajelor de CAN, poate depăși foarte ușor cele câteva sute de euro.
Un prim avantaj adus de interfața grafică este că nu necesită instalare. La copierea
executabilului pe orice PC, aceasta poate funcționa fără a mai fi necesară instalarea anumitor
framework-uri. De exemplu, pentru aplicațiile dezvoltate în Java portarea acestora pe orice alt
calculator, implică instalarea Java Runtime Environment.
Pentru a scăpa de necesitatea instalării unor drivere, la conectarea plăcii de dezoltare pe
orice PC, aceasta este vazută ca HID (Human Interface Device). Acest lucru înseamnă că placa
este recunoscută automat de sistemul de operare sau de oricare aplicație care interacționează cu
acest modul.
Codul dezvoltat pentru placa de dezvoltare este foarte flexibil. Acesta poate fi portat cu
ușurintă pe orice variantă de microcontroler oferită de cei de la STM.
Singura limitare adus ă de aceste aplicații, este faptul că mesajele venite pe CAN pot fi
afișate doar daca vin la un interval de minim 1ms. În funcție de rata de comunicație CAN,
mesajele pot veni pe CAN mult mai repede, dar interfața grafică nu ar face față unui număr mai
mare de mesaje. Thread-urile care lucrează în buclă infinită sunt gestionate strict de sistemul de
operare al calculatorului. Dacă într-un moment calculatorul are un task mai prioritar de rezolvat
s-ar putea ca afișarea mesajului să fie intreruptă iar calculatorul să rezolve în funcție de prioritate
evenimentele apărute. Afișarea mesajelor nefiind atât de prioritară pentru el.
Întreruperea de recepție a mesajelor de pe CAN reușeste să primească toate mesajele, dar
copierea acestora într-o zonă de memorie implică timp și spațiu de memorie ocupat. Astfel,
timpul acesta cumulat cu timpul în care se realizează trimiterea acestora pe USB aduc mai multe
întârzieri și astfel s-ar ajunge la pierderea mesajelor.
O îmbunatățire adusă aplicației ar fi găsirea unei modalități prin care anumite mesaje care
vor a fi transmise pe CAN, să fie importate cu ajutorul unui fișier extern. Astfel utilizatorul nu va
mai introduce mesajele folosind fereastra de adăugare mesaje.
Pe lânga faptul că mesajele recepționate de pe CAN sunt afișate în secțiunea grafică din
interfață, un thread se ocupă și cu introducerea mesajelor într-un fișier .xml. Fișierul se crează
automat atunci când mesajele încep a fi recepționate. Placa de dezvoltare este capabilă sa suporte
integrarea unui card micro SD, în care să fie stocată interfața de pe PC dar și fișierului cu log-
urile de pe CAN.
Modulul și interfața grafică permite gestionarea mesajelor standard de CAN. O
îmbunătațire ar mai putea fi trecerea de la formatul standard la formatul extins de date (CAN
FD). Astfel s-ar imbunătați considerabil viteza de transmisie și recepția a datelor pe CAN,
deoarece dimensiunea câmpului de date crește de la 8 octeți la 64 de o cteți.
33

Constantin Abăceoae
Bibliografie
[1]ISO, ISO 11898-1:2015, „Road vehicles – Controller area netwok (CAN) – Part 1: Data link layer
and physical signalling, International Organization for Standardization”, , , pp. 1, 2015.
[2]G. Cena, I. C. Bertolotti, T. Hu, A. Valenzano, „CAN XR: CAN with extensible in-frame Reply”, ,
IEEE 14th International Conference on Industrial Informatics (INDIN), pp. 119 – 120, 2016.
[3]EngineersGarage, „CAN Protocol – Understanding the Controller area Network Protocol[online]”,
https://www.engineersgarage.com/article/what-is-controller-area-network page=2 , , pp. 1, .
[4]National Instruments, „Controller Area Network (CAN) Overview”, http://www.ni.com/white-
paper/2732/en/, , pp. 1, .
[5]Y . Luo, „The Design of CAN/USB Embedded Adapter”, , 3rd International Conference on
Mechanical and Electronics Engineering, Hefei, 2011, in Mechanical and Electronics Engineering
III, PTS 1-5, Book Series: Applied Mechanics and Materials, V olume: 130-134, pp. 3938 – 3941,
2012.
[6]M. Liping, Z. Weiguo, „Design and implementation of USB and CAN communication adapter”, ,
Proceedings of International Conference on Intelligent Computation and Industrial Application,
Hong Kong, vol.III, pp. 387 – 390, 2011.
[7]W.-C. Hsu, S.-T. Liu, „Design and Implementation of CANUSB Converter Based on ARM7 Serial
Protocol API”, , Internațional Symposium on Computer, Consumer and Control, Taichung, pp. 333
– 336, 2012.
[8]M. Postolache, C. Spiridon, „XCPI – A Measurement and Calibration Software Tool for Networked
and Embedded Control Systems”, , Proceedings of the 14th International Conference on Systems
Theory and Control, Sinaia, pp. 397 – 402, 2010.
[9]Texas Instruments, „Introduction to the Controller Area Network (CAN)”,
http://www.ti.com/lit/an/sloa101b/sloa101b.pdf, , pp. 1, .
[10]Dr. Baruch Zoltan Francisc, „MAGISTRALA USB”,
http://users.utcluj.ro/~baruch/sie/labor/Magistrala-USB.pdf, , pp. 1, .
[11], „Universal Serial Bus”, https://www.techopedia.com/definition/2320/universal-serial-bus-usb, ,
pp. 1, .
[12]ST Microelectronics, „Discovery kit with STM32F407VG MCU, User Manual (UM1472)”,
http://www.st.com/content/st_com/en.html, , pp. 1, 2017.
34