Protocoale de Comunicatie Si Programe Pentru Conectarea In Retea a Sistemelor Specialzate cu Microprocesoare Dsp

=== lucr ===

I.Blackfin 537

Blackfin este o familiea de microprocesoare pe 16 sau 32 de biti, produse de catre Analog Devices. Acestea sunt caracterizate de functia de procesare de semnale digitale (DSP), care este acompaniata de un microcontoler mic dar foarte efficient. Rezultatul este o arhitectura unitara de mica putere care poate rula sisteme de operare si in acelsi timp poate executa sarcini numerice complexe cum ar fi codificarea video H.264 in timp real.

Nucleul de procesor Blackfin conține doi multiplicatori de 16 biti, doi acumulatori de 40 de biti, doua alu de 40 de biti, patru ALU video și un shifter de 40 de biți. Regiștrii de calcul conțin opt registre pe 32 de biți. Când se efectuază operații de calcul pe date operand pe 16 biți, fișierul de registru funcționează ca 16 registre independente pe 16 biți. Toți operanzii de calcul provin din fișierul registru multiport și din câmpuri de instrucțiuni constante.

Fiecare Mac pote efectua o multiplicare din 16 în 16 ciclică, acumulând rezultatele în acumulatori de 40 de biți.

ALU efectuază un set tradițional de operații aritmetice și logice pe date de 16 biți sau 32 de biți.

În plus, multe instrucțiuni speciale sunt incluse pentru a accelera diverse sarcini de prelucrare a semnalului. Acestea includ operațiunile de biți, cum ar fi extrasul din domeniu și numărarea, multiplicări modulo 2 la puterea 32, împărți primitive, saturație și rotunjire, și detectarea semnului / exponentului. Setul de instrucțiuni video conțin aliniarea octeților și împachetarea operațiilor.

Pentru unele instrucțiuni, două operații ALU pe 16 biți pot fi înfăptuite simultan pe regiștri pereche.

Shifter-ul pe 40 de biți poate efectua translatări și rotații și este folosit ca suport de normalizare, extrageri de câmpuri și depozite de instrucțiuni de câmp.

Secvențiatorul de program controlează fluxul instrucțiunilor de executie, inclusiv alinierea instrucțiunilor și decodarea.

Setul de instrucțiuni al procesorului Blackfin a fost optimizat astfel că opcodurile pe 16 biți reprezintă instrucțiunile cele mai frecvent utilizate, rezultate excelente în densitatea de cod compilat. Instrucțiunile DSP complexe sunt codificate în opcodes 32-bit, reprezentând instrucțiunile multifuncționale. Procesoarele Blackfin suporta capacitatea de a soluționa probleme multiple, în cazul în care o instrucțiune de 32 de biți poate fi emisă în paralel cu două instrucțiuni pe 16 biți, permițând programatorului să folosească multe din resuresele de bază într-un singur ciclu de instrucțiuni.

Limbajul procesorului Blackfin de asamblare foloseste o sintaxa algebrică pentru a ușura codificarea și lizibilitatea. Arhitectura a fost optimizată pentru utilizarea legăturii cu compilatorul C / C + +, rezultat rapid și eficient implementării de software.

Procesoarele ADSP-BF536 și ADSP-BF537 ofera posibilitatea să se conecteze direct la o rețea prin intermediul unei Fast Ethernet Media Access Controller (MAC) încorporat care acceptă ambele operațiuni 10-BaseT (10 Mbps) și 100-BaseT (100 Mbps). 10/100 Ethernet MAC periferic este pe deplin conform cu standardul IEEE 802.3 – 2002, și oferă caracteristici programabile concepute pentru a minimiza supravegherea, utilizarea magistralei, sau procesarea mesajului de procesorul sistemului.

Caracteristicile standard sunt:

• suport de MII și protocoale RMII pentru Phys externe.
• moduri full duplex și semi-duplex.
• încadrarea datelor și încapsulare: generarea și detectarea
din preambul, lungimea padding-ului, și FCS.
• managementul accesului dispozitivelor media (în funcționare semi-duplex)
• flux de control (funcționare full-duplex): generarea și
detectarea de rame PAUZĂ.

• managementul stației: generarea de MSD / cadre MDIO
pentru acces de citire-scriere la registrele PHY.
• SCLK de funcționare până la 25 MHz (modurile de operare activ și sleep).
• loopback interne din Tx la Rx.

Unele caracteristici avansate sunt:

• calcularea de control automată a header-ului IP

Descriptor independet pe 32 de biti condus de canalele DMA rx si tx

Starea livrarii cadrelor catre memori via DMA , incluzand semafoarelor pentru eficientizarea cozii zonelor tampon in produsele soft

Suport DAM tx pentru descriptori separati pentru antetul MAC si sarcina utila eliminand operatia de copiere zonei tampon

Moduri de aliniere convenabila a cadrelor ale pachetelor de date tx si rx in memorie dupa antetul MAC de 14 octeti

Suport pentru intreruperi Ethernet programabile

47 de numaratori statistici MAC cu stergere dupa citire selectabila si intreruperi programabile la jumatate din valoare maxima

Filtre de adrese rx programabile, incuzand tabele rezumat pe 64 de biti pentru cadre multicast si/sau unicast si moduri programabile pentru broadcast, multicast, unicast, control si cadre stricate

Mod de filtrare a anumitor pachete petru iesirea din starea de adormire

II. Protocolul CAN

2.1Noțiuni introductive

Controller Area Network (CAN) este o rețea serială care a fost proiectata inițial pentru industria auto, dar a devenit deasemenea o magistrala populara în automatizarea industriilor și în alte aplicații. Magistrala CAN este folosita în principal în sisteme incorporatate și numele indica faptu că este reteaua se stabilește între microcontrolere. Este un sistem format din două fire , half duplex, și de mare viteză. Este foarte potrivit a se folosi în aplicații de mare viteză care au la baza transmiterea de mesaje scurte, fiind un sistem de incredere si robust .

Teoretic CAN poate fi implementat pentru a lega 2032 de dispozitive (fiecare nod fiind un identificator) intr-o singură rețea. Totuși datorită limitării practice a dispozitivelor fizice(tranceiver-ele), poate să conecteze doar pana la 110 noduri, folosind 82C250, Philips, intr-o singură retea. Acest procedeu oferă o comunicație la viteză ridicată de până la 1 mb/secundă, astfel obținundu-se un controller în timp real, în plus apariția erorilor și detecția lor este mult mai ușor de rezolvat într-un mediu zgomotos.

2.2 ISTORIE

CAN a fost dezvoltat prima dată de Robert Bosch GmbH, Germania, în 1986 unde i-a fost cerut să dezvolte un sistem de comunicație între unitățile de control (ECU) la vehiculele firmei Mercedes. Cercetatorii au descoperit că un UART nu mai este potrivit în această situație pentru că este folosit în comunicații punct la punct. Nevoia de un sistem de comunicație multimaster a devenit imperativă. Prima implementare fizică CAN a fost fabricata în 1987 de firma INTEL.

In tabelul urmator este prezentat evolutia cronologica a conceptului CAN:

2.3 Dezvoltarea primului chip

La inceputul anului 1980 inginerii de la BOSCH au evaluat sistemul magistralei seriale existente cu privire la posibila folosire pentru mașini. Deoarece niciun protocol de rețea disponibil nu a fost capabil să facă față cerințelor inginerilor în automobile, Uwe Kiencke a început să dezvolte un nou sistem de magistrală serială în 1983. Noul protocol trebuia să adauge în principal o nouă funcționalitate și oportunitatea reducerii numărului de fire. Inginerii de la Mercedes-Benz s-au implicat încă de la început în faza de specificații a acestei noi magistrale seriale, la fel și Intel . Professorul doctor Wolfhard Lawrenz de la Universitatea de Științe Aplicate din Braunschweig-Wolfenbüttel, care a fost angajat ca consultant a dat noului protocol numele “Controller Area Network”. Profesorul Dr. Horst Wettstein de la Universitatea din Karlsruhe a acordat o deosebita asistenție academica proiectului.

În februarie 1986, a aparut CAN: la congresul SAE din Detroit, noul sistem dezvoltat de Bosch a fost prezentat sub numele de ‘Automotive Serial Controller Area Network’, Uwe Kiencke, Siegfried Dais si Martin Litschel au introdus protocolul de rețea multimaster. Acesta era bazat pe un mecanism de arbitrare indestructibil, care ofera acces la mesajele cu cea mai mare prioritate indiferent de intarziere,neexistand niciun controller master central. Mai mult decat atât, „părintii” CAN au implementat anumite mecanisme pentru detecția erorilor. Managementul erorilor cuprinde deasemenea deconectarea automată a nodurilor defecte pentru a mentine comunicația între celelalte noduri, mesajele transmise nu erau identificate după adresa nodului transmițătorului sau receptorului mesajului(cum se întamplă în majoritatea sistemelor), ci după conținut, identificatorul reprezentând conținutul mesajului avea și funcția de a specifica prioritatea mesajului în cadrul sistemului.

Multe prezentări și publicații care decriu aceast protocol inovator au urmat până la mijlocul anului 1987 când intel a scos pe piață primul chip CAN, Intel 82526. A fost prima implementare hard a protocolului CAN. Puțin după aceea Philips Semiconductors au introdus pe piață 82C200. Acești doi stramoși ai controlerelor CAN sunt puțin diferiți privind filtrarea mesajelor și managementul acestora. Pe de o parte conceptul FullCAN implementat de catre INTEL necesită mai putin încărcarea procesorului microcontroller-ului față de implementarea BasicCAN a Philips. Pe de altă parte, dispozitivele FullCAN erau limitate privind numarul de mesaje care puteau fi primite. Controller-ul BasicCAN folosește mai puțin silicon.

În controller-ele de astazi au aparut o serie de diferențe privind concepția, acceptarea și filtrarea mesajelor.

.

2.4 Standardizarea

Speciificațiile CAN Bosh (versiunea 2.0) au fost trimise pentru standardizare internațională la inceputul anilor 1990. După câteva divergente, implicând în special “rețeaua de vehicule”, dezvoltată de un fabricant de automobile mare al pieței Franceze, în anul 1993 standardul ISO 11898 pentru CAN a fost publicat. În plus, protocolul CAN definește un nivel fizic pentru a atinge o rată de transfer de până la 1 Mb/s. În 1995 standardul ISO 11898 a fost extins cu descrierea idetificatorul CAN pe 29 de biti.

Din păcate toate specificațiile și standardizăriile specificatiilor CAN publicate contineau erori sau erau incomplete. Pentru a evita incompatibilitatea implementarilor CAN, Bosh s-a facut răspunzător ca toate chip-urile create să fie compatibile cu modelul propriu. Mai mult decât atât Universitatea pentru Știinte Aplicate din Germania, a condus teste de conformitate CAN pentru câțiva ani. Parametrii de testare se bazează pe standardizarea internațională de specificare a testelor ISO 16845.

Standardul ISO 11898-1 descrie nivelul de date CAN, iar standardele 11898-2 si 11898-3 fac referință la nivelul fizic. Standardele 11992 și 11783 definesc aplicații specifice bazate pe CAN, interfețe petnru camione respective automatizare în agricultura, bazându-se pe protocolul American j1939, fiind totuși incompatibile.

2.5 Timpul și pionierii CAN

Deși CAN a fost dezvoltat inițial pentru a fi folosit în automobile, primele aplicații au apărut în segmente de piață diferite. În special în Europa de nord, CAN era deja foarte popular la inceput. În Finlanda, fabricantul de lifturi Kone folosea magistrala CAN. Un inginer Suedez, Kvaser, a sugerat CAN anumitor producători de echipamente folosite în industria textilă. Astfel sub conducere lui Lars-Berno Frederiksson s-a format grupul ‘CAN Textile User’s Group’.

În Norvegia, Philips Medical System s-a alăturat utilizatorilor industriali CAN prin decizia de a folosi CAN pentru reteaua internă a mașinilor folosite pentru radiografii. Specificațiile pentru mesaje ale Philips (PMS), dezvoltate de Tom Suters, reprezintă primul nivel aplicatie al retelei CAN. Profesor Etschberger de la Universitate de Știinte Aplicate a avut idei aproape identice, dezvoltând un protocol similar.

În pofida faptului că aparuse prima standardizare pentru un protocol de nivel înalt, o mulțime dintre pionierii CAN foloseau o abordare momolitică. Funcțiile de comuniare, managementul rețelei și codul aplicației făceau parte din soft. Deși unii utilizatori preferau o abordare modulară ei încă aveau dezavantajele soluției impuse. Efortul necesar pentru promovarea și menținerea protocolului CAN de nivel superior au fost subestimate.

La începutul anilor 90 a fost timpul pentru fomarea unui grup de utilizatori pentru standardizarea diferitelor soluții. În anul 1992, Holger Zeltwanger, editor șef la revista VMEbus, a adus laolaltă utilizatorii și producătorii pentru a stabili o platformă netură de dezvoltare CAN. Prima publicație tehnică, a apăruta la câteva săptămâni și prezenta nivelul retea: CiA recomandă folosirea tranceiverului CAN pentru a concorda cu standardul ISO 11898.

Una dintre principalele sarcini a CiA a fost descrierea nivelului aplicatie. Folosind materialul existent al Philips Medical Systems și STZP, impreuna cu alți membrii ai CiA, a fost dezvoltat nivelul de aplicație CAN(CAL). În tot acest timp CiA reprezenta legatura între experții CAN și cei care doreau să cunoască domeniul. Astfel, din anul 1994 are loc conferința internatională anuală CAN( iCC)

O altă abordare academică a fost promovată de LAV, o asociație de vehicule agricole. Până în anul 1980 sistemul bazat pe CAN pentru vehicule agricole (LBS) a fost dezvoltat. Înainte ca munca să fie complet terminată comitetul international a decis să aprobe varianta SUA j1939, o abordare non-modulară care este foarte usor de folosit dar totuși foarte inflexibilă.

2.6 De la teorie la practica

Desigur producătorii de semiconductoare care au implementat module CAN în dispozitivele proprii s-au axat pe indurstia de automobile. De la mijlocul anilor 1990, Infineon Technologies și Motorola au exportat o mare cantitate de controllere CAN către producatorii de automobile din Europa. Ca urmator val, producătorii de semiconductori din Est au oferit controllere CAN la sfarsitul anilor 1990. Cei de la NEC au scos pe piață cu un chip legendar CAN 72005 în anul 1994.

Începând cu anul 1992, Mercedes-Benz a folosit CAN pentru masinile de clasă ridicată. Ca un prim pas unitatea de control făcea managementul motorului prin magistrale CAN. Al doilea pas a fost conectarea altor componente electronice. Au fost implementate doua sisteme de magistrale CAN contectate cu ajutorul unor gateway-uri. Alți producători precum BMW, Renault, Fiat, Saab, Volvo folosesc CAN în cadrul contrucției autoturismelor autorurismelor.

La sfârșitul anilor 1990 inginerii de la Cincinnati Milacron împreună cu Allen-Bradley și Honeyweel Microswitch au început un proiect de comunicații bazat pe CAN. După ceva timp câțiva cercetatori importanți au abandonat, dar Allen-Bradley și Honeywell au continuat să lucreze separat. Cerectarea a dus la doua protocoale de nivel înalt: „DeviceNet” și „Smart Distributed System” care sunt asemanatoare.

În Europa, câteva companii au încercat să folosească CAL. Deși abordarea CAL era corecta din punct de vedere academic și era posibil să fie folosită în aplicații industriale, fiecare utilizator trebuia să creeze un nou profil deoareace CAL era un adevarat nivel aplicatie. CAL poate fi privit ca un pas academic necesar către o soluție de aplicație independentă CAN, dar nu a caștigat niciodata acceptarea în domeniu.

Din anul 1993 a fost dezvoltat CANopen. Pe partea academică, profesorul dr. Gerhard Gruhler și dr. Mohammed Farsi au participat într-una dintre cele mai de succes activități. După terminarea proiectului, specificatile CANopen au fost inmanate către CiA pentru dezvoltare ulterioara și mentenanță. În 1995, profilul de comunicații CANopen a fost publicat și doar în cinci ani a devenit cel mai important standard pentru rețele integrate din Europa. CANopen oferă flexibilitate ridicată și este ușor de configurat. Acest protocol de nivel înalt , care a fost folosit in diferite arii de aplicatii a fost standardizat international (EN 50325-4)

CANopen este folosit în special în Europa: mașini în Italia, fierăstraie mecanice în Germania, mașini folsite în industria tabacului in Marea Britanie, mașini pentru producerea ceasurilor în Elveția. În SUA CANopen este folosit în automatele de sortat scrisori.

CANopen nu definește doar nivelul aplicatie și profilul de comunicație, ci și un mediu de lucru pentru programarea sistemului, diferite dispositive, interfețe și profile de aplicații. Acesta este motivul pentru care toate segmentele industriei au decis sa folosească CANopen la sfârșitul anilor 90.

DeviceNet este optimizat pentru automatizări în fabricație și CANopen este potrivit pentru controlul mașinilor.

2.7 Viitorul privind CAN

În anul 2000 ISO impreună cu alte companii au definit un protocol pentru transmiterea mesajelor CAN bazat pe declanșare în funcție de timp. Dr Bernd Muller, Thomas Feuhrer și alți angajați Bosch, împreună cu experții din industria de semiconductori și din mediul academic au definit protocolul TTCAN.

Această extensie CAN, care acum trebuie implementată în silicon nu va permite doar transmiterea mesajelor la intervale egale de timp sau implementarea ciclurilor finite cu ajutorul CAN ci și conectarea unui numar mare de controller în aplicații. Deoarece protocolul CAN nu a fost alterat este posibila transmiterea pe aceași magistrală fizica a mesajelor declanșate în funcție de timp sau de evenimente.

Luând în considerare că protocolul CAN este înca la inceput pe piața globala, chiar și conservatorii estimeaza o creștere în acest domeniu în urmatorii 15 ani. Acest lucru este subliniat și de faptul că producatorii de automobile abia au inceput să folosească protocolul în producția de serie. Mai mult decât atât se asteaptă un volum mare de noi tipuri de aplicații.

Bosh a dezvoltat CAN in 1985 pentru rețele în interiorul vehiculelor. În trecut producătorii de automobile conectau dispozitivele electronice folosind sisteme punct la punct. Producătorii au început să foloseasca din ce in ce mai multe electronice în vehicule ceea ce înseamană foarte multe fire și costuri ridicate. Apoi ei au înlocuit firele dedicate cu rețele interne, ceea ce reduce costurile cablajelor, complexitatea și greutatea. CAN, un sistem de nivel înalt pentru rețele inteligente a pornit ca un standard de rețea internă pentru autovehicule. Industria de automobile a adoptat rapid CAN și în 1993 a devenit standardaul internațional cunoscut ca ISO 11898. Din 1994 au fost standardizate protocoale de nivel înalt precum CANopen și DeviceNet. Alte piețe au adoptat aceste protocoale adiționale, care acum sunt standard pentru comunicații industriale.

2.8 Beneficiile CAN

CAN oferă o soluție ieftină și durabilă pentru o rețea de comunicatie între mai multe dispositive CAN. Un avantaj al acestui lucru este că unitățile de control pot avea o singură interfață CAN în loc de intrări pentru fiecare dispozitiv analogic sau digital din sistem. Acest lucru micșorează costurile și greutatea produsului rezultat. Fiecare dispozitiv din rețea are un controller CAN. Toate dispozitivele din rețea văd toate mesajele transmise, putând astfel să decidă dacă mesajul este ralevat sau trebuie filtrat. În plus fiecare mesaj are o prioritate, și deci dacă două noduri încearcă să trimită un mesaj simultan, cel cu prioritate maximă are dreptul de transmitere

2.9 Aplicații CAN

CAN a fost creat inițial pentru folosirea în automobile, și deci cea mai comuna aplicație este rețaua electronica din automobile.

În timp și alte ramuri ale indurstriei si-au dat seama de nevoia și beneficiile aduse de CAN în ultimii 15 ani și au adoptat protocolul pentru o paletă largă de aplicații. Un tip important de aplicații sunt cele feroviare cum ar fi tramvaie, metrouri, trenuri ușoare și trenuri de lungă distanță. CAN poate fi găsit pe diferite nivele în retelele multiple din aceste vehicule. Spre exemplu poate fi folosit pentru deschiderea ușilor, frânare, controlul locurilor pasagerilor și altele. CAN are aplicabilitate și in industria aeronautică: senzori de zbor, sisteme de navigație. Se poate gasi o implementare CAN în foarte multe aplicații aerospațiale pornind de la analize de zbor până la sisteme de control al motorului cum ar fi nivelul combustibilului, pompele și motoarele liniare.

Producătorii de echipamente medicale folosesc CAN ca rețea incorporată în dispozitivele medicale. De fapt unele spitale folosesc CAN pentru a gestiona o întreaga camera de operație. Componentele camerelor de control ale spitalelor cum are fi lumini, camere de filmat, aparate cu raze X și paturile pacienților sunt controlate folosind CAN.

Lifturile și scările rulante folosesc deasemenea CAN, iar spitalele folosesc protocolul CANopen pentru legarea în rețea a dispozitivelor lifturilor și pentru a le controla. CANopen este folosit de asemenea și în aplicații non-industriale cum ar fi echipamente de laborator, camere sportive, telescoape, uși automatizate și chiar espresoare de cafea.

2.10 Nivelele fizice CAN

Protocolul CAN oferă mai multe nivele fizice care pot fi folosite. Aceste nivele fizice clasifică anumite aspect ale unei rețele CAN, cum ar fi nivele electrice, scheme de semnale, impedanța firelor, rată maximă de transfer a benzii și altele. Cele mai folosite nivele fizice sunt:

CAN de mare viteza (High-Speed CAN)

Acesta e de departe cel mai folosit nivel fizic. Rețele CAN de mare viteza sunt imlementate cu două fire și permit transfer de până la 1 MB/s. Dispozitivele care conțin CAN de mare viteză sunt sistemele antiblocare a franelor (ABS), module de control al motoarelor, sisteme de evacuare

Dispozitive fizice de viteză redusă și toleranță la erori

Acestea sunt implementate deasemenea cu două fire și pot cumunica cu viteze de până la 125kb/s și ofera transceiver-e cu capabilitate de toleranță a erorilor. Acestea sunt folosite în special pentru confort deoarece nu sunt neaparat necesare.Spre exemplu ele sunt folosite pentru a detecta dacă toate usile sunt inchise, pentru deschiderea electrica a geamurilor, pentru detecția stprii centrurii de siguranță, sau luminile de frânare.

Dispozitive CAN cu un singur fir

Aceste pot comunica cu o rata de pana la 33,3kb/s. O alta denumire este SAE-j2411, CAN-A sau GMLAN.Aceste sunt folosite in industria auto pentru ajutarea scaunelor si oglinzilor.

Dispozitice CAN selectabile soft

Produsele National Instruments CAN oferă posibilitatea configurării soft a intefețelor CAN pentru folosirea oricărui tip de tranceiver.

2.11 Pachetele CAN

Dispozitivele CAN trimit data in cadrul retelei in pachete numite cadre. Un cadru CAN conține urmatoarele câmpuri

SOF (start-of-frame) bit –indică începutul unui mesaj cu un bit dominant (logic 0)t

Arbitration ID – Identifică mesajul și indică prioritatea acestuia. Cadrele apar în două formate—standard care folosesc un ID de arbitrare pe 11 biti și extinse care folosesc o arbitrare pe 29 de biti

IDE (identifier extension) bit –permite diferentierea între cadrele standard si extinse

RTR (remote transmission request) bit –permite diferentierea unui cadru izolat de unul de date. Un bit de 0 indica un cadru de date iar un bit de 1 indica un cadru izolat

DLC (data length code) – indica numarul de biți de date

Data Field –conține între 0 și 8 biți de date

CRC (cyclic redundancy check) –conține 15 biti pentru verificare redundanței codului. Câmpul CRC este folosit pentru detecția erorilor.

ACK (ACKnowledgement) slot –orice controller CAN care primește un mesaj correct trimite un bit ACK la sfarsitul mesajului.Nodul de transmitere verifica prezenta acestui bit și dacă nu il gasește reîncearca transmitera.

CAN Signal – o parte independetă de date dintr-un cadru de date CAN. Se mai numește și canale.Deoarece câmpul de date conține 8 biți de date, un cadru CAN conține între 0 și 64 de semnale individuale.  

În imaginea următoare , sunt reprezentate șase canale conținute într-un cadru de date ale unui cadru CAN simplu. Fiecare semnal conține 8 biti de date.

2.12 Fisierele bazei de date CAN

Fișierele bazei de date CAN sunt fișiere text care conțin informații scalare pentru cadrele de date și definițiile semnalelor.Editorul de baze de date NI-XNET recunoaște FIBEX database files (.xml), Vector Database file (*.dbc) și National Instruments CAN database files (*.ncd).
Pentru fiecare semnal baza de date CAN defineste reguli de conversie pentru unitățile tehnice. Următoarele date sunt stocate în baza de date:

Numele canalului

Locația (bitul de start) și lungimea( numarul de biți) al unui canal dintr-un mesaj

Ordinea biților (Intel/Motorola)

Tipul de date (signed, unsigned, and IEEE float)

Gama

Valoarea initiala

Comentarii

Aceste informatii pot fi folosite pentru a converti informația cadrului intr-o valoare inteligibilă. Figura urmatoare prezintă un exemplu al unei astfel de conversii

Fișierele pot conține cadre sau definiții de semnale pentru un intreg dispozitiv în care se folosesc(de exemplu pentru un intreg vehicul).Fiecarea rețea are o baza de date unică. În plus, aceste baze de date sunt specifice producatorului și de obicei sunt confidențiale.

Folosind o baza de date pentru multe cadre într-o retea CAN, multe aplicații CAN pot automat converti o informație a unui cadru direct într-o valoare inteligibila pentru o persoana. Acest lucru simplifică dezvoltarea aplicației.

2.13 Functionarea comunicatiilor CAN

După cum am prezentat pînă acum CAN este o rețea Peer-to-peer. Aceasta înseamană că nu există niciun controller master și nodurile au permisiunea de a scrie și citi date pe magistrala CAN. Când un nod CAN este gata sa transmită date , face o verificare să vadă dacă magistrala este ocupată, și apoi doar scrie direct cadrul pe aceasta. Cadrele CAN care sunt transmise nu conțin adrese nici pentru nodul care se transmite nici despre nodul care a transmis. În schimb, un ID de arbitrare care este unic în rețea etichetează cadrul. Toate nodurile din rețeaua CAN primesc cadrul CAN , și în funcție de ID-ul de arbitrare al cadrului transmis, fiecare nod CAN din rețea decide daca acceptă sau nu cadrul.

Daca mai multe noduri încearcă să transmită un mesaj pe magistrala CAN în același timp, nodul cu prioritate maximă ( cel mai mic ID de arbitrare) primește automat accesul la magistrală. Nodurile cu prioritate mică trebuie să aștepte până când magistrala devine libera înainte de a încerca să transmită un mesaj. În acest fel se pot implementa retele CAN pentru a asigura comunicarea deterministă intre nodurile CAN.

III Prezentarea generala a protocolului CAN din BF537

Facilitatile protocolului CAN implementat continut in Blackfin 537 sunt:

1.se bazeaza se standardul CAN 2.0B( accepta ID de mesaj atât pe 11 biți cat și pe 29 de biți)

3.suportă rate de transfer până la 1Mbit/s

4.contine 32 mailbox-uri (8 de transmitere, 8 de primire și 16 de configurare)

5. masca de acceptare pentru fiecare mailbox

6. infiltrarea datelor (primii 2 bytes) pot fi folositi pentru filtrarea acceptarii(Modul DeviceNetTM)

7.registrii pentru erori și pentru avertizari

8. valoari vizbile ale pinilor de primire și transmitere.

Modulul CAN este o interfata cu rată mica de biți care poate fi folosită în aplicații în care rata de biți ajunge până la 1mb/s.

Protocolul CAN conține un segment de verificare CRC, urmărirea erorilor mesajelor și limitarea căderii nodurilor ca mijloace de imbunătătire a fiabilitatii retelei la nivelul cerut de controlul aplicatiei.

3.1 Generalităti privind interfața

Interfața magistralei CAN este o linie simpla cu 2 fire. Vezi fig.1 pentru reprezentarea simbolica a interconectării unui transceiver CAN, si fig.2 pentru diagram block. Ieșirea CANTX a procesorului Blackfin si intrarea CANRX sunt conectate la un transceiver extern CAN.

Pinii CANTX și CANRX operează cu nivele TTL și sunt potriviți pentru operații cu magistrala tranceivelor CAN în conformitate cu ISO/DIS 11898

Fig.1 reprezentarea interconectarii tranceiverului CAN

Semnalele CANRX și CANTX sunt multiplexate cu semnalele secundare ale SPORT0. Pentru a permite funcționalitatea CAN a pinilor PJ4 și PJ5 câmpul de biți PJCE ai registrului PORT_MUX trebuiesc setați la 01. Datele CAN sunt definite fie ca dominant (0L) fie ca recesiv(1L). starea implicită a ieșirii CANTX este recesivă. Deoarece pinul CANTX este multiplexat cu un semnal de transmitere SPORT ieșirea poate fi 0, dacă SPORT-ul este selectat în loc de CAN ca implicit după resetare.

Fig2. Diagrama BLOCK

Controlerul CAN facilitează 32 de buffere de mesaje, numite mailbox-uri. Opt mailbox-uri sunt dedicate pentru transmiterea mesajelor, opt pentru recepționare și 16 sunt pentru configurare. În consecință, arhitectura protocolului CAN se bazeaza pe 32 de intrări mailbox de tip Ram. Mailbox-ul este accesat secvențial de interfața serială CAN sau de procesorul BlackFin. Fiecare mailbox conține 8 regiștrii de date și control pe 16 biti, și 2 registrii pe 16 biți de mască(opționali). Toți acești regiștrii trebuie configurați înainte de folosire. Din moment ce aceste mailbox-uri sunt implementate ca RAM, valorile de reset ale acestor registrii find nedefinite. Datele sunt împărtite în 2 câmpuri, care conțin : identificatorul de mesaj , time stamp(stampilă termporală), numărator de biți, până la 8 biți de date și cațiva biți de control. Vezi fig.3

Fig.3 Mailbox-ul CAN

Registrii perche de identificare ai mailbox-ului CAN include:

29 de biți de identificare

Bitul de validare a maștii (AME)

Bitul de cerere al încheierii transmisiei(RTR)

Bitul de indentificare al extensiei(IDE)

Alti regiștrii de mailbox sunt:

Lungimea codului de date(DLC) în CAN_MBxx_LENGHT. Cei mai semnificativi 12biți ai CAN_MBxx_LENGHT ai fiecarui mailbox sunt rezervati. Acești 12 biti întotdeauna trebuie setati pe 0.

Până la 8 biți de date, se trimite mai întâi MSB din registrii CAN_MBxx_DATA3/2/1/0 pe baza numărului de biți definite în DLC.

2 octeti pentru valoarea time stamp(TSV)in registrul CAN_MBxx_TIMESTAMP

Ultimii regiștrii din zona de mailbox-uri sunt regiștrii de mască (CAN_AMxxH și CAN_AMxxL). Masca este activă atunci când bitul AM este setat în registrul CAN_MBxx_ID1. Dacă DNM = 1 în registrul CAN_CONTROL și FDF=1 în masca corespondentă atunci biții EXTID_HI[15:0] și registrului CAN_MBxx_ID0 sunt refolosiți ca și cod de acceptare. (DFC) al filtrării datelor.

3.2 Cotrolul mailbox-urilor

Funcția de control MMR a Mailbox-urilor este în regiștrii de control și status pentru toate cele 32 de Mailbox-uri. Fiecare bit din acești registrii reprezintă un mailbox anume. Din moment ce MMR are 16 biți, o pereche de regiștrii este necesară pentru a gestiona anumite functionalități pentru toate cele 32 de Mailbox-uri. Mailbox-urile 0-15 sunt configurate/monitorizate în regiștrii cu un bit de padding cu valoarea 1. Similar mailbox-urile 16-31 folosesc aceiași regiștrii cu bitul de pading 2. De exemplu, registrii de direcție a mailbox-urilor CAN (CAN_MDx) controlează mailbox-urile așa cum se arată in figura următoare.

Fig 4. Perechea de registrii CAN

Zona de regiștrii de control pentru mailbox-uri constă în trei perechi de regiștrii:

CAN_TRR1 și CAN_TRR2 (regiștrii de transmitere a cererii)

CAN_RMP1 și CAN_RMP2 (regiștrii de asteptare a primirii mesajului)

CAN_RML1 și CAN_RML2 (regiștrii pentru primirea mesajelor pierdute)

CAN_RFH1și CAN_RFH2 (regiștrii de manipulare a cadrelor)

CAN_OPSS1 și CAN_OPSS2 (regiștrii de rescriere a protecției sau de transmitere unică)

CAN_MBIM1 și CAN_MBIM2 (regiștrii măstilor de întrerupere)

CAN_MBTIF1 și CAN_MBTIF2 (regiștrii pentru transmiterea flag-urilor de întrerupere)

CAN_MBRIF1 și CAN_MBRIF2 (regiștrii pentru primirea flag-urilor de întrerupere)

Din moment ce mailbox-urile 24-31 suportă doar operații de transmitere și mailbox-urile 0-7 sunt doar pentru primire, cei mai nesemnificativi 8 biți din “primul” registru și cei mai semnificativi 8 biți din ce de-al “doilea” registru sunt uneori rezervați sau restrictionați.

3.3 Funcționarea protocolului CAN

Deși CANRX și CANTX sunt semnale TTL, semnalele CAN din “spatele” transciverului au un excitator asimetric. O stare low a pinului CANTX activează excitatori puternici în timp ce o stare high este condusă slab. În consecință, starea low este definită ca stare “dominantă” iar stare high este definită ca stare „recesivă”. Dacă modul CAN este pasiv, pinul CANTX este și el high. Dacă două noduri CAN transmit în același timp, biții dominanți suprascriu biții recesivi.

Protocolul CAN spune că toate nodurile care încearcă să trimită un mesaj pe magistrală CAN încearcă să trimită un mesaj imediat ce magistrala devine liberă. Semanlui SOF(Start of Frame Indicator) atenționează începutul unui nou cadru. Fiecare nod care trimite un mesaj începe cu trimiterea id-ului mesajului (message ID). În timpul transmiterii, controlerul CAN eșantionează pinul CANRX iar ca nivel logic transmis este valoarea pinului CANTX din acel moment. Dacă un nod care transmite plasează un ‚1’ recesiv la pinul CANTX și detectează un ‚0’ dominant la pinul CANRX, recunoaște că un alt nod a transmis un bit dominant pe magistrală, ceea ce inseamna ca un alt nod are prioritatea mai mare. Deci dacă valoarea de la pinul CANRX este valoare pinului CANTX, transmisia continuă, altfel controller-ul CAN recunoaște ca a pierdut arbitrarea și configurația sa este cea care va „dicta” următoarea acțiune. Pentru mai multe detalii privind structura cadrului CAN analizați figura următoare.

Fig 5.Cadrul CAN standard(Standard CAN frame)

Figura prezintă un cadru identificator de 11 biți. După SOF și identificator se află bitul RTR, care indică dacă acest cadru conține date sau este o cerere de date asociată cu un identificator de mesaj(remote frame).

Când este setat câmpul IDE se indică faptul ca mesajul este un cadru extins cu un identificator de 29 de biti. Într-un cadru extins, prima parte a mesajului este asemănătoare cu cea a unui cadru normal.

Fig 6. Cadru CAN Extins

După cum se observa în câmpul RTR, un bit dominant în câmpul IDE câștigă arbitrarea cu un cadru extins cu aceiași cei mai nesemnificativi 11 biți. În consescință cadrele standard au prioritate mai mare decât cadrele extinse. Cererea de substituire a bitului (SRR, întotdeauna trimite ca recesiune), biții rezervați r0 și r1(trimite intotdeauna ca dominant), și suma de control sunt generate automat.

3.4 Procesele CAN

Controlerul CAN este în modul configurare când procesorul revine în strea de reset sau hibernare. Înainte de inițializarea mailbox-urilor trebuie setat ceasul CAN pentru lucrul cu magistrala.

3.5 BIT TIMING

Controlerul CAN nu are un ceas dedicat, acesat este derivat din ceasul-sistem.(SCLK) bazat pe un număr configurabil al cuantei de timp.

TQ = (BRP+1)/SCLK, BRP=10biti, din registrul CAN_CLOCK

Registrul CAN_CLOCK definește valoarea TQ, și de acolo rezultă durata de transmitere a unui bit pe magistrală CAN. Registrul CAN_TIMING controleaza bitul de timp si esantioanele din cadrul potrocolului CAN.fig.7 arata cele 3 faze ale unui bit CAN : segmentul de sincronizare, segmentul anterior esantionului de proba si segmentul urmator esantionului de proba.

Fig.7 cele 3 faze ale bitului CAN

Campurile TSEG1,TSEG2 ale CAN_TIMING controleaza cate TQ sunt necesare pentru transmiterea unui bit. Timpul bitului este calculat dupa formula: tBIT = TQ x (1 + (1 + TSEG1) + (1 + TSEG2)). Modulul CAN implementat de Blackfin nu face distinctive dintre segmental de propagare si segmental de faza 1 asa cum sunt definite in standard. Valoarea TSEG1 are rolul de a acoperi ambele valori. Valoarea TSEG2 reprezinta segmental de faza 2.

Daca modulul CAN detecteaza un salt recesiv-dominant in afara segmentului de sincronizare poate automat sa mute automat esantionul de proba, astfel incat sa functioneze correct. Saltul sincronizarii SJW specifica numarul maxim TQ, cuprinse intre1-4 , permitand o astfel de incercare de resincronizare. Valoarea SJW, nu trebuie sa fie mai mare decat TSEG2 sau TSEG1. In consecinta, regula de scriere a CAN_TIMING este:

SJW <= TSEG2 <= TSEG1

In plus fata de aceaasta regula fundamental segmental de faza 2 trebui deasemenea sa fie >= cu timpul de procesare al informatiei IPT. Acesta este timpul necesar unei intrari unui esantion de intrare logica CANRX. In cazul Blackfin acest modul can reprezinta 3 cicluri SCLK. Din aceasta cauza restrictia aplicata valorii minime TSEG2 , daca BRP <2. Daca BRP=0, TSEG trebuie sa fie >=2. Daca este setata pe 1, atunci minimul TSEG este 1.

3.6 Operatiile de transmitere

Fig. 8 arata operatia de tranmitere CAN.Mailbox-urile 24-31 sunt dedicate transmiterii, mailbox-urile 8-23 pot fi configurate pentru transmitere scriind 0 in bitul correspondent in registrul CAN_MDx. Dupa scrierea datelor si identificatorilor in zona mailbox-urilor mesajul este trimis dup ace mailbox-ul n este activat.

Cand transmiterea este complete bitul corecpondent in registrul cererii de transmitere sic el din registrul de resetare al cererii de tranmitere sunt stersi.daca transmiterea s-a efectuat cu success bitul correspondent din registrul de acceptare al transmisie este setat. Daca transmisia a fost intrerupta datorita pierderii arbitrarii sau unei erori bitul correspondent din registru CAN_AAX este setat, o cerere de transmitere poate fi deasemenea suspendata setand bitul correspondent TRRn din registrul CAN_TRRx.

Un caz special este atunci cand bitul TRSn este setat, accesul de scriere in mailbox este permis prin setarea TRSn dar schimbarea datelor intr-un astfel de mailbox poate duce la confuzii in timpul transmiterii.

Activarea si dezactivarea mailboxurilor au impact asupra cererii de transmitere. Setarea bitului TRSn asociat cu un mailbox dezactivat poate duce la eroare. Similar dezactivarea unui mailbox inainte de resetarea bitului TRS poate duce la rezultate neasteptate.

3.7 Retransmiterea

In mod normal mesajul este retransmis dup ace arbitrarea este pierduta sau un cadru eronat este detectat pe magistrala CAN. Daca exista mai mult de un mesaj care asteapta sa fie trimise mailbox-ul cu cea mai mare prioritate trimite primul. (fig.8). Transmisia nereusita este reluata dupa ce toate mesajele cu prioritate mai mare sunt trimise.

Fig.8 Graficul operatiei de transmitere CAN

3.8 Transmiterea Single Shot.

Daca este folosita transmiterea Single Shot(OPSSn = 1 in CAN_OPSSx), bitul TRSn correspondent este sters dup ace mesajul este transmis cu success sau daca transmisia a fost pierduta din cauza unei pierderii unei arbitrary sau a unei erori de cadru. Totusi, nu exista nici o incercare de retransmitere daca prima incercare nu a reusit, si renutarea este raportata(AAn = 1 in CAN_AAx)

3.9 Operatia de primire

Hardware-ul Can primeste mesaje si renunta la mesajele invalide autonom. Odata ce un mesaj valid a fost primit cu succes, receptorul logic interogheaza toate mailbox-urile active secvential, de la 23 la 0,chiar daca mesajul este de interes pentru nodul respectiv sau nu.

Indentificatorul de mesaj al mesajului primit, impreuna cu identificatorul de extensie(IDE) si bitii RTR sunt Daca AME este setat, registru mastilor de acceptare determina care identificator este necesr pentru potrivire.comparate cu setarile registrilor fiecarui mailbox. Daca bit-ul AME nu este setat, o potrivire este semnalata doar daca IDE, RTR si toti bitii identificatorilor se potrivesc exact.

Tabelul 1. Mailbox-uri folosite pentru Filtrarea Mastii de Acceptare.

Daca filtrul de acceptare gaseste o potrivire a identificatorilor, continutul cadrului de date este salvat in mailbox. Daca identificatorl nu corespunde niciunui mailbox, mesajul nu este salvat. Figura 9 ilustreaza algoritmul de decizie pentru salvarea mesajelor in mailbox-uri.

Fig 9.Graficul de receptionare CAN

3.10 Filtru de acceptare a datelor

Daca este activate DeviceNet(DNM = 1 in CAN_CONTROL) si mailbox-ul este setat pentru filtrare in campul de date filtrarea este facuta pe ID-ul standard al mesajului si campului de date. Campul de filtrare al datelor poate fi programat fie pentru doar primii bytes sau pentru primii 2, cum se arata in tabelul 2.

Tableul 2. Filtrarea campului de date

Daca este setat bitul FDF in registrul corespondent CAN_AMxxH, registrul CAN_AMxxL retine masca acestui camp de date(DFM[15:0]). Daca bitul FDF nu este setat in registrul corespunzator CAN_AMxxH, atunci registrul CAN_AMxxL contine identificatorul de masca extins(EXTID_HI[15:0]).

3.11 Time Stamps

Pentru a primi informatii privind timpul receptiei sau timpul transmiterii pentru fiecare mesaj, se programeaza numaratorul universal CAN in modul time stamp. Valoarea celor 16 biti este scrisa in registrul CAN_MBxx_TIMESTAMP corespunzator mailbox-ului care a primit sau a transmis mesajul.

Valoarea time stamp este incapsulata in esantionul de proba al inceputului de cadru(SOF) pentru fiecare mesaj ce se trimie sau se primiste. Dupa aceea, aceasta valoare este copiata in registrul CAN_MBxx_TIMESTAMP correspondent

Daca mailboxul este configurat manipularea automata a cadrelor, valoarea time stamp este scrisa pentru transmiterea unui cadru de date sau pentru receptia unui cadru de date.

Numaratorul poate fi sters(UCRC=1) sau dezactivat (UCE=0) scriind registrul CAN_UCCNF. Numaratorul poate fi deasemenea incarcat cu o valoare scriind registrul CAN_UCCNT.

O supraincarcare a numaratorului seteaza un bitn in registrul global de intreruperi CAN(UCEIS). O intrerupere globala poate sa apara nemascand bitul in registurl global de al mastilor de intrerupere. Daca sursa intreruperii este nemascata, un bit in registrul flag-urilor de intrerupere este deasemenea setat

3.12 Intreruperile CAN

Modulul can ofera trei tipuri de intreruperi independente:

Doua intreruperi pentru mailbox-uri(rreceptionare MBRIRQ si transmitere MBTIRQ)

O intrerupere globala GIRQ

3.12.1 Intreruperile pentru mailbox-uri

Fiecare mailbox poate genera o intrerupere de primire sau transmitere, in functie de configuratie. Pentru a active generarea cererilor de intrerupere pentru mailbox-uri se seteaza bitul correspondent MBIMn in registrul CAN_MBIMx.

Daca mailboxul este configurate pentru primire, flag-ul pentru intreruperea de receptionare corespondenta este MBRIFn=1 in CAN_MBRIFx) dup ace mesajul este salvat.

Daca mailboxul este configurat pentru transmitere, flag-ul correspondent este setat(MBTIFn = 1 in CAN_MBTIFx) dupa ce mesajul este transmis correct.

3.12.2 Intreruperile globale CAN

Pentru gestionarea intreruperilor globale sunt necesari trei registrii

CAN_GIM – registru mastilor de intreruperi globale

CAN_GIS – registrul starilor intreruperilor globale

CAN_GIF – registrul flag-urilor intreruperilor globale

Biti mastii de intrerupere pot afecta doar continutul CAN_GIF. Daca bitul de masca nu este setat, bitul correspondent din CAN_GIF nu este setata cand evenimetul are loc. Bitii de stare din registrul CAN_GIS, sunt setati in permanenta daca intreruperea are loc, independent de biti mastii. Totusi , bitii de stare pot fi folositi pentru salvarea temporara a intreruperilor.

Iesirea de iesire a starii intreruperii globale (GIRQ) este evidentiat daca un bit in registrul CAN_GIF este setat. Bitul GIRQ ramane setat atat timp cat cel putin un bit din registrul de flag-uri este setat.

Exista mai multe tipuri de intreruperi care pot active aceasta intrerupere GIRQ:

Access denied interrupt (ADIM, ADIS, ADIF)

External trigger output interrupt (EXTIM, EXTIS, EXTIF)

Universal counter exceeded interrupt (UCEIM, UCEIS, UCEIF)

Receive message lost interrupt (RMLIM, RMLIS, RMLIF)

Abort acknowledge interrupt (AAIM, AAIS, AAIF)

Access to unimplemented address interrupt (UIAIM, UIAIS, UIAIF)

Wakeup interrupt (WUIM, WUIS, WUIF)

Bus-Off interrupt (BOIM, BOIS, BOIF)

Error-Passive interrupt (EPIM, EPIS, EPIF)

Error warning receive interrupt (EWRIM, EWRIS, EWRIF)

Error warning transmit interrupt (EWTIM, EWTIS, EWTIF)

3.13 Evenimente

Pentru ajutor in implementare, este posibila folosirea numaratorului universal pe post de numerator de evenimente. Numaratorul poate fi programat in campul de 4 biti UCCNF[3:0] al registrului CAN-UCCNF pentru a incremente intr-unul din cazurile urmatoare:

UCCNF[3:0] = 0x6 – eroare de cadru CAN;

UCCNF[3:0] = 0x7 – supraincarcare de cadru CAN

UCCNF[3:0] = 0x8 – pierderea arbitrarii

UCCNF[3:0] = 0x9 – renuntarea transmiterii

UCCNF[3:0] = 0xA – transmisie reusita

UCCNF[3:0] = 0xB – mesajul primit este respins

UCCNF[3:0] = 0xC –mesajul primit este pierdut

UCCNF[3:0] = 0xD – mesaj primit cu success

UCCNF[3:0] = 0xE – mesaj salvat

UCCNF[3:0] = 0xF – mesaj valid

3.14 Registrii CAN

Registrii CAN, ale caror functionalitati si descrieri sunt prezentate in urmatoarele tablele sunt:

Registrii CAN globali(Global CAN Registers

Registrii Mailbox si de masca(Mailbox/Mask Registers)

Regsitrii pentru controlul Mailbox-urilor(Mailbox Control Registers)

Registrii Numaratori Universali(Universal Counter Registers)

Registrii pentru erori(Error Registers)

Tablelul 3. Registrii Globali CAN – descriere

Tablelul 4. Registrii Mailbox si de masca – descriere

Tablelul 5. Regsitrii pentru controlul Mailbox-urilor – descriere

Tablelul 6. Registrii Numaratori Universali – descriere

Tablelul 7. Registrii pentru erori – descriere

3.14.1 Registrii globali CAN

Registrul principal de control CAN(CAN_CONTROL Register)

Figura 11. Registrul principal de control CAN

Registurul global de stare(CAN_STATUS Register)

Figura 12. Registrul global de stare

Mail Box pointer – reprezinta numarul mailbox-ului corespunzator mesajului current transmis. Dupa o transmitere cu success, acesti biti raman neschimbati.

[11111] mesajul mailbox-ului 31 este procesat

…

…

[00000] mesajul mailbox-ului 0 este procesat

Figura 13. Registrul de debug CAN(CAN_DEBUG register)

Figura 14. Registrul de ceas CAN(CAN_CLOCK register)

Figura 15. Registrul de Timing( CAN_TIMING register)

Figura 16. Registrul de intreruperi CAN(CAN _INTR register)

Figura 17. Registrul mastilor de intreruperi(CAN_GIM register)

Figura 18. Registrul de stare al intreruperilor(CAN_GIS register

Figura 19. Registrul de flaguri de intrerupere(CAN_GIF register)

3.14.2 Registrii pentru Mailbox-uri si Masti

Figura 20 Registru de acceptare a mastilor H

Valoare acestui registru nu conteaza atunci cand bitul AME este 0. Daca bitul AME este setat, sunt comparati doar bitii care au bitul carespondet mastii 0. Un bit din registrul de masti care este 1 nu are nevoie de “potrivire”.

Registrii de masti si adresa corespondenta:

CAN_AM00H – 0xFFC0 2B04

CAN_AM01H – 0xFFC0 2B0C

CAN_AM02H – 0xFFC0 2B14

CAN_AM03H – 0xFFC0 2B1C

CAN_AM04H – 0xFFC0 2B24

CAN_AM05H – 0xFFC0 2B2C

CAN_AM06H – 0xFFC0 2B34

CAN_AM07H – 0xFFC0 2B3C

CAN_AM08H – 0xFFC0 2B44

CAN_AM09H – 0xFFC0 2B4C

CAN_AM10H – 0xFFC0 2B54

CAN_AM11H – 0xFFC0 2B5C

CAN_AM12H – 0xFFC0 2B64

CAN_AM13H – 0xFFC0 2B6C

CAN_AM14H – 0xFFC0 2B74

CAN_AM15H – 0xFFC0 2B7C

CAN_AM16H – 0xFFC0 2B84

CAN_AM17H – 0xFFC0 2B8C

CAN_AM18H – 0xFFC0 2B94

CAN_AM19H – 0xFFC0 2B9C

CAN_AM20H – 0xFFC0 2BA4

CAN_AM21H – 0xFFC0 2BAC

CAN_AM22H – 0xFFC0 2BB4

CAN_AM23H – 0xFFC0 2BBC

CAN_AM24H – 0xFFC0 2BC4

CAN_AM25H – 0xFFC0 2BCC

CAN_AM26H – 0xFFC0 2BD4

CAN_AM27H – 0xFFC0 2BDC

CAN_AM28H – 0xFFC0 2BE4

CAN_AM29H – 0xFFC0 2BEC

CAN_AM30H – 0xFFC0 2BF4

CAN_AM31H – 0xFFC0 2BFC

Figura 21. Registru de acceptare a mastilor L

Registrii de masti si adresa corespondenta:

CAN_AM00L – 0xFFC0 2B00

CAN_AM01L – 0xFFC0 2B08

CAN_AM02L – 0xFFC0 2B10

CAN_AM03L – 0xFFC0 2B18

CAN_AM04L – 0xFFC0 2B20

CAN_AM05L – 0xFFC0 2B28

CAN_AM06L – 0xFFC0 2B30

CAN_AM07L – 0xFFC0 2B38

CAN_AM08L – 0xFFC0 2B40

CAN_AM09L – 0xFFC0 2B48

CAN_AM10L – 0xFFC0 2B50

CAN_AM11L – 0xFFC0 2B58

CAN_AM12L – 0xFFC0 2B60

CAN_AM13L – 0xFFC0 2B68

CAN_AM14L – 0xFFC0 2B70

CAN_AM15L – 0xFFC0 2B78

CAN_AM16L – 0xFFC0 2B80

CAN_AM17L – 0xFFC0 2B88

CAN_AM18L – 0xFFC0 2B90

CAN_AM19L – 0xFFC0 2B98

CAN_AM20L – 0xFFC0 2BA0

CAN_AM21L – 0xFFC0 2BA8

CAN_AM22L – 0xFFC0 2BB0

CAN_AM23L – 0xFFC0 2BB8

CAN_AM24L – 0xFFC0 2BC0

CAN_AM25L – 0xFFC0 2BC8

CAN_AM26L – 0xFFC0 2BD0

CAN_AM27L – 0xFFC0 2BD8

CAN_AM28L – 0xFFC0 2BE0

CAN_AM29L – 0xFFC0 2BE8

CAN_AM30L – 0xFFC0 2BF0

CAN_AM31L – 0xFFC0 2BF8

Figura 22. Registrul de Mailbox 7

Registrii si adresa corespondenta:

CAN_MB00_ID1 – 0xFFC0 2C1C

CAN_MB01_ID1 – 0xFFC0 2C3C

CAN_MB02_ID1- 0xFFC0 2C5C

CAN_MB03_ID1 – 0xFFC0 2C7C

CAN_MB04_ID1 – 0xFFC0 2C9C

CAN_MB05_ID1- 0xFFC0 2CBC

CAN_MB06_ID1 – 0xFFC0 2CDC

CAN_MB07_ID1 – 0xFFC0 2CFC

CAN_MB08_ID1- 0xFFC0 2D1C

CAN_MB09_ID1 – 0xFFC0 2D3C

CAN_MB10_ID1 – 0xFFC0 2D5C

CAN_MB11_ID1 – 0xFFC0 2D7C

CAN_MB12_ID1 – 0xFFC0 2D9C

CAN_MB13_ID1- 0xFFC0 2DBC

CAN_MB14_ID1 – 0xFFC0 2DDC

CAN_MB15_ID1- 0xFFC0 2DFC

CAN_MB16_ID1 – 0xFFC0 2E1C

CAN_MB17_ID1 – 0xFFC0 2E3C

CAN_MB18_ID1 – 0xFFC0 2E5C

CAN_MB19_ID1 – 0xFFC0 2E7C

CAN_MB20_ID1- 0xFFC0 2E9C

CAN_MB21_ID1- 0xFFC0 2EBC

CAN_MB22_ID1- 0xFFC0 2EDC

CAN_MB23_ID1 – 0xFFC0 2EFC

CAN_MB24_ID1- 0xFFC0 2F1C

CAN_MB25_ID1 – 0xFFC0 2F3C

CAN_MB26_ID1 – 0xFFC0 2F5C

CAN_MB27_ID1 – 0xFFC0 2F7C

CAN_MB28_ID1- 0xFFC0 2F9C

CAN_MB29_ID1 – 0xFFC0 2FBC

CAN_MB30_ID1 – 0xFFC0 2FDC

CAN_MB31_ID1- 0xFFC0 2FFC

Figura 23. Registrul de mailbox 7

CAN_MB00_ID0- 0xFFC0 2C18

CAN_MB01_ID0- 0xFFC0 2C38

CAN_MB02_ID0 – 0xFFC0 2C58

CAN_MB03_ID0 – 0xFFC0 2C78

CAN_MB04_ID0 – 0xFFC0 2C98

CAN_MB05_ID0 – 0xFFC0 2CB8

CAN_MB06_ID0- 0xFFC0 2CD8

CAN_MB07_ID0 – 0xFFC0 2CF8

CAN_MB08_ID0- 0xFFC0 2D18

CAN_MB09_ID0 – 0xFFC0 2D38

CAN_MB10_ID0 – 0xFFC0 2D58

CAN_MB11_ID0 – 0xFFC0 2D78

CAN_MB12_ID0 – 0xFFC0 2D98

CAN_MB13_ID0- 0xFFC0 2DB8

CAN_MB14_ID0 – 0xFFC0 2DD8

CAN_MB15_ID0- 0xFFC0 2DF8

CAN_MB16_ID – 0xFFC0 2E18

CAN_MB17_ID0- 0xFFC0 2E38

CAN_MB18_ID – 0xFFC0 2E58

CAN_MB19_ID0- 0xFFC0 2E78

CAN_MB20_ID0- 0xFFC0 2E98

CAN_MB21_ID0 – 0xFFC0 2EB8

CAN_MB22_ID0 – 0xFFC0 2ED8

CAN_MB23_ID0 – 0xFFC0 2EF8

CAN_MB24_ID0 – 0xFFC0 2F18

CAN_MB25_ID0- 0xFFC0 2F38

CAN_MB26_ID0 -0xFFC0 2F58

CAN_MB27_ID0 -0xFFC0 2F78

CAN_MB28_ID0- 0xFFC0 2F98

CAN_MB29_ID0 -0xFFC0 2FB8

CAN_MB30_ID0- 0xFFC0 2FD8

CAN_MB31_ID0- 0xFFC0 2FF8

Figura 24. Registrul de Mailbox 5

CAN_MB00_TIMESTAMP – 0xFFC0 2C14

CAN_MB01_TIMESTAMP – 0xFFC0 2C34

CAN_MB02_TIMESTAMP – 0xFFC0 2C54

CAN_MB03_TIMESTAMP – 0xFFC0 2C74

CAN_MB04_TIMESTAMP -0xFFC02C94

CAN_MB05_TIMESTAMP -0xFFC02CB4

CAN_MB06_TIMESTAMP -xFFC02CD4

CAN_MB07_TIMESTAMP-0xFFC0 2CF4

CAN_MB08_TIMESTAMP-0xFFC0 2D14

CAN_MB09_TIMESTAMP -0xFFC02D34

CAN_MB10_TIMESTAMP-0xFFC02D54

CAN_MB11_TIMESTAMP -0xFFC02D74

CAN_MB12_TIMESTAMP -0xFFC02D94

CAN_MB13_TIMESTAMP-0xFFC02DB4

CAN_MB14_TIMESTAMP-0xFFC02DD4

CAN_MB15_TIMESTAMP -0xFFC0 2DF4

CAN_MB16_TIMESTAMP -0xFFC0 2E14

CAN_MB17_TIMESTAMP -0xFFC0 2E34

CAN_MB18_TIMESTAMP -0xFFC0 2E54

CAN_MB19_TIMESTAMP -0xFFC0 2E74

CAN_MB20_TIMESTAMP -0xFFC0 2E94

CAN_MB21_TIMESTAMP -0xFFC02EB4

CAN_MB22_TIMESTAMP -0xFFC0 2ED4

CAN_MB23_TIMESTAMP-0xFFC0 2EF4

CAN_MB24_TIMESTAMP-0xFFC0 2F14

CAN_MB25_TIMESTAMP -0xFFC0 2F34

CAN_MB26_TIMESTAMP -0xFFC0 2F54

CAN_MB27_TIMESTAMP -0xFFC0 2F74

CAN_MB28_TIMESTAMP -0xFFC0 2F94

CAN_MB29_TIMESTAMP -0xFFC02FB4

CAN_MB30_TIMESTAMP -0xFFC02FD4

CAN_MB31_TIMESTAMP -0xFFC0 2FF4

Figura 25. Registru de mailbox 4

CAN_MB00_LENGTH-0xFFC0 2C10

CAN_MB01_LENGTH- 0xFFC0 2C30

CAN_MB02_LENGTH- 0xFFC0 2C50

CAN_MB03_LENGTH- 0xFFC0 2C70

CAN_MB04_LENGTH- 0xFFC0 2C90

CAN_MB05_LENGTH- 0xFFC0 2CB0

CAN_MB06_LENGTH- 0xFFC0 2CD0

CAN_MB07_LENGTH- 0xFFC0 2CF0

CAN_MB08_LENGTH-0xFFC0 2D10

CAN_MB09_LENGTH-0xFFC0 2D30

CAN_MB10_LENGTH- 0xFFC0 2D50

CAN_MB11_LENGTH- 0xFFC0 2D70

CAN_MB12_LENGTH- 0xFFC0 2D90

CAN_MB13_LENGTH- 0xFFC0 2DB0

CAN_MB14_LENGTH- 0xFFC0 2DD0

CAN_MB15_LENGTH- 0xFFC0 2DF0

CAN_MB16_LENGTH- 0xFFC0 2E10

CAN_MB17_LENGTH- 0xFFC0 2E30

CAN_MB18_LENGTH- 0xFFC0 2E50

CAN_MB19_LENGTH -0xFFC0 2E70

CAN_MB20_LENGTH- 0xFFC0 2E90

CAN_MB21_LENGTH- 0xFFC0 2EB0

CAN_MB22_LENGTH – 0xFFC0 2ED0

CAN_MB23_LENGTH- 0xFFC0 2EF0

CAN_MB24_LENGTH- 0xFFC0 2F10

CAN_MB25_LENGTH- 0xFFC0 2F30

CAN_MB26_LENGTH- 0xFFC0 2F50

CAN_MB27_LENGTH- 0xFFC0 2F70

CAN_MB28_LENGTH- 0xFFC0 2F90

CAN_MB29_LENGTH- 0xFFC0 2FB0

CAN_MB30_LENGTH- 0xFFC0 2FD0

CAN_MB31_LENGTH- 0xFFC0 2FF0

Figura 26. Registrulde Mailbox- 3

CAN_MB00_DATA3- 0xFFC0 2C0C

CAN_MB01_DATA3- 0xFFC0 2C2C

CAN_MB02_DATA3-0xFFC0 2C4C

CAN_MB03_DATA3-0xFFC0 2C6C

CAN_MB04_DATA3- 0xFFC0 2C8C

CAN_MB05_DATA3- 0xFFC0 2CAC

CAN_MB06_DATA3- 0xFFC0 2CCC

CAN_MB07_DATA3 -0xFFC0 2CEC

CAN_MB08_DATA3- 0xFFC0 2D0C

CAN_MB09_DATA3 -0xFFC0 2D2C

CAN_MB10_DATA3 -0xFFC0 2D4C

CAN_MB11_DATA – 0xFFC0 2D6C

CAN_MB12_DATA3-0xFFC0 2D8C

CAN_MB13_DATA3- 0xFFC0 2DAC

CAN_MB14_DATA3 -0xFFC0 2DCC

CAN_MB15_DATA3- 0xFFC0 2DEC

CAN_MB16_DATA3- 0xFFC0 2E0C

CAN_MB17_DATA3-0xFFC0 2E2C

CAN_MB18_DATA3- 0xFFC0 2E4C

CAN_MB19_DATA3 – 0xFFC0 2E6C

CAN_MB20_DATA3 – 0xFFC0 2E8C

CAN_MB21_DATA3- 0xFFC0 2EAC

CAN_MB22_DATA3-0xFFC0 2ECC

CAN_MB23_DATA3- 0xFFC0 2EEC

CAN_MB24_DATA3 -0xFFC0 2F0C

CAN_MB25_DATA3 -0xFFC0 2F2C

CAN_MB26_DATA3 -0xFFC0 2F4C

CAN_MB27_DATA3 -0xFFC0 2F6C

CAN_MB28_DATA3- 0xFFC0 2F8C

CAN_MB29_DATA3 -0xFFC0 2FAC

CAN_MB30_DATA3-0xFFC0 2FCC

CAN_MB31_DATA3-0xFFC0 2FEC

Figura 27. Registrul de Mailbox 2

CAN_MB00_DATA2- 0xFFC0 2C08

CAN_MB01_DATA2 -0xFFC0 2C28

CAN_MB02_DATA2 -0xFFC0 2C48

CAN_MB03_DATA2 -0xFFC0 2C68

CAN_MB04_DATA2 -0xFFC0 2C88

CAN_MB05_DATA2 -0xFFC0 2CA8

CAN_MB06_DATA2 – 0xFFC0 2CC8

CAN_MB07_DATA2 -0xFFC0 2CE8

CAN_MB08_DATA2- 0xFFC0 2D08

CAN_MB09_DATA2 -0xFFC0 2D28

CAN_MB10_DATA2 -0xFFC0 2D48

CAN_MB11_DATA2-0xFFC0 2D68

CAN_MB12_DATA2- 0xFFC0 2D88

CAN_MB13_DATA2 -0xFFC0 2DA8

CAN_MB14_DATA2 -0xFFC0 2DC8

CAN_MB15_DATA2 – 0xFFC0 2DE8

CAN_MB16_DATA2- 0xFFC0 2E08

CAN_MB17_DATA2- 0xFFC0 2E28

CAN_MB18_DATA2 – 0xFFC0 2E48

CAN_MB19_DATA2-0xFFC0 2E68

CAN_MB20_DATA2- 0xFFC0 2E88

CAN_MB21_DATA2-0xFFC0 2EA8

CAN_MB22_DATA2-0xFFC0 2EC8

CAN_MB23_DATA2-0xFFC0 2EE8

CAN_MB24_DATA2-0xFFC0 2F08

CAN_MB25_DATA2-0xFFC0 2F28

CAN_MB26_DATA2-0xFFC0 2F48

CAN_MB27_DATA2-0xFFC0 2F68

CAN_MB28_DATA2-0xFFC0 2F88

CAN_MB29_DATA2-0xFFC0 2FA8

CAN_MB30_DATA2-0xFFC0 2FC8

CAN_MB31_DATA2-0xFFC0 2FE8

Figura 28. Registrul de mailbox 1

CAN_MB00_DATA1- 0xFFC0 2C04

CAN_MB01_DATA1- 0xFFC0 2C24

CAN_MB02_DATA1 – 0xFFC0 2C44

CAN_MB03_DATA1 – 0xFFC0 2C64

CAN_MB04_DATA1 – 0xFFC0 2C84

CAN_MB05_DATA1 – 0xFFC0 2CA4

CAN_MB06_DATA1- 0xFFC0 2CC4

CAN_MB07_DATA1 – 0xFFC0 2CE4

CAN_MB08_DATA1 -0xFFC0 2D04

CAN_MB09_DATA1 -0xFFC0 2D24

CAN_MB10_DATA1 -0xFFC0 2D44

CAN_MB11_DATA1 -0xFFC0 2D64

CAN_MB12_DATA1 -0xFFC0 2D84

CAN_MB13_DATA1- 0xFFC0 2DA4

CAN_MB14_DATA1 -0xFFC0 2DC4

CAN_MB15_DATA1 -0xFFC0 2DE4

CAN_MB16_DATA1 -0xFFC0 2E04

CAN_MB17_DATA1 -0xFFC0 2E24

CAN_MB18_DATA1 -0xFFC0 2E44

CAN_MB19_DATA1 -0xFFC0 2E64

CAN_MB20_DATA1 -0xFFC0 2E84

CAN_MB21_DATA1 -0xFFC0 2EA4

CAN_MB22_DATA1- 0xFFC0 2EC4

CAN_MB23_DATA1 -0xFFC0 2EE4

CAN_MB24_DATA1 -0xFFC0 2F04

CAN_MB25_DATA1 -0xFFC0 2F24

CAN_MB26_DATA1 -0xFFC0 2F44

CAN_MB27_DATA1 -0xFFC0 2F64

CAN_MB28_DATA1 -0xFFC0 2F84

CAN_MB29_DATA1 -0xFFC0 2FA4

CAN_MB30_DATA1 -0xFFC0 2FC4

CAN_MB31_DATA1 -0xFFC0 2FE4

Figura 29. Registrul de mailbox 0

CAN_MB00_DATA0-0xFFC0 2C00

CAN_MB01_DATA0 – 0xFFC0 2C20

CAN_MB02_DATA0 – 0xFFC0 2C40

CAN_MB03_DATA0 – 0xFFC0 2C60

CAN_MB04_DATA0-0xFFC0 2C80

CAN_MB05_DATA0-0xFFC0 2CA0

CAN_MB06_DATA0-0xFFC0 2CC0

CAN_MB07_DATA0 – 0xFFC0 2CE0

CAN_MB08_DATA0-0xFFC0 2D00

CAN_MB09_DATA0-0xFFC0 2D20

CAN_MB10_DATA0 – 0xFFC0 2D40

CAN_MB11_DATA0 – 0xFFC0 2D60

CAN_MB12_DATA0 – 0xFFC0 2D80

CAN_MB13_DATA0 – 0xFFC0 2DA0

CAN_MB14_DATA0 – 0xFFC0 2DC0

CAN_MB15_DATA0 – 0xFFC0 2DE0

CAN_MB16_DATA0 – 0xFFC0 2E00

CAN_MB17_DATA0-0xFFC0 2E20

CAN_MB18_DATA0-0xFFC0 2E40

CAN_MB19_DATA0-0xFFC0 2E60

CAN_MB20_DATA0-0xFFC0 2E80

CAN_MB21_DATA0-0xFFC0 2EA0

CAN_MB22_DATA0-0xFFC0 2EC0

CAN_MB23_DATA0-0xFFC0 2EE0

CAN_MB24_DATA0-0xFFC0 2F00

CAN_MB25_DATA0-0xFFC0 2F20

CAN_MB26_DATA0 – 0xFFC0 2F40

CAN_MB27_DATA0-0xFFC0 2F60

CAN_MB28_DATA0 – 0xFFC0 2F80

CAN_MB29_DATA0-0xFFC0 2FA0

CAN_MB30_DATA0-0xFFC0 2FC0

CAN_MB31_DATA0-0xFFC0 2FE0

3.14.3 Registrii de control ai mailbox-urilor

Figura 30. Registrul de configurare Mailbox 1

Figura 31. Registrul de configurare Mailbox 2

Figura 32. Registrul de directie 1

Figura 33. Registrul de directive 2

Figura 34. Registrul de mesaj in asteptare 1

Figura 35. Registrul de mesaj in asteptare 2

Figura 36. Regisrul de mesaje pierdute 1

Figura 37.Regisrul de mesaje pierdute 2

Figura 38. Registrul de protectie a rescrierii 1

Figura 39. Registrul de protectie a rescrierii 2

Figura40. Registrul de setare a cereri de transmisie 1

Figura 41. Regsitrul de setare a cereri de transmisie 2

Figura 42. Regsitrul de resetare a cereri de transmisie 1

Figura 43. Regsitrul de resetare a cereri de transmisie 2

Figura 44. Registrul acceptarii anularii 1

Figura 45. Registrul acceptarii anularii 2

Figura 46. Registurl de acceptare a transmiterii

Figura 47. Registurl de acceptare a transmiterii

Figura 48. Registrul de dezactivare temporara a maibox-urilor

Figura 49. Registrul de maipulare a cadrelor de la distanta 1

Figura 50. Registrul de maipulare a cadrelor de la distanta 2

Figura 51. Registrul de masti de intrerupere pentru Mailbox-uri 1

Figura52. Registrul de masti de intrerupere pentru Mailbox-uri2

Figura 53. Registrul de flaguri de intrerupere a transmiterii pentru mailbox-uri 1

Figura 54. Registrul de flaguri de intrerupere a transmiterii pentru mailbox-uri 2

Figura 55. Registrul de flaguri de intrerupere a primirii mesajului pentru mailbox-uri 1

Figura 56. Registrul de flaguri de intrerupere a primirii mesajului pentru mailbox-uri 2

3.14.4 Registrii numaratori universali

Figura 57. Registrul de configurare a numaratorului

Figura 58. Registru numerator universal

Figura 59. Registrul de reincarcare a numaratorului

3.14.5 Registrii de eroare

Figura 60. Registrul de eroare a numaratorului

Figura 61. Registurl de stare a erorilor numaratorului

Figura 62s. Registrul de avertizari al numaratorului universal

IV. LwIP TCP/IP

Pachetul de lucru cu stiva TCP/IP lwIP in cadrul procesoarelor din familia Blackfin conta intr-o varianta disponibila gratuit a stivei lwIP. Stiva portat foloseste un dirver de interfata standardizat pentru a permite folosirea cu diferite controllere Ethernet. Toate driverele sunt implementate ca facand parte din modelul de drivere PTG si folosesc librariile serviciilor sistem(System Services Libraries)

Stiva ofera socket-ul standard BSD pentru aplicatii si a fost structurata pentru a o decupla de la sistemul de operare si interfata de reteta care este folosita. Stiva este conectata la mediul inconjurator din motive de standardizarea interfetei care sunt implementatea ca diferite librarii pentru fiecare mediu separat.

API-ul pentru nucleu abstractizeaza serviciile sistemulei de operare si facilitatile necesare stivei si este folosit pentru a simplifica trecerea aplicatiei intr-un sistem de operare diferit. Serviciile de baza includ servicii de sincronizare, servicii pentru tratarea intreruperilor, si servicii de reapelare bazate pe timp. Librariile kervdkbfxxx.dlb ofera o implementarea a interfete pentru a active stiva in vedere folosirii acesteia cu VDK pe diferite procesoare Blackfin. Stiva poate fi folosita cu alte nuclee furnzandui o impementare a interfetei api a nucleului necesar si a procesorului.

Stiva ofera suport pentru orice controller Ethernet care are un driver care suporta o interfata care este definite in fisierul EtherDeviceDriverDefinition.doc. Definitia interfeteio furnizeaza un set comun de functii care trebuie sa fie furnizat pentru fiecare implementare. Fiecare implementare poate deasemenea sa furnizeze un set extins de functionalitati. Stiva insasi va folosi doar functiile comune dar aplicatiile pot fi avantajate de setul de functii extins. Odata cu stiva sunt disponibile implementari ale interfetelor pentru diferite placi cum ar fi Blackfin537

Visual DSP++ 5.0 permite crearea unui proiect VDK cu suport TCP/IP auntoinclus si gata pentru folosire. Detaliile interfetei socket-urilor pot fi accesat deschizand index.html din directorul <install_path>\Blackfin\lwip\docs\socket_api

Configurarea stivei poate fi efectuata folosind un plugin Visual DSPcare va genera fisiere antet adaptate si o structura C initializata ce va fi folosita de stiva. Acesta permita modificare configurarii initiale a parametrilor. Alternativ stiva poate fi configurata complet modificand standardul antetului lwIP manual.

Este furnizat deasemena si suport pentru a permite urmarirea cadrelor trimise si receptionate de catre stiva fie direct pe procesorul Blackfin sau pe aplicatia calculatorului gazda folosind o conectie TCP/IP sau Background Telemetry Channel.

Stiva suporta urmatoarele protocoale:

TCP Transport Control Protocol

UDP User Datagram Protocol

IP Internet Protocol

ICMP Internet Control Message Protocol

ARP Address Resolution Protocol

DHCP Dynamic Host Configuration Protocol (DHCP client supporting BOOTP)

DSN Domain Name System

Una dintre principalele scopuri la portarea stivei a fost minimalizarea schimbarilor necesare sursei actualei stive lwIP pentru a activa noutati stivei ce pot fi integrate mai usor. Principalele schimbari care au fost facut sunt mentionat mai jos:

Alocarea memoriei de baza a fost schimbata de la tablouri statice la alocare dinamica in momentul in care stiva este initializata

Procedure de detectia erorilor pe diferite fire de executie pentru anumite socket-uri

Adaugarea unuor campuri anumitor structuri pentru a asigura corectitudinea

Toate schimbarile facute stive sunt sub controlul procesoarelor ADSPBLACKFIN

V. Aplicatie: Tranferul unui mesaj folosind magistrala CAN

5.1 Scopul aplicației

Obiectivul principal al aplicației este implentarea unor programe soft astfel încât să se facă posibilă si vizibilă transmiterea unui mesaj între două plăci ADSP-Blackfin 537 folosind magitrala CAN. Demostrația va fi efectuată pe doua plăci dar aceasta poate fi extinsă la un număr foarte mare de controller pentru că așa cum am explicat anterior o rețea CAN este o rețea peer-to-peer. Faptul ca o rețea este p2p ne oferă flexibilitatea de a adăuga oricând un alt nod sau de a scoate oricând un nod din rețea fara a afecta funcționalitățile acesteia.

5.2 Proiectarea aplicației

Având în vedere că dorim să demonstrăm o transmisie pe magistrala CAN avem nevoie de următoarele:

Două placi ADSP-BF537

1 cablu telefonic cu mufe RJ11 crossover

Două calculatoare pentru a putea încărca programele soft pe plăci

2 cabluri cu mufă USB pentru a încarca repectivele programe

Pentru a putea demostra aceast concept consider ca este nevoie de două programe diferite care vor fi incarcate pe cele două plăci. Acest lucru este necesar doarece în cadrul unei transmisii pe intr-o rețea un dipozitiv trebuie sa trimita si celalalt sa primească.

În continuare se va explica implementarea a doua programe CAN_RX si CAN_TX care au rolul de a face managemantul unui pachet CAN primit pe magistrala respect ce se dorește sa fie transmis.

CAN_TX este un program care se ocupa efectiv de transmiterea unui pachet de tip CAN pe magistrala catre un alt controller CAN. Explicat rudimentar la apăsarea unui buton existent pe placa BF537 programul va inițialza o transmisie CAN si va trimite un mesaj cu codul butonului apasat mai departe. Dupa ce transmisia e fost efectuată acesta așteaptă un pachet înapoi care să conțină un ACK(faptul că pachetul a fost recepționat cu success) si va aprinde ledul corespunzător butonului apăsat. Dacă nu se primește pachetul cu ACK trasmisia este reluată.

Pentru a putea să rulam acest program trebuie sa ne asiguram ca switch-urile 2.4 si 5.1-4 sunt setate pe poziția ”on”. Switch-ul 2 este folosit pentru a putea lucra cu controller-ul CAN de pe placă, iar switch-ul 5 este folosit pentru activarea butoanelor.

Programul conține patru fișiere sursă ce vor fi prezentate în continuare:

Fișierul sursă principal (main.c) are rolul de a efectua procesele de inițializare și de a seta placa sa astepte o întrerupere. Pentru inițializarea tuturor evenimentelor necesare se executa urmatoarele funcții:

Init_PLL(); – folosita pentru generarea unui frecvente stabile.În cadrul acesteia se seteaza CCLK si SCLK

Init_Port(); – funcție de inițializare a porturilor

Init_Interrupts(); – funcție de inițializare a întreruperilor

Init_CAN_Timing(); – funcție care seteaza Clock-ul de lucru al CAN

Init_CAN_Mailboxes(); – funcție de inițializare a mailbox-urilir

CAN_Setup_Interrupts(); – funcție pentru stabilirea intreruperilor

CAN_Enable(); – functie pentru activarea dispozitivului CAN

În continuare programul intră într-o buclă infinită pentru a astepta o întrerupere fizică (de la butoane). Pentru aceasta în libaj soft s-a implementat un ciclu infinit while(1)

Fișierul sursă Initialization.c este fisierul care conține codul sursa efectiv al funcțiilor de inițializare. Funcțiile specifice și cele mai importante sunt:

Init_CAN_Timing() este funcția în care se seteaza regiștrii CAN_TIMING și CAN_CLOCK cu valorile: *pCAN_TIMING = 0x0334 respectiv *pCAN_CLOCK = 22;

Init_CAN_Mailboxes() este funcția care inițializează modul de lucru cu mailbox-urile. În aceasta se setează ID-ul mesajlului folosit pentru primire sau pentru trimitere și se scoate masca. În cazul nostru ID primire este 0x007 iar pentru trimitere este 0x411.

Init_interupts() este funcția care inițializează întreruperile. Detaliat aceasta asignează fiecărei întreruperi un canal( un nivel de prioritate) și memorează adresele de inceput ale subrutinei de tratare a întreruperilor. În cazul de față întreruperea de primire a unui pachet este pe nivelul 7 iar intrerupere pentru trimiterea unui pachet este pe nivelul 8

Fisierul sursă CAN_Functions.c conține două funcții importante: una pentru activarea întreruperilor și una pentru activarea controllerului CAN. În funcția de activarea a controller-ului CAN se setează ca mailbox-ul 7 să fie pentru transmitere și maibox-ul 24 pentru primire.

Fisierul sursă Interupts.c conține codul de tratare al întreruperilor. În cazul întreruperii de trimitere se verifica ce mailbox dorește să transmita se transmite codul din partea de date a acestuia. În cadrul întreruperii de primire acesta după ce a primit mesajul ACK de la aprinde led-ul corespunzător butonului apăsat.

CAN_RX este un program care tratează partea de primire pe magistrala CAN pe o placa Blackfin537. Odată încărcat pe placă programul face ca ledurile acesteia să se aprinda unul câte unul de la stanga la drepta (această aprindere o vom denumi in continuare shiftare de la stanga la dreapta). Aceasta este starea de wait a programului el asteptând o întrerupere. Întreruperea are loc când primește un pachet de la un alt controller CAN în mailbox-ul 24. În acel moment în funcție de datele din pachet se execută o schimbare de luminozitate a ledurilor: fie se sting toate, fie se aprind toate, fie shiftarea se inverseaza sau fie toate becurile se sting și se aprind în același timp. Aceste lucruri sunt facute in functi de codul butonului care s-a apasat pe placa unde este incarcat programul CAN_TX.

Pentru initializare programul folosesc aceleasi functii ca si CAN_TX. In schimb in acesta apar urmatoarele diferente:

In fisierul sursa main.c dupa inițializarea întreruperilor, porturilor, și controllerului CAN se executa un while(1)- infinit care așteaptă o întrerupere. În cadrul acestuia există un alt while care se executa cât timp nu a aparut altă întrerupre. Cel de-al doilea while face efectiv afișarea pe leduri în funcție de anumite variabile presetate în întreruperea de primire: blink, off, change,display.

Trebuie menționat că în fisierul sursă initialization.c de data aceasta ID-ul mesajelor acceptate de mailbox-ul 24(cel de primire) este cel al mesajelor din mailbox-ul 7 din CAN_TX si ID-ul mesajelor trimise de mailbox-ul 7 este cel al mesajelor acceptate de mailbox-ul 24 din CAN_TX.

O altă diferență apare în întrerupere de primire. Când se semnalizează ca au fost puse date in mailbox-ul 24 in zona Data_3 se iau datele de acolo și în funcție de cod(codul butonului apăsat pe placa CAN_TX) se seteaza variabilele dupa cum urmeaza:

0x0400(butonul 4) – off=1, blink=0

0x0300(butonul 3) – blink=0,off=0,scroll=1 iar change egal cu 0 sau 1 pentru schimbare de direcție

0x0200(butonul 2) – la fel ca la butonul 3 doar ca scroll=0

0x0100(butonul 1) – off=0,blink=1, display=0fc0(toate ledurile aprinse)

5.3 Rularea și testarea aplicatiei

Pentru a putea rula aplicația avem nevoie după cum am menționat anterior de doua placi Blackfin Ez Kit Lite 537, Visual DSP++ 5.0, 2 calculatoare si un cablu telefonic cu mufe RJ11 crossover.

Încărcarea pe placi și apoi testarea se fac după cum urmează:

Se conectează cele două plăci la cele două calculatoare prin intermediul cablului USB pentru a putea încărca aplicația în memoria plăcilor

Pe cele două calculatoare se pornește VisualDSP++ 5.0 Evironement. În acesta din meniul File se alege opțiunea Open și se deschid cele două proiecte CAN_TX și CAN_RX fiecare pe câte un calculator

Cele două placi se conectează pe magistrala CAN folosind cablul crossover

De pe fiecare calculator din VisualDSP++ se încarcă programele pe placă. Pentru aceasta trebuie să apasăm butonul Build.

După ce programele au fost încărcate pe placa pe care a fost încarcat CAN_TX observăm că toate ledurile s-au stins iar pe placa pe care a fost încărcat CAN_RX observăm o shiftare de la stanga la dreapta a ledurilor.

Pentru a testa comunicația se apasă un buton de pe placa pe care e încarcat CAN_TX. În urma apăsării unui buton vom observa o schimbare în modul de luminare al ledurilor de pe placa pe care este încărcat CAN_RX iar pe placa cealaltă se va aprinde ledul corespunzător butonului apăsat, ceea ce ne spune că placa a primit ACK

Trebuie mentionat înca o dată că pentru a putea sa rulăm aceste programe trebuie să setăm switch-ul 2.4 pe ”on” (Enable CAN receive) și switch-ul 5.1-4 pe ”on” (enable push buttons).

VI. Aplicație: Transferului unui pachet pe Ethernet

6.1 Scopul Aplicației

Prin acestă aplicație se testează folosirea unui pachet de programe soft oferite de firma Analog Devices pentru a trimite pachete de la o placă DSP Blackfin537 către un calculator folosind interfața Ethernet. Aplicația în sine necesita încarcarea unui program pe FileServerStdioBF537 care se va conecta la un calculator folosind IP-ul acestuia, configurat în prealabil, și va trimite apoi un fișier text care conține ”test” de 1000 de ori folosind socket-ul 20000. Pentru a putea trimite este necesar să deschidem aplicația concepută de Analog Devices FileServer.exe. În aceasta înafară de faptul că vom observa momentul în care s-a făcut conectarea efectivă și transmiterea fișierului, vom putea observa în consolă și textul afișat de 1000 de ori.

6.2 Descrierea aplicației

Pentru a putea rula această aplicație avem nevoie de urmatoarele:

Un calculator

Un cablu de rețea UTP cu mufe RJ45

O placă Blackfin EZ KIT LITE 537

Proiectul FileServerStdioBF537 este dezvoltat folosind VDK. Acesta lucrează în întreruperi de tip DMA pentru a face transferul pe interfața Ethernet. Principala funcționalitate a acestuia este de a deschide o conecție nouă către un IP host setat la începutul programului, a redirecționa stdout către acesta, de a crea un nou fișier pe harddisk-ul hostului, a scrie în acesta și a scrie în consola programului FileServer.exe. În linii mari este simularea unei aplicații client server.

Proiectul FileServerStdioBF537 conține urmatoarele fișiere:

lwip_sysboot_threadtype.c – acesta este fișierul sursă folosit de firul de execuție de bootare. În cadrul acestuia se fac toate operațiile principale cum ar fi deschiderea unui setarea adresei IP a calculatorului host, deschiderea unei noi conecții, redirecționarea stdout, scriere fișierului la adresa de IP setatș, scriere textului în consolă, modul de creare a noilor fire de execuție, stabilirea priorităților acestora și a comunicației dintre ele. Pentru deschiderea unei noi conecții se folosește funcția system_init() iar pentru redirecționarea către host se folosește FS_STDIO_init(5, FILE_ SERVER _HOST _ADDRESS,20000) implementată în FileServerStudio.c

.Fișierul FileServerStudio.c este cel în care sunt implementate funcțiile necesare pentru redirecționarea std la adresa IP a hostului:

Redirect() – redirecționează unul dintre stoud, stdin, stderr și redeschide ”con:” un nume de fișier specific FileServer

Make-connection() – Crează o conecție la FileServer și cere ca fișierul să fie deschis

FS_STDIO_init –inițialezează funcția pentru acest dispozitiv STDIO, acceptă un număr unic de aplicație folosit pentru instalare, o intrare în tabela sa de rulare, Apoi face driver cel implicit și redirecționează fișierele. Un alt argument specifică adresa IP și portul calculatorului cu care va comunica și adresa IP a dispozitivului de pe care se trimite. Argumentul PortBase este unul dintre cele 16 porturi de adresă pe care acest driver îl poate folosi pentru conecția sa

FS_open – este apelată când aplicația dorește să deschidă un fișier, alocă o intrare în tablela de socket-uri și obține un socket de conectare către calculatorul unde rulează FileServer și trimite o cerere ”open”. La final întoarce fid-ul intrării în tabela de socket-uri care este folosit de funcțiile FS_write si FS_read

FS_write – scrie pe un anumit socket

FS_read – citește de la un anumit socket

Fișierul ExceptionHandler- BF537.asm este fișierul care conține subrutina de tratare a întreruperii necesară pentru transmitere pe interfața Ethernet

6.3 Rularea și testarea aplicației

Pentru a putea rula aplicația se execută următorii pași:

Se conectează placa Blackfin la calculator folsind interfața USB pentru a încarca programul

Se deschide VisualDSP++ 5.0, se setează un IP pentru placa DSP după cum urmează

Se selectează din meniul Setting opțiunea Preferences. În cadrul acestei navigăm până la plugins de unde selectăm TCP/IP configuration Manager. Apoi din meniu Settings se selectează TCP/IP Configuration. În network 0 se poate memora IP-ul plăcii Blackfin așa cum este prezentat în figura urmatoare.

După configurarea rețelei proprii în fișierul sursă lwip_sysboot_ thread type.c se setează IP-ul calculatorului către care dorim să transmitem.

Se încarcă programul pe placă folosind butonul Build din VisualDSP

Înainte de a se face conectarea se deschide pe calculatorul pe care dorim să primim program FileServer.exe din VisualDSP/…/Blackfin537/ Examples /Lan /Host /Fileserver.

Se crează un director ”tmp” în care va fi creat fișierul de test automat

După încărcarea aplicației pe placă se observă cum se efectuează conectarea și ca rezultat vom avea în consola FileServer cuvântul Heeellllllo de 1000 de ori. Dacă deschidem directorul ”tmp” creat vom oberva fișierul txt adăugat automat în care găsim acelasi text de 1000 de ori. În concluzie trasnmisia a fost reușită.

VII. Aplicație: Transportul într-o rețea hirbidă CAN->Ethernet

7.1 Scopul aplicației

Prin implementarea acestei aplicații se dorește realizarea transmiterii unui pachet într-o rețea mixtă CAN->Ethernet. Cu alte cuvinte se va realiza o comunicație CAN între două plăci Backfin537 iar una dintre acestea va transmite mai departe un mesaj primar pe magistrala CAN către un calculator folosind interfața Ethernet.

Presupunem că avem un angrenaj foarte mare folosind într-o uzină care conține în implementarea sa o rețea CAN. Acesta este vitală pentru funcționarea corespunzatoare a mecanismului. Folosind modelul propus anterior putem oricând să monitorizăm această rețea conectându-ne cu un simplu laptop ca la o rețea normală, poate chiar fară a ști cum funcționează rețeaua CAN.

7.2 Proiectarea aplicației

Pentru a putea realiza cerințele acestei aplicații avem nevoie de :

Două plăci Blackfin EZ KIT LITE 537

Două sau trei calculatoare

Un cablu telefonic cu mufe RJ11 corssover pentru conectarea controller-elor CAN

Un calbu UTP cu mufe RJ45 pentru a reliza rețeaua între placă și un calculator

Pentru a demonstra funcționalitatea acestei rețele hibrite am gândit un scenariu combinând cele două apicații prezentate anterior.

Observand fluxul , informația pleacă de la o placă, ajunge la cealaltă placă de unde este trimis în continuare către un calculator.

Pentru a face comunicația dintre cele două placi pe magistrala CAN am prezentat anterior o aplicație care folosea două programe ce se încărcau pe două placi separat.Program încărcat pentru transmitere (CAN_TX) transmitea codul unui buton apăsat pe placa pe care era încărcat către cealalta placă. În momentul în care a doua placă primea un pachet CAN datorită programului încărcat pe ea(CAN_RX) aceasta intră în întrerupere verifică ce date a primit în mailbox-ul setat pentru primire(24) iar în funcție de codul gasit se efectua o schimbare în modul de luminare a ledurilor de pe această placă. Se trimitea apoi către prima placă un ACK pentru a semnala faptul că pachetul a fost primit cu succes

Pentru a face comunicația dintre o placa BF537 și un calculator am prezentat anterior o aplicație care folosea un program FileServerStdio-bf537 care era încărcat pe placă și un FileServer.exe care era rulat pe host. Programul încărcat pe placă redirecționa stdout, și stdin către programul rulat pe host pe portul 20000 și scria un fișier și un text în consola FileServer.

Având în minte cele două aplicații ne dăm seama că pentru a efectua transmisia noastră putem folosi în continuare programele efectuate anterior cu anumite modificări.

CAN_TX – acest program poate fi folosit în continuare și în aplicația curentă fără a fi modificată deoarece se ocupă doar cu transmiterea unui cod în momentul în care este declanșată o întrerupere de la un buton

CAN_RX – acest program nu poate fi folosit în continuare pentru că nu face decât să primească date și să modifice afișajul ledurilor. Programul nu este totuși inutil doarece se pot folosi din el funcțiile de initializare a dispozitivului CAN și conținutul întreruperii de primire.

FileServerStdio-BF537 – programul nu poate fi folosit în continuare pentru că face doar o simplă transmisie către un calculator folosind IP-ul acestuia. Totuși nici acest program nu este inutil pentru că pe se ocupă de inițializarea unei conecții TCP/IP și de trimitere unor date. Acesta poate fi considerat un schelet pentru o nouă aplicație care ar trebui să primească date de la controller-ul CAN și să le trimită mai departe folosind TCP/IP

FileServer.exe – programul poate fi folosit în continuare deoarece permite conectarea, redirecționarea stdou, și stdin a unei plăci bf537 la un calculator pe baza unui IP și a unui Socket. Programul este ideal pentru demonstrarea succesului transmiterii deorece interfața permite vizualizarea imediat și este foarte simplă

Privind mai sus observăm că în momentul de față avem doar ”capetele” unei transmisii de date: partea de trimitere și partea de primire. Tot ce ramâne de efectuat este partea de mijloc care se ocupă recepția și retransmitere datelor.

Pentru a rezolva această problemă luând în considereare cele spuse mai sus am realizat un program care îmbina functionalitățiile CAN_RX și FileServerStdio-BF537. Programul se numește CR&FS(CAN Recive and File Server).

Pentru implementarea acestui program există trei metode:

Inserarea codului din CAN_RX necesar în zone optime de cod ale FileServerStdio-BF537 pentru a atinge funcționalitatea dorită

Crearea unui nou fire de execuție în VDK, adăugarea unui nou dispozitiv și întreruperile acestuia. Pentru a transmite apoi informația rezultat primit în firul de execuție CAN este transmis către firul de execuție care se ocupă de transmisie pe TCP/IP cu ajutorul unei variabile externe

Îmbinarea zonei de inițializare a controlului odată cu inițializarea conecției TCP/IP și realizarea unei noi întreruperi specifice CAN în VDK

Varianta aleasă pentru implementare este prima. În continuare voi explica cum folosind scheletul aplicație FileServerStdio-BF537 vom adauga secțiuni de cod din CAN_RX pentru a realiza funcționalitatea necesară.

Sursa firului de execuție de start lwip_sysboot_threadtype.c va fi modificată pentru a avea următoarele funcționalități în această ordine:

Inițializarea întreruperilor CAN

Inițializarea CAN_TIMING

Inițializarea întreruperilor

Inițializarea mailbox-rulor CAN

Setarea întreruperilor CAN

Activarea dispozitivului CAN

Inițializarea conecției

Inițializarea stivei

Redirecționarea stdout și stdin la IP-ul hostului

While(1) ciclu infinit pentru a vedea dacă apar date în mailbox-ul 24

Verificăm continuu dacă apar date în mailbox

În momentul apariției datelor se setează asemeni întreruperii CAN variabilele blink,off,change, și display pentru a avea în continuare schimbarea de lumini pe placa intermediară transmisiei. Datele primite se memorează într-o variabilă care este scrisă apoi în fișier și pe consola FileServer de pe calculatorul host.

7.3 Rularea și testarea aplicației

Pentru a testa aplicația se conectează cele două plăci la două calculatoare prin intermediul interfeței USB. Pe fiecare se încarcă programele CAN_TX respectiv CR&FS folosind VisualDSP++. Placa pe care s-a încarcat CR&FS se conectează folosind interfața Ehernet la un al treilea calculator. După ce programele au fost încărcate pe placi se deschide FileServer pe al treilea calculator pentru a permite redirecționarea stdout și stdin, și se crează directorul c:\proiect licență. După ce programele sunt încărcate și rulează vom observa că în urma apăsării unui buton pe placă unde este încărcat CAN_TX , ledurile iși vor schimba tipul luminării pe placă unde este încărcat CR&FS și în același timp pe calculator se va crea un fișier în directorul nou crest numit test.txt. La deschidere fișierului se poate vedea un text de tipul: ”cod_buton” – A fost apăsat butonul x, semna că transmisia a funcționat, și codul transmis de prima placă a ajuns pe calculator.

VIII. Concluzii

Având in vedere evoluția tehnologiei putem observa o creștere exponențială a nevoii de aplicații real-time.

In urma studierii conceptelor prezentate anterior și anume protocolul CAN(Controller Area Network) și stiva TCP/IP folosind ADSP Blackfin 537 EZ KIT LITE am ajuns la concluzia că protocolul CAN a fost optimizat pentru sisteme care au nevoie să transmită sau să recepționeze foarte rapid cantități mici de date,comparativ cu Ethernet sau USB care sunt folosite pentru transportul unuor pachete mari de date.

Din moment ce protocolul este bazat pe mesaje nu pe adrese, toate dispozitivele conectate la magistrală primesc orice mesaj, necontând dacă datele din acesta sunt relevante sau nu pentru ele. Aceasta permite magistralei să opereze cu mesaje punct-la-punct, sau multicast fără a fi nevoie să trimită diferite tipuri de mesaje.

Un alt punct important este faptul că rețeaua CAN este o rețea peer-to-peer. Datorită acestei arhitecturi rețeaua este una fiabilă. În cazul în care nu se defectează acesta este ”scos” din magistrala fără a afecta funcționarea celorlalte noduri.

In plus,CAN oferă o soluție ieftină și durabilă pentru o rețea de comunicație între mai multe dispozitive CAN. Un avantaj al acestui lucru este că unitățile de control pot avea o singură interfață CAN în loc de intrări pentru fiecare dispozitiv analogic sau digital din sistem. Acest lucru micșorează costurile și greutatea produsului rezultat. Fiecare dispozitiv din rețea are un controller CAN. Toate dispozitivele din rețea văd toate mesajele transmise, putând astfel să decidă dacă mesajul este ralevant sau trebuie filtrat. În plus fiecare mesaj are o prioritate, și deci dacă două noduri încearcă să trimită un mesaj simultan, cel cu prioritate maximă are dreptul de transmitere.

Din punct de vedere al securitații, protocolul CAN este unul de nivel jos, si nu are integrată nici o caracteristică de securitate. Acest lucru este așteptat să fie dezvoltat in cadrul aplicațiilor ca mecanisme de securitate, cum ar fi de exmplu cel de autentificare al dispozitivului. Din această cauză dacă un atacator doreste sa introduca mesaje malițioase pe magistrală îi va fi foarte ușor.

Deși protocolul CAN a fost inventat de către Bosch la cererea companiei Mercedes și implicit primele utilizări ale acestuia au fost în cadrul autoturismelor, conceptul a câștigat rapid teren, fiind asimilat rapid în domeniul agricol, în automatizarea industriei si ingineria aviatică și altele, dovedind astfel calitățile noului protocol .

Privind comunicațiile Ethernet, chiar dacă acesta există de 38 de ani, abia acum cațiva ani au inceput sa câștige teren si totuși au inceput sa fie subclasate de comunicațiile wireless.

Ethernet oferă utilizatorilor săi un grad înalt de flexibilitate alocând banda exactă pentru cât trebuie să fie livrat. Acestea sunt extrem de scalabile suportând creșteri de lătime de bandă necesare in situați critice.

Comparând cele două tipuri de comunicații folosite CAN si Ethernet am ajuns să concluzionez că protocolul CAN este excelent utilizabil în aplicați care necesită promptitudine maximă și transfer mic de date (asemenea unor alarme), iar Ethernet este folosit pentru transportul unei cantități mari de date pe care nu dorim să le livrăm instant dar care totuși dorim să fie livrate cu succes si integral.

Cu toate că aplicația care implementează protocolul CAN a fost testată doar pe două placi BF537 iar efectul rezultat a fost aprinderea unor anumite leduri pot să spun că viteza de reacție a elementelor componente a fost foarte mare drept pentru care acesta poate fi folosit cu succes in toate aplicțiile de automatizare deja implementat sau ce urmează sa fie implementate.

Din punctul meu de vedere un viitor pentru magistrala CAN este hibridizarea acesteia cu o retea de senzori si aplicarea produsului rezultat in echipamente medicale cum ar fi echipamente pentru operare automatizata.

Avand in vedere aplicatia hibrida realizata in acest proiect tin sa mentionez ca aceasta isi poate gasi aplicabilitatea in monitorizarea si controlul unor dispozitive CAN dintr-un angrenaj industrial mare, cum ar fi un reactor nuclear doar cu o simpla conectare a unui calculator folosind placa de retea.

In plus pe langa aceasta aplicatie conectand un calculator la o magistrala CAN putem face chiar atacuri asupra acesteia.

Cea mai importanta idee care este prezentata in aceasta lucrare este faptul ca cu toate ca cele doua tipuri de comunicatii difera foarte mult, una referinduse la comunicatii de mare viteza si cantitati mici de date iar cealalata la cantitati mari de date indiferent de viteza, imbinarea celor doua poate duce la un nou model de comunicare in viitor.