Mikroskop ostida BLE (ATTy GATTy…)
1-qism, umumiy ko'rinish
Bluetooth 4.0 uchun birinchi spetsifikatsiya chiqarilganidan beri ancha vaqt o'tdi. Va BLE mavzusi juda qiziqarli bo'lsa-da, u hali ham murakkabligi tufayli ko'plab ishlab chiquvchilarni to'xtatadi. Oldingi maqolalarimda men asosan eng past darajali bog'lanish qatlami va jismoniy qatlamni ko'rib chiqdim. Bu bizga atribut protokoli (ATT) va umumiy atribut profili (GATT) kabi murakkab va chalkash tushunchalarga murojaat qilishdan qochish imkonini berdi. Biroq, boradigan joy yo'q, ularni tushunmasdan, mos keluvchi qurilmalarni ishlab chiqish mumkin emas. Bugun men ushbu bilimlarni siz bilan baham ko'rmoqchiman. Mening maqolamda men tayanaman Nordic veb-saytidan yangi boshlanuvchilar uchun. Shunday qilib, keling, boshlaylik.
Nega hamma narsa shunchalik qiyin?
Menimcha, smartfonlar orqali qurilmalarni boshqarish juda istiqbolli va uzoq davom etadigan mavzu ekanligi darhol ayon bo'ldi. Shuning uchun ular uni darhol va maksimal darajada tuzishga qaror qilishdi. Turli xil gadjetlarni ishlab chiqaruvchilar o'zlarining protokollarini o'ylab topmasliklari uchun, keyinchalik ular mos kelmaydi. Shuning uchun qiyinchilik. Birinchi bosqichda ular BLE protokoliga hamma narsani siqib chiqarishga harakat qilishdi. Va keyinroq foydali bo'ladimi yoki yo'qmi muhim emas. Bundan tashqari, ular kelajakdagi qurilmalar ro'yxatini kengaytirish imkoniyatini taqdim etdilar.
Keling, BLE protokoli diagrammasi chizilgan rasmni ko'rib chiqaylik. U bir necha qatlamlardan iborat. Eng past, jismoniy qatlam (PHY) qurilmaning radio kanali uchun javobgardir. Bog'lanish qatlami (LL) uzatilgan xabardagi baytlarning butun ketma-ketligini o'z ichiga oladi. Oldingi maqolalarda biz buni aniq o'rganib chiqdik. Xost Controller Interface (HCI), agar Controller va Host turli mikrosxemalarda amalga oshirilgan bo'lsa, BLE qatlamlari yoki chiplari o'rtasidagi almashish protokoli. Mantiqiy havolalarni boshqarish va moslashtirish protokoli (L2CAP) paketlarni shakllantirish, ramkalash, xatolarni boshqarish va paketlarni yig'ish uchun javobgardir. Xavfsizlik menejeri protokoli (SMP) paketlarni shifrlash uchun javobgardir. Umumiy kirish profili (GAP) "Kim kim" ni aniqlash uchun qurilmalar o'rtasida dastlabki ma'lumotlar almashinuvi uchun javobgardir. Shuningdek, u skanerlash va reklamani ham o'z ichiga oladi. Ushbu maqolada men protokolning qolgan ikkita qismiga - GATT va ATTga e'tibor qarataman. GATT ATT ning yuqori tuzilishi, shuning uchun ular bir-biri bilan chambarchas bog'langan.
Hikoyani soddalashtirish uchun men analogiyaga murojaat qilmoqchiman. Men buni qaerdadir eshitdim va uni qo'llab-quvvatlamoqchi edim. BLE qurilmasini bir nechta javonli kitob javoni sifatida tasavvur qiling. Har bir javon alohida mavzudir. Misol uchun, bizda ilmiy fantastika, matematika va ensiklopediyalar javonlari mavjud. Har bir javonda ma'lum bir mavzuga oid kitoblar mavjud. Va ba'zi kitoblarda yozuvlar bilan qog'oz xatcho'plar ham mavjud. Bundan tashqari, bizda barcha kitoblarning kichik qog'oz katalogi mavjud. Esingizda bo'lsa, maktab kutubxonalari qog'oz kartalari bo'lgan tor qutidir. Ushbu o'xshashlik bilan shkaf bizning qurilmamizning profilidir. Tokchalar xizmatlar, kitoblar xarakteristikalar, katalog esa atributlar jadvalidir. Kitoblardagi xatcho'plar tavsiflovchilar bo'lib, ular haqida keyinroq batafsilroq gaplashaman.
Qurilmalarni ishlab chiqqan har bir kishi, ko'plab loyihalarda o'xshash kod qismlari mavjudligini biladi. Gap shundaki, ko'plab qurilmalar o'xshash funktsiyalarga ega. Misol uchun, agar qurilmalar batareyalar bilan quvvatlansa, unda zaryadlash va ularning darajasini kuzatish muammosi bir xil bo'ladi. Xuddi shu narsa sensorlar uchun ham amal qiladi. Aslida, dasturlash uchun ob'ektga yo'naltirilgan yondashuv "Xususiyatlar va xatti-harakatlarni birlashtirgan ob'ektlarni yaratish qobiliyatini ta'minlaydi, keyinchalik ularni qayta ishlatish mumkin". Menimcha, BLE shunga o'xshash yondashuvni sinab ko'rdi. Profillar Bluetooth Special Interest Group (SIG) tomonidan ishlab chiqilgan. Turli ishlab chiqaruvchilarning bir xil profilga ega qurilmalari bir-biri bilan qiyinchiliksiz ishlashi kerak. Profillar, o'z navbatida, tavsiflovchilar bilan to'ldirilgan xizmatlar va xususiyatlar xizmatlaridan iborat. Umuman olganda, u quyidagicha ko'rinishi mumkin:
Masalan, yurak urish tezligi monitorining (fitness bilaguzuk) profil diagrammasini ko'rib chiqing. U ikkita xizmat va bir nechta xususiyatlardan iborat. Undan profil ierarxiyasi darhol aniq bo'ladi. Tekshirish punktining xarakteristikasi umumiy kaloriya sarfini nolga qaytaradi.
1. Yurak urish tezligi xizmati uchta xususiyatni o'z ichiga oladi (0x180D):
a) yurak urish tezligining majburiy xarakteristikasi (0x2A37)
b) ixtiyoriy tana sensori joylashuvi tavsifi (0x2A38)
c) yurak urish tezligini nazorat qilish nuqtasining shartli xususiyatlari (0x2A39)
2. Batareyaga texnik xizmat ko'rsatish (0x180F):
a) Majburiy batareya zaryadlash darajasining xarakteristikasi (0x2A19)
UUID
Profil elementlariga (xizmatlar, xarakteristikalar va tavsiflovchilar) yagona kirishimiz uchun biz ularning barchasini qandaydir tarzda raqamlashimiz kerak. Shu maqsadda Universal Unique ID (UUID) yoki Univerally Unique Identifier kabi tushunchalar kiritilgan. UUID har bir satrning qavs ichida ko'rsatilgan. Va bu erda bitta o'ziga xoslik bor. UUID uchun biz 16 va 128 bit uzunlikdagi koddan foydalanishga qaror qildik. Nega, deb so'rayapsizmi? BLE protokolida hamma narsa energiya tejash bilan bog'liq. Shuning uchun 16 bitning o'lchami juda o'rinli. Yaqin kelajakda 65 mingdan ortiq yaratilishi dargumon. noyob xizmatlar va xususiyatlar. Ayni paytda ular allaqachon hisoblanishi mumkin bo'lgan hamma narsa (bu qaerdan kelganini eslang - "u sizni ham hisoblagan" :-)) Raqamlangan elementlar , , и havolalarni ko'rishingiz mumkin.
Biroq, menimcha, hamma Internetdagi 4 bayt IP-manzillar bilan hikoyani eslaydi. Avvaliga biz bu etarli deb o'yladik, lekin hozir biz hali ham 6 baytlik manzilga o'ta olmaymiz. Ushbu xatoni takrorlamaslik va DIYerlarning o'ynoqi qo'llariga erkinlik berish uchun SIG darhol 128 bitli UUID-larni joriy etishga qaror qildi. Bu shaxsan menga radiokanaldan barcha turdagi Kulibinlarga berilgan litsenziyasiz 433 MGts diapazonini eslatadi. Bizning holatlarimizda xizmatlar va xususiyatlarning 128 bitli identifikatori ishlab chiqilgan. Bu shuni anglatadiki, biz xizmatlarimiz va qurilmalarimiz uchun deyarli har qanday 128 bitli qiymatdan foydalanishimiz mumkin. Shunga qaramay, bir xil UUID bilan kelish ehtimoli nolga intiladi.
Aslida, qisqa 16-bitli UUID-lar 128-bitli qiymatga kengaytmasiga ega. Spetsifikatsiyada ushbu kengaytma Bluetooth Base UUID deb ataladi va 00000000-0000-1000-8000-00805F9B34FB qiymatiga ega. Agar, masalan, 16-bitli UUID atributi 0x1234 qiymatiga ega boʻlsa, ekvivalent 128-bitli UUID 00001234-0000-1000-8000-00805F9B34FB qiymatiga ega boʻladi. Va hatto tegishli formula ham berilgan:
128_bit_qiymat = 16_bit_qiymat * 2^96 + Bluetooth_Base_UUID
Bu sehrli raqam qaerdan kelganini bilmayman. Agar o'quvchilardan kimdir bilsa, izohlarda yozishlariga ruxsat bering (Sinopteek laqabli foydalanuvchi buni allaqachon qilgan. Izohlarga qarang). 128-bitli UUID-larni ishlab chiqishga kelsak, printsipial jihatdan siz maxsus foydalanishingiz mumkin buni siz uchun kim qiladi.
ATTy GATTy...
Aslida, o'yin-kulgi boshlanadi. Eslatib o'taman, ATT mijoz-server munosabatlariga asoslanadi. Endi biz server qurilmasiga qaraymiz. Unda sensor qiymatlari, yorug'lik kaliti holati, joylashuv ma'lumotlari va boshqalar kabi ma'lumotlar mavjud. Endi barcha "paradimiz ishtirokchilari" raqamlangan bo'lsa, biz ularni qandaydir tarzda qurilma xotirasiga joylashtirishimiz kerak. Buning uchun ularni atributlar jadvali deb ataladigan jadvalga joylashtiramiz. Buni yaxshi eslab qoling. Bu BLEning yuragi. Bu biz bundan keyin ko'rib chiqamiz. Endi biz har bir qatorni atribut deb ataymiz. Ushbu jadval stekning chuqurligida joylashgan va, qoida tariqasida, biz unga to'g'ridan-to'g'ri kirish imkoniga ega emasmiz. Biz uni ishga tushiramiz va unga kiramiz, lekin ichkarida sodir bo'layotgan voqealar bizdan etti muhr ortida yashiringan.
Keling, rasmni spetsifikatsiyadan ko'rib chiqaylik, lekin bundan oldin men darhol atamalarda, xususan deskriptorlarda tez-tez chalkashliklarga e'tibor qaratmoqchiman. Deskriptorning roli xarakteristikaning tavsifini to'ldirishdan iborat. Uning imkoniyatlarini kengaytirish zarur bo'lganda, deskriptorlar qo'llaniladi. Ular ham atributlardir va xuddi xizmatlar va xarakteristikalar kabi atributlar jadvalida joylashgan. Biz ularni maqolaning ikkinchi qismida batafsil ko'rib chiqamiz. Biroq, ba'zida deskriptorlar atributlar jadvalidagi qator raqamiga murojaat qiladilar. Buni yodda tutish kerak. Chalkashmaslik uchun biz ushbu maqsadlar uchun "atribut ko'rsatkichi" atamasidan foydalanamiz.
Demak, atribut diskret qiymat bo‘lib, u bilan bog‘liq quyidagi xususiyatlarga ega:
1. Atribut tutqichi atributga mos keladigan jadval indeksidir
2. Atribut turi - uning turini tavsiflovchi UUID
3. Atribut qiymati atribut ko'rsatkichi tomonidan indekslangan ma'lumotlardir
4. Atribut ruxsatnomalari atributning bir qismi, atribut protokoli yordamida o‘qish yoki yozish mumkin bo‘lmagan ruxsatlardir.
Bularning barchasini qanday tushunish kerak? Atribut ko'rsatkichi, nisbatan aytganda, bizning jadvalimizdagi raqamidir.
Bu mijozga o'qish yoki yozish so'rovlarida atributga murojaat qilish imkonini beradi. Biz satrlarimizni (atributlarimizni) 0x0001 dan 0xFFFF gacha raqamlashimiz mumkin. Kitob shkafi bilan assotsiatsiyamizda bu qog'oz katalogidagi karta raqami. Xuddi shunday, kutubxona katalogida bo'lgani kabi, kartochkalar soni ortib borayotgan tartibda joylashtirilgan. Har bir keyingi qatorning soni oldingisidan kattaroq bo'lishi kerak. Xuddi kutubxonada bo'lgani kabi, ba'zida ba'zi kartalar yo'qoladi, shuning uchun biz bilan qatorlarni raqamlashda bo'shliqlar bo'lishi mumkin. Bunga ruxsat berilgan. Asosiysi, ular asta-sekin o'tadi.
Atribut turi atribut nimani anglatishini aniqlaydi. C tiliga o'xshatib,
qaerda mantiqiy, raqamli o'zgaruvchilar va satrlar bor, shuning uchun bu erda. Atribut turi bo'yicha biz taniymiz
biz nima bilan shug'ullanyapmiz va bu xususiyat bilan qanday ishlashni davom ettirishimiz mumkin. Quyida biz atributlarning o'ziga xos turlarini ko'rib chiqamiz. Masalan, "xizmat deklaratsiyasi" (0x2800), "xarakteristik deklaratsiya" (0x2803), "deskriptor deklaratsiyasi" (0x2902).
Atributning qiymati uning haqiqiy ma'nosidir, tavtologiyani kechiring. Agar atribut turi satr bo'lsa, atribut qiymati, masalan, "Salom Dunyo !!!" shiori bo'lishi mumkin. Agar atribut turi "xizmat deklaratsiyasi" bo'lsa, uning qiymati xizmatning o'zi hisoblanadi. Va ba'zida bu boshqa atributlarni va ularning xususiyatlarini qaerdan topish mumkinligi haqida ma'lumot.
Atribut ruxsatlari serverga o'qish yoki yozishga ruxsat berilganligini tushunish imkonini beradi.
E'tibor bering, bu ruxsatlar faqat atribut qiymatiga taalluqlidir, ko'rsatkich, tur yoki ruxsat maydonining o'ziga emas. Bular. agar atribut yozishga ruxsat berilsa, biz, masalan, "Salom Dunyo !!!" qatorini o'zgartirishimiz mumkin. "Xayrli tong" qatoriga. Lekin biz yangi qator yozishni taqiqlay olmaymiz yoki atribut turini o'zgartira olmaymiz va qatorni "xizmat deklaratsiyasi" sifatida belgilay olmaymiz. Mijoz serverga murojaat qilganda, mijoz uning atributlarini so'raydi. Bu mijozga server nimani taqdim etishi mumkinligini bilish imkonini beradi. Garchi qiymatlarni o'qish va yozish kerak bo'lmasa-da.
Bu nimaga o'xshaydi
GATT tushunchasi atributlar jadvalidagi atributlarni juda aniq va mantiqiy tartibda birga guruhlashdir. Keling, quyida yurak urish tezligi profilini batafsil ko'rib chiqaylik. Ushbu jadvalning eng chap ustuni ixtiyoriy. Bu shunchaki bizga bu chiziq (atribut) nima ekanligini tasvirlaydi. Boshqa barcha ustunlar bizga allaqachon tanish.
Har bir guruhning yuqori qismida biz doimo xizmat deklaratsiyasi atributiga egamiz. Uning turi har doim 0x2800 va ko'rsatkich jadvalda qancha atribut mavjudligiga bog'liq. Uning ruxsatlari har doim faqat o'qish uchun, hech qanday autentifikatsiya yoki ruxsatsiz. Bu tushunchalar haqida biroz keyinroq gaplashamiz. Qiymat xizmat nima ekanligini aniqlaydigan boshqa UUID hisoblanadi. Jadvalda qiymat 0x180D bo'lib, u Bluetooth SIG tomonidan yurak urish tezligi xizmati sifatida aniqlanadi.
Xizmat haqida e'lon qilingandan so'ng, xarakteristikaning e'lon qilinishi keladi. Shaklda u xizmat deklaratsiyasiga o'xshaydi. Uning UUID har doim 0x2803 va ruxsatnomalari har doim faqat o'qish uchun, hech qanday autentifikatsiya yoki avtorizatsiyasiz. Keling, ba'zi ma'lumotlarni o'z ichiga olgan Atribut qiymati maydonini ko'rib chiqaylik. U har doim ko'rsatgich, UUID va xususiyatlar to'plamini o'z ichiga oladi. Ushbu uchta element xarakterli qiymatning keyingi e'lon qilinishini tavsiflaydi. Ko'rsatkich tabiiy ravishda atributlar jadvalidagi xarakterli qiymat deklaratsiyasining joylashishini bildiradi. UUID biz kutishimiz mumkin bo'lgan ma'lumot yoki qiymatni tavsiflaydi. Misol uchun, harorat qiymati, yorug'lik kalitining holati yoki boshqa o'zboshimchalik qiymati. Va nihoyat, xarakterli qiymat bilan qanday o'zaro ta'sir qilish mumkinligini tavsiflovchi xususiyatlar.
Bu erda bizni yana bir tuzoq kutmoqda. U atribut ruxsatlari va xarakterli xususiyatlar bilan bog'liq. Keling, spetsifikatsiyadan bit maydoni xususiyatlarining rasmini ko'rib chiqaylik.
Ko'rib turganingizdek, bu erda o'qish va yozish imkoniyatlarini ta'minlaydigan maydonlar ham mavjud. Nima uchun bizda atribut va xususiyat uchun o'qish/yozish ruxsatnomalari borligiga hayron bo'lishingiz mumkin
xarakterli qiymat uchun o'qish/yozish? Ular har doim bir xil bo'lishi kerak emasmi? Haqiqat shundaki, xarakterli qiymat uchun xususiyatlar aslida faqat GATT va dastur qatlamlarida ishlatiladigan mijoz uchun tavsiyalardir. Bu oddiygina mijoz xarakterli deklaratsiya atributidan nimani kutishi mumkinligi haqida maslahatlar. Keling, buni batafsil ko'rib chiqaylik. Atribut qanday turdagi ruxsatlarga ega?
1. Kirish ruxsatlari:
- o'qish
- rekord
- o'qish va yozish
2. Autentifikatsiya ruxsati:
- autentifikatsiya talab qilinadi
- autentifikatsiya talab qilinmaydi
3. Avtorizatsiya ruxsati:
- avtorizatsiya talab qilinadi
- avtorizatsiya talab qilinmaydi
Atribut ravshanligi va xarakteristik xususiyatlar o'rtasidagi asosiy farq shundaki, birinchisi serverlarga, ikkinchisi esa mijozlarga tegishli. Serverga xarakteristikani o'qishga ruxsat berilishi mumkin, ammo autentifikatsiya yoki avtorizatsiya talab qilinishi mumkin. Shuning uchun, mijoz xarakteristikaning xususiyatlarini so'raganda, biz o'qishga ruxsat berilganligini olamiz. Ammo biz o'qishga harakat qilsak, xatoga yo'l qo'yamiz. Shuning uchun, biz ruxsatlarning mulkka nisbatan ustuvorligi haqida ishonch bilan gapirishimiz mumkin. Mijoz tomonida biz atribut qanday ruxsatlarga ega ekanligi haqida ma'lumotga ega bo'la olmaymiz.
Deskriptor
Keling, stolimizga qaytaylik. Xarakteristikaning qiymatini e'lon qilgandan so'ng, quyidagi atribut e'lonlari mumkin:
1. Xususiyatlarning yangi deklaratsiyasi (xizmat ko'plab xususiyatlarga ega bo'lishi mumkin)
2. Yangi xizmat deklaratsiyasi (jadvalda ularning ko'plari bo'lishi mumkin)
3. Tutqichni e'lon qilish
Yurak urish tezligini o'lchash xarakteristikasi bo'lsa, bizning jadvalimizda xarakteristik qiymat deklaratsiyasi deskriptor deklaratsiyasi bilan birga keladi. Deskriptor - bu belgi haqida qo'shimcha ma'lumotga ega atribut. Deskriptorlarning bir necha turlari mavjud. Biz ular haqida ushbu maqolaning ikkinchi qismida batafsil gaplashamiz. Hozircha biz faqat Client Characteristic Configuration Deskriptor (CCCD) ga tegamiz. U 0x2902 ga teng UUIDga ega. Ushbu identifikatordan foydalanib, mijoz serverda ko'rsatma yoki bildirishnomani yoqish imkoniyatiga ega. Ularning orasidagi farq kichik, lekin hali ham mavjud. Xabarnoma mijozdan olinganligini tasdiqlashni talab qilmaydi. Ko'rsatkich buni talab qiladi, garchi u GATT darajasida sodir bo'lsa-da, dastur darajasiga etib bormaydi. Nega shunday, deb so'rayapsizmi? Afsuski, men buni bilmayman. Aytmoqchimanki, Nordic mutaxassislari bildirishnomalardan foydalanishni tavsiya qiladilar. Bundan tashqari, paketning yaxlitligini tekshirish (CRC yordamida) ikkala holatda ham sodir bo'ladi.
xulosa
Maqolaning oxirida men shuni aytmoqchiman. Oxirgi jadval biroz chalkash. Biroq, men uni tanladim, chunki u berilgan , men bunga tayanaman. Maqolamning ikkinchi qismida men BlueTooth 4.0 spetsifikatsiyasini chuqurroq o'rganish niyatidaman. U erda bizni yanada to'g'ri diagrammalar va chizmalar kutmoqda. Uchinchi qismda men Wireshark dasturi yordamida gadjetlardan birida olingan jurnalni tahlil qilishni va biz o'rganayotgan barcha nazariyani "jonli" ko'rishni xohlayman.
Kompaniyalar guruhining xodimi
Pecherskix Vladimir
Manba: www.habr.com