BLE mikroszkóp alatt (ATTы GATTы…)
1. rész, áttekintés
Elég hosszú idő telt el azóta, hogy megjelent a Bluetooth 4.0 első specifikációja. És bár a BLE téma nagyon érdekes, összetettsége miatt mégis sok fejlesztőt elriaszt. Korábbi cikkeimben elsősorban a legalacsonyabb szintet, a Link Layer-t és a Physical Layer-t néztem ki. Ez lehetővé tette számunkra, hogy elkerüljük az olyan összetett és zavaros fogalmak alkalmazását, mint az Attribute Protocol (ATT) és az Általános tulajdonságprofil (GATT). Azonban nincs hova menni, ezek megértése nélkül lehetetlen kompatibilis eszközöket fejleszteni. Ma ezt a tudást szeretném megosztani veletek. Cikkemben támaszkodni fogok kezdőknek a skandináv weboldalról. Tehát kezdjük.
Miért olyan nehéz minden?
Véleményem szerint azonnal kiderült, hogy az okostelefonon keresztüli eszközök kezelése nagyon ígéretes és hosszan tartó téma. Ezért úgy döntöttek, hogy azonnal és maximálisan strukturálják. Annak érdekében, hogy a különféle kütyük gyártói ne álljanak elő saját protokolljaikkal, amelyek ezután inkompatibilisek lesznek. Ezért a nehézség. Már az első szakaszban megpróbáltak mindent belepréselni a BLE protokollba. És nem számít, hogy később hasznos lesz-e vagy sem. Emellett lehetőséget biztosítottak a készülékek listájának a jövőbeni bővítésére.
Nézzük meg azt a képet, ahol a BLE protokoll diagramja van megrajzolva. Több rétegből áll. A legalsó, fizikai réteg (PHY) felelős az eszköz rádiócsatornájáért. A Link Layer (LL) tartalmazza a továbbított üzenet teljes bájtsorozatát. Korábbi cikkeinkben pontosan ezt tanulmányoztuk. A Host Controller Interface (HCI) egy csereprotokoll BLE rétegek vagy chipek között, ha a Controller és a Host különböző chipeken vannak implementálva. A Logical Link Control and Adaptation Protocol (L2CAP) a csomagképzésért, a keretezésért, a hibakezelésért és a csomag-összeállításért felelős. A Security Manager Protocol (SMP) felelős a csomagok titkosításáért. Az általános hozzáférési profil (GAP) felelős az eszközök közötti kezdeti adatcseréért, hogy meghatározza a „Ki kicsodát”. Ez magában foglalja a szkennelést és a reklámozást is. Ebben a cikkben a protokoll két fennmaradó részére – a GATT-ra és az ATT-re – fogok összpontosítani. A GATT az ATT felépítménye, tehát szorosan összefonódnak.
A történet leegyszerűsítése érdekében egy hasonlatra térnék ki. Valahol hallottam, és szeretném támogatni. Képzelje el a BLE készüléket több polcos könyvespolcként. Minden polc külön téma. Vannak például polcaink tudományos-fantasztikus, matematikai és enciklopédiákkal. Minden polcon egy meghatározott témájú könyv található. És néhány könyvnek még papír könyvjelzője is van jegyzetekkel. Ezen kívül van egy kis papír katalógusunk az összes könyvből. Ha emlékszel, az iskolai könyvtárak keskeny dobozok papírkártyákkal. Ezzel a hasonlattal a szekrény a készülékünk profilja. A polcok szolgáltatások, a könyvek jellemzők, a katalógus pedig egy attribútumtábla. A könyvekben lévő könyvjelzők leírók, amelyekről később részletesebben is szólok.
Aki fejlesztett már eszközöket, tudja, hogy sok projektben hasonló kódrészletek vannak. A tény az, hogy sok eszköz hasonló funkciókkal rendelkezik. Például, ha az eszközöket akkumulátorok táplálják, akkor a töltés és a szint ellenőrzése ugyanaz lesz. Ugyanez vonatkozik az érzékelőkre is. Valójában egy objektum-orientált megközelítés a programozáshoz „Lehetővé teszi olyan objektumok létrehozását, amelyek a tulajdonságokat és a viselkedést egy önálló unióvá egyesítik, amelyek aztán újra felhasználhatók”. Véleményem szerint a BLE hasonló megközelítéssel próbálkozott. A profilokat a Bluetooth Special Interest Group (SIG) fejlesztette ki. A különböző gyártóktól származó, azonos profillal rendelkező eszközöknek nehézség nélkül kell működniük egymással. A profilok pedig szolgáltatásokból és jellemzők szolgáltatásaiból állnak, amelyeket leírók egészítenek ki. Általában így nézhet ki:
Vegyük például egy pulzusmérő (fitnesz karkötő) profildiagramját. Két szolgáltatásból és több jellemzőből áll. Ebből azonnal világossá válik a profil hierarchia. Az ellenőrzőpont jellemző nullára állítja a teljes kalóriaráfordítást.
1. A pulzusszám szolgáltatás három jellemzőt tartalmaz (0x180D):
a) Kötelező pulzusjellemző (0x2A37)
b) Opcionális testérzékelő helyzetkarakterisztika (0x2A38)
c) A pulzusszám szabályozási pont feltételes jellemzői (0x2A39)
2. Akkumulátor karbantartási szolgáltatás (0x180F):
a) Kötelező akkumulátor töltöttségi szint karakterisztikája (0x2A19)
UUID
Ahhoz, hogy egyedileg hozzáférhessünk a profilelemekhez (szolgáltatásokhoz, jellemzőkhöz és leírókhoz), mindegyiket számozni kell valahogy. Ebből a célból olyan koncepciót vezetnek be, mint az univerzálisan egyedi azonosító (UUID) vagy az univerzálisan egyedi azonosító. Az UUID az egyes sorok zárójelében van feltüntetve. És van itt egy sajátosság. Az UUID esetében úgy döntöttünk, hogy 16 és 128 bites kódot használunk. Miért kérdezed? A BLE protokollban minden az energiatakarékosságról szól. Ezért a 16 bites méret meglehetősen ésszerű. Nem valószínű, hogy a közeljövőben több mint 65 ezer jön létre. egyedi szolgáltatások és jellemzők. Jelenleg mindent meg lehetett volna számolni (ne feledd, honnan jött ez - “megszámolt téged is” :-)) Számozott elemek , , и meg lehet nézni a linkeket.
Viszont szerintem mindenki emlékszik a történetre 4 bájt IP-címekkel az interneten. Először azt hittük, ez elég, de most mégsem tudunk 6 bájtos címre váltani. Annak érdekében, hogy ne ismétlődjön meg ez a hiba, és szabad utat engedjen a barkácsolók játékos kezének, a SIG azonnal a 128 bites UUID bevezetése mellett döntött. Erről személy szerint az engedély nélküli 433 MHz-es sáv jut eszembe, amit a rádiócsatornáról mindenféle Kulibin kapott. Esetünkben a szolgáltatások és jellemzők 128 bites azonosítóját tanyáztuk ki. Ez azt jelenti, hogy szolgáltatásainkhoz és eszközeinkhez szinte bármilyen 128 bites értéket használhatunk. Mindazonáltal annak a valószínűsége, hogy ugyanazt az UUID-t hozzuk létre, általában nulla.
Valójában a rövid, 16 bites UUID-ek kiterjesztése 128 bites érték. A specifikációban ennek a kiterjesztésnek a neve Bluetooth Base UUID, értéke 00000000-0000-1000-8000-00805F9B34FB. Ha például a 16 bites UUID attribútum értéke 0x1234, akkor az ezzel egyenértékű 128 bites UUID értéke 00001234-0000-1000-8000-00805F9B34FB. És még a megfelelő képlet is adott:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nem tudom, honnan jött ez a varázslatos szám. Ha valaki tudja az olvasók közül, írja meg kommentben (Egy Sinopteek becenevű felhasználó már megtette. Lásd a hozzászólásokat). Ami a 128 bites UUID-eket illeti, elvileg lehet speciálisat használni aki megteszi helyetted.
ATTy GATTy...
Valójában ezután kezdődik a móka. Hadd emlékeztesselek arra, hogy az ATT ügyfél-szerver kapcsolaton alapul. Most a szerver eszközt nézzük. Olyan információkat tartalmaz, mint az érzékelők értékei, a lámpakapcsoló állapota, a helyadatok stb. Most, hogy minden „felvonulásunk résztvevője” meg van számozva, valahogy el kell helyeznünk őket a készülék memóriájában. Ehhez egy attribútumtáblázatnak nevezett táblába helyezzük őket. Emlékezz erre jól. Ez a BLE szíve. Ezt fogjuk tovább mérlegelni. Most minden sort attribútumnak nevezünk. Ez az asztal a verem mélyén található, és általában nincs közvetlen hozzáférésünk hozzá. Inicializáljuk és elérjük, de ami belül történik, az hét pecsét mögé rejtve van előlünk.
Nézzük a specifikációból a képet, de előtte azonnal felhívnám a figyelmet a gyakori fogalomzavarra, mégpedig a leírókban. A leíró szerepe az, hogy kiegészítse a jellemző leírását. Ha bővíteni kell képességeit, akkor leírókat használnak. Ezek is attribútumok, és a szolgáltatásokhoz és jellemzőkhöz hasonlóan az attribútumtáblázatban találhatók. Ezeket a cikk második részében részletesen megvizsgáljuk. Néha azonban a leírók az attribútumtáblázat sorszámára hivatkoznak. Ezt szem előtt kell tartani. A félreértések elkerülése érdekében erre a célra az „attribútummutató” kifejezést használjuk.
Tehát az attribútum egy diszkrét érték, amelyhez a következő tulajdonságok vannak társítva:
1. Az attribútumkezelő az attribútumnak megfelelő táblázatindex
2. Az Attribútum típusa egy UUID, amely leírja a típusát
3. Az attribútumérték az attribútummutató által indexelt adat
4. Az attribútumjogosultságok az attribútum azon részei, az engedélyek, amelyek nem olvashatók vagy írhatók az attribútum protokoll segítségével
Hogyan kell mindezt megérteni? Az attribútummutató viszonylagosan a táblázatunkban szereplő száma.
Lehetővé teszi az ügyfél számára, hogy egy attribútumra hivatkozzon az olvasási vagy írási kérésekben. Sorainkat (attribútumainkat) 0x0001-től 0xFFFF-ig számozhatjuk. Nálunk a könyvespolccal ez a kártyaszám a papír katalógusban. Hasonlóan, mint a könyvtári katalógusban, a kártyák növekvő számsorrendben vannak elrendezve. Az egyes sorok számának nagyobbnak kell lennie az előzőnél. Akárcsak a könyvtárban, itt is elvész néhány kártya, így nálunk is előfordulhatnak hiányosságok a sorszámozásban. Ez megengedett. A lényeg az, hogy fokozatosan haladjanak.
Az attribútum típusa határozza meg, hogy az attribútum mit képvisel. A C nyelv analógiájára
ahol logikai, numerikus változók és karakterláncok vannak, így itt van. Attribútumtípus alapján ismerjük fel
mivel foglalkozunk és hogyan tudunk tovább dolgozni ezzel a tulajdonsággal. Az alábbiakban az attribútumok néhány konkrét típusát tekintjük meg. Például: „szolgáltatási nyilatkozat” (0x2800), „jellemző nyilatkozat” (0x2803), „leíró nyilatkozat” (0x2902).
Egy attribútum értéke a tényleges jelentése, elnézést a tautológiáért. Ha az attribútum típusa egy karakterlánc, akkor az attribútum értéke lehet például a „Hello World!!!” szlogen. Ha az attribútum típusa „szolgáltatás deklaráció”, akkor értéke maga a szolgáltatás. És néha ez arra vonatkozó információ, hogy hol találhat más attribútumokat és tulajdonságaikat.
Az attribútumjogosultságok lehetővé teszik a szerver számára, hogy megértse, hogy engedélyezett-e az olvasási vagy írási hozzáférés.
Vegye figyelembe, hogy ezek az engedélyek csak az attribútumértékre vonatkoznak, magára a mutatóra, típusra vagy engedélymezőre nem. Azok. ha engedélyezett az attribútum rögzítése, akkor módosíthatjuk például a „Hello World !!!” sort. a „Jó reggelt” sorba. De nem tilthatjuk meg egy új sor írását, nem változtathatjuk meg az attribútum típusát, és nem jelölhetjük ki a sort „szolgáltatási nyilatkozatként”. Amikor egy kliens kapcsolatba lép egy szerverrel, a kliens lekéri annak attribútumait. Ez lehetővé teszi az ügyfél számára, hogy tudja, mit tud nyújtani a szerver. Bár nem szükséges olvasni és írni az értékeket.
Hogy néz ki
A GATT koncepciója az attribútumok attribútumok csoportosítása egy attribútumtáblázatban, nagyon specifikus és logikus sorrendben. Nézzük meg közelebbről az alábbi pulzusprofilt. A táblázat bal szélső oszlopa nem kötelező. Egyszerűen leírja számunkra, hogy mi ez a vonal (attribútum). Az összes többi rovat már ismerős számunkra.
Minden csoport tetején mindig van egy szolgáltatás deklarációs attribútum. Típusa mindig 0x2800, és a mutató attól függ, hogy hány attribútum szerepel már a táblázatban. Engedélyei mindig csak olvashatóak, hitelesítés vagy felhatalmazás nélkül. Ezekről a fogalmakról egy kicsit később fogunk beszélni. Az érték egy másik UUID, amely azonosítja a szolgáltatást. A táblázatban az érték 0x180D, amelyet a Bluetooth SIG pulzusszám szolgáltatásként határoz meg.
A szolgáltatás bejelentését követően jön a jellemző bejelentése. Formáját tekintve hasonló a szolgáltatási nyilatkozathoz. Az UUID-je mindig 0x2803, és az engedélyei mindig csak olvashatók, hitelesítés vagy felhatalmazás nélkül. Nézzük meg az Attribútumérték mezőt, amely néhány adatot tartalmaz. Mindig tartalmaz egy mutatót, egy UUID-t és egy tulajdonságkészletet. Ez a három elem a jellemző érték utólagos deklarálását írja le. A mutató természetesen a jellemző érték deklarációjának helyét jelöli az attribútumtáblázatban. Az UUID leírja, hogy milyen típusú információra vagy értékre számíthatunk. Például a hőmérséklet értéke, a lámpakapcsoló állapota vagy más tetszőleges érték. És végül a tulajdonságok, amelyek leírják, hogyan lehet a karakterisztikus értékkel kölcsönhatásba lépni.
Itt egy újabb buktató vár ránk. Attribútumengedélyekkel és jellemző tulajdonságokkal van társítva. Nézzük meg a bitmező tulajdonságainak képét a specifikációból.
Mint látható, itt is vannak olyan mezők, amelyek olvasási és írási lehetőségeket biztosítanak. Kíváncsi lehet, miért van olvasási/írási jogosultságunk az attribútumokhoz és a tulajdonságokhoz
jellemző értékhez olvasni/írni? Nem kellene mindig egyformának lenniük? Az a tény, hogy a jellemző érték tulajdonságai valójában csak ajánlások a GATT-ban és az alkalmazási rétegekben használt kliens számára. Ezek egyszerűen tippek arra vonatkozóan, hogy az ügyfél mit várhat a jellemző deklarációs attribútumtól. Nézzük ezt részletesebben. Milyen típusú jogosultságokkal rendelkezik egy attribútum?
1. Hozzáférési engedélyek:
- olvasás
— rekord
- Olvass és írj
2. Hitelesítési engedély:
- azonosítás szükséges
- nincs szükség hitelesítésre
3. Engedélyezési engedély:
— engedély szükséges
- nincs szükség engedélyre
A fő különbség az attribútumfelbontás és a jellemző tulajdonságok között az, hogy az előbbi a szerverekre, az utóbbi a kliensekre vonatkozik. A kiszolgáló számára engedélyezhető a jellemző érték beolvasása, de hitelesítést vagy engedélyezést igényelhet. Ezért amikor az ügyfél kéri a jellemző tulajdonságait, azt kapjuk, hogy az olvasás engedélyezett. De amikor megpróbálunk olvasni, hibát kapunk. Ezért nyugodtan beszélhetünk az engedélyek elsőbbségéről a tulajdonságokkal szemben. Az ügyféloldalon nem szerezhetünk tudomást arról, hogy egy attribútum milyen jogosultságokkal rendelkezik.
Leíró
Térjünk vissza az asztalunkhoz. Egy jellemző értékének deklarálása után a következő attribútumdeklarációk lehetségesek:
1. Új jellemzők deklarációja (egy szolgáltatásnak sok jellemzője lehet)
2. Új szolgáltatási nyilatkozat (a táblázatban sok is lehet)
3. Fogantyú bejelentése
A pulzusmérési karakterisztika esetében táblázatunkban a jellemző érték deklarációjához a leíró megadása társul. A leíró egy attribútum, amely további információkat tartalmaz egy jellemzőről. Többféle leíró létezik. A cikk második részében részletesen fogunk beszélni róluk. Egyelőre csak a Client Characteristic Configuration Descriptor-t (CCCD) fogjuk érinteni. UUID-je 0x2902. Ezzel a leíróval a kliens képes jelzést vagy értesítést engedélyezni a szerveren. Kicsi a különbség köztük, de akkor is. Az értesítéshez nem szükséges az ügyféltől az átvétel megerősítése. A jelzés megköveteli ezt, bár ez GATT szinten történik, nem éri el az alkalmazási szintet. Miért, kérdezed? Jaj, ezt nem tudom. Csak annyit mondok, hogy a skandináv szakértők az értesítések használatát javasolják. Ezenkívül mindkét esetben megtörténik a csomag integritásának ellenőrzése (CRC használatával).
Következtetés
A cikk végén ezt szeretném elmondani. Az utolsó táblázat kissé zavaros. Én azonban ezt választottam, mert megadatott , amelyre támaszkodok. Cikkem második részében a BlueTooth 4.0 specifikációjával kívánok mélyebben foglalkozni. Ott még korrektebb diagramok, rajzok várnak ránk. A harmadik részben szeretném elemezni az egyik kütyüből a Wireshark programmal kapott naplót, és „élőben” látni az összes általunk vizsgált elméletet.
A cégcsoport alkalmazottja
Pecherskikh Vladimir
Forrás: will.com