Mikroskop altında BLE (ATTы GATTы…)
1-ci hissə, ümumi baxış
Bluetooth 4.0 üçün ilk spesifikasiyanın buraxılmasından xeyli vaxt keçib. Və BLE mövzusu çox maraqlı olsa da, mürəkkəbliyinə görə hələ də bir çox tərtibatçıları təxirə salır. Əvvəlki məqalələrimdə əsasən ən aşağı səviyyə olan Link Layer və Physical Layerə baxdım. Bu, bizə Atribut Protokolu (ATT) və Ümumi Atribut Profili (GATT) kimi mürəkkəb və çaşdırıcı anlayışlara müraciət etmək məcburiyyətində qalmamağa imkan verdi. Ancaq getmək üçün heç bir yer yoxdur, onları başa düşmədən, uyğun cihazları inkişaf etdirmək mümkün deyil. Bu gün mən bu bilikləri sizinlə bölüşmək istərdim. Məqaləmdə etibar edəcəyəm Nordic saytından yeni başlayanlar üçün. Beləliklə, başlayaq.
Niyə hər şey bu qədər çətindir?
Məncə, smartfonlar vasitəsilə cihazların idarə edilməsinin çox perspektivli və uzunmüddətli mövzu olduğu dərhal aydın oldu. Ona görə də onu dərhal və maksimum dərəcədə strukturlaşdırmağa qərar verdilər. Belə ki, müxtəlif gadget istehsalçıları öz protokollarını icad etməsinlər, bu da sonradan uyğun gəlməyəcəkdir. Buna görə də çətinlik. Artıq ilk mərhələdə, mümkün olan hər şeyi BLE protokoluna sıxmağa çalışdılar. Və sonradan faydalı olub-olmayacağının əhəmiyyəti yoxdur. Bundan əlavə, onlar gələcək üçün cihazların siyahısını genişləndirmək imkanını təmin etdilər.
BLE protokol diaqramının çəkildiyi şəklə nəzər salaq. Bir neçə təbəqədən ibarətdir. Ən aşağı, fiziki təbəqə (PHY) cihazın radio kanalına cavabdehdir. Link Layer (LL) ötürülən mesajda bütün bayt ardıcıllığını ehtiva edir. Əvvəlki yazılarımızda məhz bunu öyrənmişdik. Host Controller Interface (HCI), Controller və Host müxtəlif çiplərdə həyata keçirilirsə, BLE təbəqələri və ya çipləri arasında mübadilə protokoludur. Məntiqi Bağlantı Nəzarəti və Uyğunlaşma Protokolu (L2CAP) paketin formalaşması, çərçivənin qurulması, səhvlərə nəzarət və paketlərin yığılması üçün cavabdehdir. Təhlükəsizlik Meneceri Protokolu (SMP) paketlərin şifrələnməsinə cavabdehdir. Ümumi Giriş Profili (GAP) “Kimin kim olduğunu” müəyyən etmək üçün cihazlar arasında ilkin məlumat mübadiləsinə cavabdehdir. Buraya skan və reklam da daxildir. Bu yazıda mən protokolun qalan iki hissəsinə - GATT və ATT-yə diqqət yetirəcəyəm. GATT ATT-nin üst quruluşudur, ona görə də onlar bir-biri ilə sıx bağlıdır.
Hekayəni sadələşdirmək üçün bir bənzətməyə müraciət etmək istərdim. Hardasa eşitdim və dəstək olmaq istərdim. BLE cihazını bir neçə rəfi olan kitab şkafı kimi düşünün. Hər bir rəf ayrı bir mövzudur. Məsələn, bizdə elmi fantastika, riyaziyyat və ensiklopediyalar olan rəflər var. Hər rəfdə müəyyən bir mövzu ilə bağlı kitablar var. Bəzi kitablarda hətta qeydləri olan kağız əlfəcinlər var. Bundan əlavə, bizdə bütün kitabların kiçik bir kağız kataloqu var. Yadınızdadırsa, məktəb kitabxanaları kağız kartları olan dar bir qutudur. Bu bənzətmə ilə kabinet cihazımızın profilidir. Rəflər xidmətlər, kitablar xüsusiyyətlər, kataloq isə atribut cədvəlidir. Kitablardakı əlfəcinlər deskriptorlardır, onlar haqqında daha sonra daha ətraflı danışacağam.
Cihazlar hazırlamış hər kəs bilir ki, bir çox layihədə oxşar kod parçaları var. Fakt budur ki, bir çox cihazın oxşar funksionallığı var. Məsələn, qurğular akkumulyatorlardan qidalanırsa, o zaman onların doldurulması və səviyyəsinin monitorinqi problemi eyni olacaq. Eyni şey sensorlara da aiddir. Əslində, proqramlaşdırmaya obyekt yönümlü yanaşma "Xüsusiyyətləri və davranışları özündə birləşdirən və sonra yenidən istifadə oluna bilən obyektlər yaratmaq qabiliyyətini təmin edir". Fikrimcə, BLE oxşar yanaşmaya cəhd etdi. Profillər Bluetooth Xüsusi Maraq Qrupu (SIG) tərəfindən hazırlanmışdır. Eyni profillərə malik olan müxtəlif istehsalçıların cihazları bir-biri ilə çətinlik çəkmədən işləməlidir. Profillər, öz növbəsində, deskriptorlarla tamamlanan xidmətlərdən və xüsusiyyətlərin xidmətlərindən ibarətdir. Ümumiyyətlə, bu belə görünə bilər:
Məsələn, ürək dərəcəsi monitorunun (fitness qolbaq) profil diaqramını nəzərdən keçirin. O, iki xidmətdən və bir neçə xüsusiyyətdən ibarətdir. Ondan profil iyerarxiyası dərhal aydın olur. Yoxlama nöqtəsi xarakteristikası ümumi kalori xərclərini sıfıra sıfırlayır.
1. Ürək dərəcəsi xidmətinə üç xüsusiyyət daxildir (0x180D):
a) Məcburi ürək dərəcəsi xarakteristikası (0x2A37)
b) Opsiyonel bədən sensorunun mövqe xarakteristikası (0x2A38)
c) Ürək dərəcəsinə nəzarət nöqtəsinin şərti xüsusiyyətləri (0x2A39)
2. Batareyaya texniki xidmət (0x180F):
a) Məcburi batareya doldurma səviyyəsinin xarakteristikası (0x2A19)
UUID
Profil elementlərinə (xidmətlər, xüsusiyyətlər və deskriptorlar) unikal şəkildə daxil olmaq üçün onların hamısını bir şəkildə nömrələməliyik. Bu məqsədlə Universal Unique ID (UUID) və ya Universal Unique Identifier kimi konsepsiya təqdim edilir. UUID hər bir sətirin mötərizəsində göstərilir. Və burada bir özəllik var. UUID üçün biz 16 və 128 bit uzunluğunda koddan istifadə etmək qərarına gəldik. Niyə, soruşursan? BLE protokolunda hər şey enerjiyə qənaətlə bağlıdır. Buna görə də, 16 bit ölçüsü olduqca məqbuldur. Yaxın gələcəkdə 65 mindən çoxunun yaradılması mümkün deyil. unikal xidmətlər və xüsusiyyətlər. Hal-hazırda, onların sayıla biləcəyi hər şey (bunun haradan gəldiyini xatırlayın - "o da sizi saydı" :-)) Nömrələnmiş elementlər , , и linklərə baxa bilərsiniz.
Bununla belə, məncə hər kəs internetdə 4 bayt IP ünvanları ilə hekayəni xatırlayır. Əvvəlcə bunun kifayət olduğunu düşündük, amma indi hələ də 6 baytlıq ünvana keçə bilmirik. Bu səhvi təkrarlamamaq və DIYerlərin oynaq əllərinə sərbəstlik vermək üçün SIG dərhal 128 bitlik UUID-ləri təqdim etmək qərarına gəldi. Bu şəxsən mənə radio kanalından hər cür Kulibinlərə verilən lisenziyasız 433 MHz diapazonunu xatırladır. Bizim vəziyyətimizdə xidmətlərin və xüsusiyyətlərin 128 bit identifikatoru hazırlanmışdır. Bu o deməkdir ki, biz xidmətlərimiz və cihazlarımız üçün demək olar ki, istənilən 128 bit dəyərdən istifadə edə bilərik. Eyni zamanda, eyni UUID ilə gəlmə ehtimalı sıfıra enir.
Əslində, qısa 16 bitlik UUID-lərin 128 bit dəyərinə qədər uzantısı var. Spesifikasiyada bu genişləndirmə Bluetooth Base UUID adlanır və 00000000-0000-1000-8000-00805F9B34FB dəyərinə malikdir. Məsələn, 16 bitlik UUID atributunun 0x1234 dəyəri varsa, ekvivalent 128 bitlik UUID 00001234-0000-1000-8000-00805F9B34FB dəyərinə sahib olacaq. Və hətta müvafiq düstur verilir:
128_bit_dəyər = 16_bit_dəyər * 2^96 + Bluetooth_Base_UUID
Bu sehrli nömrənin haradan gəldiyini bilmirəm. Oxuculardan kim bilirsə, şərhlərdə yazsın (Sinopteek ləqəbli istifadəçi artıq bunu edib. Şərhlərə baxın). 128-bit UUID-lərlə gəlməyə gəldikdə, prinsipcə xüsusi istifadə edə bilərsiniz bunu sizin üçün kim edəcək.
ATTy GATTy...
Əslində əyləncə bundan sonra başlayır. Nəzərinizə çatdırım ki, ATT müştəri-server münasibətinə əsaslanır. İndi biz server cihazına baxırıq. O, sensor dəyərləri, işıq açarının vəziyyəti, yer məlumatları və s. kimi məlumatları ehtiva edir. İndi bütün "paradımızın iştirakçıları" nömrələndiyi üçün onları birtəhər cihazın yaddaşına yerləşdirməliyik. Bunun üçün onları atribut cədvəli adlanan cədvələ qoyuruq. Bunu yaxşı xatırla. Bu, BLE-nin ürəyidir. Bu, daha sonra nəzərdən keçirəcəyimiz şeydir. İndi hər sətri bir atribut adlandıracağıq. Bu cədvəl yığının dərinliyində yerləşir və bir qayda olaraq, ona birbaşa çıxışımız yoxdur. Biz onu işə salırıq və daxil oluruq, lakin içəridə baş verənlər bizdən yeddi möhür arxasında gizlənir.
Şəkilə spesifikasiyadan baxaq, amma bundan əvvəl dərhal terminlərdə, yəni deskriptorlarda tez-tez baş verən qarışıqlığa diqqət çəkmək istərdim. Təsvirçinin rolu xarakteristikanın təsvirini tamamlamaqdır. Onun imkanlarını genişləndirmək lazım olduqda, deskriptorlardan istifadə olunur. Onlar da atributlardır və xidmətlər və xüsusiyyətlər kimi atribut cədvəlində yerləşirlər. Məqalənin ikinci hissəsində onları ətraflı araşdıracağıq. Bununla belə, bəzən deskriptorlar atribut cədvəlindəki sıra nömrəsinə istinad edirlər. Bunu nəzərə almaq lazımdır. Qarışıqlığın qarşısını almaq üçün bu məqsədlər üçün “atribut göstəricisi” terminindən istifadə edəcəyik.
Beləliklə, atribut onunla əlaqəli aşağıdakı xüsusiyyətlərə malik diskret dəyərdir:
1. Atribut Dəstəyi atributa uyğun gələn cədvəl indeksidir
2. Atribut Tipi onun növünü təsvir edən UUID-dir
3. Atribut Dəyəri atribut göstəricisi tərəfindən indeksləşdirilmiş məlumatdır
4. Atribut İcazələri atribut protokolundan istifadə etməklə oxuna və ya yazıla bilməyən atributun, icazələrin hissəsidir.
Bütün bunları necə başa düşmək olar? Atribut göstəricisi, nisbətən desək, cədvəlimizdəki sayıdır.
Müştəriyə oxumaq və ya yazma sorğularında atributa istinad etməyə imkan verir. Biz 0x0001-dən 0xFFFF-ə qədər sətirlərimizi (atributlarımızı) nömrələyə bilərik. Kitab şkafı ilə əlaqəmizdə bu, kağız kataloqunda kart nömrəsidir. Eynilə, kitabxana kataloqunda olduğu kimi, kartlar artan say sırasına görə düzülür. Hər bir sonrakı sətrin sayı əvvəlkindən çox olmalıdır. Kitabxanada olduğu kimi, bəzən bəzi kartlar itirilir, ona görə də bizdə sətir nömrələnməsində boşluqlar ola bilər. Buna icazə verilir. Əsas odur ki, onlar tədricən gedirlər.
Atribut növü atributun nəyi təmsil etdiyini müəyyən edir. C dili ilə analoji olaraq,
harada boolean, ədədi dəyişənlər və sətirlər varsa, buradadır. Atribut növünə görə tanıyırıq
nə ilə məşğul oluruq və bu atributla işləməyə necə davam edə bilərik. Aşağıda bəzi xüsusi atribut növlərinə baxacağıq. Məsələn, “xidmət bəyannaməsi” (0x2800), “xarakterik bəyannamə” (0x2803), “deskriptor bəyannaməsi” (0x2902).
Bir atributun dəyəri onun həqiqi mənasıdır, tavtologiyanı bağışlayın. Əgər atribut növü sətirdirsə, atribut dəyəri, məsələn, “Salam Dünya !!!” şüarı ola bilər. Əgər atribut növü “xidmət bəyannaməsi”dirsə, onun dəyəri xidmətin özüdür. Və bəzən bu, digər atributları və onların xassələrini harada tapmaq barədə məlumatdır.
Atribut icazələri serverə oxumaq və ya yazmaq imkanı verildiyini anlamağa imkan verir.
Qeyd edək ki, bu icazələr göstərici, tip və ya icazə sahəsinin özünə deyil, yalnız atribut dəyərinə tətbiq edilir. Bunlar. atribut qeydinə icazə verilirsə, məsələn, "Salam Dünya !!!" xəttini dəyişə bilərik. "Sabahınız xeyir" sətrinə. Lakin biz yeni sətir yazmağı qadağan edə və ya atribut tipini dəyişdirə və xətti “xidmət bəyannaməsi” kimi təyin edə bilmərik. Müştəri bir serverlə əlaqə saxladıqda, müştəri onun atributlarını tələb edir. Bu, müştəriyə serverin nə təmin edə biləcəyini bilməyə imkan verir. Baxmayaraq ki, dəyərləri oxuyub yazmaq lazım deyil.
Nə bənzəyir?
GATT konsepsiyası atribut cədvəlində atributları çox xüsusi və məntiqi ardıcıllıqla qruplaşdırmaqdır. Aşağıdakı ürək dərəcəsi profilinə daha yaxından nəzər salaq. Bu cədvəlin ən sol sütunu isteğe bağlıdır. Sadəcə olaraq bu xəttin (atributun) nə olduğunu bizə təsvir edir. Bütün digər sütunlar artıq bizə tanışdır.
Hər bir qrupun yuxarı hissəsində həmişə xidmət bəyannaməsi atributumuz var. Onun növü həmişə 0x2800-dir və göstərici cədvəldə artıq neçə atributun mövcudluğundan asılıdır. Onun icazələri heç bir autentifikasiya və ya icazə olmadan həmişə yalnız oxunur. Bu anlayışlar haqqında bir az sonra danışacağıq. Dəyər xidmətin nə olduğunu müəyyən edən başqa bir UUID-dir. Cədvəldə dəyər 0x180D-dir ki, bu da Bluetooth SIG tərəfindən ürək dərəcəsi xidməti kimi müəyyən edilir.
Xidmətin elanından sonra xarakteristikanın elanı gəlir. Formasına görə xidmət bəyannaməsinə bənzəyir. Onun UUID-i həmişə 0x2803-dir və icazələri heç bir autentifikasiya və ya icazə olmadan həmişə yalnız oxunur. Bəzi məlumatları ehtiva edən Atribut Dəyəri sahəsinə baxaq. O, həmişə göstərici, UUID və bir sıra xüsusiyyətlərdən ibarətdir. Bu üç element xarakterik dəyərin sonrakı elanını təsvir edir. Göstərici təbii olaraq atribut cədvəlində xarakterik dəyər bəyannaməsinin yerini göstərir. UUID hansı növ məlumat və ya dəyəri gözləyə biləcəyimizi təsvir edir. Məsələn, temperatur dəyəri, işıq açarının vəziyyəti və ya başqa bir ixtiyari dəyər. Və nəhayət, xarakterik dəyərin necə qarşılıqlı əlaqədə ola biləcəyini təsvir edən xüsusiyyətlər.
Burada bizi başqa bir tələ gözləyir. Bu, atribut icazələri və xarakterik xüsusiyyətlərlə əlaqələndirilir. Spesifikasiyadan bit sahəsinin xüsusiyyətlərinin şəklinə baxaq.
Gördüyünüz kimi, burada oxumaq və yazmaq imkanlarını təmin edən sahələr də var. Atribut və mülkiyyət üçün niyə oxumaq/yazmaq icazələrimiz olduğunu merak edə bilərsiniz
xarakterik dəyər üçün oxumaq/yazmaq? Onlar həmişə eyni olmalı deyilmi? Fakt budur ki, xarakterik dəyər üçün xüsusiyyətlər əslində yalnız GATT və tətbiq səviyyələrində istifadə olunan müştəri üçün tövsiyələrdir. Bunlar sadəcə olaraq müştərinin xarakterik bəyannamə atributundan nə gözləyə biləcəyinə dair göstərişlərdir. Buna daha ətraflı baxaq. Atribut hansı növ icazələrə malikdir?
1. Giriş icazələri:
- oxumaq
- rekord
- oxu və yaz
2. Doğrulama icazəsi:
- autentifikasiya tələb olunur
- autentifikasiya tələb olunmur
3. Avtorizasiya icazəsi:
- icazə tələb olunur
- icazə tələb olunmur
Atribut həlli ilə xarakterik xüsusiyyətlər arasındakı əsas fərq ondan ibarətdir ki, birincisi serverlərə, ikincisi isə müştərilərə aiddir. Serverə xarakterik dəyəri oxumağa icazə verilə bilər, lakin autentifikasiya və ya icazə tələb oluna bilər. Buna görə, müştəri xarakteristikanın xüsusiyyətlərini tələb etdikdə, oxumağa icazə verildiyini alacağıq. Amma oxumağa cəhd etdikdə xəta alırıq. Buna görə də, icazələrin xassələrdən üstünlüyü haqqında etibarlı şəkildə danışa bilərik. Müştəri tərəfində biz atributun hansı icazələrə malik olduğuna dair məlumat əldə edə bilmirik.
Deskriptor
Gəlin süfrəmizə qayıdaq. Xarakteristikanın dəyərini elan etdikdən sonra aşağıdakı atribut elanları mümkündür:
1. Xüsusiyyətlərin yeni bəyannaməsi (xidmət bir çox xüsusiyyətlərə malik ola bilər)
2. Yeni xidmət bəyannaməsi (cədvəldə onlardan çoxu ola bilər)
3. Dəstəyin elan edilməsi
Ürək dərəcəsinin ölçülməsi xarakteristikası vəziyyətində, cədvəlimizdə xarakterik dəyərin elanı deskriptorun elanı ilə müşayiət olunur. Təsviredici xüsusiyyət haqqında əlavə məlumatı olan atributdur. Deskriptorların bir neçə növü var. Bu məqalənin ikinci hissəsində onlar haqqında ətraflı danışacağıq. Hələlik biz yalnız Müştəri Xarakterik Konfiqurasiya Deskriptoruna (CCCD) toxunacağıq. 0x2902-ə bərabər olan UUID-ə malikdir. Bu deskriptordan istifadə edərək müştəri serverdə göstərici və ya bildirişi aktivləşdirmək imkanına malikdir. Aralarındakı fərq kiçikdir, amma yenə də var. Bildiriş müştəridən qəbzin təsdiqini tələb etmir. Göstəriş bunu tələb edir, baxmayaraq ki, GATT səviyyəsində baş verir, tətbiq səviyyəsinə çatmır. Niyə belə, soruşursan? Təəssüf ki, mən bunu bilmirəm. Sadəcə deyim ki, Nordic mütəxəssisləri bildirişlərdən istifadə etməyi məsləhət görürlər. Üstəlik, paketin bütövlüyünün yoxlanılması (CRC-dən istifadə etməklə) hər iki halda baş verir.
Nəticə
Məqalənin sonunda bunu demək istərdim. Sonuncu cədvəl bir az qarışıqdır. Bununla belə, mən onu seçdim, çünki o, verilir , mən etibar edirəm. Məqaləmin ikinci hissəsində mən BlueTooth 4.0 spesifikasiyasını daha dərindən araşdırmaq niyyətindəyəm. Orada bizi daha düzgün diaqramlar və rəsmlər gözləyir. Üçüncü hissədə, Wireshark proqramından istifadə edərək əldə edilmiş jurnalı gadgetlardan birindən təhlil etmək və öyrəndiyimiz bütün nəzəriyyəni "canlı" görmək istərdim.
Şirkətlər Qrupunun əməkdaşı
Peçerskix Vladimir
Mənbə: www.habr.com