BLE միկրոսկոպի տակ (ATT-ներ GATT-ներ…)
Մաս 1, ակնարկ
Ո Already quite some time has passed since the first specification for Bluetooth 4.0 came out. While the topic of BLE is very interesting, it still deters many developers due to its complexity. In my previous articles, I primarily dealt with the lowest levels of the Link Layer and Physical Layer. This allowed us to avoid tackling such complex and convoluted concepts as the Attribute Protocol (ATT) and the Generic Attribute Profile (GATT). However, there is no way around it; without understanding them, it's impossible to develop compatible devices. Today I would like to share this knowledge with you. In my article, I will rely on Nordic-ի սկզբնակների համար։ Ուրեմն, եկեք սկսենք։
Ինչո՞ւ ամեն բան այնքան դժվար է:
Իմ կարծիքով, անմիջապես պարզ էր, որ սարքերի կառավարման թեման սմարթֆոնների միջոցով՝ շատ հեռանկարային և երկարատև է: Այս պատճառով այն պետք է համակարգել հնարավորինս արդյունավետ: Որպեսզի տարբեր սարքերի արտադրողները չստեղծեն իրենց՝ այնքան էլ անհամատեղելի պրոտոկոլները, որոնց ձերից հետո դժվար կլինի օգտագործել: Նրա բարդությունը հենց այսպիսինն է: ԱլիքըBLE-ի պրոտոկոլի առաջին քայլից փորձել են ներառել ամեն բան, ինչ հնարավոր էր: Եվ կարևոր չէ, թե դա հետագայում անհրաժեշտ կլինի, թե ոչ: Բացի այդ, նախատեսել էին ապագայի սարքերի ցանկը ընդլայնելու հնարավորությունները:
Մ vamos դեպի նկարին, որտեղ ներկայացված է BLE պրոտոկոլի սխեման։ Դա բաղկացած է մի քանի շերտերից: Դրա ամենացածր, ֆիզիկական շիճուկ (PHY) պատասխանատու է սարքի ռադիոալիքի համար: Link Layer (LL) պարունակում է փոխանցվող հաղորդագրության բոլոր բայթերի հաջորդականությունը: Նախորդ հոդվածներում մենք ուսումնասիրեցինք հենց դա: Host Controller Interface (HCI) — դա շերտերի կամ BLE չիպերի միջև փոխանակման պրոտոկոլն է, եթե Controller և Host տարբեր չիպերում են: Փաթեթների ձևավորման, կադրերի բաժանման, սխալների վերահսկման և փաթեթների հավաքման համար պատասխանատու է Logical Link Control and Adaptation Protocol (L2CAP): Փաթեթների անդրադարձի համար պատասխանատու է Security Manager Protocol (SMP): Գլխավոր Արձանագրության սահմանված գիծը (GAP) պատասխանատու է սարքերի միջև տվյալների առաջին փոխանակման համար՝ «Ո՞վ է ով» գիտելու համար: Դրան նաև պատկանում են սկանավորում և գովազդ: Այս հոդվածում ես կկենտրոնանամ պրոտոկոլի մնացած երկու հատվածների վրա՝ GATT և ATT: GATT-ը ATT-ի վերին շերտն է, այնպես որ նրանք խորը իրար հետ կապված են։
Մասնավորացնելու համար, ես կցանկանայի դիմել մի analojiի: Ես դա որտեղ որ լսել եմ և ուզում եմ աջակցել: Կարծեք BLE устройството որպես գրքերի գրապահարան, որտեղ կան մի քանի շելֆեր: Յուրաքանչյուր շելֆ բարձրացնում է առանձին թեմա: Օրինակ, մեզ մոտ կան շելֆեր ֆանտաստիկայի, մաթեմատիկայի, իմացության մասին: Յուրաքանչյուր շելֆում կան գրքեր, որոնք ունեն նշված թեման: Եվ որոշ գրքերի մեջ նույնիսկ կան թղթե նշումներ: Բացի այդ, մեզ մոտ կա փոքր թղթային կատալոգ բոլոր գրքերի համար: Եթե հիշում եք դպրոցական գրադարանները՝ դա նեղ տուփ է թղթե քարտերով: Այդ analojiի համաձայն, գրապահարանն է մեր սարքի պրոֆիլը: Շելֆերը՝ ծառայությունները, գրքերը՝ հատկանիշները, իսկ կատալոգը՝ ատրիբուտների աղյուսակը: Գրքերում են նշումները՝ դա տնտնելուց առաջ վերագրված քննարկման միտումն է:
Բոլորը, ովքեր սարքեր են մշակել, գիտեն, որ շատ նախագծերում կան նմանատիպ կոդի կտորներ: Պատճառը նրանում է, որ շատ սարքեր ունեն նման գործառույթներ: Օրինակ, եթե սարքերը աշխատում են բետոնով, ապա նրանց լիցքավորման և մակարդակի վերահսկման խնդիրը նույնն կլինի: Նույնը վերաբերում է նաև սենսորներին: Ի դեպ, օբյեկտно-հասկանալի մոտեցումը ծրագրազրկման մեջ «ներդնում է այնպիսի սարքերի ստեղծման հնարավորություն, որոնք միավորում են հատկությունները և վարքերը ինքնուրույն միավորի, որը հետո կարելի է բազմիցս օգտագործել». Իմ կարծիքով, BLE-ում կատարվել է նման մոտեցման փորձ: Bluetooth Special Interest Group (SIG) խմբի կողմից մշակվել են պրոֆիլներ: Տարբեր արտադրողների սարքեր, որոնք ունեն նույն պրոֆիլները, պետք է խնդիր չունենան միմյանց հետ աշխատելու: Պրոֆիլները ստիպված են ծառայություններից, իսկ ծառայություններ՝ հատկանիշներից, լրացված դեսկրիպտորներով: Ընտրովի դեպքում դա կարող է выглядеть так:
Օրինակ, դիտարկենք սրտի ռիթմի մոնիտորի պրոֆիլը (ֆիթնես բրասլետ): Այն կազմված է երկու ծառայությունից և մի քանի հատկանիշներից: Դրանից անմիջապես երևում է պրոֆիլի հիերարխիան: Հատկանիշը ընդհանուր հաշվարկը իջեցնում է ծախսված կալորիաների քանակը զրոյական:
1. Սրտային ռիթմի ծառայությունը ներառում է երեք հատկանիշ (0x180D):
ա) Անհրաժեշտ հատկանիշ սրտային ռիթմի հաճախությունը (0х2A37)
բ) Օպցիոնալ հատկանիշ մարմնի սենսորի դիրքը (0x2A38)
գ) Շատոնական հատկանիշ սրտային ռիթմի контрольային կետը (0x2A39)
2. Բետոնային ծառայությունը (0x180F):
ա) Անհրաժեշտ հատկանիշ բետոնի լիցքի մակարդակը (0x2A19)
UUID
Այն բանի համար, որպեսզի մենք կարողանանք հստակ դիմել պրոֆիլի տարրերին (ծառայություններին, բնութագրերին և նկարագրություններին) անհրաժեշտ է դրանք ինչ-որ կերպ համարնալ: Այս նպատակով մտցվում է այնպիսի հասկացություն, ինչպիսին է Universally Unique ID (UUID) կամ Համահամօրինակ uniek identifier: Օգտագործվող UUID-երը նշված են յուրաքանչյուր տողի մեջ: Եվ այստեղ կա մեկ առանձնահատկություն: UUID-ի համար որոշում է ընդունվել օգտագործել 16- և 128-բիթանոց կոդ: Ինչու, կհ спросեք: BLE պրոտոկոլում ամեն ինչ ենթակա է էներգիայի խնայողությանը: Հետևաբար, 16 բիթանոց չափը լիովին արդարացված է: Երկու 65 հազարից ավել уникալ ծառայությունների և բնութագրերի ստեղծումը դժվար է սպասվում: Այս պահին, ինչ հնարավոր էր, արդեն հաշվարկվել է (հիշեք, որտեղից է սա՝ «նա ձեզ ևս հաշվել է» :-)) Համարտացած տարրեր , , և կարող եք տեսնել հղումներով:
Հ然而, ես կարծում եմ, որ բոլորը հիշում են պատմությունը ինտերնետում 4-որդ բիթ IP դիմումների մասին: սկզբում կարծում էին, որ դա բավական է, իսկ այժմ մինչև հիմա չենք անցնում 6-բիթանոց հասցեին: Բենցապն չկրկնել այդ սխալը և չմարվելու համար, SIG-ը անմիջապես որոշել է ներմուծել նաև 128-բիթանոց UUID-ներ: Սա ինձ հիշեցնում է անլիցենզիա ուղղություն 433ՄՀց, որը տրված էր տարբեր վարպետներին ռադիոալիքի: Մեր պարագայում, 128-բիթանոց ծառայությունների և բնութագրերի նույնականացուցիչը տրված է: Դա նշանակում է, որ մենք մեր ծառայությունների և սարքերի համար կարող ենք օգտագործել prácticamente οποιοδήποτε 128 բիթանոց արժեք: Ինչպես կամ միևնույն UUID գտնելը մոտ մոտ 0-ի:
Իրապես, կարճ 16-բիթանոց UUID-ները ունեն իրենց ընդլայնումը 128-բիթանոց արժեքի: Նորմայում այս ընդլայնումը կոչվում է Bluetooth Base UUID և ունի 00000000-0000-1000-8000-00805F9B34FB արժեքը: Ալևս, օրինակ՝ 16-բիթանոց UUID-ի արժեքը 0x1234, ապա համապատասխան 128-բիթանոց UUID-ն կունենա 00001234-0000-1000-8000-00805F9B34FB արժեքը: Եվ կա համապատասխան բանաձևը:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Այս ազատական թիվը որտեղից է, ես չգիտեմ: Եթե որևէ մեկի ընթերցողներից դա գիտի՝ թող գրի մեկնաբանություններում (Sinopteek-ի անունով օգտվողն արդեն դա արել է: Տեսեք մեկնաբանությունները): Ինչ վերաբերում է 128-բիթանոց UUID-ների մտերմությանը, ապա փաստացի կարելի է օգտվել հատուկ , որը կանի դա ձեր փոխարեն:
ATT-ները GATT-ները…
Այժմ սկսվում է ամենահետաքրքիրը։ Ներկայացնում եմ, որ ATT-ը հիմնադրված է հաճախորդ-ծառայում հարաբերությունների վրա։ Այժմ մենք քննարկում ենքשרת կտարը։ Այն պարունակում է նման տեղեկություններ, ինչպիսիք են սենսորների արժեքները, լույսի անջատիչի վիճակը, տեղակայման տվյալները և այլն։ Որպեսզի մեր «երեկոյի մասնակիցները» ստանան համարը, անհրաժեշտ է ինչ-որ կերպ տեղադրել դրանք սարքի հիշողության մեջ։ Այս məqsով մենք դրանք տեղադրում ենք հատկությունների աղյուսակում։ Հիշեք սա լավ։ Սա BLE-ի սիրտն է։ Եվ հենց դա ենք մենք հետագայում քննարկելու։ Այժմ մենք կնվիրենք յուրաքանչյուր տող հատկություն։ Այս աղյուսակը գտնվում է стекի խորքում և սովորաբար մենք չունենք դրա ուղիղ մուտք։ Մենք այն ներմուծում ենք և դիմում ենք դրա վրա, բայց ինչի մեջ տեղի է ունենում ներքին, մեզ ծածկված է յոթ կնիքների հետևում։
Նայենք նկարին, որը ներկայացված է մասնագիտական տեքստում, սակայն նախքան դա, ուզում եմ ուշադրություն դարձնել տերմինների հաճախակի շփոթության վրա, իսկապես կարգավորմանն։ Կարգավորման դերն է լրացնել հատկության նկարագրությունը։ Երբ անհրաժեշտ է ընդլայնել դրա հնարավորությունները, ապա կիրառվում են կարգավորումները։ Նաև նրանք հատկություններ են, և հավասարապես, ծառայությունների և հատկությունների հետ միասին, գտնվում են հատկությունների աղյուսակում։ Մենք մանրամասնորեն կքննարկենք դրանք հոդվածի երկրորդ մասում։ Սակայն երբեմն կարգավորումներ անվանում են տրամադրական շարք աղյուսակում։ Սա պետք է հիշել։ Մենք, որպեսզի չշփոթվենք, այս նպատակների համար օգտագործելու ենք «հատկության նշման» տերմինը։
Այսպիսով, հատկություն՝ այսինքն, դա դիսկրետ արժեք է, որը ունի հետևյալ հատկությունները, որոնք կապված են դրա հետ՝
1. Հատկության նշում (Attribute Handle)՝ սա աղյուսակի ինդեքսն է, որը համապատասխանում է հատկությանը
2. Հատկության տեսակ (Attribute Type)՝ սա UUID-ն է, որը նկարագրում է դրա տեսակը
3. Հատկության արժեք (Attribute Value)՝ սա տվյալներն են, որոնք նշվում են հատկության նշմանով
4. Հատկությունների թույլատրություններ (Attribute Permissions)՝ սա հատկության մի մասն է, թույլատրություններ, որոնք չեն կարող ընթերցվել կամ գրանցվել, օգտագործելով հատկային նախատիպերը
Ինչպե՞ս հասկանալ սա։ Հատկության նշման ենթադրվում է, որ սա, պայմանականաբար ասած, նրա համարը մեր աղյուսակում։
Այն թույլ է տալիս հաճախորդին վերագրանցել հատկությունը ընթերցման կամ գրելու հարցներում։ Մենք կարող ենք թվարկել մեր տողերը (հատկություններ) 0x0001-ից մինչև 0xFFFF։ Մեր գրադարանային համակարքի մեջ սա համարը քարտի կողմից թղթային կատալոգում։ Անալոգիկից, գրադարանի կատալոգում, քարտերը տեղադրվում են համարը աճող կարգով։ Ամեն հաջորդ տողի համարը պետք է լինի նախորդից մեծ։ Ինչպես գրադարանում, երբեմն որոշ քարտեր են կորցվում, այնպես էլ մեզ՝ տողերի թվագրվածությամբ կարող են լինել անդադար։ Սա թույլատրելի է։ Կարևորը, որ նրանք ունենան աճող հերթականություն։
Հատկության տեսակն սահմանում է, թե ինչու է այս հատկությունը ներկայացնում։ Անալոգիկին՝ C լեզվի համեմատ,
որտեղ կան բուլևներ, թիվային փոփոխականներ և ստրինգներ, այստեղ նույնպես: Атрибутների տեսակից մենք իմանում ենք
թե ինչի հետ ենք գործ ունենալու և ինչպես պետք է շարունակել այդ атрибուտով: Ուղևորվենք որոշ հատուկ атрибուտների տեսակների մասին: Օրինակ ՝ «ծառայության հայտարարություն» (0х2800), «հայտարարության բնութագիրը» (0х2803), «դեսկրիպտորի հայտարարություն» (0x2902):
Ատրիբուտի արժեքը՝ հենց դա է նրա արժեքը, ներեցեք մտերմության համար: Եթե ատրիբուտի տեսակը աստիճանում է, ապա ատրիբուտի արժեքը կարող է լինել, օրինակ՝ կարգախոս «Hello World !!!». Եթե ատրիբուտի տեսակը «Ծառայության հայտարարություն» է, ապա նրա արժեքը հենց ծառայությունն է: Երբեմն, դա տեղեկություն է այն մասին, թե որտեղ են գտնվում մյուս ատրիբուտներն ու դրանց հատկությունները:
Ատրիբուտների թույլատրումը թույլ է տալիս սերվերին հասկանալ, արդյոք ընթերցման կամ գրելու մուտքը թույլատրվում է:
Ուշադրությունը, որ այս թույլատրումները կիրառվում են միայն ատրիբուտի արժեքի վրա, այլ ոչ թե մատնանշիչի, տեսակի և ինքնին թույլատրությունների դաշտի: Օրինակ, եթե թույլատրվում է ատրիուբտի գրումը, ապա կարող ենք փոխել, ասենք, այն «Hello World !!!» շարքից «Good morning» շարք: Բայց չենք կարող արգելել նոր շարքի գրումը կամ փոխել ատրիբուտի տեսակը և նշանակել շարքը որպես «ծառայության հայտարարություն»: Գրանցվելու դեպքում, օգտագործողը հարցնում է սերվերին նրա ատրիբուտները: Սա թույլ է տալիս օգտագործողին իմանալ, թե ինչ է կարող տրամադրել սերվերը: Չկան պարտադիր տեղեկություններ գրելու և ընթերցելու արժեքները:
Ինչպես է դա երևում
GATT-ի կոնցեպտը ոգեշնչել ատրիբուտները խմբավորել կանգառների ջրպատի մեջ՝ շատ հատուկ և տրամաբանական կարգով: Դавайте ավելի մանրամասն ուսումնասիրենք սիրտ-գործողությունների պրոֆիլը, որը ներկայացված է ստորև: Այս կանգառի ամենաբարի սյունակը պարտադիր չէ: Այն պարզապես նկարագրում է մեզ, թե ինչ է այս շարք (ատրիբուտ): Բոլոր մյուս սյունակները արդեն ծանոթ են մեզ:
Յուրաքանչյուր խմբի վերևում մենք միշտ ունենք ծառայության հայտարարության ատրիբուտ: Նրա տեսակը միշտ համապատասխանում է 0x2800, իսկ մատնանշիչը կախված է նրանից, թե քանի ատրիբուտ արդեն կա կանգառում: Նրա թույլատրությունները միշտ հասանելի են միայն ընթերցման համար, առանց որևէ վավերացման կամ թոյլտրվածքի: Այս հասկացությունների մասին մենք կխոսենք稍后: Արժեքը՝ ուրիշ UUID, բնորոշող, թե որն է այս ծառայությունը: Կանգառի արժեքը 0x180D է, որը Bluetooth SIG-ը սահմանում է որպես սիրտ-գործողությունների ծառայություն:
Սպ השירות հայտարարվել համաձայն բնութագրերին նույնպես ազդարարում է. Դրա UUID-ն միշտ կլինի 0x2803, իսկ թույլտվությունները միշտ հասանելի են միայն կարդալու համար առանց որեւէ վերընթերցում կամ հեղինակություն: Եկեք նայենք Attribute Value դաշտին, որը ներառում է որոշ տվյալներ: Այն միշտ պարունակում է ցուցիչ, UUID եւ գույքագրի հավաքածու: Այս երեք բաղադրիչներն ինձ մնում են բնութագրային արժեքի հայտարարության: Ցուցիչը բնականաբար ցույց է տալիս, թե որտեղ է հայտարարում բնութագրային արժեքը կենդանի գծում: UUID-ն նկարագրում է, թե ինչպիսի տեղեկատվություն կամ արժեք կարող ենք ակնկալել: Օրինակ, ջերմաստիճանի արժեք, լույսի սեղանելու վիճակը կամ որեւէ այլ պատահական արժեք: Եվ վերջապես առանձնահատկությունները, որոնք նկարագրում են, թե ինչպես կարելի է փոխհամագործակցել բնութագրային արժեքի հետ.
Այստեղ մեզ սպասվում է մեկ այլ դժվարություն: Այն կապված է հատկությունների թույլտվություններով եւ բնութագրերի հատկություններով: Եկեք նայենք հատկությունների բիթային տեղակալման նկարին սփեցիֆիկացիայից.
Ինչպես տեսնում եք, այստեղ նույնպես առկա են կարդալու եւ գրելու հնարավորությունները: Դուք կարող եք հարց բարձրացնել, թե ինչու ունենք կարդալու/գրելու թույլտվություններ հատկության եւ բնութագրի արժեքի համար? Չե՞ն նրանք միշտ պետք է նույնը լինեն? Բանը այն է, որ բնութագրային արժեքի հատկությունները, ըստ էության, միայն առաջարկություններ են հաճախորդի համար, որոնք օգտագործվում են GATT եւ կիրառական շերտեր: Սա պարզապես տողեր է, թե ինչ կարող է ակնկալել հաճախորդը բնութագրի հատկությունից: Եկեք լրիվ հասկանանք դրա հետ կապված: Ինչպիսի ստորագրություններ կան հատկությունում:
1. Տեղեկատվության թույլտվություններ:
— կարդալու
— գրելու
— կարդալու եւ գրելու
2. Պաշտպանության թույլտվություն:
— պահանջվում է պաշտպանություն
— պաշտպանությունը անհրաժեշտ չէ
3. Վավերացման թույլտվություն:
— անհրաժեշտ է վավերացում
— վավերացումը անհրաժեշտ չէ
Պետք է նշել, որ հատկությունների թույլտվությունների գլխավոր տարբերությունը բնութագրերի առանձնահատկությունների հետ է, որ առաջինները վերաբերում են սերվերներին, իսկ երկրորդները հաճախորդներին: Սերվերի վրա կարող է լինել թույլված բնութագրային արժեքի կարդալու, բայց այդ դեպքում կարող է լինել պաշտպանման կամ վավերացման պահանջ: Այդ պատճառով, երբ հաճախորդը հարցնում է բնութագրի հատկությունները, մենք կստանանք, որ կարդալու թույլված է: Բայց երբ փորձենք կարդալ, կստանանք սխալ: Այսպիսով, կարելի է առանց երկիմաստության ասել, որ թույլտվությունների առաջնահերթությունը գերազանցում է մարմնավորումների: Գիտելիքը, թե ինչպիսի թույլտվություններ ունի հատկությունը, մենք հաճախորդի ձեռքից չենք կարող ստանալ.
Դեսկրիպթոր
Վերադառնանք մեր աղյուսակին: Բնութագրային արժեքի հայտարարումից հետո հնարավոր են հետեւյալ հատկությունների հայտարություններ:
1. Նոր բնութագրի հայտարարում (ծառայում է բազմաթիվ բնութագրեր)
։
2. Նոր ծառայության հայտարարություն (սեղանին կարող է լինել դրանք շատ)
3. Դեսկրիպտորի հայտարարություն
Սրտի անձրևների հաճախության չափման բնութագրի դեպքում, մեր սեղանից, բնութագրի արժեքի հայտարարությունը ուղեկցվում է դեսկրիպտորի հայտարարությամբ: Դեսկրիպտորը՝ հատկությամբ լրացուցիչ impormasyon այս բնութագրի մասին: Կկա մի քանի տեսակ դեսկրիպտորների: Այն մասին մենք մանրամասնորեն կխոսենք հոդվածի երկրորդ մասում: Այժմ մենք անդրադարձնենք միայն հաճախականության բնութագրի կոնֆիգուրացիայի դեսկրիպտորին (Client Characteristic Configuration Descriptor — CCCD): Այն ունի UUID 0х2902: Այս դեսկրիպտորի միջոցով հաճախորդը կարող է ակտիվացնել սերվերում ինդիկացիա կամ նոթիֆիկացիա: Դրանց միջև տարբերությունը փոքր է, բայց այն առկա է: Նոթիֆիկացիան չի պահանջում հաճախորդի կողմից ստացման հաստատում: Ինդիկացիան դրա կարիքն ունի, թեև դա տեղի է ունենում GATT մակարդակում, չհասնելով կիրառման մակարդակ: Ինչու՞ այնպես, հարցրեք դուք? Ափսոս, որ դա ինձ հայտնի չէ: Պարզ միայն, որ Nordic-ի մասնագետները խորհուրդ են տալիս օգտագործել նոթիֆիկացիա: Հետագայում, որ փաթեթի ամբողջականության ստուգումը (CRC-ի միջոցով) տեղի է ունենում երկու դեպքերում էլ:
Ավարտ
Հոդվածի վերջին մասում ուզում եմ նշել հետևյալը: Վերջին սեղանը մի sedikit բարդ է: Սակայն ես կանգ առա դրա վրա, քանի որ այն ներկայացված է , որի վրա հիմնվում եմ: Հոդվածիս երկրորդ մասում մտադիր եմ խորանալ BlueTooth 4.0 հատկանիշների վերաբերյալ: Այնտեղ մեզ սպասվում են ավելի ճշգրիտ սխեմաներ և նկարներ: Երրորդ մասում, ես կցանկանայի ուսումնասիրել լոգը, որը ստացվել է Wireshark ծրագրի միջոցով մեկ գաջետից և տեսնել «կենդանի» տերմինալը, որը մենք ուսումնասիրում ենք:
Քննարկման խմբի աշխատակից
Պեչերսկի Վլադիմիր
Ընտանիք: habr.com
