Микроскопоор BLE (ATTы GATTы…)
1-р хэсэг, тойм
Bluetooth 4.0-ийн анхны тодорхойлолт гарснаас хойш нэлээд удаан хугацаа өнгөрчээ. Хэдийгээр BLE сэдэв нь маш сонирхолтой боловч нарийн төвөгтэй байдлаасаа болж олон хөгжүүлэгчдийг хойшлуулсаар байна. Өмнөх нийтлэлүүддээ би хамгийн доод түвшин болох Link Layer болон Physical Layer-ыг голчлон авч үзсэн. Энэ нь Аттрибутын протокол (ATT) болон Ерөнхий шинж чанарын профайл (GATT) зэрэг нарийн төвөгтэй, ойлгомжгүй ойлголтуудыг ашиглахаас зайлсхийх боломжийг бидэнд олгосон. Гэсэн хэдий ч явах газар байхгүй, тэдгээрийг ойлгохгүйгээр тохирох төхөөрөмжийг хөгжүүлэх боломжгүй юм. Өнөөдөр би энэ мэдлэгийг тантай хуваалцахыг хүсч байна. Миний нийтлэлд би найдах болно Нордикийн вэбсайтаас эхлэгчдэд зориулсан. Ингээд эхэлцгээе.
Яагаад бүх зүйл ийм хэцүү байдаг вэ?
Миний бодлоор ухаалаг гар утсаараа төхөөрөмжүүдийг удирдах нь маш ирээдүйтэй, урт хугацааны сэдэв гэдэг нь шууд тодорхой болсон. Тиймээс тэд үүнийг нэн даруй, дээд зэргээр зохион байгуулахаар шийдсэн. Төрөл бүрийн гаджет үйлдвэрлэгчид өөрсдийн протоколыг гаргахгүй байхын тулд тэдгээр нь нийцэхгүй байх болно. Тиймээс хүндрэлтэй байдаг. Эхний шатанд аль хэдийн тэд BLE протоколд боломжтой бүх зүйлийг шахахыг хичээсэн. Энэ нь дараа нь хэрэг болох эсэх нь хамаагүй. Нэмж дурдахад тэд ирээдүйд төхөөрөмжүүдийн жагсаалтыг өргөжүүлэх боломжийг олгосон.
BLE протоколын диаграммыг зурсан зургийг харцгаая. Энэ нь хэд хэдэн давхаргаас бүрдэнэ. Хамгийн доод физик давхарга (PHY) нь төхөөрөмжийн радио сувгийг хариуцдаг. Link Layer (LL) нь дамжуулагдсан мессеж дэх байтуудын бүх дарааллыг агуулдаг. Өмнөх нийтлэлүүдэд бид яг үүнийг судалж үзсэн. Host Controller Interface (HCI) нь Controller болон Host нь өөр чип дээр хэрэгжсэн тохиолдолд BLE давхарга эсвэл чип хоорондын солилцооны протокол юм. Логик холбоосын хяналт ба дасан зохицох протокол (L2CAP) нь пакет үүсгэх, хүрээлэх, алдааны хяналт, пакет угсралтыг хариуцдаг. Security Manager Protocol (SMP) нь пакетуудыг шифрлэх үүрэгтэй. Ерөнхий хандалтын профайл (GAP) нь "Хэн нь хэн бэ" гэдгийг тодорхойлохын тулд төхөөрөмжүүдийн хооронд анхны өгөгдөл солилцох үүрэгтэй. Үүнд сканнердах, сурталчилгаа хийх зэрэг орно. Энэ нийтлэлд би протоколын үлдсэн хоёр хэсэгт анхаарлаа хандуулах болно - GATT болон ATT. ТХЕХ нь ATT-ийн дээд бүтэц учраас тэдгээр нь хоорондоо нягт холбоотой байдаг.
Түүхийг хялбарчлахын тулд би аналоги руу шилжихийг хүсч байна. Хаа нэгтээ сонсоод дэмжмээр байна. BLE төхөөрөмжийг хэд хэдэн тавиуртай номын тавиур гэж төсөөлөөд үз дээ. Тавиур бүр нь тусдаа сэдэв юм. Жишээлбэл, бид шинжлэх ухааны уран зохиол, математик, нэвтэрхий толь бүхий тавиуруудтай. Тавиур бүр дээр тодорхой сэдэвтэй ном байдаг. Мөн зарим номонд тэмдэглэл бүхий цаасан хавчуурга байдаг. Нэмж дурдахад бид бүх номын жижиг цаасан каталогтой. Хэрэв та санаж байгаа бол сургуулийн номын сан бол цаасан карт бүхий нарийн хайрцаг юм. Энэ зүйрлэлээр кабинет нь манай төхөөрөмжийн профайл юм. Тавиур нь үйлчилгээ, ном бол шинж чанар, каталог нь шинж чанарын хүснэгт юм. Номон дээрх хавчуурга нь тодорхойлогч бөгөөд би үүнийг дараа нь илүү дэлгэрэнгүй ярих болно.
Төхөөрөмжийг бүтээсэн хэн бүхэн олон төсөлд ижил төстэй код байдаг гэдгийг мэддэг. Баримт нь олон төхөөрөмжүүд ижил төстэй ажиллагаатай байдаг. Жишээлбэл, хэрэв төхөөрөмжүүд батерейгаар тэжээгддэг бол тэдгээрийн түвшинг цэнэглэх, хянах асуудал ижил байх болно. Мэдрэгчийн хувьд ч мөн адил. Ер нь програмчлалын объект хандалтат хандлага «предоставляет возможность создавать объекты, которые соединяют свойства и поведения в самостоятельный союз, который затем можно многоразово использовать». На мой взгляд, в BLE была предпринята попытка похожего подхода. Группой Bluetooth Special Interest Group (SIG) были разработаны профили. Устройства от разных производителей, имеющие одинаковые профили, должны без труда работать друг с другом. Профили в свою очередь состоят из сервисов, а сервисы из характеристик, дополняемых дескрипторами. В общем случае это может выглядеть так:
Для примера, рассмотрим схему профиля heart rate monitor (фитнес браслет). Он состоит из двух сервисов и нескольких характеристик. Из неё сразу становится понятна иерархия профиля. Характеристика контрольной точки сбрасывает общий подсчет расходов калорий в ноль.
1. Зүрхний цохилтын үйлчилгээ нь гурван шинж чанарыг агуулдаг (0x180D):
a) Заавал зүрхний цохилтын шинж чанар (0x2A37)
b) Нэмэлт биеийн мэдрэгчийн байрлалын шинж чанар (0x2A38)
в) Зүрхний цохилтын хяналтын цэгийн нөхцөлт шинж чанар (0x2A39)
2. Зайны засвар үйлчилгээ (0x180F):
a) Зайны цэнэгийн түвшний шинж чанар (0x2A19)
UUID
Бид профайлын элементүүдэд (үйлчилгээ, шинж чанар, тодорхойлогч) өвөрмөц байдлаар хандахын тулд тэдгээрийг бүгдийг нь ямар нэгэн байдлаар дугаарлах хэрэгтэй. Энэ зорилгоор Universal Unique ID (UUID) эсвэл Universal Unique Identifier гэх мэт ойлголтыг нэвтрүүлсэн. UUID-г мөр бүрийн хаалтанд зааж өгсөн болно. Мөн энд нэг онцлог бий. UUID-ийн хувьд бид 16 ба 128 битийн урттай код ашиглахаар шийдсэн. Яагаад чи асуув? BLE протоколд бүх зүйл эрчим хүчний хэмнэлттэй холбоотой байдаг. Тиймээс 16 битийн хэмжээ нь нэлээд үндэслэлтэй юм. Ойрын хугацаанд 65 мянгаас илүү бий болно гэдэг юу л бол. өвөрмөц үйлчилгээ, онцлог. Одоогийн байдлаар тэдний тоолж болох бүх зүйлийг аль хэдийн тооцсон байсан (энэ нь хаанаас ирснийг санаарай - "тэр чамайг бас тоосон" :-)) Дугаарласан элементүүд , , и вы можете посмотреть по ссылкам.
Однако, я думаю, все помнят историю с 4-мя байтами IP адреса в интернете. Сначала думали что хватит, а теперь всё никак не перейдем на 6-ти байтный адрес. Что бы не повторять этой ошибки и дать простор шаловливым ручкам самодельщиков, 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. Attribute Handle нь атрибутад харгалзах хүснэгтийн индекс юм
2. Attribute Type нь түүний төрлийг тодорхойлсон UUID юм
3. Attribute Value нь атрибут заагчаар индексжүүлсэн өгөгдөл юм
4. Атрибутын зөвшөөрлүүд нь атрибутын протоколыг ашиглан унших, бичих боломжгүй атрибутын хэсэг буюу зөвшөөрлүүд юм.
Энэ бүхнийг яаж ойлгох вэ? Атрибут заагч нь харьцангуйгаар манай хүснэгтэд байгаа тоо юм.
Энэ нь үйлчлүүлэгчид унших эсвэл бичих хүсэлт дэх шинж чанарыг лавлах боломжийг олгодог. Бид мөрүүдээ (атрибутууд) 0x0001-ээс 0xFFFF хүртэл дугаарлаж болно. Номын шүүгээтэй манай холбоонд энэ нь цаасан каталог дахь картын дугаар юм. Номын сангийн каталогийн нэгэн адил картуудыг тооны өсөх дарааллаар байрлуулна. Дараагийн мөр бүрийн тоо өмнөхөөсөө их байх ёстой. Номын санд байдаг шиг заримдаа зарим картууд алдагддаг тул бидэнтэй хамт шугамын дугаарлалтад цоорхой гарч болзошгүй. Үүнийг зөвшөөрдөг. Хамгийн гол нь тэд аажмаар явдаг.
Аттрибутын төрөл нь шинж чанар нь юуг төлөөлж байгааг тодорхойлдог. Си хэлтэй зүйрлэвэл,
хаана логик, тоон хувьсагч, мөр байгаа тул энд байна. Атрибут төрлөөр нь бид танина
Бид юутай тулгараад байгаа, энэ шинж чанараараа хэрхэн үргэлжлүүлэн ажиллах боломжтой. Доор бид тодорхой төрлийн шинж чанаруудыг авч үзэх болно. Жишээлбэл, "үйлчилгээний мэдэгдэл" (0x2800), "шинжлэлийн мэдэгдэл" (0x2803), "тодорхойлогчийн мэдэгдэл" (0x2902).
Атрибутын үнэ цэнэ нь түүний бодит утга учир, тавтологийг уучлаарай. Хэрэв атрибутын төрөл нь мөр бол атрибутын утга нь жишээ нь "Сайн уу Дэлхий !!!" гэсэн уриа байж болно. Хэрэв шинж чанарын төрөл нь "үйлчилгээний мэдэгдэл" бол түүний утга нь үйлчилгээ өөрөө юм. Заримдаа энэ нь бусад шинж чанарууд, тэдгээрийн шинж чанаруудыг хаанаас олох тухай мэдээлэл юм.
Аттрибутын зөвшөөрлүүд нь серверт унших, бичих хандалтыг зөвшөөрөх эсэхийг ойлгох боломжийг олгодог.
Эдгээр зөвшөөрөл нь заагч, төрөл эсвэл зөвшөөрлийн талбарт хамаарахгүй, зөвхөн атрибутын утгад хамаарахыг анхаарна уу. Тэдгээр. Хэрэв шинж чанарын бичлэгийг зөвшөөрвөл бид жишээ нь "Сайн уу Дэлхий !!!" гэсэн мөрийг өөрчилж болно. "Өглөөний мэнд" гэсэн мөрөнд. Гэхдээ бид шинэ мөр бичихийг хориглож, атрибутын төрлийг өөрчилж, мөрийг "үйлчилгээний мэдэгдэл" гэж зааж болохгүй. Үйлчлүүлэгч сервертэй холбогдох үед үйлчлүүлэгч түүний шинж чанаруудыг хүсдэг. Энэ нь үйлчлүүлэгчид сервер юу өгч чадахыг мэдэх боломжийг олгодог. Хэдийгээр энэ нь утгыг уншиж, бичих шаардлагагүй юм.
Энэ нь ямар харагдаж байна
ТХЕХ-ийн ойлголт нь шинж чанарын хүснэгтэд байгаа шинж чанаруудыг маш тодорхой бөгөөд логик дарааллаар бүлэглэх явдал юм. Доорх зүрхний цохилтын профайлыг нарийвчлан авч үзье. Энэ хүснэгтийн зүүн талын багана нь сонголттой. Энэ мөр (шинж чанар) нь юу болохыг бидэнд зүгээр л тайлбарладаг. Бусад бүх баганууд бидэнд аль хэдийн танил болсон.
Бүлэг бүрийн дээд талд бид үргэлж үйлчилгээний мэдэгдлийн шинж чанартай байдаг. Түүний төрөл нь үргэлж 0x2800 бөгөөд заагч нь хүснэгтэд аль хэдийн хэдэн шинж чанараас хамаарна. Түүний зөвшөөрөл нь ямар ч баталгаажуулалт, зөвшөөрөлгүйгээр зөвхөн унших боломжтой. Бид эдгээр ойлголтуудын талаар бага зэрэг дараа ярих болно. Утга нь үйлчилгээ гэж юу болохыг тодорхойлох өөр UUID юм. Хүснэгтэнд 0x180D утга байгаа бөгөөд энэ нь Bluetooth SIG-ээр зүрхний цохилтын үйлчилгээ гэж тодорхойлогддог.
Үйлчилгээг зарласны дараа шинж чанарын тухай зарлал ирдэг. Энэ нь үйлчилгээний мэдэгдэлтэй хэлбэрийн хувьд төстэй юм. Түүний UUID нь үргэлж 0x2803 бөгөөд зөвшөөрөл нь ямар ч баталгаажуулалт, зөвшөөрөлгүйгээр зөвхөн унших боломжтой. Зарим өгөгдлийг агуулсан Attribute Value талбарыг харцгаая. Энэ нь үргэлж заагч, UUID болон шинж чанаруудыг агуулдаг. Эдгээр гурван элемент нь шинж чанарын утгын дараагийн мэдэгдлийг дүрсэлдэг. Заагч нь шинж чанарын хүснэгт дэх шинж чанарын утгын мэдэгдлийн байршлыг заадаг. UUID нь бид ямар төрлийн мэдээлэл эсвэл үнэ цэнийг хүлээж болохыг тодорхойлдог. Жишээлбэл, температурын утга, гэрлийн унтраалгын төлөв эсвэл бусад дурын утга. Эцэст нь шинж чанарын утгыг хэрхэн харьцаж болохыг тодорхойлсон шинж чанарууд.
Энд биднийг өөр нэг бэрхшээл хүлээж байна. Энэ нь атрибутын зөвшөөрөл, шинж чанарын шинж чанартай холбоотой. Тодорхойлолтоос битийн талбарын шинж чанаруудын зургийг харцгаая.
Как видите, здесь так же присутствуют поля, дающие возможности чтения и записи. Вы можете задаться вопросом, почему у нас есть разрешения на чтение/запись для атрибута и свойства
шинж чанарын утгыг унших/бичих? Тэд үргэлж адилхан байх ёстой биш гэж үү? Үнэн хэрэгтээ шинж чанарын шинж чанарууд нь зөвхөн GATT болон хэрэглээний давхаргад ашиглагддаг үйлчлүүлэгчдэд зориулсан зөвлөмжүүд юм. Эдгээр нь тунхаглалын шинж чанараас үйлчлүүлэгч юу хүлээж болох тухай зүгээр л сануулга юм. Үүнийг илүү дэлгэрэнгүй авч үзье. Атрибут ямар төрлийн зөвшөөрөлтэй вэ?
1. Хандалтын зөвшөөрөл:
- унших
- бичлэг
- уншаад бичнэ үү
2. Разрешение аутентификации:
- баталгаажуулалт шаардлагатай
- баталгаажуулалт шаардлагагүй
3. Зөвшөөрлийн зөвшөөрөл:
- зөвшөөрөл шаардлагатай
- зөвшөөрөл шаардлагагүй
Атрибутын нарийвчлал ба шинж чанарын шинж чанаруудын гол ялгаа нь эхнийх нь серверт, сүүлийнх нь үйлчлүүлэгчдэд хамаарах явдал юм. Серверт шинж чанарын утгыг уншихыг зөвшөөрч болох ч баталгаажуулалт эсвэл зөвшөөрөл шаардаж болно. Тиймээс, үйлчлүүлэгч шинж чанарын шинж чанарыг хүсэх үед бид уншихыг зөвшөөрнө гэдгийг хүлээн авах болно. Гэхдээ бид унших гэж оролдоход алдаа гардаг. Тиймээс бид үл хөдлөх хөрөнгөөс зөвшөөрлийн тэргүүлэх ач холбогдлын талаар аюулгүй ярьж болно. Үйлчлүүлэгчийн талаас бид атрибут ямар зөвшөөрөлтэй болохыг олж мэдэх боломжгүй.
Дескриптор
Ширээндээ буцаж орцгооё. Шинж чанарын утгыг зарласны дараа дараах шинж чанарын мэдэгдлүүдийг хийх боломжтой.
1. Шинж чанарын шинэ мэдэгдэл (үйлчилгээ нь олон шинж чанартай байж болно)
2. Новая декларация сервиса (в таблице может быть их много)
3. Бариулыг зарлах
Зүрхний цохилтын хэмжилтийн шинж чанарын хувьд манай хүснэгтэд шинж чанарын утгын мэдэгдлийг тодорхойлогчийн мэдэгдэл дагалддаг. Тодорхойлогч нь шинж чанарын талаархи нэмэлт мэдээлэл бүхий шинж чанар юм. Хэд хэдэн төрлийн тодорхойлогч байдаг. Бид энэ өгүүллийн хоёрдугаар хэсэгт тэдгээрийн талаар дэлгэрэнгүй ярих болно. Одоогоор бид зөвхөн Client Characteristic Configuration Descriptor (CCCD) дээр л хүрнэ. Энэ нь 0x2902-тэй тэнцэх UUID-тэй. Энэ тодорхойлогчийг ашигласнаар үйлчлүүлэгч сервер дээрх заалт эсвэл мэдэгдлийг идэвхжүүлэх боломжтой. Тэдний хоорондох ялгаа бага боловч хэвээр байна. Мэдэгдэл нь үйлчлүүлэгчээс хүлээн авсан баталгаажуулалтыг шаарддаггүй. Хэрэглээний түвшинд хүрээгүй ч ТХЕХ-ийн түвшинд тохиолддог боловч заалт нь үүнийг шаарддаг. Яагаад тэгж байна гэж та асууж байна уу? Харамсалтай нь, би үүнийг мэдэхгүй байна. Нордикийн мэргэжилтнүүд мэдэгдэл ашиглахыг зөвлөж байна гэдгийг хэлье. Түүнчлэн, багцын бүрэн бүтэн байдлыг шалгах (CRC ашиглах) нь хоёр тохиолдолд тохиолддог.
дүгнэлт
Өгүүллийн төгсгөлд би үүнийг хэлмээр байна. Сүүлийн хүснэгт нь жаахан ойлгомжгүй байна. Гэсэн хэдий ч энэ нь өгсөн учраас би үүнийг сонгосон , на которую я опираюсь. Во второй части своей статьи я намерен углубиться в спецификацию BlueTooth 4.0. Там нас ждут более корректные схемы и рисунки. В третьей части, я хотел бы разобрать лог, полученный при помощи программы Wireshark от одного из гаджетов и увидеть «в живую» всю ту теорию, которую мы с вами изучаем.
Компанийн группын ажилтан
Печерских Владимир
Эх сурвалж: www.habr.com