BLE po mikroskopu (ATTы GATTы…)
1 dalis, apžvalga
Jau gana daug laiko praėjo nuo pirmosios Bluetooth 4.0 specifikacijos išleidimo. Ir nors BLE tema yra labai įdomi, ji vis tiek atbaido daugelį kūrėjų dėl savo sudėtingumo. Ankstesniuose savo straipsniuose daugiausia nagrinėjau žemiausią lygį – nuorodų sluoksnį ir fizinį sluoksnį. Tai leido mums išvengti tokių sudėtingų ir painių sąvokų kaip atributų protokolas (ATT) ir bendrasis atributų profilis (GATT). Tačiau nėra kur dėtis, jų nesuvokus neįmanoma sukurti suderinamų įrenginių. Šiandien šiomis žiniomis norėčiau pasidalinti su jumis. Savo straipsnyje aš remsiuosi pradedantiesiems iš Šiaurės šalių svetainės. Taigi pradėkime.
Kodėl viskas taip sunku?
Mano nuomone, iš karto buvo aišku, kad įrenginių valdymas išmaniaisiais telefonais yra labai perspektyvi ir ilgai trunkanti tema. Todėl jie nusprendė jį nedelsiant ir maksimaliai struktūrizuoti. Kad įvairių programėlių gamintojai nesugalvotų savo protokolų, kurie tada bus nesuderinami. Iš čia ir kyla sunkumų. Jau pirmajame etape jie bandė į BLE protokolą įsprausti viską, kas įmanoma. Ir nesvarbu, ar tai bus naudinga vėliau, ar ne. Be to, jie numatė galimybę išplėsti įrenginių sąrašą ateičiai.
Pažiūrėkime į paveikslėlį, kuriame nubraižyta BLE protokolo schema. Jis susideda iš kelių sluoksnių. Žemiausias fizinis sluoksnis (PHY) yra atsakingas už įrenginio radijo kanalą. Link Layer (LL) yra visa baitų seka perduodamame pranešime. Ankstesniuose straipsniuose mes ištyrėme būtent tai. Host Controller Interface (HCI) yra keitimosi protokolas tarp BLE sluoksnių arba lustų, jei valdiklis ir pagrindinis kompiuteris yra įdiegti skirtinguose lustuose. Loginio ryšio valdymo ir pritaikymo protokolas (L2CAP) yra atsakingas už paketų formavimą, kadravimą, klaidų kontrolę ir paketų surinkimą. „Security Manager Protocol“ (SMP) yra atsakingas už paketų šifravimą. Bendrosios prieigos profilis (GAP) yra atsakingas už pradinį keitimąsi duomenimis tarp įrenginių, siekiant nustatyti „Kas yra kas“. Tai taip pat apima skenavimą ir reklamą. Šiame straipsnyje daugiausia dėmesio skirsiu dviem likusioms protokolo dalims – GATT ir ATT. GATT yra ATT antstatas, todėl jie yra glaudžiai susiję.
Norėdami supaprastinti istoriją, norėčiau kreiptis į analogiją. Kažkur girdėjau ir norėčiau paremti. Pagalvokite apie BLE įrenginį kaip knygų lentyną su keliomis lentynomis. Kiekviena lentyna yra atskira tema. Pavyzdžiui, turime lentynas su moksline fantastika, matematika ir enciklopedijomis. Kiekvienoje lentynoje yra knygos su nurodyta tema. O kai kurios knygos netgi turi popierines žymes su užrašais. Be to, turime nedidelį popierinį visų knygų katalogą. Jei prisimenate, mokyklų bibliotekos yra siaura dėžutė su popierinėmis kortelėmis. Pagal šią analogiją spintelė yra mūsų įrenginio profilis. Lentynos yra paslaugos, knygos yra charakteristikos, o katalogas yra atributų lentelė. Žymės knygose yra aprašai, apie kuriuos taip pat pakalbėsiu vėliau plačiau.
Kiekvienas, kuris sukūrė įrenginius, žino, kad daugelyje projektų yra panašios kodo dalys. Faktas yra tas, kad daugelis įrenginių turi panašias funkcijas. Pavyzdžiui, jei įrenginiai maitinami baterijomis, tada įkrovimo ir jų lygio stebėjimo problema bus tokia pati. Tas pats pasakytina apie jutiklius. Tiesą sakant, į objektą orientuotas požiūris į programavimą „suteikia galimybę kurti objektus, kurie sujungia savybes ir elgesį į savarankišką sąjungą, kurią vėliau galima panaudoti dar kartą“. Mano nuomone, BLE bandė taikyti panašų požiūrį. Profilius sukūrė „Bluetooth“ specialiųjų interesų grupė (SIG). Skirtingų gamintojų įrenginiai, turintys tuos pačius profilius, turėtų dirbti tarpusavyje be sunkumų. Savo ruožtu profilius sudaro paslaugos ir charakteristikų paslaugos, papildytos aprašais. Apskritai tai gali atrodyti taip:
Pavyzdžiui, apsvarstykite širdies ritmo monitoriaus (treniruotės apyrankės) profilio schemą. Jį sudaro dvi paslaugos ir kelios charakteristikos. Iš jo iš karto paaiškėja profilio hierarchija. Kontrolinio taško charakteristika iš naujo nustato bendrą suvartojamų kalorijų skaičių į nulį.
1. Širdies ritmo paslauga apima tris charakteristikas (0x180D):
a) Privaloma širdies ritmo charakteristika (0x2A37)
b) Pasirenkama kūno jutiklio padėties charakteristika (0x2A38)
c) Sąlyginės širdies ritmo valdymo taško charakteristikos (0x2A39)
2. Akumuliatoriaus priežiūros paslauga (0x180F):
a) Privaloma akumuliatoriaus įkrovimo lygio charakteristika (0x2A19)
UUID
Kad galėtume unikaliai pasiekti profilio elementus (paslaugas, charakteristikas ir aprašus), turime juos visus kažkaip sunumeruoti. Šiuo tikslu pristatoma tokia sąvoka kaip universaliai unikalus ID (UUID) arba universaliai unikalus identifikatorius. UUID nurodytas kiekvienos eilutės skliausteliuose. Ir čia yra vienas ypatumas. UUID nusprendėme naudoti 16 ir 128 bitų ilgio kodą. Kodėl klausi? BLE protokole viskas yra apie energijos taupymą. Todėl 16 bitų dydis yra gana pagrįstas. Mažai tikėtina, kad artimiausiu metu bus sukurta daugiau nei 65 tūkst. unikalios paslaugos ir savybės. Šiuo metu viskas, ką jie galėjo jau suskaičiuoti (prisiminkite iš kur tai - "jis suskaičiavo ir tave" :-)) Sunumeruoti elementai , , и galite pažiūrėti nuorodas.
Tačiau manau, kad visi prisimena istoriją su 4 baitais IP adresais internete. Iš pradžių manėme, kad to pakanka, bet dabar vis dar negalime pereiti prie 6 baitų adreso. Kad ši klaida nepasikartotų ir duotų valią žaismingoms „pasidaryk pats“ rankomis, SIG iškart nusprendė įvesti 128 bitų UUID. Tai man asmeniškai primena nelicencijuotą 433 MHz juostą, kuri buvo suteikta visokiems kulibinams iš radijo kanalo. Mūsų atveju buvo sukurtas 128 bitų paslaugų ir charakteristikų identifikatorius. Tai reiškia, kad mes savo paslaugoms ir įrenginiams galime naudoti beveik bet kokią 128 bitų vertę. Vis dėlto tikimybė sugalvoti tą patį UUID yra lygi nuliui.
Tiesą sakant, trumpi 16 bitų UUID išplečiami iki 128 bitų vertės. Specifikacijoje šis plėtinys vadinamas „Bluetooth Base UUID“ ir jo reikšmė yra 00000000-0000-1000-8000-00805F9B34FB. Jei, pavyzdžiui, 16 bitų atributo UUID reikšmė yra 0x1234, tada lygiavertis 128 bitų UUID turės reikšmę 00001234-0000-1000-8000-00805F9B34FB. Ir netgi pateikiama atitinkama formulė:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nežinau, iš kur atsirado šis stebuklingas skaičius. Jei kas iš skaitytojų žino, leiskite parašyti komentaruose (Sinopteek slapyvardžiu vartotojas jau tai padarė. Žiūrėkite komentarus). Kalbant apie 128 bitų UUID, iš esmės galite naudoti specialų kas tai padarys už tave.
ATTy GATTy...
Tiesą sakant, tada prasideda linksmybės. Leiskite jums priminti, kad ATT yra pagrįsta kliento ir serverio ryšiu. Dabar žiūrime į serverio įrenginį. Jame yra tokia informacija kaip jutiklių reikšmės, šviesos jungiklio būsena, vietos duomenys ir kt. Dabar, kai visi „mūsų parado dalyviai“ yra sunumeruoti, turime kažkaip juos įrašyti į įrenginio atmintį. Norėdami tai padaryti, įtraukiame juos į lentelę, vadinamą atributų lentele. Prisiminkite tai gerai. Tai pati BLE širdis. Tai mes svarstysime toliau. Dabar kiekvieną eilutę vadinsime atributu. Ši lentelė yra giliai kamino viduje ir, kaip taisyklė, mes neturime tiesioginės prieigos prie jos. Mes jį inicijuojame ir pasiekiame, bet tai, kas vyksta viduje, nuo mūsų paslėpta už septynių antspaudų.
Pažiūrėkime į paveikslėlį iš specifikacijos, bet prieš tai norėčiau nedelsiant atkreipti dėmesį į dažną terminų painiavą, būtent aprašuose. Deskriptoriaus vaidmuo yra papildyti charakteristikos aprašymą. Kai reikia išplėsti jo galimybes, naudojami aprašai. Jie taip pat yra atributai ir, kaip ir paslaugos bei charakteristikos, yra atributų lentelėje. Išsamiai juos išnagrinėsime antroje straipsnio dalyje. Tačiau kartais aprašai nurodo eilutės numerį atributų lentelėje. Tai reikia turėti omenyje. Norėdami išvengti painiavos, šiais tikslais naudosime terminą „atributo rodyklė“.
Taigi atributas yra atskira reikšmė, turinti šias su juo susijusias savybes:
1. Atributo rankena yra lentelės indeksas, atitinkantis atributą
2. Atributo tipas yra UUID, apibūdinantis jo tipą
3. Atributo reikšmė yra atributo rodyklės indeksuojami duomenys
4. Atributo leidimai yra atributo dalis, leidimai, kurių negalima nuskaityti ar įrašyti naudojant atributo protokolą
Kaip visa tai suprasti? Atributo rodyklė, palyginti, yra jos numeris mūsų lentelėje.
Tai leidžia klientui nurodyti atributą skaitymo arba rašymo užklausose. Savo eilutes (atributus) galime sunumeruoti nuo 0x0001 iki 0xFFFF. Mūsų asociacijoje su knygų spinta tai yra kortelės numeris popieriniame kataloge. Panašiai, kaip ir bibliotekos kataloge, kortelės išdėstomos didėjančia skaičiaus tvarka. Kiekvienos paskesnės eilutės skaičius turi būti didesnis nei ankstesnės. Kaip ir bibliotekoje, kartais kai kurios kortelės pasimeta, tad pas mus gali atsirasti spragų eilučių numeracijoje. Tai leidžiama. Svarbiausia, kad jie eitų palaipsniui.
Atributo tipas nustato, ką atributas reiškia. Pagal analogiją su C kalba,
kur yra loginiai, skaitiniai kintamieji ir eilutės, taip yra čia. Pagal atributo tipą atpažįstame
su kuo susiduriame ir kaip galime toliau dirbti su šiuo atributu. Toliau apžvelgsime kai kuriuos konkrečius atributų tipus. Pavyzdžiui, „paslaugų deklaracija“ (0x2800), „charakteristikos deklaracija“ (0x2803), „deskriptoriaus deklaracija“ (0x2902).
Atributo vertė yra tikroji jo reikšmė, atleiskite už tautologiją. Jei atributo tipas yra eilutė, tada atributo reikšmė gali būti, pavyzdžiui, šūkis „Hello World!!!“. Jei atributo tipas yra „paslaugos deklaracija“, tada jo reikšmė yra pati paslauga. Ir kartais tai yra informacija apie tai, kur rasti kitus atributus ir jų savybes.
Atributų leidimai leidžia serveriui suprasti, ar leidžiama skaitymo ar rašymo prieiga.
Atminkite, kad šie leidimai taikomi tik atributo reikšmei, o ne pačiam žymekliui, tipui ar leidimo laukui. Tie. jei leidžiamas atributų įrašymas, galime pakeisti, pavyzdžiui, eilutę „Hello World !!!“ į eilutę „Labas rytas“. Tačiau negalime uždrausti rašyti naujos eilutės arba pakeisti atributo tipą ir priskirti eilutę „paslaugos deklaracija“. Kai klientas susisiekia su serveriu, klientas prašo jo atributų. Tai leidžia klientui žinoti, ką serveris gali suteikti. Nors skaityti ir rašyti vertybes nebūtina.
Kaip tai atrodo
GATT koncepcija yra sugrupuoti atributus atributų lentelėje labai konkrečia ir logiška tvarka. Pažvelkime atidžiau į žemiau pateiktą širdies ritmo profilį. Kairiausias šios lentelės stulpelis yra neprivalomas. Tai tiesiog mums apibūdina, kas yra ši eilutė (atributas). Visi kiti stulpeliai mums jau pažįstami.
Kiekvienos grupės viršuje visada turime paslaugų deklaracijos atributą. Jo tipas visada yra 0x2800, o rodyklė priklauso nuo to, kiek atributų jau yra lentelėje. Jo leidimai visada yra tik skaitomi, be jokio autentifikavimo ar leidimo. Apie šias sąvokas pakalbėsime šiek tiek vėliau. Reikšmė yra kitas UUID, identifikuojantis, kokia paslauga. Lentelėje reikšmė yra 0x180D, kurią Bluetooth SIG apibrėžia kaip širdies ritmo paslaugą.
Paskelbus paslaugą, pranešama apie charakteristikas. Savo forma ji panaši į paslaugų deklaraciją. Jo UUID visada yra 0x2803, o jo leidimai visada yra tik skaitymo be jokio autentifikavimo ar leidimo. Pažiūrėkime į lauką Atributo vertė, kuriame yra keletas duomenų. Jame visada yra rodyklė, UUID ir ypatybių rinkinys. Šie trys elementai apibūdina vėlesnį būdingos vertės deklaravimą. Rodyklė natūraliai žymi būdingos reikšmės deklaracijos vietą atributų lentelėje. UUID aprašo, kokio tipo informacijos ar vertės galime tikėtis. Pavyzdžiui, temperatūros vertė, šviesos jungiklio būsena arba kita savavališka reikšmė. Ir galiausiai savybės, apibūdinančios, kaip galima sąveikauti su būdinga verte.
Čia mūsų laukia dar vienas spąstas. Jis susietas su atributų leidimais ir būdingomis savybėmis. Pažiūrėkime į bitų lauko savybių paveikslėlį iš specifikacijos.
Kaip matote, čia taip pat yra laukų, kuriuose yra skaitymo ir rašymo galimybės. Jums gali kilti klausimas, kodėl turime atributo ir nuosavybės skaitymo / rašymo teises
skaityti / rašyti būdingą vertę? Ar jie neturėtų visada būti vienodi? Faktas yra tas, kad būdingos vertės savybės iš tikrųjų yra tik rekomendacijos klientui, naudojamos GATT ir taikomųjų programų sluoksniuose. Tai tiesiog užuominos apie tai, ko klientas gali tikėtis iš būdingo deklaracijos atributo. Pažvelkime į tai išsamiau. Kokių tipų leidimus turi atributas?
1. Prieigos leidimai:
- skaitymas
– rekordas
- Skaityti ir rašyti
2. Autentifikavimo leidimas:
- reikalingas autentifikavimas
- autentifikavimo nereikia
3. Autorizacijos leidimas:
— reikalingas leidimas
- leidimo nereikia
Pagrindinis skirtumas tarp atributo skiriamosios gebos ir būdingų savybių yra tas, kad pirmoji taikoma serveriams, o antroji - klientams. Serveriui gali būti leista nuskaityti būdingą reikšmę, tačiau gali reikėti autentifikavimo arba autorizacijos. Todėl, kai klientas paprašys charakteristikos savybių, gausime, kad skaitymas leidžiamas. Bet kai bandome skaityti, gauname klaidą. Todėl galime drąsiai kalbėti apie leidimų prioritetą prieš nuosavybę. Kliento pusėje negalime sužinoti, kokius leidimus turi atributas.
Deskriptorius
Grįžkime prie savo stalo. Deklaravus charakteristikos reikšmę, galimos šios atributų deklaracijos:
1. Nauja charakteristikų deklaracija (paslauga gali turėti daug savybių)
2. Nauja paslaugų deklaracija (lentelėje jų gali būti daug)
3. Rankenos deklaravimas
Širdies ritmo matavimo charakteristikos atveju mūsų lentelėje charakteristikos reikšmės deklaracija pateikiama kartu su deskriptoriaus deklaracija. Deskriptorius yra atributas su papildoma informacija apie charakteristiką. Yra keletas deskriptorių tipų. Apie juos išsamiai kalbėsime antroje šio straipsnio dalyje. Kol kas paliesime tik kliento charakteristikų konfigūracijos aprašą (CCCD). Jo UUID yra lygus 0x2902. Naudodamas šį deskriptorių, klientas gali įjungti indikaciją arba pranešimą serveryje. Skirtumas tarp jų nedidelis, bet vis tiek yra. Pranešimas nereikalauja gavimo patvirtinimo iš kliento. Nurodymas to reikalauja, nors tai vyksta GATT lygmeniu, bet nepasiekia taikymo lygio. Kodėl taip, klausiate? Deja, aš šito nežinau. Norėčiau pasakyti, kad Šiaurės šalių ekspertai rekomenduoja naudoti pranešimus. Be to, abiem atvejais tikrinamas paketo vientisumas (naudojant CRC).
išvada
Straipsnio pabaigoje norėčiau tai pasakyti. Paskutinė lentelė yra šiek tiek paini. Tačiau pasirinkau, nes pasiduoda , kuriuo pasitikiu. Antroje straipsnio dalyje ketinu gilintis į „BlueTooth 4.0“ specifikaciją. Ten mūsų laukia teisingesnės schemos ir brėžiniai. Trečioje dalyje norėčiau išanalizuoti žurnalą, gautą naudojant Wireshark programą iš vienos programėlės, ir pamatyti „gyvai“ visą mūsų studijuojamą teoriją.
Įmonių grupės darbuotojas
Pečerskis Vladimiras
Šaltinis: www.habr.com