BLE ing mikroskop (ATTы GATTы…)
Part 1, ringkesan
Wis suwe banget wiwit spesifikasi pisanan kanggo Bluetooth 4.0 dirilis. Lan, sanajan topik BLE menarik banget, nanging isih akeh pangembang amarga kerumitan. Ing artikel sadurunge, aku utamane ndeleng level paling murah, Link Layer lan Physical Layer. Iki ngidini kita ora kudu nggunakake konsep sing rumit lan mbingungake kayata Protokol Atribut (ATT) lan Profil Atribut Umum (GATT). Nanging, ora ana ngendi wae, tanpa mangerteni, ora mungkin ngembangake piranti sing kompatibel. Dina iki aku pengin nuduhake kawruh iki karo sampeyan. Ing artikelku aku bakal ngandelake kanggo pamula saka situs web Nordic. Dadi ayo miwiti.
Napa kabeh angel banget?
Mratelakake panemume, langsung jelas yen ngatur piranti liwat smartphone minangka topik sing janjeni lan tahan lama. Mulane, dheweke mutusake kanggo nggawe struktur kasebut kanthi cepet lan maksimal. Supaya produsen macem-macem gadget ora nggawe protokol dhewe, sing banjur ora kompatibel. Mula kangelan. Wis ing tataran pisanan, padha nyoba kanggo remet kabeh bisa menyang protokol BLE. Lan ora masalah apa bakal migunani mengko utawa ora. Kajaba iku, padha kasedhiya kanggo kamungkinan ngembangaken dhaftar piranti kanggo mangsa.
Ayo katon ing gambar ing ngendi diagram protokol BLE digambar. Iku kasusun saka sawetara lapisan. Lapisan fisik sing paling ngisor (PHY) tanggung jawab kanggo saluran radio piranti. Link Layer (LL) ngemot kabeh urutan bita ing pesen sing dikirim. Ing artikel sadurunge kita sinau persis iki. Host Controller Interface (HCI) iku sawijining protokol exchange antarane lapisan BLE utawa Kripik yen Controller lan Host dipun ginakaken ing Kripik beda. Logical Link Control and Adaptation Protocol (L2CAP) tanggung jawab kanggo pembentukan paket, framing, kontrol kesalahan lan perakitan paket. Security Manager Protocol (SMP) tanggung jawab kanggo enkripsi paket. Profil Akses Umum (GAP) tanggung jawab kanggo ijol-ijolan data awal antarane piranti kanggo nemtokake "Sapa sing". Iku uga kalebu mindhai lan iklan. Ing artikel iki aku bakal fokus ing rong bagéan isih saka protokol - GATT lan ATT. GATT punika superstructure saka ATT, supaya padha rapet intertwined.
Kanggo nyederhanakake crita, aku arep ngowahi analogi. Aku krungu nang endi wae lan pengin ndhukung. Coba piranti BLE minangka lemari buku kanthi pirang-pirang rak. Saben rak minangka tema sing kapisah. Contone, kita duwe rak karo fiksi ilmiah, matematika, lan ensiklopedia. Ing saben rak ana buku kanthi topik tartamtu. Lan sawetara buku malah duwe tetenger kertas kanthi cathetan. Kajaba iku, kita duwe katalog kertas cilik kabeh buku. Yen sampeyan kelingan, perpustakaan sekolah minangka kothak sing sempit kanthi kertu kertas. Kanthi analogi iki, kabinet minangka profil piranti kita. Rak minangka layanan, buku minangka ciri, lan katalog minangka tabel atribut. Tetenger ing buku minangka deskriptor, sing uga bakal dakkandhakake kanthi luwih rinci.
Sapa wae sing wis ngembangake piranti ngerti manawa akeh proyek duwe potongan kode sing padha. Kasunyatane manawa akeh piranti duwe fungsi sing padha. Contone, yen piranti didhukung dening baterei, masalah ngisi daya lan ngawasi levele bakal padha. Padha dadi kanggo sensor. Bener, pendekatan berorientasi obyek kanggo program "nyedhiyakake kemampuan kanggo nggawe obyek sing nggabungake sifat lan prilaku dadi kesatuan sing mandhiri sing banjur bisa digunakake maneh". Miturut pendapatku, BLE nyoba pendekatan sing padha. Profil dikembangake dening Bluetooth Special Interest Group (SIG). Piranti saka manufaktur beda sing duwe profil padha kudu bisa karo saben liyane tanpa kangelan. Profil, ing siji, kalebu layanan, lan layanan karakteristik, ditambah dening deskriptor. Umumé bisa katon kaya iki:
Contone, nimbang diagram profil monitor detak jantung (gelang fitness). Iku kasusun saka rong layanan lan sawetara ciri. Saka iku hirarki profil langsung dadi cetha. Karakteristik checkpoint ngreset jumlah pengeluaran kalori dadi nol.
1. Layanan detak jantung kalebu telung ciri (0x180D):
a) Karakteristik denyut jantung wajib (0x2A37)
b) Karakteristik posisi sensor awak opsional (0x2A38)
c) Karakteristik kondisi titik kontrol denyut jantung (0x2A39)
2. Layanan pangopènan baterei (0x180F):
a) Karakteristik level pangisian baterei wajib (0x2A19)
UUID
Supaya kita bisa ngakses unsur profil unik (layanan, karakteristik lan deskriptor), kita kudu nomer kabeh piye wae. Kanggo tujuan iki, konsep kayata Universally Unique ID (UUID) utawa Universally Unique Identifier dienalake. UUID dituduhake ing kurung saben baris. Lan ana siji peculiarity kene. Kanggo UUID, kita mutusake nggunakake kode 16 lan 128 bit. Ngopo kowe takon? Ing protokol BLE, kabeh babagan konservasi energi. Mulane, ukuran 16 bit cukup cukup. Ora mungkin luwih saka 65 ewu bakal digawe ing mangsa ngarep. layanan unik lan ciri. Ing wayahe, kabeh sing bisa diitung (elinga saka ngendi asale - "dheweke uga ngetung sampeyan" :-)) Unsur angka , , и sampeyan bisa ndeleng ing pranala.
Nanging, aku mikir kabeh wong ngelingi crita kanthi alamat IP 4 byte ing Internet. Ing kawitan kita panginten sing cukup, nanging saiki kita isih ora bisa ngalih menyang alamat 6-bait. Supaya ora mbaleni kesalahan iki lan menehi free rein kanggo tangan Playful saka DIYers, SIG langsung mutusaké kanggo introduce UUIDs 128-dicokot. Iki pribadi ngelingaken kula ing unlicensed 433 MHz band, kang diwenehi kanggo kabeh limo Kulibins saka saluran radio. Ing kasus kita, pengenal 128-bit saka layanan lan karakteristik wis farmed metu. Iki tegese kita, kanggo layanan lan piranti, bisa nggunakake meh kabeh nilai 128-bit. Kabeh padha, kemungkinan teka munggah karo UUID padha cenderung nol.
Nyatane, UUID cendhak 16-bit duwe ekstensi menyang nilai 128-bit. Ing spesifikasi, ekstensi iki diarani Bluetooth Base UUID lan nduweni nilai 00000000-0000-1000-8000-00805F9B34FB. Yen, contone, UUID atribut 16-bit nduweni nilai 0x1234, banjur UUID 128-bit sing padha bakal duwe nilai 00001234-0000-1000-8000-00805F9B34FB. Lan malah rumus sing cocog diwenehi:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Aku ora ngerti saka ngendi nomer tenung iki teka. Yen ana sing maca ngerti, ayo nulis ing komentar (Panganggo kanthi julukan Sinopteek wis nindakake iki. Waca komentar). Minangka kanggo teka munggah karo UUIDs 128-dicokot, ing asas sampeyan bisa nggunakake khusus sing bakal nindakake kanggo sampeyan.
ATTy GATTy...
Bener, banjur seneng-seneng diwiwiti. Ayo kula ngelingake sampeyan sing ATT adhedhasar hubungan klien-server. Saiki kita ndeleng piranti server. Isine informasi kayata nilai sensor, status switch lampu, data lokasi, lsp. Saiki yen kabeh "peserta ing parade kita" wis diwenehi nomer, kita kudu nyelehake ing memori piranti kasebut. Kanggo nindakake iki, dilebokake ing tabel sing diarani tabel atribut. Elinga iki. Iki minangka jantung BLE. Iki sing bakal kita nimbang luwih lanjut. Saiki kita bakal nelpon saben baris minangka atribut. Tabel iki dumunung ing jero tumpukan lan, minangka aturan, kita ora duwe akses langsung menyang. Kita miwiti lan ngakses, nanging apa sing kedadeyan ing njero didhelikake saka pitung segel.
Ayo ndeleng gambar saka spesifikasi, nanging sadurunge, aku pengin langsung narik kawigaten babagan kebingungan sing kerep, yaiku ing deskriptor. Peran saka deskriptor kanggo nglengkapi deskripsi karakteristik. Yen perlu kanggo nggedhekake kabisan, banjur deskriptor digunakake. Dheweke uga minangka atribut, lan kaya layanan lan karakteristik, ana ing tabel atribut. Kita bakal nliti kanthi rinci ing bagean kapindho artikel kasebut. Nanging, kadhangkala deskriptor nuduhake nomer baris ing tabel atribut. Iki kudu dieling-eling. Kanggo ngindhari kebingungan, kita bakal nggunakake istilah "pitunjuk atribut" kanggo tujuan kasebut.
Dadi atribut minangka nilai diskrit sing nduweni sifat ing ngisor iki sing digandhengake:
1. Attribute Handle yaiku indeks tabel sing cocog karo atribut
2. Tipe Atribut yaiku UUID sing nggambarake jinise
3. Nilai Atribut yaiku data sing diindeks dening pointer atribut
4. Idin Atribut yaiku bagean saka atribut, ijin, sing ora bisa diwaca utawa ditulis nggunakake protokol atribut
Kepiye carane ngerti kabeh iki? Pointer atribut punika, relatif ngandika, nomer ing tabel kita.
Ngidini klien kanggo ngrujuk atribut ing panjalukan maca utawa nulis. Kita bisa nomer baris kita (atribut) saka 0x0001 kanggo 0xFFFF. Ing asosiasi karo lemari buku, iki minangka nomer kertu ing katalog kertas. Kajaba iku, kaya ing katalog perpustakaan, kertu disusun kanthi urutan nomer. Jumlah saben baris sakteruse kudu luwih gedhe tinimbang sing sadurunge. Kaya ing perpustakaan, kadhangkala sawetara kertu ilang, supaya karo kita, bisa uga ana kesenjangan ing nomer baris. Iki diijini. Ingkang utama yaiku dheweke maju kanthi progresif.
Jinis atribut nemtokake apa sing diwakili atribut. Kanthi analogi karo basa C,
ngendi ana boolean, variabel numerik lan strings, supaya kene. Miturut jinis atribut kita kenal
apa kita dealing with lan carane kita bisa terus bisa karo atribut iki. Ing ngisor iki kita bakal ndeleng sawetara jinis atribut tartamtu. Contone, "deklarasi layanan" (0x2800), "deklarasi karakteristik" (0x2803), "deklarasi deskriptor" (0x2902).
Nilai atribut yaiku makna sing sejatine, ngapura tautologi. Yen jinis atribut minangka senar, mula nilai atribut bisa, contone, slogan "Hello World !!!". Yen jinis atribut minangka "deklarasi layanan", mula nilai kasebut yaiku layanan kasebut. Lan kadhangkala iki minangka informasi babagan ngendi golek atribut liyane lan sifate.
Ijin atribut ngidini server ngerti apa akses maca utawa nulis diidini.
Elinga yen ijin iki mung ditrapake kanggo nilai atribut, lan ora kanggo pointer, jinis, utawa kolom ijin dhewe. Sing. yen ngrekam atribut diijini, mula kita bisa ngganti, contone, baris "Hello World !!!" menyang baris "Sugeng enjing". Nanging kita ora bisa nglarang nulis baris anyar utawa ngganti jinis atribut lan nemtokake baris kasebut minangka "deklarasi layanan". Nalika klien ngubungi server, klien njaluk atribute. Iki ngidini klien ngerti apa sing bisa diwenehake server. Sanajan ora perlu maca lan nulis nilai-nilai kasebut.
Apa sing katon kaya
Konsep GATT yaiku nglumpukake atribut ing tabel atribut kanthi urutan sing spesifik lan logis. Ayo goleki kanthi luwih rinci babagan profil denyut jantung ing ngisor iki. Kolom paling kiwa tabel iki opsional. Iku mung njlèntrèhaké kanggo kita apa baris iki (atribut). Kabeh kolom liyane wis akrab karo kita.
Ing ndhuwur saben klompok kita tansah duwe atribut deklarasi layanan. Jinise tansah 0x2800, lan pointer gumantung saka jumlah atribut sing wis ana ing tabel. Ijine tansah mung diwaca, tanpa otentikasi utawa wewenang. Kita bakal ngomong babagan konsep kasebut mengko. Nilai kasebut minangka UUID liyane sing ngenali layanan kasebut. Ing Tabel, nilai 0x180D, sing ditetepake dening SIG Bluetooth minangka layanan detak jantung.
Sawise woro-woro layanan, rawuh woro-woro karakteristik. Iku padha ing wangun kanggo deklarasi layanan. UUID tansah 0x2803, lan ijine tansah diwaca tanpa otentikasi utawa wewenang. Ayo goleki kolom Nilai Atribut, sing kalebu sawetara data. Iku tansah ngemot pointer, UUID, lan sakumpulan properti. Telung unsur kasebut nggambarake deklarasi sabanjure babagan nilai karakteristik. Pointer kanthi alami nuduhake lokasi deklarasi nilai karakteristik ing tabel atribut. UUID nggambarake jinis informasi utawa nilai apa sing bisa kita ngarepake. Contone, nilai suhu, kahanan saklar lampu, utawa sawetara nilai sewenang-wenang liyane. Lan pungkasane sifat, sing nggambarake carane nilai karakteristik bisa sesambungan.
Pitfall liyane nunggu kita ing kene. Iki digandhengake karo ijin atribut lan sifat karakteristik. Ayo katon ing gambar saka sifat lapangan bit saka specification.
Kaya sing sampeyan ngerteni, ana uga lapangan ing kene sing nyedhiyakake kemampuan maca lan nulis. Sampeyan bisa uga mikir kenapa kita duwe ijin maca / nulis kanggo atribut lan properti
maca / nulis kanggo nilai karakteristik? Apa ora mesthi padha? Kasunyatan iku sifat kanggo nilai karakteristik bener mung Rekomendasi kanggo klien digunakake ing GATT lan lapisan aplikasi. Iki mung minangka pitunjuk babagan apa sing bisa dikarepake klien saka atribut deklarasi karakteristik. Ayo ndeleng iki kanthi luwih rinci. Apa jinis ijin sing diduweni atribut?
1. Izin akses:
- maca
- ngrekam
- maca lan nulis
2. Izin otentikasi:
- bukti asli dibutuhake
- ora ana bukti asli sing dibutuhake
3. Izin Izin:
- wewenang dibutuhake
- ora ana wewenang sing dibutuhake
Bentenane utama antarane resolusi atribut lan sifat karakteristik yaiku sing sadurunge ditrapake kanggo server, lan sing terakhir kanggo klien. Server bisa diijini maca nilai karakteristik, nanging mbutuhake otentikasi utawa wewenang. Mulane, nalika klien njaluk sifat karakteristik, kita bakal nampa maca sing diijini. Nanging nalika nyoba maca, kita entuk kesalahan. Mula, kita bisa ngomong kanthi aman babagan prioritas ijin tinimbang properti. Ing sisih klien, kita ora bisa entuk kawruh babagan ijin apa sing diduweni atribut.
Deskriptor
Ayo bali menyang meja kita. Sawise nyatakake nilai karakteristik, deklarasi atribut ing ngisor iki bisa ditindakake:
1. Pranyatan karakteristik anyar (layanan bisa duwe akeh karakteristik)
2. Pranyatan layanan anyar (bisa uga ana akeh ing tabel)
3. Nyatakake gagang
Ing kasus karakteristik pangukuran denyut jantung, ing tabel kita, deklarasi nilai karakteristik diiringi deklarasi deskriptor. Deskriptor minangka atribut kanthi informasi tambahan babagan karakteristik. Ana sawetara jinis deskriptor. Kita bakal ngomong babagan dheweke kanthi rinci ing bagean kapindho artikel iki. Saiki, kita mung bakal ndemek Deskriptor Konfigurasi Karakteristik Klien (CCCD). Nduwe UUID sing padha karo 0x2902. Nggunakake deskriptor iki, klien nduweni kemampuan kanggo ngaktifake indikasi utawa kabar ing server. Bentenipun antarane wong-wong mau cilik, nanging isih ana. Notifikasi ora mbutuhake konfirmasi panrimo saka klien. Indikasi mbutuhake iki, sanajan ana ing tingkat GATT, ora tekan tingkat aplikasi. Kenapa ngono, sampeyan takon? Aduh, aku ora ngerti iki. Ayo kula ujar manawa para ahli Nordic nyaranake nggunakake kabar. Kajaba iku, mriksa integritas paket (nggunakake CRC) kedadeyan ing kasus kasebut.
kesimpulan
Ing pungkasan artikel aku arep ngomong iki. Tabel pungkasan rada bingung. Nanging, aku milih amarga diwenehake , sing dakkarepake. Ing bagean kapindho artikelku, aku arep nliti luwih jero babagan spesifikasi BlueTooth 4.0. Diagram lan gambar sing luwih bener nunggu kita ing kana. Ing bagean katelu, aku pengin ngurai log sing dipikolehi nggunakake program Wireshark saka salah sawijining gadget lan ndeleng "urip" kabeh teori sing kita sinau.
Karyawan Grup Perusahaan
Pecherskikh Vladimir
Source: www.habr.com