BLE nën një mikroskop (ATTы GATTы…)
Pjesa 1, përmbledhje
Ka kaluar shumë kohë që nga publikimi i specifikimit të parë për Bluetooth 4.0. Dhe, megjithëse tema BLE është shumë interesante, ajo ende shtyn shumë zhvillues për shkak të kompleksitetit të saj. Në artikujt e mi të mëparshëm, unë shikoja kryesisht nivelin më të ulët, Shtresën e Lidhjes dhe Shtresën fizike. Kjo na lejoi të shmangnim përdorimin e koncepteve të tilla komplekse dhe konfuze si Protokolli i Atributit (ATT) dhe Profili i Atributit të Përgjithshëm (GATT). Sidoqoftë, nuk ka ku të shkojë, pa i kuptuar ato, është e pamundur të zhvillohen pajisje të pajtueshme. Sot do të doja të ndaja këtë njohuri me ju. Në artikullin tim do të mbështetem për fillestarët nga faqja e internetit Nordic. Pra, le të fillojmë.
Pse gjithçka është kaq e vështirë?
Sipas mendimit tim, u bë menjëherë e qartë se menaxhimi i pajisjeve përmes telefonave inteligjentë është një temë shumë premtuese dhe afatgjatë. Ndaj vendosën ta strukturojnë menjëherë dhe në maksimum. Në mënyrë që prodhuesit e pajisjeve të ndryshme të mos dalin me protokollet e tyre, të cilat më pas do të jenë të papajtueshme. Prandaj vështirësia. Tashmë në fazën e parë, ata u përpoqën të shtrydhnin gjithçka që ishte e mundur në protokollin BLE. Dhe nuk ka rëndësi nëse do të jetë e dobishme më vonë apo jo. Përveç kësaj, ata parashikuan mundësinë e zgjerimit të listës së pajisjeve për të ardhmen.
Le të hedhim një vështrim në foton ku është vizatuar diagrami i protokollit BLE. Ai përbëhet nga disa shtresa. Shtresa fizike më e ulët (PHY) është përgjegjëse për kanalin radio të pajisjes. Shtresa e lidhjes (LL) përmban të gjithë sekuencën e bajteve në mesazhin e transmetuar. Në artikujt e mëparshëm kemi studiuar pikërisht këtë. Ndërfaqja e kontrolluesit të hostit (HCI) është një protokoll shkëmbimi midis shtresave ose çipave BLE nëse Controller dhe Host zbatohen në çipa të ndryshëm. Protokolli i Kontrollit dhe Përshtatjes së Lidhjeve Logjike (L2CAP) është përgjegjës për formimin e paketave, kornizën, kontrollin e gabimeve dhe montimin e paketave. Protokolli i Menaxherit të Sigurisë (SMP) është përgjegjës për enkriptimin e paketave. Profili i Përgjithshëm i Aksesit (GAP) është përgjegjës për shkëmbimin fillestar të të dhënave midis pajisjeve për të përcaktuar "Kush është kush". Ai gjithashtu përfshin skanimin dhe reklamimin. Në këtë artikull do të fokusohem në dy pjesët e mbetura të protokollit - GATT dhe ATT. GATT është një superstrukturë e ATT, kështu që ato janë të ndërthurura ngushtë.
Për ta thjeshtuar historinë, do të doja të kthehesha në një analogji. E kam dëgjuar diku dhe do të doja ta mbështesja. Mendoni për një pajisje BLE si një raft librash me disa rafte. Çdo raft është një temë më vete. Për shembull, ne kemi rafte me fantashkencë, matematikë dhe enciklopedi. Në çdo raft ka libra me një temë të caktuar. Dhe disa libra madje kanë faqerojtës letre me shënime. Përveç kësaj, ne kemi një katalog të vogël letre të të gjithë librave. Nëse ju kujtohet, bibliotekat e shkollave janë një kuti e ngushtë me karta letre. Me këtë analogji, kabineti është profili i pajisjes sonë. Raftet janë shërbime, librat janë karakteristika dhe katalogu është një tabelë atributesh. Faqeshënuesit në libra janë përshkrues, për të cilët do të flas gjithashtu më vonë më në detaje.
Kushdo që ka zhvilluar pajisje e di se shumë projekte kanë pjesë të ngjashme të kodit. Fakti është se shumë pajisje kanë funksionalitet të ngjashëm. Për shembull, nëse pajisjet ushqehen me bateri, atëherë problemi i karikimit dhe monitorimit të nivelit të tyre do të jetë i njëjtë. E njëjta gjë vlen edhe për sensorët. Në fakt, një qasje e orientuar nga objekti ndaj programimit "ofron aftësinë për të krijuar objekte që kombinojnë vetitë dhe sjelljet në një bashkim të pavarur që më pas mund të ripërdoret". Sipas mendimit tim, BLE tentoi një qasje të ngjashme. Profilet u zhvilluan nga Grupi i Interesit Special të Bluetooth (SIG). Pajisjet nga prodhues të ndryshëm që kanë të njëjtat profile duhet të punojnë me njëra-tjetrën pa vështirësi. Profilet, nga ana tjetër, përbëhen nga shërbime dhe shërbime të karakteristikave, të plotësuara me përshkrues. Në përgjithësi mund të duket kështu:
Për shembull, merrni parasysh diagramin e profilit të një monitori të rrahjeve të zemrës (byzylyk fitnesi). Ai përbëhet nga dy shërbime dhe disa karakteristika. Prej tij hierarkia e profilit bëhet menjëherë e qartë. Karakteristika e pikës së kontrollit rivendos numrin total të shpenzimeve të kalorive në zero.
1. Shërbimi i rrahjeve të zemrës përfshin tre karakteristika (0x180D):
a) Karakteristikë e detyrueshme e rrahjeve të zemrës (0x2A37)
b) Karakteristika opsionale e pozicionit të sensorit të trupit (0x2A38)
c) Karakteristikat e kushtëzuara të pikës së kontrollit të rrahjeve të zemrës (0x2A39)
2. Shërbimi i mirëmbajtjes së baterisë (0x180F):
a) Karakteristika e nivelit të ngarkimit të detyrueshëm të baterisë (0x2A19)
UUID
Në mënyrë që ne të kemi qasje unike në elementët e profilit (shërbimet, karakteristikat dhe përshkruesit), duhet t'i numërojmë të gjitha disi. Për këtë qëllim, prezantohet një koncept si ID-ja unike universale (UUID) ose identifikuesi universal unik. UUID tregohet në kllapat e çdo rreshti. Dhe këtu ka një veçori. Për UUID, vendosëm të përdorim një kod me gjatësi 16 dhe 128 bit. Pse pyet? Në protokollin BLE, gjithçka ka të bëjë me ruajtjen e energjisë. Prandaj, dimensioni prej 16 bitësh është mjaft i arsyeshëm. Nuk ka gjasa që më shumë se 65 mijë të krijohen në të ardhmen e afërt. shërbime dhe karakteristika unike. Për momentin, gjithçka që ata mund të ishin numëruar tashmë (mos harroni se nga erdhi kjo - "ai ju numëroi edhe ju" :-)) Elemente të numëruara , , и mund të shikoni lidhjet.
Megjithatë, mendoj se të gjithë e mbajnë mend historinë me 4 bajt adresa IP në internet. Në fillim menduam se ishte e mjaftueshme, por tani ende nuk mund të kalojmë në një adresë 6 bajt. Për të mos përsëritur këtë gabim dhe për t'i dhënë dorë të lirë duarve lozonjare të DIYers, SIG vendosi menjëherë të prezantojë UUID 128-bit. Kjo më kujton personalisht brezin e palicencuar 433 MHz, i cili iu dha të gjitha llojeve të Kulibins nga kanali i radios. Në rastin tonë, u krijua një identifikues 128-bit i shërbimeve dhe karakteristikave. Kjo do të thotë që ne, për shërbimet dhe pajisjet tona, mund të përdorim pothuajse çdo vlerë 128-bit. Gjithsesi, probabiliteti për të dalë me të njëjtën UUID priret në zero.
Në fakt, UUID-të e shkurtër 16-bit kanë shtrirjen e tyre në një vlerë 128-bit. Në specifikim, kjo shtesë quhet Bluetooth Base UUID dhe ka vlerën 00000000-0000-1000-8000-00805F9B34FB. Nëse, për shembull, atributi 16-bit UUID ka vlerën 0x1234, atëherë UUID ekuivalent 128-bit do të ketë vlerën 00001234-0000-1000-8000-00805F9B34FB. Dhe madje formula përkatëse është dhënë:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nuk e di nga erdhi ky numër magjik. Nëse dikush nga lexuesit e di, le të shkruajë në komente (Një përdorues me pseudonimin Sinopteek e ka bërë tashmë këtë. Shihni komentet). Sa i përket krijimit të UUID-ve 128-bit, në parim mund të përdorni një speciale kush do ta beje per ty.
ATTy GATTy...
Në fakt, atëherë fillon argëtimi. Më lejoni t'ju kujtoj se ATT bazohet në një marrëdhënie klient-server. Tani po shikojmë pajisjen e serverit. Ai përmban informacione të tilla si vlerat e sensorit, statusin e çelësit të dritës, të dhënat e vendndodhjes, etj. Tani që të gjithë "pjesëmarrësit në paradën tonë" janë numëruar, ne duhet t'i vendosim disi në kujtesën e pajisjes. Për ta bërë këtë, ne i vendosim ato në një tabelë të quajtur tabelë atribute. Mbaje mend mirë këtë. Kjo është vetë zemra e BLE. Kjo është ajo që ne do të shqyrtojmë më tej. Tani do ta quajmë çdo rresht një atribut. Kjo tabelë ndodhet thellë në pirg dhe, si rregull, ne nuk kemi qasje të drejtpërdrejtë në të. Ne e inicializojmë atë dhe e aksesojmë atë, por ajo që ndodh brenda na fshihet pas shtatë vulave.
Le të shohim foton nga specifikimi, por para kësaj, do të doja të tërhiqja menjëherë vëmendjen për konfuzionin e shpeshtë në terma, përkatësisht në përshkruesit. Roli i përshkruesit është të plotësojë përshkrimin e karakteristikës. Kur është e nevojshme të zgjerohen aftësitë e tij, atëherë përdoren përshkruesit. Ato janë gjithashtu atribute, dhe ashtu si shërbimet dhe karakteristikat, ato janë të vendosura në tabelën e atributeve. Ne do t'i shqyrtojmë ato në detaje në pjesën e dytë të artikullit. Megjithatë, ndonjëherë përshkruesit i referohen numrit të rreshtit në tabelën e atributeve. Kjo duhet mbajtur parasysh. Për të shmangur konfuzionin, ne do të përdorim termin "tregues atributi" për këto qëllime.
Pra, një atribut është një vlerë diskrete që ka karakteristikat e mëposhtme të lidhura me të:
1. Trajtimi i atributeve është indeksi i tabelës që korrespondon me atributin
2. Tipi i atributit është një UUID që përshkruan llojin e tij
3. Vlera e Atributit është të dhënat e indeksuara nga treguesi i atributit
4. Lejet e atributit janë pjesë e një atributi, lejet, që nuk mund të lexohen ose shkruhen duke përdorur protokollin e atributeve
Si të kuptoni të gjitha këto? Treguesi i atributit është, në përgjithësi, numri i tij në tabelën tonë.
Ai lejon një klient të referojë një atribut në kërkesat për lexim ose shkrim. Ne mund të numërojmë linjat (atributet) tona nga 0x0001 në 0xFFFF. Në lidhjen tonë me raft librash, ky është numri i kartës në katalogun e letrës. Në mënyrë të ngjashme, si në katalogun e bibliotekës, kartat janë renditur sipas renditjes në rritje të numrit. Numri i çdo rreshti pasues duhet të jetë më i madh se ai i mëparshmi. Ashtu si në bibliotekë, ndonjëherë disa karta humbasin, kështu që tek ne mund të ketë boshllëqe në numërimin e rreshtave. Kjo lejohet. Gjëja kryesore është që ata të shkojnë në mënyrë progresive.
Lloji i atributit përcakton se çfarë përfaqëson atributi. Për analogji me gjuhën C,
ku ka variabla logjike, numerike dhe vargje, kështu është këtu. Sipas llojit të atributit ne njohim
me çfarë kemi të bëjmë dhe si mund të vazhdojmë të punojmë me këtë atribut. Më poshtë do të shikojmë disa lloje specifike të atributeve. Për shembull, "deklarata e shërbimit" (0x2800), "deklarata karakteristike" (0x2803), "deklarata e përshkruesit" (0x2902).
Vlera e një atributi është kuptimi i tij aktual, falni tautologjinë. Nëse lloji i atributit është një varg, atëherë vlera e atributit mund të jetë, për shembull, slogani "Hello World !!!". Nëse lloji i atributit është një "deklaratë shërbimi", atëherë vlera e tij është vetë shërbimi. Dhe ndonjëherë ky është informacion se ku mund të gjeni atribute të tjera dhe vetitë e tyre.
Lejet e atributeve lejojnë serverin të kuptojë nëse lejohet qasja për lexim ose shkrim.
Vini re se këto leje zbatohen vetëm për vlerën e atributit, dhe jo për vetë pikën, llojin ose fushën e lejes. Ato. nëse lejohet regjistrimi i atributeve, atëherë mund të ndryshojmë, për shembull, rreshtin "Hello World !!!" në rreshtin "Mirëmëngjes". Por ne nuk mund të ndalojmë shkrimin e një rreshti të ri ose të ndryshojmë llojin e atributit dhe ta caktojmë rreshtin si një "deklaratë shërbimi". Kur një klient kontakton një server, klienti kërkon atributet e tij. Kjo i lejon klientit të dijë se çfarë mund të ofrojë serveri. Edhe pse nuk është e nevojshme të lexoni dhe shkruani vlerat.
Si duket
Koncepti i GATT është të grupojë atributet në një tabelë atributesh së bashku në një mënyrë shumë specifike dhe logjike. Le të hedhim një vështrim më të afërt në profilin e rrahjeve të zemrës më poshtë. Kolona më e majtë e kësaj tabele është opsionale. Ajo thjesht na përshkruan se çfarë është kjo linjë (atribut). Të gjitha kolonat e tjera janë tashmë të njohura për ne.
Në krye të çdo grupi kemi gjithmonë një atribut të deklaratës së shërbimit. Lloji i tij është gjithmonë 0x2800, dhe treguesi varet nga sa atribute janë tashmë të pranishme në tabelë. Lejet e tij janë gjithmonë vetëm për lexim, pa ndonjë vërtetim ose autorizim. Ne do të flasim për këto koncepte pak më vonë. Vlera është një tjetër UUID që identifikon se çfarë është shërbimi. Në tabelë, vlera është 0x180D, e cila përcaktohet nga Bluetooth SIG si një shërbim i rrahjeve të zemrës.
Pas njoftimit të shërbimit, vjen njoftimi i karakteristikës. Është e ngjashme në formë me një deklaratë shërbimi. UUID-ja e tij është gjithmonë 0x2803 dhe lejet e tij janë gjithmonë vetëm për lexim pa ndonjë vërtetim ose autorizim. Le të shohim fushën Vlera e Atributit, e cila përfshin disa të dhëna. Ai gjithmonë përmban një tregues, një UUID dhe një grup karakteristikash. Këta tre elementë përshkruajnë deklarimin e mëvonshëm të vlerës karakteristike. Treguesi natyrshëm tregon vendndodhjen e deklarimit të vlerës karakteristike në tabelën e atributeve. UUID përshkruan llojin e informacionit ose vlerën që mund të presim. Për shembull, vlera e temperaturës, gjendja e çelësit të dritës ose ndonjë vlerë tjetër arbitrare. Dhe së fundi vetitë, të cilat përshkruajnë se si mund të ndërveprohet me vlerën karakteristike.
Këtu na pret një kurth tjetër. Ajo shoqërohet me lejet e atributeve dhe vetitë karakteristike. Le të shohim foton e vetive të fushës së bitit nga specifikimi.
Siç mund ta shihni, këtu ka edhe fusha që ofrojnë aftësi leximi dhe shkrimi. Ju mund të pyesni veten pse ne kemi leje leximi/shkrimi për atributin dhe pronën
lexo/shkruaj për vlerën karakteristike? A nuk duhet të jenë gjithmonë të njëjtë? Fakti është se vetitë për vlerën karakteristike janë në fakt vetëm rekomandime për klientin e përdorur në GATT dhe shtresat e aplikacionit. Këto janë thjesht sugjerime se çfarë mund të presë klienti nga atributi karakteristik i deklarimit. Le ta shohim këtë në më shumë detaje. Çfarë lloje lejesh ka një atribut?
1. Lejet e aksesit:
- leximi
- rekord
- lexo dhe shkruaj
2. Leja e vërtetimit:
- kërkohet vërtetimi
- nuk kërkohet vërtetim
3. Leja e autorizimit:
- Kerkohet Autorizimi
- nuk kërkohet autorizim
Dallimi kryesor midis rezolucionit të atributeve dhe vetive karakteristike është se të parat zbatohen për serverët, dhe të dytat për klientët. Serverit mund t'i lejohet të lexojë vlerën karakteristike, por mund të kërkojë vërtetim ose autorizim. Prandaj, kur klienti kërkon vetitë e karakteristikës, do të marrim që leximi është i lejuar. Por kur përpiqemi të lexojmë, marrim një gabim. Prandaj, mund të flasim me siguri për përparësinë e lejeve mbi pronat. Nga ana e klientit, ne nuk mund të marrim njohuri se cilat leje ka një atribut.
Përshkruesi
Le të kthehemi në tryezën tonë. Pas deklarimit të vlerës së një karakteristike, deklaratat e mëposhtme të atributeve janë të mundshme:
1. Deklarata e re e karakteristikave (një shërbim mund të ketë shumë karakteristika)
2. Deklarata e re e shërbimit (mund të ketë shumë prej tyre në tabelë)
3. Deklarimi i një doreze
Në rastin e karakteristikës së matjes së rrahjeve të zemrës, në tabelën tonë, deklarimi i vlerës karakteristike shoqërohet me deklaratën e përshkruesit. Një përshkrues është një atribut me informacion shtesë për një karakteristikë. Ekzistojnë disa lloje përshkruesish. Ne do të flasim për to në detaje në pjesën e dytë të këtij artikulli. Tani për tani, ne do të prekim vetëm përshkrimin e konfigurimit të karakteristikave të klientit (CCCD). Ka një UUID të barabartë me 0x2902. Duke përdorur këtë përshkrues, klienti ka mundësinë të aktivizojë treguesin ose njoftimin në server. Dallimi midis tyre është i vogël, por ende ekziston. Njoftimi nuk kërkon konfirmim të marrjes nga klienti. Indikacioni e kërkon këtë, megjithëse ndodh në nivelin GATT, duke mos arritur nivelin e aplikimit. Pse kështu, ju pyesni? Mjerisht, unë nuk e di këtë. Më lejoni të them vetëm se ekspertët nordikë rekomandojnë përdorimin e njoftimeve. Për më tepër, kontrollimi i integritetit të paketës (duke përdorur CRC) ndodh në të dyja rastet.
Përfundim
Në fund të artikullit do të doja të them këtë. Tabela e fundit është pak konfuze. Megjithatë, e zgjodha sepse është dhënë , tek e cila mbështetem. Në pjesën e dytë të artikullit tim, unë synoj të gërmoj më thellë në specifikimin BlueTooth 4.0. Aty na presin diagrame dhe vizatime më të sakta. Në pjesën e tretë, unë do të doja të analizoja regjistrin e marrë duke përdorur programin Wireshark nga një prej veglave dhe të shikoj "live" të gjithë teorinë që po studiojmë.
Punonjës i Grupit të Kompanive
Pecherskikh Vladimir
Burimi: www.habr.com