Микроскопоор BLE (ATTы GATTы…)
1-р хэсэг, тойм
Анхны Bluetooth 4.0 тодорхойлолт гарснаас хойш багагүй хугацаа өнгөрчээ. BLE-ийн сэдэв нь маш сонирхолтой боловч нарийн төвөгтэй байдлаасаа болж олон хөгжүүлэгчдийг хойшлуулсаар байна. Өмнөх нийтлэлүүддээ би голчлон хамгийн доод түвшин болох Холболтын давхарга ба Физик давхаргад анхаарлаа хандуулсан. Энэ нь надад Attribute Protocol (ATP) болон Generic Attribute Profile (GATT) зэрэг төвөгтэй, ойлгомжгүй ойлголтоос зайлсхийх боломжийг олгосон. Гэсэн хэдий ч эдгээр ойлголтуудыг ойлгохгүйгээр нийцтэй төхөөрөмжийг хөгжүүлэх боломжгүй юм. Өнөөдөр би та бүхэнтэй энэ мэдлэгээ хуваалцахыг хүсч байна. Энэ нийтлэлд би найдах болно Эхлэгчдэд Нордикийн вэбсайтаас. За ингээд эхэлцгээе.
Яагаад бүх зүйл ийм төвөгтэй байдаг вэ?
Миний бодлоор ухаалаг гар утсаар төхөөрөмжүүдийг удирдах нь маш ирээдүйтэй, урт хугацааны ойлголт байсан нь шууд тодорхой болсон. Тиймээс бид үүнийг аль болох нарийвчлан зохион байгуулахаар шийдсэн. Энэ нь гаджет үйлдвэрлэгчид хожим нь үл нийцэх протоколуудыг боловсруулахаас урьдчилан сэргийлэх зорилготой байв. Энэ нь нарийн төвөгтэй байдлыг тайлбарлаж байна. Бид эхнээсээ BLE протоколд боломжтой бүх зүйлийг шахахыг хичээсэн. Тэгээд дараа нь хэрэг болох уу, үгүй юу гэдэг нь хамаагүй байсан. Ирээдүйд төхөөрөмжүүдийн жагсаалтыг өргөжүүлэх боломжийг бид бас өгсөн.
BLE протоколын диаграммыг харуулсан зургийг харцгаая. Энэ нь хэд хэдэн давхаргаас бүрдэнэ. Хамгийн доод физик давхарга (PHY) нь төхөөрөмжийн радио сувгийг хариуцдаг. Холболтын давхарга (LL) нь дамжуулагдсан мессеж дэх байт дарааллыг бүхэлд нь агуулна. Бид энэ давхаргыг өмнөх нийтлэлүүддээ судалж үзсэн. Host Controller Interface (HCI) нь Controller болон Host нь өөр чип дээр хэрэгжсэн тохиолдолд BLE давхаргууд эсвэл чипүүдийн хооронд харилцах протокол юм. Логик холболтын хяналт ба дасан зохицох протокол (L2CAP) нь пакет үүсгэх, хүрээлэх, алдааны хяналт, багцыг дахин угсрах үүрэгтэй. Хамгаалалтын менежерийн протокол (SMP) нь пакетийн шифрлэлтийг хариуцдаг. Ерөнхий хандалтын профайл (GAP) нь "хэн нь хэн бэ" гэдгийг тодорхойлохын тулд төхөөрөмжүүдийн хооронд анхны өгөгдөл солилцох үүрэгтэй. Сканнердах болон зар сурталчилгаа нь энэ профайлд багтдаг. Энэ нийтлэлд би протоколын үлдсэн хоёр хэсэг болох ТХЕХ болон ATT дээр анхаарлаа хандуулах болно. ТХЕХ нь ATT дээрх дээд бүтэц учраас тэдгээр нь хоорондоо нягт холбоотой байдаг.
Хэлэлцүүлгийг хялбарчлахын тулд би аналоги ашиглахыг хүсч байна. Би үүнийг хаа нэгтээ сонссон, цуурайтахыг хүсч байна. BLE төхөөрөмжийг хэд хэдэн тавиуртай номын тавиур гэж төсөөлөөд үз дээ. Тавиур бүр нь тусдаа сэдвийг илэрхийлдэг. Жишээлбэл, бид шинжлэх ухааны уран зохиол, математик, нэвтэрхий толь зэргийг хадгалах тавиуртай. Тавиур бүрт тухайн сэдвээр бичсэн номнууд байдаг. Зарим номонд тэмдэглэл бүхий цаасан хавчуурга хүртэл байдаг. Мөн бид бүх номны жижиг цаасан каталогтой. Хэрэв та сургуулийн номын санг санаж байгаа бол тэдгээр нь цаасан карттай нарийн шүүгээтэй адил юм. Энэ зүйрлэлээр номын тавиур нь манай төхөөрөмжийн профайл юм. Тавиур нь үйлчилгээ, ном нь шинж чанар, каталог нь шинж чанарын хүснэгт юм. Номон дээрх хавчуурга нь тодорхойлогч бөгөөд би үүнийг дараа нь илүү дэлгэрэнгүй авч үзэх болно.
Төхөөрөмжийг бүтээсэн хэн бүхэн олон төсөлд ижил төстэй код агуулагддаг гэдгийг мэддэг. Учир нь олон төхөөрөмжүүд ижил төстэй ажиллагаатай байдаг. Жишээлбэл, хэрэв төхөөрөмжүүд батерейгаар ажилладаг бол цэнэглэх, тэдгээрийн түвшинг хянах асуудал ижил байх болно. Мэдрэгчид мөн адил хамаарна. Үндсэндээ програмчлалын объект хандалтат хандлага "Энэ нь шинж чанар, зан төлөвийг нэгтгэсэн объектуудыг бий болгох, дараа нь дахин ашиглах боломжтой бие даасан нэгдэл болгох боломжийг олгодог."Миний бодлоор BLE ижил төстэй арга барилыг оролдсон. Bluetooth тусгай сонирхлын бүлэг (SIG) профайлыг боловсруулсан. Ижил профайлтай өөр өөр үйлдвэрлэгчдийн төхөөрөмжүүд бие биентэйгээ жигд ажиллах ёстой. Профайл нь эргээд үйлчилгээнүүдээс бүрдэх ба үйлчилгээ нь тодорхойлогчдын нэмэлт шинж чанаруудаас бүрддэг. Ерөнхийдөө энэ нь иймэрхүү харагдаж болно:
Жишээлбэл, зүрхний цохилт хэмжигч (биеийн тамирын бугуйвч) профайлын диаграммыг харцгаая. Энэ нь хоёр үйлчилгээ, хэд хэдэн функцээс бүрдэнэ. Профайлын шатлал нь энэ диаграмаас шууд тодорхой харагдаж байна. Шалгах цэгийн онцлог нь илчлэгийн нийт зарцуулалтын тоог тэг болгон тохируулдаг.
1. Зүрхний цохилтын үйлчилгээ нь гурван шинж чанарыг агуулдаг (0x180D):
a) Заавал зүрхний цохилтын шинж чанар (0x2A37)
b) Нэмэлт биеийн мэдрэгчийн байрлалын параметр (0x2A38)
в) Зүрхний цохилтын хяналтын цэгийн нөхцөлт шинж чанар (0x2A39)
2. Зайны засвар үйлчилгээ (0x180F):
a) Заавал батерейны түвшний шинж чанар (0x2A19)
UUID
Профайлын элементүүдэд (үйлчилгээ, шинж чанар, тодорхойлогч) өвөрмөц хандах боломжтой байхын тулд тэдгээрийг бүгдийг нь дугаарласан байх шаардлагатай. Энэ зорилгоор Universal Unique ID (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 үүсгэхийн тулд зарчмын хувьд та тусгай ашиглаж болно , энэ нь танд үүнийг хийх болно.
ATTs GATTs…
Одоо хөгжилтэй хэсэг ирлээ. ATT нь үйлчлүүлэгч серверийн харилцаанд суурилдаг гэдгийг сануулъя. Бид одоо серверийн төхөөрөмжийг харж байна. Энэ нь мэдрэгчийн утга, гэрлийн унтраалга, байршлын өгөгдөл гэх мэт мэдээллийг агуулдаг. Одоо бүх "манай парадад оролцогчид" дугаарлагдсан тул бид ямар нэгэн байдлаар төхөөрөмжийн санах ойд хадгалах хэрэгтэй. Үүнийг хийхийн тулд бид тэдгээрийг шинж чанарын хүснэгт гэж нэрлэдэг хүснэгтэд байрлуулна. Үүнийг сайтар санаарай. Энэ бол BLE-ийн зүрх сэтгэл юм. Үүнийг бид цаашид судлах болно. Одооноос эхлэн бид мөр бүрийг атрибут гэж нэрлэх болно. Энэ хүснэгт нь стекийн гүнд байрладаг бөгөөд дүрмээр бол бид түүнд шууд хандах эрхгүй. Бид үүнийг эхлүүлж, түүнд ханддаг, гэхдээ дотор нь юу болж байгаа нь нууц юм.
Тодорхойлолтоос зургийг харцгаая, гэхдээ үүнээс өмнө би нэр томьёоны нийтлэг төөрөгдөл, тухайлбал тодорхойлогчдыг тэмдэглэхийг хүсч байна. Тодорхойлогчийн үүрэг бол шинж чанарын тайлбарыг нөхөх явдал юм. Тодорхойлогчдыг түүний чадавхийг өргөжүүлэх шаардлагатай үед ашигладаг. Эдгээр нь мөн шинж чанарууд бөгөөд үйлчилгээ, шинж чанаруудын нэгэн адил шинж чанарын хүснэгтэд байрладаг. Бид тэдгээрийг нийтлэлийн хоёрдугаар хэсэгт нарийвчлан авч үзэх болно. Гэсэн хэдий ч заримдаа шинж чанарын хүснэгтийн мөрийн дугаарыг тодорхойлоход тодорхойлогчдыг ашигладаг. Үүнийг анхаарч үзэх хэрэгтэй. Төөрөгдөл гаргахгүйн тулд бид эдгээр зорилгоор "атрибут заагч" гэсэн нэр томъёог ашиглана.
Тиймээс атрибут нь дараах шинж чанаруудтай холбоотой салангид утга юм.
1. Аттрибутын бариул нь атрибуттай харгалзах хүснэгтийн индекс юм.
2. Attribute Type нь түүний төрлийг тодорхойлсон UUID юм
3. Attribute Value нь атрибут заагчаар индексжүүлсэн өгөгдөл юм.
4. Аттрибутын зөвшөөрөл гэдэг нь атрибутын протоколыг ашиглан унших, бичих боломжгүй атрибутын хэсэг юм.
Энэ бүхнийг бид хэрхэн ойлгох ёстой вэ? Атрибутын индекс нь бүдүүвчээр хэлбэл бидний хүснэгтэд байгаа тоо юм.
Энэ нь үйлчлүүлэгчид унших эсвэл бичих хүсэлт дэх шинж чанарыг лавлах боломжийг олгодог. Бид мөрүүдээ (атрибутууд) 0x0001-ээс 0xFFFF хүртэл дугаарлаж болно. Манай номын тавиурын зүйрлэлд энэ нь цаасан каталог дээрх картын дугаар юм. Номын сангийн каталогийн нэгэн адил картуудыг өсөх дарааллаар байрлуулна. Дараагийн мөр бүрийн тоо өмнөхөөсөө их байх ёстой. Номын санд картууд заримдаа алдагддагтай адил бидний мөрийн дугаарын цоорхой гарч ирдэг. Үүнийг хүлээн зөвшөөрөх боломжтой. Хамгийн гол нь тэдгээр нь өсөх дарааллаар байна.
Аттрибутын төрөл нь шинж чанар нь юуг төлөөлж байгааг тодорхойлдог. Си хэлтэй төстэй,
Boolean, тоон хувьсагч, тэмдэгт мөр байгаа газар энд адилхан байна. Атрибутын төрлөөр бид мэднэ
Бид энд юутай тулгараад байгаа бөгөөд энэ шинж чанарыг хэрхэн үргэлжлүүлэх ёстой вэ? Доор бид тодорхой шинж чанарын төрлүүдийг авч үзэх болно. Жишээлбэл, "үйлчилгээний мэдэгдэл" (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
