BLE mikroskoobi all (ATTы GATTы…)
1. osa, ülevaade
Bluetooth 4.0 esimese spetsifikatsiooni avaldamisest on juba päris palju aega möödas. Ja kuigi BLE teema on väga huvitav, ajab see oma keerukuse tõttu siiski paljusid arendajaid eemale. Oma eelmistes artiklites vaatlesin peamiselt madalaimat taset, lingikihti ja füüsilist kihti. See võimaldas meil vältida selliste keerukate ja segadusttekitavate mõistete kasutamist nagu atribuutide protokoll (ATT) ja üldine atribuutide profiil (GATT). Samas pole kuhugi minna, ilma neid mõistmata on võimatu arendada ühilduvaid seadmeid. Täna tahaksin seda teadmist teiega jagada. Oma artiklis toetun algajatele Põhjamaade kodulehelt. Nii et alustame.
Miks kõik nii raske on?
Minu meelest oli kohe selge, et nutitelefonide kaudu seadmete haldamine on väga paljulubav ja kauakestev teema. Seetõttu otsustasid nad selle kohe ja maksimaalselt struktureerida. Nii et erinevate vidinate tootjad ei mõtleks välja oma protokolle, mis siis kokkusobimatud on. Sellest ka raskus. Juba esimesel etapil üritasid nad BLE protokolli suruda kõik võimaliku. Ja pole vahet, kas sellest on hiljem kasu või mitte. Lisaks nägid nad ette võimaluse seadmete nimekirja tulevikus laiendada.
Vaatame pilti, kus on joonistatud BLE protokolli skeem. See koosneb mitmest kihist. Seadme raadiokanali eest vastutab madalaim füüsiline kiht (PHY). Link Layer (LL) sisaldab kogu baitide jada edastatud sõnumis. Eelmistes artiklites uurisime täpselt seda. Host Controller Interface (HCI) on vahetusprotokoll BLE kihtide või kiipide vahel, kui kontroller ja host on rakendatud erinevatele kiipidele. Loogilise lingi juhtimise ja kohandamise protokoll (L2CAP) vastutab pakettide moodustamise, raamimise, veakontrolli ja pakettide koostamise eest. Turvahalduri protokoll (SMP) vastutab pakettide krüptimise eest. Üldine juurdepääsuprofiil (GAP) vastutab esialgse andmevahetuse eest seadmete vahel, et teha kindlaks, kes on kes. See hõlmab ka skaneerimist ja reklaami. Selles artiklis keskendun protokolli kahele ülejäänud osale – GATTile ja ATT-le. GATT on ATT-i pealisehitis, seega on need omavahel tihedalt läbi põimunud.
Jutu lihtsustamiseks pöörduksin analoogia poole. Ma kuulsin seda kuskil ja tahaksin seda toetada. Mõelge BLE-seadmele kui mitme riiuliga raamatukapile. Iga riiul on eraldi teema. Näiteks on meil riiulid ulme, matemaatika ja entsüklopeediatega. Igal riiulil on kindla teemaga raamatud. Ja mõnel raamatul on isegi paberjärjehoidjad märkmetega. Lisaks on meil kõigist raamatutest väike paberkataloog. Kui mäletate, on kooliraamatukogud kitsas kast paberkaartidega. Selle analoogia põhjal on kapp meie seadme profiil. Riiulid on teenused, raamatud on omadused ja kataloog on atribuutide tabel. Järjehoidjad raamatutes on deskriptorid, millest räägin ka hiljem pikemalt.
Kõik, kes on seadmeid arendanud, teavad, et paljudel projektidel on sarnased koodijupid. Fakt on see, et paljudel seadmetel on sarnased funktsioonid. Näiteks kui seadmeid toidavad patareid, on laadimise ja nende taseme jälgimise probleem sama. Sama kehtib ka andurite kohta. Tegelikult objektorienteeritud lähenemine programmeerimisele "annab võimaluse luua objekte, mis ühendavad omadused ja käitumise iseseisvaks ühenduseks, mida saab seejärel uuesti kasutada". Minu arvates proovis BLE sarnast lähenemist. Profiilid töötas välja Bluetooth Special Interest Group (SIG). Erinevate tootjate seadmed, millel on samad profiilid, peaksid üksteisega raskusteta töötama. Profiilid omakorda koosnevad teenustest ja tunnuste teenustest, mida täiendavad deskriptorid. Üldiselt võib see välja näha selline:
Mõelge näiteks pulsikella (fitnessi käevõru) profiiliskeemile. See koosneb kahest teenusest ja mitmest omadusest. Sellest selgub koheselt profiili hierarhia. Kontrollpunkti karakteristik nullib kogu kalorikulu.
1. Pulsi teenus sisaldab kolme omadust (0x180D):
a) Kohustuslik südame löögisageduse näitaja (0x2A37)
b) Valikuline kehaanduri asendi karakteristikud (0x2A38)
c) Südame löögisageduse kontrollpunkti tingimuslikud omadused (0x2A39)
2. Aku hooldusteenus (0x180F):
a) Kohustuslik aku laetuse taseme näitaja (0x2A19)
UUID
Selleks, et saaksime profiilielementidele (teenustele, omadustele ja kirjeldustele) unikaalselt juurde pääseda, peame need kõik kuidagi nummerdama. Sel eesmärgil võetakse kasutusele kontseptsioon nagu universaalne kordumatu ID (UUID) või universaalne kordumatu identifikaator. UUID on märgitud iga rea sulgudes. Ja siin on üks eripära. UUID jaoks otsustasime kasutada 16 ja 128 biti pikkust koodi. Miks sa küsid? BLE protokollis on kõik seotud energiasäästuga. Seetõttu on 16-bitine mõõde üsna mõistlik. On ebatõenäoline, et lähiajal luuakse rohkem kui 65 tuhat. ainulaadsed teenused ja omadused. Hetkel võinuks kõik juba loetud olla (pidage meeles, kust see tuli - "ta luges ka sind" :-)) Nummerdatud elemendid , , и võite vaadata linke.
Arvan siiski, et kõik mäletavad seda lugu 4-baidise IP-aadressiga Internetis. Alguses arvasime, et sellest piisab, kuid nüüd ei saa me ikkagi 6-baidise aadressi vastu lülituda. Et seda viga mitte korrata ja isetegijate mängulistele kätele vabad käed anda, otsustas SIG kohe võtta kasutusele 128-bitised UUID-d. See tuletab mulle isiklikult meelde litsentseerimata 433 MHz sagedusala, mis raadiokanalist kõikvõimalikele kulibinatele anti. Meie puhul töötati välja 128-bitine teenuste ja omaduste identifikaator. See tähendab, et saame oma teenuste ja seadmete jaoks kasutada peaaegu mis tahes 128-bitist väärtust. Samas kipub sama UUID-i leidmise tõenäosus olema null.
Tegelikult on lühikeste 16-bitiste UUID-de laiendus 128-bitine. Spetsifikatsioonis nimetatakse seda laiendust Bluetooth Base UUID-ks ja selle väärtus on 00000000-0000-1000-8000-00805F9B34FB. Kui näiteks 16-bitise atribuudi UUID väärtus on 0x1234, siis samaväärse 128-bitise UUID väärtus on 00001234-0000-1000-8000-00805F9B34FB. Ja isegi vastav valem on antud:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Ma ei tea, kust see võlunumber tuli. Kui keegi lugejatest teab, andke kommentaaridesse kirjutada (Sinopteek hüüdnimega kasutaja on seda juba teinud. Vaata kommentaare). Mis puutub 128-bitiste UUID-de väljamõtlemisse, siis põhimõtteliselt saate kasutada spetsiaalset kes seda sinu eest teeb.
ATTy GATTy...
Tegelikult algab lõbus. Lubage mul teile meelde tuletada, et ATT põhineb kliendi ja serveri suhetel. Nüüd vaatame serveriseadet. See sisaldab teavet, nagu anduri väärtused, tulede lüliti olek, asukohaandmed jne. Nüüd, kui kõik "meie paraadil osalejad" on nummerdatud, peame nad kuidagi seadme mällu salvestama. Selleks paneme need tabelisse, mida nimetatakse atribuutide tabeliks. Pidage seda hästi meeles. See on BLE süda. Seda kaalume edasi. Nüüd nimetame iga rida atribuudiks. See laud asub sügaval virnas ja reeglina pole meil sellele otsest juurdepääsu. Initsialiseerime selle ja pääseme sellele juurde, kuid seespool toimuv on meie eest seitsme pitseri taga peidus.
Vaatame pilti spetsifikatsioonist, kuid enne seda juhin kohe tähelepanu sagedasele segadusele terminites, nimelt deskriptorites. Deskriptori roll on täiendada tunnuse kirjeldust. Kui on vaja selle võimalusi laiendada, kasutatakse deskriptoreid. Need on ka atribuudid ja nagu teenused ja omadused, asuvad need atribuutide tabelis. Vaatleme neid üksikasjalikult artikli teises osas. Kuid mõnikord viitavad deskriptorid atribuutide tabeli rea numbrile. Seda tuleb meeles pidada. Segaduse vältimiseks kasutame nendel eesmärkidel terminit "atribuudi osuti".
Seega on atribuut diskreetne väärtus, millel on järgmised omadused:
1. Atribuudikäepide on atribuudile vastav tabeliindeks
2. Atribuudi tüüp on UUID, mis kirjeldab selle tüüpi
3. Atribuudi väärtus on atribuudi osutiga indekseeritud andmed
4. Atribuudi õigused on atribuudi osa, õigused, mida ei saa lugeda ega kirjutada atribuudiprotokolli kasutades
Kuidas seda kõike mõista? Atribuudi osuti on suhteliselt selle number meie tabelis.
See võimaldab kliendil lugemis- või kirjutamistaotlustes viidata atribuudile. Saame nummerdada oma ridu (atribuute) vahemikus 0x0001 kuni 0xFFFF. Meie ühenduses raamatukapiga on see paberkataloogi kaardi number. Sarnaselt, nagu raamatukogu kataloogis, on kaardid järjestatud järjest kasvavas arvus. Iga järgneva rea arv peab olema suurem kui eelmine. Nii nagu raamatukoguski, läheb vahel mõni kaart kaotsi, nii et meie puhul võib ridade nummerdamises lünki tekkida. See on lubatud. Peaasi, et nad läheksid järk-järgult.
Atribuudi tüüp määrab, mida atribuut esindab. Analoogiliselt C-keelega
kus on tõeväärtus, numbrilised muutujad ja stringid, nii on see siin. Atribuudi tüübi järgi tunneme ära
millega me tegeleme ja kuidas saame selle atribuudiga edasi töötada. Allpool vaatleme mõnda konkreetset tüüpi atribuute. Näiteks "teenusedeklaratsioon" (0x2800), "karakteristiku deklaratsioon" (0x2803), "deskriptori deklaratsioon" (0x2902).
Atribuudi väärtus on selle tegelik tähendus, andestage tautoloogia. Kui atribuudi tüüp on string, siis võib atribuudi väärtuseks olla näiteks loosung “Tere maailm !!!”. Kui atribuudi tüüp on "teenuse deklaratsioon", on selle väärtus teenus ise. Ja mõnikord on see teave selle kohta, kust leida muid atribuute ja nende omadusi.
Atribuutide õigused võimaldavad serveril aru saada, kas lugemis- või kirjutamisõigus on lubatud.
Pange tähele, et need õigused kehtivad ainult atribuudi väärtusele, mitte osutile, tüübile või loaväljale endale. Need. kui atribuudi salvestamine on lubatud, siis saame muuta näiteks rida “Tere maailm !!!” reale “Tere hommikust”. Kuid me ei saa keelata uue rea kirjutamist ega muuta atribuudi tüüpi ja määrata rida "teenuse deklaratsiooniks". Kui klient võtab serveriga ühendust, küsib klient selle atribuute. See võimaldab kliendil teada, mida server võib pakkuda. Kuigi väärtusi pole vaja lugeda ja kirjutada.
Kuidas see välja näeb
GATTi kontseptsioon seisneb atribuutide rühmitamises atribuutide tabelis väga konkreetses ja loogilises järjekorras. Vaatame allolevat pulsiprofiili lähemalt. Selle tabeli vasakpoolseim veerg on valikuline. See lihtsalt kirjeldab meile, mis see rida (atribuut) on. Kõik muud veerud on meile juba tuttavad.
Iga rühma ülaosas on meil alati teenuse deklaratsiooni atribuut. Selle tüüp on alati 0x2800 ja kursor sõltub sellest, kui palju atribuute tabelis juba on. Selle load on alati kirjutuskaitstud, ilma autentimise või autoriseerimiseta. Nendest mõistetest räägime veidi hiljem. Väärtus on teine UUID, mis tuvastab, mis teenus on. Tabelis on väärtus 0x180D, mille Bluetooth SIG määratleb südame löögisageduse teenusena.
Pärast teenuse väljakuulutamist tuleb tunnuse teade. See on vormilt sarnane teenuse deklaratsiooniga. Selle UUID on alati 0x2803 ja selle load on alati kirjutuskaitstud ilma autentimise või autoriseerimiseta. Vaatame välja Atribuudi väärtus, mis sisaldab mõningaid andmeid. See sisaldab alati kursorit, UUID-d ja atribuutide komplekti. Need kolm elementi kirjeldavad järgnevat tunnusväärtuse deklareerimist. Kursor tähistab loomulikult iseloomuliku väärtuse deklaratsiooni asukohta atribuutide tabelis. UUID kirjeldab, millist tüüpi teavet või väärtust võime oodata. Näiteks temperatuuri väärtus, tulede lüliti olek või mõni muu suvaline väärtus. Ja lõpuks atribuudid, mis kirjeldavad, kuidas iseloomustava väärtusega saab suhelda.
Siin ootab meid veel üks lõks. See on seotud atribuutide lubade ja iseloomulike omadustega. Vaatame spetsifikatsioonist pilti bitivälja omadustest.
Nagu näete, on siin ka väljad, mis pakuvad lugemis- ja kirjutamisvõimalusi. Võite küsida, miks meil on atribuudi ja atribuudi lugemis-/kirjutusõigused
iseloomuliku väärtuse jaoks lugeda/kirjutada? Kas need ei peaks alati ühesugused olema? Fakt on see, et iseloomuliku väärtuse omadused on tegelikult ainult soovitused kliendile, mida kasutatakse GATT-is ja rakenduskihtides. Need on lihtsalt vihjed selle kohta, mida klient võib iseloomuliku deklaratsiooni atribuudilt oodata. Vaatame seda üksikasjalikumalt. Mis tüüpi õigused atribuudil on?
1. Juurdepääsuload:
- lugemine
- rekord
- Loe ja kirjuta
2. Autentimisluba:
- vajalik autentimine
- autentimist pole vaja
3. Autoriseerimisluba:
— nõutav luba
- luba pole vaja
Peamine erinevus atribuudi eraldusvõime ja iseloomulike omaduste vahel on see, et esimene kehtib serverite ja teine klientide kohta. Serveril võib olla lubatud lugeda iseloomulikku väärtust, kuid see võib nõuda autentimist või autoriseerimist. Seega, kui klient küsib tunnuse omadusi, saame teada, et lugemine on lubatud. Kuid kui proovime lugeda, saame vea. Seetõttu võime julgelt rääkida õiguste prioriteedist atribuutide ees. Kliendi poolel ei saa me teadmisi selle kohta, millised õigused atribuudil on.
Kirjeldaja
Tuleme tagasi oma laua juurde. Pärast tunnuse väärtuse deklareerimist on võimalikud järgmised atribuudideklaratsioonid:
1. Uus omaduste deklaratsioon (teenusel võib olla palju omadusi)
2. Uus teenuse deklaratsioon (neid võib tabelis olla palju)
3. Käepideme deklareerimine
Südame löögisageduse mõõtmise tunnuse puhul on meie tabelis tunnusväärtuse deklaratsiooniga kaasas deskriptori deklaratsioon. Deskriptor on atribuut, mis sisaldab tunnuse kohta lisateavet. Kirjeldajaid on mitut tüüpi. Me räägime neist üksikasjalikult käesoleva artikli teises osas. Praegu puudutame ainult kliendi karakteristiku konfiguratsiooni kirjeldust (CCCD). Selle UUID on 0x2902. Seda deskriptorit kasutades saab klient lubada serveris indikatsiooni või teavituse. Erinevus nende vahel on väike, kuid siiski olemas. Teavitamiseks ei ole vaja kliendilt kinnitust kättesaamise kohta. Näidus nõuab seda, kuigi see toimub GATT-i tasemel, mitte aga rakendustasandini. Miks nii, küsite? Kahjuks ma ei tea seda. Ütlen vaid, et Põhjamaade eksperdid soovitavad kasutada märguandeid. Veelgi enam, paketi terviklikkuse kontrollimine (CRC abil) toimub mõlemal juhul.
Järeldus
Artikli lõpus tahaksin öelda seda. Viimane tabel on veidi segane. Valisin selle siiski, sest see on alla antud , millele ma toetun. Oma artikli teises osas kavatsen ma süveneda BlueToothi 4.0 spetsifikatsiooni. Seal ootavad meid õigemad skeemid ja joonised. Kolmandas osas tahaksin sõeluda Wiresharki programmi abil saadud logi ühest vidinast ja näha kogu uuritavat teooriat otseülekandena.
Ettevõtete grupi töötaja
Petšerskih Vladimir
Allikas: www.habr.com