Микроскоптағы BLE (ATTы GATTы…)
1-бөлім, шолу
Bluetooth 4.0 бірінші спецификациясы шыққаннан бері көп уақыт өтті. BLE тақырыбы өте қызықты болғанымен, ол әлі де күрделілігіне байланысты көптеген әзірлеушілерді тоқтатады. Алдыңғы мақалаларымда мен негізінен ең төменгі деңгейді қарастырдым, сілтеме қабаты және физикалық деңгей. Бұл атрибуттар хаттамасы (ATT) және жалпы төлсипат профилі (GATT) сияқты күрделі және түсініксіз тұжырымдамаларға жүгінбеуге мүмкіндік берді. Дегенмен, баратын жер жоқ, оларды түсінбей, үйлесімді құрылғыларды әзірлеу мүмкін емес. Бүгін мен сіздермен осы білімімді бөліскім келеді. Менің мақаламда мен сүйенетін боламын Nordic веб-сайтынан жаңадан бастаушылар үшін. Ендеше, бастайық.
Неге бәрі соншалықты қиын?
Менің ойымша, смартфондар арқылы құрылғыларды басқару өте перспективалы және ұзаққа созылатын тақырып екені бірден белгілі болды. Сондықтан олар оны дереу және барынша құрылымдауға шешім қабылдады. Әртүрлі гаджеттерді өндірушілер өздерінің протоколдарын ойлап таппайды, содан кейін олар үйлесімсіз болады. Сондықтан қиындық. Бірінші кезеңде олар BLE протоколына мүмкін болатынның бәрін сығуға тырысты. Оның кейін пайдалы бола ма, жоқ па маңызды емес. Сонымен қатар, олар болашақта құрылғылар тізімін кеңейту мүмкіндігін қарастырды.
BLE протоколының диаграммасы сызылған суретті қарастырайық. Ол бірнеше қабаттардан тұрады. Ең төменгі физикалық деңгей (PHY) құрылғының радио арнасына жауап береді. Сілтеме қабаты (LL) жіберілетін хабарламадағы байттардың бүкіл тізбегін қамтиды. Алдыңғы мақалаларда біз дәл осыны зерттедік. Host Controller Interface (HCI) - егер контроллер мен хост әртүрлі микросхемаларда жүзеге асырылса, BLE деңгейлері немесе чиптері арасындағы алмасу протоколы. Логикалық сілтемені басқару және бейімдеу протоколы (L2CAP) пакеттерді қалыптастыруға, жақтауға, қателерді басқаруға және пакеттерді құрастыруға жауап береді. Қауіпсіздік менеджерінің протоколы (SMP) пакеттерді шифрлауға жауапты. Жалпы рұқсат профилі (GAP) құрылғылар арасында «Кім кім» дегенді анықтау үшін деректердің бастапқы алмасуына жауап береді. Оған сканерлеу мен жарнама да кіреді. Бұл мақалада мен хаттаманың қалған екі бөлігіне - ГАТТ және АТТ-ға тоқталамын. ГАТТ АТТ қондырмасы болып табылады, сондықтан олар бір-бірімен тығыз байланысты.
Оқиғаны жеңілдету үшін аналогияға жүгінгім келеді. Бір жерден естіп, қолдағым келеді. BLE құрылғысын бірнеше сөресі бар кітап шкафы ретінде елестетіп көріңіз. Әрбір сөре бөлек тақырып. Мысалы, бізде фантастика, математика және энциклопедиялар бар сөрелер бар. Әр сөреде белгілі бір тақырып жазылған кітаптар бар. Ал кейбір кітаптарда жазбалары бар қағаз бетбелгілері де бар. Сонымен қатар, бізде барлық кітаптардың шағын қағаз каталогы бар. Естеріңізде болса, мектеп кітапханалары – қағаз карталары бар тар жәшік. Осы ұқсастығымен шкаф - бұл біздің құрылғының профилі. Сөрелер - қызметтер, кітаптар - сипаттамалар, ал каталог - атрибуттар кестесі. Кітаптардағы бетбелгілер дескрипторлар болып табылады, мен олар туралы кейінірек толығырақ айтатын боламын.
Құрылғыларды жасаған кез келген адам көптеген жобаларда ұқсас код бөліктері бар екенін біледі. Өйткені, көптеген құрылғылардың ұқсас функционалдығы бар. Мысалы, егер құрылғылар батареялардан қуат алса, онда зарядтау және олардың деңгейін бақылау мәселесі бірдей болады. Бұл сенсорларға да қатысты. Шын мәнінде, бағдарламалауға объектілі-бағытталған тәсіл «Қасиеттер мен мінез-құлықтарды біріктіретін, кейін қайта пайдалануға болатын дербес бірлестікке нысандарды жасау мүмкіндігін береді». Менің ойымша, BLE ұқсас тәсілге тырысты. Профильдерді Bluetooth Special Interest Group (SIG) әзірлеген. Профильдері бірдей әртүрлі өндірушілердің құрылғылары бір-бірімен қиындықсыз жұмыс істеуі керек. Профильдер өз кезегінде дескрипторлармен толықтырылған сипаттамалар қызметтерінен және қызметтерінен тұрады. Жалпы, бұл келесідей болуы мүмкін:
Мысалы, жүрек соғу жиілігі мониторының (фитнес білезігі) профиль диаграммасын қарастырыңыз. Ол екі қызметтен және бірнеше сипаттамадан тұрады. Одан профиль иерархиясы бірден анық болады. Бақылау нүктесінің сипаттамасы жалпы калория шығынын нөлге дейін қалпына келтіреді.
1. Жүрек соғу жиілігі қызметі үш сипаттаманы қамтиды (0x180D):
а) Міндетті жүрек соғу жиілігінің сипаттамасы (0x2A37)
b) Қосымша дене сенсорының орны сипаттамасы (0x2A38)
c) Жүрек соғу жиілігін бақылау нүктесінің шартты сипаттамалары (0x2A39)
2. Батареяға техникалық қызмет көрсету (0x180F):
a) Батарея зарядының міндетті деңгейінің сипаттамасы (0x2A19)
UUID
Профиль элементтеріне (қызметтер, сипаттамалар және дескрипторлар) бірегей қол жеткізу үшін біз олардың барлығын қандай да бір жолмен нөмірлеуіміз керек. Осы мақсат үшін әмбебап бірегей идентификатор (UUID) немесе әмбебап бірегей идентификатор сияқты тұжырымдама енгізілген. UUID әр жолдың жақшаларында көрсетілген. Және бұл жерде бір ерекшелік бар. UUID үшін біз ұзындығы 16 және 128 биттік кодты пайдалануды шештік. Сен неге сұрайсың? BLE хаттамасында бәрі энергияны үнемдеуге қатысты. Сондықтан 16 биттің өлшемі өте орынды. Алдағы уақытта 65 мыңнан астам құрылуы екіталай. бірегей қызметтер мен сипаттамалар. Қазіргі уақытта олардың барлығын санауға болатын еді (бұл қайдан шыққанын есте сақтаңыз - «ол сені де санады» :-)) Нөмірленген элементтер , , и сілтемелерінен қарай аласыз.
Дегенмен, менің ойымша, Интернетте 4 байт IP мекенжайлары бар оқиға барлығының есінде. Басында біз бұл жеткілікті деп ойладық, бірақ қазір біз әлі де 6 байттық мекенжайға ауыса алмаймыз. Бұл қатені қайталамау және DIYерлердің ойнақы қолдарына еркіндік беру үшін SIG бірден 128 биттік UUID енгізуге шешім қабылдады. Бұл маған радиоарнадан Кулибиндердің барлық түрлеріне берілген лицензиясыз 433 МГц диапазонын есіме түсіреді. Біздің жағдайда қызметтер мен сипаттамалардың 128 биттік идентификаторы шығарылды. Бұл біздің қызметтеріміз бен құрылғыларымыз үшін кез келген дерлік 128 биттік мәнді пайдалана алатынымызды білдіреді. Дегенмен, бірдей UUID пайда болу ықтималдығы нөлге тең.
Шын мәнінде, қысқа 16 биттік UUID 128 биттік мәнге дейін кеңейтілуіне ие. Техникалық сипаттамада бұл кеңейтім Bluetooth Base UUID деп аталады және 00000000-0000-1000-8000-00805F9B34FB мәніне ие. Мысалы, 16-биттік UUID төлсипатының 0x1234 мәні болса, онда баламалы 128-биттік UUID 00001234-0000-1000-8000-00805F9B34FB мәніне ие болады. Тіпті сәйкес формула берілген:
128_бит_мәні = 16_бит_мәні * 2^96 + Bluetooth_Base_UUID
Мен бұл сиқырлы санның қайдан шыққанын білмеймін. Оқырмандардың бірі білсе, пікірге жазсын (Sinopteek лақап аты бар қолданушы мұны істеп қойған. Пікірлерді қараңыз). 128-биттік UUID-ті ойлап табуға келетін болсақ, негізінен сіз арнайы пайдалана аласыз оны сен үшін кім жасайды.
ATTy GATTy...
Негізі қызық содан басталады. Еске сала кетейін, ATT клиент пен сервер қатынасына негізделген. Енді біз сервер құрылғысын қарастырамыз. Ол сенсор мәндері, жарық қосқышының күйі, орын деректері және т.б. сияқты ақпаратты қамтиды. Енді барлық «шеруімізге қатысушылар» нөмірленгендіктен, біз оларды құрылғының жадына қандай да бір түрде орналастыруымыз керек. Ол үшін оларды атрибуттар кестесі деп аталатын кестеге орналастырамыз. Мұны жақсы есте сақтаңыз. Бұл BLE-дің жүрегі. Бұл біз әрі қарай қарастыратын нәрсе. Енді біз әрбір жолды атрибут деп атаймыз. Бұл кесте стектің тереңінде орналасқан және әдетте оған тікелей қол жеткізе алмаймыз. Біз оны инициализациялаймыз және оған қол жеткіземіз, бірақ ішінде не болып жатқаны бізден жеті мөрдің артында жасырылады.
Суретті спецификациядан қарастырайық, бірақ бұған дейін терминдердегі, атап айтқанда дескрипторлардағы жиі шатасуларға бірден назар аударғым келеді. Дескриптордың рөлі сипаттаманың сипаттамасын толықтыру болып табылады. Оның мүмкіндіктерін кеңейту қажет болған кезде дескрипторлар қолданылады. Олар да атрибуттар болып табылады және қызметтер мен сипаттамалар сияқты олар атрибуттар кестесінде орналасқан. Біз оларды мақаланың екінші бөлігінде егжей-тегжейлі қарастырамыз. Дегенмен, кейде дескрипторлар атрибуттар кестесіндегі жол нөміріне сілтеме жасайды. Мұны есте сақтау керек. Шатастыруды болдырмау үшін біз осы мақсаттар үшін «атрибут көрсеткіші» терминін қолданамыз.
Сонымен, атрибут онымен байланысты келесі қасиеттерге ие дискретті мән болып табылады:
1. Атрибуттың дескрипторы – атрибутқа сәйкес келетін кесте индексі
2. Атрибут түрі – оның түрін сипаттайтын UUID
3. Төлсипат мәні – төлсипат көрсеткіші арқылы индекстелген деректер
4. Атрибут рұқсаттары төлсипаттың бөлігі, рұқсаттар, атрибут протоколын пайдаланып оқу немесе жазу мүмкін емес.
Мұның бәрін қалай түсінуге болады? Атрибут көрсеткіші, салыстырмалы түрде айтқанда, оның біздің кестедегі саны.
Ол клиентке оқу немесе жазу сұрауларындағы төлсипатқа сілтеме жасауға мүмкіндік береді. Біз жолдарымызды (атрибуттарымызды) 0x0001-ден 0xFFFF-ге дейін нөмірлей аламыз. Біздің кітап шкафымен байланысымызда бұл қағаз каталогындағы карта нөмірі. Сол сияқты, кітапхана каталогындағыдай, карталар да санның өсу ретімен орналасады. Әрбір келесі жолдың саны алдыңғысынан көп болуы керек. Кітапханадағы сияқты, кейде кейбір карталар жоғалып кетеді, сондықтан бізде жолдарды нөмірлеуде олқылықтар болуы мүмкін. Бұл рұқсат етілген. Ең бастысы, олар біртіндеп жүреді.
Төлсипат түрі атрибуттың не көрсететінін анықтайды. Си тіліне ұқсас,
логикалық, сандық айнымалылар және жолдар бар жерде, дәл осында. Атрибут түрі бойынша біз танимыз
біз немен айналысамыз және осы атрибутпен қалай жұмыс істей аламыз. Төменде біз атрибуттардың кейбір нақты түрлерін қарастырамыз. Мысалы, «қызмет туралы декларация» (0x2800), «сипаттамалық декларация» (0x2803), «дескрипторлық декларация» (0x2902).
Атрибуттың мәні - оның нақты мағынасы, тавтологияны кешіріңіз. Егер төлсипат түрі жол болса, онда атрибут мәні, мысалы, «Hello World !!!» ұраны болуы мүмкін. Егер төлсипат түрі «қызмет туралы декларация» болса, оның мәні қызметтің өзі болып табылады. Кейде бұл басқа атрибуттарды және олардың қасиеттерін қайдан табуға болатыны туралы ақпарат.
Төлсипат рұқсаттары серверге оқу немесе жазу рұқсатының рұқсат етілгенін түсінуге мүмкіндік береді.
Бұл рұқсаттар көрсеткіштің, түрдің немесе рұқсат өрісінің өзіне емес, тек төлсипат мәніне қолданылатынын ескеріңіз. Анау. егер атрибутты жазуға рұқсат етілсе, біз, мысалы, «Сәлем әлем !!!» жолын өзгерте аламыз. «Қайырлы таң» жолына. Бірақ біз жаңа жолды жазуға немесе атрибут түрін өзгертуге және жолды «қызмет декларациясы» ретінде белгілеуге тыйым сала алмаймыз. Клиент сервермен байланысқанда, клиент оның атрибуттарын сұрайды. Бұл клиентке сервер не бере алатынын білуге мүмкіндік береді. Мәндерді оқу және жазу қажет болмаса да.
Бұл қалай көрінеді
ГАТТ тұжырымдамасы атрибуттар кестесіндегі атрибуттарды өте нақты және логикалық тәртіпте біріктіру болып табылады. Төмендегі жүрек соғу жиілігі профилін толығырақ қарастырайық. Бұл кестенің сол жақ бағанасы міндетті емес. Ол бізге бұл сызықтың (атрибуттың) не екенін жай ғана сипаттайды. Барлық басқа бағандар бізге бұрыннан таныс.
Әрбір топтың жоғарғы жағында бізде әрқашан қызмет декларациясының төлсипаты болады. Оның түрі әрқашан 0x2800 және көрсеткіш кестеде қанша атрибут бар екеніне байланысты. Оның рұқсаттары әрқашан тек оқуға арналған, аутентификациясыз немесе рұқсатсыз. Бұл ұғымдар туралы сәл кейінірек айтатын боламыз. Мән қызметтің не екенін анықтайтын басқа UUID болып табылады. Кестеде мән 0x180D болып табылады, ол жүрек соғу жиілігі қызметі ретінде Bluetooth SIG арқылы анықталады.
Қызмет туралы хабарландырудан кейін сипаттама туралы хабарландыру келеді. Пішіні бойынша ол қызмет туралы декларацияға ұқсас. Оның UUID әрқашан 0x2803 және оның рұқсаттары әрқашан аутентификациясыз немесе авторизациясыз тек оқуға арналған. Кейбір деректерді қамтитын төлсипат мәні өрісін қарастырайық. Онда әрқашан көрсеткіш, UUID және сипаттар жиыны болады. Бұл үш элемент сипаттамалық мәннің кейінгі декларациясын сипаттайды. Көрсеткіш табиғи түрде атрибуттар кестесіндегі сипаттамалық мән декларациясының орнын белгілейді. UUID біз күтетін ақпарат немесе мән түрін сипаттайды. Мысалы, температура мәні, жарық қосқышының күйі немесе басқа ерікті мән. Және, ең соңында, сипаттамалық мәннің өзара әрекеттесу жолын сипаттайтын қасиеттер.
Бұл жерде бізді тағы бір тұзақ күтіп тұр. Ол атрибут рұқсаттарымен және сипаттамалық сипаттармен байланысты. Спецификациядан бит өрісінің қасиеттерінің суретін қарастырайық.
Көріп отырғаныңыздай, мұнда оқу және жазу мүмкіндіктерін қамтамасыз ететін өрістер де бар. Атрибут пен сипатқа неге бізде оқу/жазу рұқсаттары бар деген сұрақ туындауы мүмкін
сипаттамалық мән үшін оқу/жазу? Олар әрқашан бірдей болуы керек емес пе? Шындығында, сипаттамалық мәнге арналған қасиеттер шын мәнінде GATT және қолданбалы қабаттарда қолданылатын клиентке арналған ұсыныстар ғана. Бұл клиент сипаттамалық мәлімдеме атрибутынан не күтетіні туралы жай ғана кеңестер. Мұны толығырақ қарастырайық. Төлсипаттың қандай рұқсат түрлері бар?
1. Қол жеткізу рұқсаттары:
- оқу
— жазба
- оқу және жазу
2. Аутентификация рұқсаты:
- аутентификация қажет
- аутентификация қажет емес
3. Авторизацияға рұқсат:
— рұқсат қажет
- рұқсат қажет емес
Атрибут ажыратымдылығы мен сипаттамалық сипаттар арасындағы негізгі айырмашылық біріншісі серверлерге, ал екіншісі клиенттерге қолданылады. Серверге сипаттама мәнін оқуға рұқсат етілуі мүмкін, бірақ аутентификация немесе авторизация қажет болуы мүмкін. Сондықтан, клиент сипаттаманың қасиеттерін сұраған кезде, біз оқуға рұқсат етілгенін аламыз. Бірақ оқуға тырысқанда, біз қате аламыз. Сондықтан, біз рұқсаттардың сипаттарға басымдылығы туралы сенімді түрде айта аламыз. Клиент жағынан біз төлсипаттың қандай рұқсаттары бар екендігі туралы білім ала алмаймыз.
Дескриптор
Дастарханымызға оралайық. Сипаттаманың мәнін жариялағаннан кейін келесі атрибут мәлімдемелері мүмкін:
1. Сипаттамалардың жаңа декларациясы (қызмет көптеген сипаттамаларға ие болуы мүмкін)
2. Жаңа қызмет туралы декларация (кестеде олардың көпшілігі болуы мүмкін)
3. Тұтқаны жариялау
Жүрек соғу жиілігін өлшеу сипаттамасы жағдайында, біздің кестеде сипаттамалық мәннің декларациясы дескриптордың декларациясымен бірге жүреді. Дескриптор - бұл сипаттама туралы қосымша ақпараты бар атрибут. Дескрипторлардың бірнеше түрі бар. Біз олар туралы осы мақаланың екінші бөлігінде егжей-тегжейлі айтатын боламыз. Әзірге біз тек Клиент сипаттамасының конфигурация дескрипторына (CCCD) тоқталамыз. Оның 0x2902 тең UUID коды бар. Бұл дескрипторды пайдалана отырып, клиент серверде индикацияны немесе хабарландыруды қосу мүмкіндігіне ие. Олардың арасындағы айырмашылық аз, бірақ әлі де бар. Хабарлама тұтынушыдан алынғанын растауды талап етпейді. Көрсеткіш мұны талап етеді, бірақ ол қолданбалы деңгейге жетпесе GATT деңгейінде орын алады. Неге олай деп сұрайсың ба? Әттең, мен мұны білмеймін. Скандинавиялық сарапшылар хабарландыруларды пайдалануды ұсынатынын айтайын. Сонымен қатар, пакеттің тұтастығын тексеру (CRC көмегімен) екі жағдайда да орын алады.
қорытынды
Мақаланың соңында мынаны айтқым келеді. Соңғы кесте біршама шатастырады. Дегенмен, мен оны таңдадым, өйткені ол берілген , мен оған сүйенемін. Мақаланың екінші бөлігінде мен BlueTooth 4.0 спецификациясын тереңірек қарастырғым келеді. Бізді одан да дұрыс диаграммалар мен сызбалар күтіп тұр. Үшінші бөлімде мен гаджеттердің бірінен Wireshark бағдарламасы арқылы алынған журналды талдап, біз зерттеп жатқан барлық теорияны «тірі» көргім келеді.
Компаниялар тобының қызметкері
Печерских Владимир
Ақпарат көзі: www.habr.com