BLE undir smásjá (ATTы GATTы…)
1. hluti, yfirlit
Nokkuð langur tími er þegar liðinn frá því að fyrsta forskriftin fyrir Bluetooth 4.0 kom út. Og þó að BLE efnið sé mjög áhugavert, setur það samt marga forritara frá sér vegna þess hve flókið það er. Í fyrri greinum mínum skoðaði ég aðallega hlekkjalagið á lægsta stigi og líkamlegt lag. Þetta gerði okkur kleift að forðast að þurfa að grípa til svo flókinna og ruglingslegra hugtaka eins og eiginleikabókunina (ATT) og General Attribute Profile (GATT). Hins vegar er hvergi að fara, án þess að skilja þau er ómögulegt að þróa samhæf tæki. Í dag langar mig að deila þessari þekkingu með þér. Í grein minni mun ég styðjast við fyrir byrjendur af norrænu vefsíðunni. Svo skulum við byrja.
Hvers vegna er allt svona erfitt?
Að mínu mati var strax ljóst að umsjón með tækjum í gegnum snjallsíma er mjög efnilegt og langvarandi viðfangsefni. Þess vegna ákváðu þeir að skipuleggja það strax og að hámarki. Svo að framleiðendur ýmissa græja komi ekki upp með eigin samskiptareglur sem verða þá ósamrýmanlegar. Þess vegna erfiðleikarnir. Þegar á fyrsta stigi reyndu þeir að kreista allt mögulegt inn í BLE siðareglur. Og það skiptir ekki máli hvort það nýtist síðar eða ekki. Auk þess var gert ráð fyrir möguleika á að stækka lista yfir tæki til framtíðar.
Við skulum kíkja á myndina þar sem BLE samskiptaritið er teiknað. Það samanstendur af nokkrum lögum. Lægsta, líkamlega lagið (PHY) ber ábyrgð á útvarpsrás tækisins. Link Layer (LL) inniheldur alla röð bæta í sendum skilaboðum. Í fyrri greinum lærðum við nákvæmlega þetta. Host Controller Interface (HCI) er samskiptareglur milli BLE laga eða flísar ef stjórnandi og gestgjafi eru útfærð á mismunandi flís. Logical Link Control and Adaptation Protocol (L2CAP) er ábyrgur fyrir pakkamyndun, ramma, villustýringu og pakkasamsetningu. Security Manager Protocol (SMP) ber ábyrgð á dulkóðun pakka. General Access Profile (GAP) er ábyrgur fyrir fyrstu skiptingu gagna milli tækja til að ákvarða „Hver er hver“. Það felur einnig í sér skönnun og auglýsingar. Í þessari grein mun ég einbeita mér að tveimur hlutum bókunarinnar sem eftir eru - GATT og ATT. GATT er yfirbygging ATT, svo þau eru nátengd.
Til að einfalda söguna langar mig að víkja að líkingu. Ég heyrði það einhvers staðar og myndi vilja styðja það. Hugsaðu um BLE tæki sem bókaskáp með nokkrum hillum. Hver hilla er sérstakt þema. Við höfum til dæmis hillur með vísindaskáldskap, stærðfræði og alfræðiorðabókum. Í hverri hillu eru bækur með tilteknu efni. Og sumar bækur eru jafnvel með pappírsbókamerki með glósum. Að auki erum við með litla pappírsskrá yfir allar bækur. Ef þú manst þá eru skólabókasöfn þröng kassi með pappírspjöldum. Með þessari líkingu er skápurinn snið tækisins okkar. Hillur eru þjónusta, bækur eru einkenni og vörulistinn er eigindatafla. Bókamerki í bókum eru lýsingarorð, sem ég mun einnig fjalla nánar um síðar.
Allir sem hafa þróað tæki vita að mörg verkefni hafa svipaða kóða. Staðreyndin er sú að mörg tæki hafa svipaða virkni. Til dæmis, ef tæki eru knúin af rafhlöðum, þá mun vandamálið við að hlaða og fylgjast með stigi þeirra vera það sama. Sama gildir um skynjara. Reyndar hlutbundin nálgun við forritun „veitir getu til að búa til hluti sem sameina eiginleika og hegðun í sjálfstætt sameiningu sem síðan er hægt að endurnýta“. Að mínu mati reyndi BLE svipaða nálgun. Snið var þróað af Bluetooth Special Interest Group (SIG). Tæki frá mismunandi framleiðendum sem hafa sömu snið ættu að vinna saman án erfiðleika. Snið, aftur á móti, samanstanda af þjónustu og þjónustu einkenna, bætt við lýsingum. Almennt séð gæti þetta litið svona út:
Skoðaðu til dæmis sniðmynd hjartsláttarmælis (fitness armband). Það samanstendur af tveimur þjónustum og nokkrum einkennum. Út frá því verður prófílstigveldið strax ljóst. Athugunarpunktseiginleikinn endurstillir heildarfjölda kaloríueyðslunnar á núll.
1. Púlsþjónustan inniheldur þrjá eiginleika (0x180D):
a) Skylda hjartsláttartíðni (0x2A37)
b) Valfrjáls stöðueiginleika líkamsskynjara (0x2A38)
c) Skilyrtir eiginleikar hjartsláttartíðnistöðvarinnar (0x2A39)
2. Viðhaldsþjónusta rafhlöðu (0x180F):
a) Lögboðin hleðslustigseinkenni rafhlöðunnar (0x2A19)
UUID
Til þess að við höfum einstaklega aðgang að prófílþáttum (þjónustu, eiginleikum og lýsingum) þurfum við að númera þá alla einhvern veginn. Í þessu skyni er hugtak eins og Universally Unique ID (UUID) eða Universally Unique Identifier kynnt. UUID er tilgreint í svigum hverrar línu. Og hér er eitt sérkenni. Fyrir UUID ákváðum við að nota kóða sem er 16 og 128 bita að lengd. Hví spyrðu? Í BLE bókuninni snýst allt um orkusparnað. Þess vegna er stærð 16 bita nokkuð sanngjarn. Ólíklegt er að meira en 65 þúsund verði til á næstunni. einstaka þjónustu og eiginleika. Í augnablikinu gæti allt sem þeir hefðu þegar verið talið (mundu hvaðan þetta kom - "hann taldi þig líka" :-)) Töluð atriði , , и þú getur skoðað tenglana.
Hins vegar held ég að allir muni eftir sögunni með 4 bæti af IP tölum á netinu. Í fyrstu héldum við að það væri nóg, en nú getum við samt ekki skipt yfir í 6-bæta heimilisfang. Til að endurtaka ekki þessi mistök og gefa leikandi höndum DIYers lausan tauminn ákvað SIG strax að kynna 128 bita UUID. Þetta minnir mig persónulega á leyfislausa 433 MHz bandið, sem var gefið til alls kyns Kulibins frá útvarpsrásinni. Í okkar tilviki var 128 bita auðkenni þjónustu og eiginleika ræktað út. Þetta þýðir að við, fyrir þjónustu okkar og tæki, getum notað nánast hvaða 128-bita gildi sem er. Engu að síður, líkurnar á að koma upp með sama UUID hafa tilhneigingu til að vera núll.
Reyndar hafa stutt 16-bita UUID framlengingu sína í 128-bita gildi. Í forskriftinni er þessi viðbót kölluð Bluetooth Base UUID og hefur gildið 00000000-0000-1000-8000-00805F9B34FB. Ef, til dæmis, 16-bita eigindin UUID hefur gildið 0x1234, þá mun samsvarandi 128-bita UUID hafa gildið 00001234-0000-1000-8000-00805F9B34FB. Og jafnvel samsvarandi formúla er gefin:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Ég veit ekki hvaðan þessi töfratala kom. Ef einhver lesenda veit það, láttu þá skrifa í athugasemdirnar (notandi með gælunafnið Sinopteek hefur þegar gert þetta. Sjá athugasemdirnar). Hvað varðar að koma með 128-bita UUID, í grundvallaratriðum geturðu notað sérstakt hver mun gera það fyrir þig.
ATTy GATTy...
Reyndar, þá byrjar fjörið. Leyfðu mér að minna þig á að ATT byggist á sambandi viðskiptavinar og netþjóns. Nú erum við að skoða netþjónatækið. Það inniheldur upplýsingar eins og skynjaragildi, stöðu ljósrofa, staðsetningargögn osfrv. Nú þegar allir „þátttakendur í skrúðgöngunni okkar“ eru taldir, þurfum við einhvern veginn að koma þeim fyrir í minni tækisins. Til að gera þetta setjum við þau í töflu sem kallast eigindatafla. Mundu þetta vel. Þetta er hjarta BLE. Þetta er það sem við munum íhuga frekar. Nú munum við kalla hverja línu eigind. Þetta borð er staðsett djúpt í staflanum og að jafnaði höfum við ekki beinan aðgang að því. Við frumstillum það og fáum aðgang að því, en það sem gerist inni er hulið okkur á bak við sjö innsigli.
Við skulum skoða myndina úr forskriftinni, en áður en það gerist vil ég strax vekja athygli á tíðum ruglingi í hugtökum, nefnilega í lýsingum. Hlutverk lýsingarinnar er að bæta við lýsingu á eiginleikum. Þegar það er nauðsynlegt að auka getu þess, þá eru lýsingar notaðir. Þeir eru líka eiginleikar og rétt eins og þjónustur og eiginleikar eru þeir staðsettir í eigindatöflunni. Við munum skoða þau í smáatriðum í seinni hluta greinarinnar. Hins vegar vísa stundum lýsingar til línunúmersins í eigindatöflunni. Þetta verður að hafa í huga. Til að forðast rugling, munum við nota hugtakið „eigindabendill“ í þessum tilgangi.
Þannig að eiginleiki er stakt gildi sem hefur eftirfarandi eiginleika sem tengjast því:
1. Eiginleikahandfang er töfluvísitalan sem samsvarar eigindinni
2. Attribute Type er UUID sem lýsir gerð þess
3. Eiginleikagildi eru gögnin sem eru verðtryggð af eigindarbendlinum
4. Eiginleikaheimildir eru sá hluti eigindar, heimildanna, sem ekki er hægt að lesa eða skrifa með því að nota eigindasamskiptareglur
Hvernig á að skilja þetta allt? Eiginleikabendilinn er, tiltölulega séð, númer hans í töflunni okkar.
Það gerir viðskiptavinum kleift að vísa til eigindar í lestrar- eða skrifbeiðnum. Við getum númerað línurnar okkar (eiginleika) frá 0x0001 til 0xFFFF. Í sambandi okkar við bókaskápinn er þetta kortanúmerið í pappírsskránni. Eins og í bókasafnsskránni er spjöldum raðað í vaxandi röð. Fjöldi hverrar síðari línu verður að vera meiri en fyrri. Rétt eins og á bókasafninu týnast stundum einhver spjöld, þannig að hjá okkur geta verið eyður í línunúmerinu. Þetta er leyfilegt. Aðalatriðið er að þeir fari smám saman.
Eigindartegundin ákvarðar hvað eigindin táknar. Með hliðstæðum hætti við C tungumálið,
þar sem eru boolean, tölulegar breytur og strengir, svo er það hér. Eftir eigindartegund viðurkennum við
hvað við erum að fást við og hvernig við getum haldið áfram að vinna með þennan eiginleika. Hér að neðan munum við skoða nokkrar sérstakar gerðir af eiginleikum. Til dæmis, „þjónustuyfirlýsing“ (0x2800), „einkennandi yfirlýsing“ (0x2803), „lýsingaryfirlýsing“ (0x2902).
Gildi eigindar er raunveruleg merking þess, fyrirgefðu tautology. Ef eigindartegundin er strengur, þá getur eigindagildið til dæmis verið slagorðið „Halló heimur !!!“. Ef eigindartegundin er „þjónustuyfirlýsing“ þá er gildi hennar þjónustan sjálf. Og stundum eru þetta upplýsingar um hvar á að finna aðra eiginleika og eiginleika þeirra.
Eiginleikaheimildir gera þjóninum kleift að skilja hvort les- eða skrifaðgangur er leyfður.
Athugaðu að þessar heimildir eiga aðeins við um eigindargildið en ekki fyrir bendilinn, tegundina eða heimildareitinn sjálfan. Þeir. ef eigindaupptaka er leyfð, þá getum við til dæmis breytt línunni „Halló heimur !!!“ í línuna „Góðan daginn“. En við getum ekki bannað að skrifa nýja línu eða breyta eigindargerðinni og tilgreina línuna sem „þjónustuyfirlýsingu“. Þegar viðskiptavinur hefur samband við netþjón biður viðskiptavinurinn um eiginleika hans. Þetta gerir viðskiptavininum kleift að vita hvað þjónninn getur veitt. Þó það sé ekki nauðsynlegt að lesa og skrifa gildin.
Hvernig það lítur út
Hugmyndin um GATT er að flokka eiginleika í eigindatöflu saman í mjög sérstakri og rökréttri röð. Við skulum skoða nánar hjartsláttarprófílinn hér að neðan. Dálkurinn lengst til vinstri í þessari töflu er valfrjáls. Það lýsir einfaldlega fyrir okkur hvað þessi lína (eiginleiki) er. Allir aðrir dálkar þekkja okkur nú þegar.
Efst í hverjum hópi höfum við alltaf þjónustuyfirlýsingareigind. Gerð þess er alltaf 0x2800 og bendillinn fer eftir því hversu margir eiginleikar eru þegar til staðar í töflunni. Heimildir þess eru alltaf skrifvarandi, án nokkurrar auðkenningar eða heimildar. Við munum tala um þessi hugtök aðeins síðar. Gildið er annað UUID sem auðkennir hvað þjónustan er. Í töflunni er gildið 0x180D, sem er skilgreint af Bluetooth SIG sem hjartsláttarþjónustu.
Í kjölfar tilkynningar um þjónustu kemur tilkynning um einkenni. Það er svipað í formi þjónustuyfirlýsingar. UUID þess er alltaf 0x2803 og heimildir þess eru alltaf skrifvarandi án nokkurrar auðkenningar eða heimildar. Við skulum skoða reitinn Eiginleikagildi, sem inniheldur nokkur gögn. Það inniheldur alltaf bendil, UUID og mengi eiginleika. Þessir þrír þættir lýsa síðari yfirlýsingu um einkennandi gildi. Bendillinn gefur náttúrulega til kynna staðsetningu einkennandi gildisyfirlýsingarinnar í eigindatöflunni. UUID lýsir hvers konar upplýsingum eða gildi við getum búist við. Til dæmis, hitastigið, ástand ljósrofans eða annað handahófskennt gildi. Og að lokum eiginleikar, sem lýsa því hvernig hægt er að hafa samband við einkennandi gildi.
Hér bíður okkar enn ein pytturinn. Það er tengt eigindaheimildum og einkennandi eiginleikum. Við skulum skoða myndina af bitareiginleikum úr forskriftinni.
Eins og þú sérð eru líka reitir hér sem veita les- og skrifgetu. Þú gætir verið að velta fyrir þér hvers vegna við höfum les-/skrifheimildir fyrir eiginleika og eign
lesa/skrifa fyrir einkennandi gildi? Eiga þeir ekki alltaf að vera eins? Staðreyndin er sú að eiginleikar fyrir einkennandi gildi eru í raun aðeins ráðleggingar fyrir viðskiptavininn sem notaður er í GATT og umsóknarlögum. Þetta eru einfaldlega vísbendingar um hvers viðskiptavinurinn gæti búist við af einkennandi yfirlýsingareigindinni. Við skulum skoða þetta nánar. Hvers konar heimildir hefur eigind?
1. Aðgangsheimildir:
- lestur
- met
- lesa og skrifa
2. Auðkenningarheimild:
- auðkenning krafist
- engin auðkenning krafist
3. Heimildarheimild:
— leyfis krafist
- engin heimild krafist
Helsti munurinn á eigindaupplausn og einkennandi eiginleikum er að hið fyrra á við um netþjóna og hið síðara um viðskiptavini. Miðlarinn gæti fengið leyfi til að lesa einkennandi gildi, en gæti þurft auðkenningu eða heimild. Þess vegna, þegar viðskiptavinurinn biður um eiginleika eiginleikans, munum við fá að lestur sé leyfður. En þegar við reynum að lesa fáum við villu. Þess vegna getum við örugglega talað um forgang heimilda umfram eignir. Við viðskiptavinina getum við ekki fengið vitneskju um hvaða heimildir eiginleiki hefur.
Lýsing
Snúum okkur aftur að borðinu okkar. Eftir að hafa gefið upp gildi eiginleika, eru eftirfarandi eiginleikayfirlýsingar mögulegar:
1. Ný yfirlýsing um eiginleika (þjónusta getur haft marga eiginleika)
2. Ný þjónustuyfirlýsing (þær gætu verið margar í töflunni)
3. Lýsa yfir handfangi
Þegar um er að ræða hjartsláttarmælingareiginleika, í töflunni okkar, fylgir yfirlýsingu um einkennandi gildi yfirlýsingu um lýsinguna. Lýsing er eiginleiki með viðbótarupplýsingum um eiginleika. Það eru til nokkrar gerðir af lýsingum. Við munum tala um þau í smáatriðum í seinni hluta þessarar greinar. Í bili munum við aðeins snerta viðskiptavinaeinkennandi stillingarlýsingu (CCCD). Það hefur UUID sem er jafnt og 0x2902. Með því að nota þessa lýsingu hefur viðskiptavinurinn getu til að virkja vísbendingu eða tilkynningu á þjóninum. Munurinn á þeim er lítill, en samt til staðar. Tilkynning krefst ekki staðfestingar á móttöku frá viðskiptavini. Ábending krefst þess, þó að það gerist á GATT-stigi, nær það ekki umsóknarstigi. Hvers vegna svo, spyrðu? Æ, ég veit þetta ekki. Ég vil bara segja að norrænir sérfræðingar mæla með því að nota tilkynningar. Ennfremur, að athuga heilleika pakkans (með því að nota CRC) á sér stað í báðum tilvikum.
Ályktun
Í lok greinarinnar langar mig að segja þetta. Síðasta borðið er svolítið ruglingslegt. Hins vegar valdi ég það vegna þess að það er gefið eftir , sem ég treysti á. Í seinni hluta greinar minnar ætla ég að kafa dýpra í BlueTooth 4.0 forskriftina. Þar bíða okkar réttari skýringarmyndir og teikningar. Í þriðja hluta langar mig að flokka annálinn sem fékkst með Wireshark forritinu úr einni af græjunum og sjá „í beinni“ alla kenninguna sem við erum að læra.
Starfsmaður fyrirtækjasamstæðu
Pecherskikh Vladimir
Heimild: www.habr.com