BLE sub mikroskopo (ATTы GATTы...)
Parto 1, superrigardo
Sufiĉe longa tempo jam pasis de kiam la unua specifo por Bluetooth 4.0 estis publikigita. Kaj, kvankam la BLE-temo estas tre interesa, ĝi ankoraŭ forpuŝas multajn programistojn pro sia komplekseco. En miaj antaŭaj artikoloj, mi ĉefe rigardis la plej malaltan nivelon, Ligo-Tavolon kaj Fizikan Tavolon. Tio permesis al ni eviti devi frekventi tiajn kompleksajn kaj konfuzajn konceptojn kiel la Atributa Protokolo (ATT) kaj la Ĝenerala Atributa Profilo (GATT). Tamen, nenie iri, sen kompreni ilin, estas neeble disvolvi kongruajn aparatojn. Hodiaŭ mi ŝatus dividi ĉi tiun scion kun vi. En mia artikolo mi fidos por komencantoj el la nordia retejo. Do ni komencu.
Kial ĉio estas tiel malfacila?
Laŭ mi, tuj estis klare, ke administri aparatojn per saĝtelefonoj estas tre promesplena kaj longdaŭra temo. Tial, ili decidis strukturi ĝin tuj kaj al la maksimumo. Por ke fabrikantoj de diversaj aparatoj ne elpensu siajn proprajn protokolojn, kiuj tiam estos malkongruaj. Tial la malfacileco. Jam en la unua etapo, ili provis elpremi ĉion eblan en la BLE-protokolon. Kaj ne gravas ĉu ĝi estos utila poste aŭ ne. Krome, ili antaŭvidis la eblecon vastigi la liston de aparatoj por la estonteco.
Ni rigardu la bildon, kie la BLE-protokola diagramo estas desegnita. Ĝi konsistas el pluraj tavoloj. La plej malalta, fizika tavolo (PHY) respondecas pri la radiokanalo de la aparato. Link Layer (LL) enhavas la tutan sekvencon de bajtoj en la elsendita mesaĝo. En antaŭaj artikoloj ni studis ĝuste tion. Host Controller Interface (HCI) estas interŝanĝa protokolo inter BLE-tavoloj aŭ fritoj se la Regilo kaj Gastiganto estas efektivigitaj sur malsamaj blatoj. Logical Link Control and Adaptation Protocol (L2CAP) respondecas pri pakaĵetformado, enkadrigo, erarkontrolo kaj pakaĵeto. Security Manager Protocol (SMP) respondecas pri ĉifrado de pakaĵoj. La Ĝenerala Aliro-Profilo (GAP) respondecas pri la komenca interŝanĝo de datumoj inter aparatoj por determini "Kiu estas kiu". Ĝi ankaŭ inkluzivas skanadon kaj reklamadon. En ĉi tiu artikolo mi koncentriĝos pri la du ceteraj partoj de la protokolo - GATT kaj ATT. GATT estas superkonstruaĵo de ATT, do ili estas proksime interplektitaj.
Por simpligi la rakonton, mi ŝatus turni al analogio. Mi aŭdis ĝin ie kaj ŝatus subteni ĝin. Pensu pri BLE-aparato kiel librobretaro kun pluraj bretoj. Ĉiu breto estas aparta temo. Ekzemple, ni havas bretojn kun sciencfikcio, matematiko kaj enciklopedioj. Sur ĉiu breto estas libroj kun difinita temo. Kaj iuj libroj eĉ havas paperajn legosignojn kun notoj. Krome, ni havas malgrandan paperan katalogon de ĉiuj libroj. Se vi memoras, lernejaj bibliotekoj estas mallarĝa skatolo kun paperaj kartoj. Kun ĉi tiu analogio, la kabineto estas la profilo de nia aparato. Bretoj estas servoj, libroj estas karakterizaĵoj, kaj la katalogo estas atributabelo. Legosignoj en libroj estas priskriboj, pri kiuj mi ankaŭ poste pli detale parolos.
Ĉiu, kiu disvolvis aparatojn, scias, ke multaj projektoj havas similajn kodojn. La fakto estas, ke multaj aparatoj havas similan funkciojn. Ekzemple, se aparatoj estas funkciigitaj per baterioj, tiam la problemo de ŝarĝo kaj monitorado de ilia nivelo estos la sama. La sama validas por sensiloj. Fakte, objekt-orientita aliro al programado "provizas la kapablon krei objektojn kiuj kombinas trajtojn kaj kondutojn en memstaran union kiu tiam povas esti recikligita". Laŭ mi, BLE provis similan aliron. Profiloj estis evoluigitaj fare de la Bluetooth Special Interest Group (SIG). Aparatoj de malsamaj fabrikistoj, kiuj havas la samajn profilojn, devus funkcii unu kun la alia sen malfacileco. Profiloj, siavice, konsistas el servoj, kaj servoj de karakterizaĵoj, kompletigitaj per priskribiloj. Ĝenerale ĝi povus aspekti jene:
Ekzemple, konsideru la profildiagramon de korfrekvenca monitoro (taŭgeca braceleto). Ĝi konsistas el du servoj kaj pluraj karakterizaĵoj. El ĝi tuj evidentiĝas la profilhierarkio. La kontrolpunkto-trajto restarigas la totalan kalorian elspezkalkulon al nulo.
1. La servo de korfrekvenco inkluzivas tri karakterizaĵojn (0x180D):
a) Deviga korfrekvenca karakterizaĵo (0x2A37)
b) Laŭvola korposensila pozicio karakterizaĵo (0x2A38)
c) Kondiĉaj karakterizaĵoj de la korfrekvenca kontrolpunkto (0x2A39)
2. Servo pri prizorgado de kuirilaro (0x180F):
a) Deviga bateria ŝarĝnivela karakterizaĵo (0x2A19)
UUID
Por ke ni unike aliru profilelementojn (servoj, karakterizaĵoj kaj priskribiloj), ni devas iel numeri ĉiujn. Tiucele oni enkondukas koncepton kiel Universally Unique ID (UUID) aŭ Universally Unique Identifier. La UUID estas indikita en la krampoj de ĉiu linio. Kaj estas unu propreco ĉi tie. Por UUID, ni decidis uzi kodon de 16 kaj 128 bitoj longa. Kial, vi demandas? En la protokolo BLE, ĉio temas pri energiŝparo. Tial, la dimensio de 16 bitoj estas sufiĉe racia. Estas neverŝajne, ke pli ol 65 mil kreiĝos baldaŭ. unikaj servoj kaj karakterizaĵoj. Nuntempe ĉio, kion ili povus esti jam kalkulitaj (memoru, de kie ĉi tio venis - "ankaŭ li kalkulis vin" :-)) Numeritaj elementoj , , и vi povas rigardi la ligilojn.
Tamen, mi pensas, ke ĉiuj memoras la historion kun 4 bajtoj da IP-adresoj en Interreto. Komence ni pensis, ke tio sufiĉas, sed nun ni ankoraŭ ne povas ŝanĝi al 6-bajta adreso. Por ne ripeti ĉi tiun eraron kaj doni liberan kondukilon al la ludemaj manoj de DIYers, SIG tuj decidis enkonduki 128-bitajn UUID-ojn. Ĉi tio persone memorigas min pri la senlicenca 433 MHz-grupo, kiu ricevis al ĉiaj Kulibins de la radiokanalo. En nia kazo, 128-bita identigilo de servoj kaj karakterizaĵoj estis elkonstruita. Ĉi tio signifas, ke ni, por niaj servoj kaj aparatoj, povas uzi preskaŭ ajnan 128-bitan valoron. Tamen, la probablo trovi la saman UUID tendencas al nulo.
Fakte, mallongaj 16-bitaj UUID-oj havas sian etendaĵon al 128-bita valoro. En la specifo, ĉi tiu etendo nomiĝas Bluetooth Base UUID kaj havas la valoron 00000000-0000-1000-8000-00805F9B34FB. Se, ekzemple, la 16-bita atributo UUID havas la valoron 0x1234, tiam la ekvivalenta 128-bita UUID havos la valoron 00001234-0000-1000-8000-00805F9B34FB. Kaj eĉ la responda formulo estas donita:
128_bit_valoro = 16_bit_valoro * 2^96 + Bluetooth_Base_UUID
Mi ne scias de kie venis ĉi tiu magia nombro. Se iu el la legantoj scias, lasu ilin skribi en la komentoj (Uzanto kun la kromnomo Sinopteek jam faris tion. Vidu la komentojn). Koncerne elpensi 128-bitajn UUIDojn, principe vi povas uzi specialan kiu faros ĝin por vi.
ATTy GATTy...
Fakte, tiam la amuzo komenciĝas. Mi memorigu vin, ke ATT baziĝas sur rilato kliento-servilo. Nun ni rigardas la servilan aparaton. Ĝi enhavas informojn kiel sensilvaloroj, lumŝaltilo statuso, lokdatenoj, ktp. Nun kiam ĉiuj "partoprenantoj en nia parado" estas numeritaj, ni devas iel meti ilin en la memoron de la aparato. Por fari tion, ni metas ilin en tabelon nomatan atributotabelo. Memoru ĉi tion bone. Ĉi tio estas la koro mem de BLE. Jen kion ni konsideros plu. Nun ni nomos ĉiun linion atributo. Ĉi tiu tablo situas profunde en la stako kaj, kiel regulo, ni ne havas rektan aliron al ĝi. Ni pravigas ĝin kaj aliras ĝin, sed kio okazas interne estas kaŝita de ni malantaŭ sep fokoj.
Ni rigardu la bildon el la specifo, sed antaŭ tio, mi ŝatus tuj atentigi pri la ofta konfuzo en terminoj, nome en priskribiloj. La rolo de la priskribilo estas kompletigi la priskribon de la trajto. Kiam necesas pligrandigi ĝiajn kapablojn, tiam oni uzas priskribilojn. Ili ankaŭ estas atributoj, kaj same kiel servoj kaj karakterizaĵoj, ili troviĝas en la atributa tabelo. Ni ekzamenos ilin detale en la dua parto de la artikolo. Tamen, foje priskriboj rilatas al la vicnumero en la atributabelo. Ĉi tio devas esti memorita. Por eviti konfuzon, ni uzos la terminon "atributo-montrilo" por ĉi tiuj celoj.
Do atributo estas diskreta valoro, kiu havas la sekvajn trajtojn asociitajn kun ĝi:
1. Atributa Tenilo estas la tabelindekso responda al la atributo
2. Atributa Tipo estas UUID, kiu priskribas ĝian tipon
3. Atributa Valoro estas la datumoj indeksitaj per la atributa montrilo
4. Atributaj Permesoj estas la parto de atributo, la permesoj, kiuj ne povas esti legitaj aŭ skribitaj per la atributa protokolo
Kiel kompreni ĉion ĉi? La atributmontrilo estas, relative parolante, ĝia nombro en nia tabelo.
Ĝi permesas al kliento referenci atributon en legi aŭ skribi petojn. Ni povas numeri niajn liniojn (atributojn) de 0x0001 ĝis 0xFFFF. En nia asocio kun la librobretaro, ĉi tiu estas la kartnumero en la papera katalogo. Simile, kiel en la biblioteka katalogo, kartoj estas aranĝitaj en kreskanta ordo de nombro. La nombro de ĉiu posta linio devas esti pli granda ol la antaŭa. Same kiel en la biblioteko, foje kelkaj kartoj perdiĝas, do ĉe ni, povas esti mankoj en la linionumerado. Ĉi tio estas permesita. La ĉefa afero estas, ke ili iras iom post iom.
La atributotipo determinas kion la atributo reprezentas. Analogie kun la C-lingvo,
kie estas buleaj, nombraj variabloj kaj ĉenoj, do ĝi estas ĉi tie. Laŭ tipo de atributo ni rekonas
kion ni traktas kaj kiel ni povas daŭrigi labori kun ĉi tiu atributo. Malsupre ni rigardos iujn specifajn specojn de atributoj. Ekzemple, "servodeklaro" (0x2800), "karakteriza deklaro" (0x2803), "priskribila deklaro" (0x2902).
La valoro de atributo estas ĝia reala signifo, pardonu la taŭtologion. Se la atributa tipo estas ĉeno, tiam la atributa valoro povas esti, ekzemple, la slogano "Saluton Mondo !!!". Se la atributtipo estas "servodeklaro", tiam ĝia valoro estas la servo mem. Kaj foje ĉi tio estas informo pri kie trovi aliajn atributojn kaj iliajn ecojn.
Atributaj permesoj permesas al la servilo kompreni ĉu legado aŭ skribaliro estas permesita.
Notu, ke ĉi tiuj permesoj validas nur por la atributvaloro, kaj ne por la montrilo, tipo aŭ permeskampo mem. Tiuj. se atributoregistrado estas permesita, tiam ni povas ŝanĝi, ekzemple, la linion "Saluton Mondo !!!" al la linio "Bonan matenon". Sed ni ne povas malpermesi skribi novan linion aŭ ŝanĝi la atributan tipon kaj nomumi la linion kiel "serva deklaro". Kiam kliento kontaktas servilon, la kliento petas ĝiajn atributojn. Ĉi tio permesas al la kliento scii kion la servilo povas provizi. Kvankam ne necesas legi kaj skribi la valorojn.
Kiel ĝi aspektas
La koncepto de GATT estas grupigi atributojn en atributotabelo kune en tre specifa kaj logika ordo. Ni rigardu pli detale la profilon de korfrekvenco sube. La plej maldekstra kolumno de ĉi tiu tabelo estas laŭvola. Ĝi simple priskribas al ni, kio estas ĉi tiu linio (atributo). Ĉiuj aliaj kolumnoj jam estas konataj al ni.
Ĉe la supro de ĉiu grupo ni ĉiam havas servodeklaratributon. Ĝia tipo ĉiam estas 0x2800, kaj la montrilo dependas de kiom da atributoj jam ĉeestas en la tabelo. Ĝiaj permesoj estas ĉiam nurlegeblaj, sen ajna aŭtentigo aŭ rajtigo. Pri ĉi tiuj konceptoj ni parolos iom poste. La valoro estas alia UUID, kiu identigas, kio estas la servo. En la Tabelo, la valoro estas 0x180D, kiu estas difinita de la Bluetooth SIG kiel servo de korfrekvenco.
Post la anonco de la servo, venas la anonco de la karakterizaĵo. Ĝi similas laŭ formo al servodeklaro. Ĝia UUID ĉiam estas 0x2803, kaj ĝiaj permesoj estas ĉiam nurlegeblaj sen ajna aŭtentigo aŭ rajtigo. Ni rigardu la kampon de Atributa Valoro, kiu inkluzivas iujn datumojn. Ĝi ĉiam enhavas montrilon, UUID kaj aron de propraĵoj. Ĉi tiuj tri elementoj priskribas la postan deklaron de la karakteriza valoro. La montrilo nature indikas la lokon de la karakteriza valordeklaro en la atributabelo. La UUID priskribas kian informon aŭ valoron ni povas atendi. Ekzemple, la temperaturvaloro, la stato de la lumŝaltilo, aŭ iu alia arbitra valoro. Kaj finfine propraĵoj, kiuj priskribas kiel la karakteriza valoro povas esti interagata kun.
Alia faŭlto atendas nin ĉi tie. Ĝi estas asociita kun atributaj permesoj kaj karakterizaj propraĵoj. Ni rigardu la bildon de la bitaj kampoj de la specifo.
Kiel vi povas vidi, estas ankaŭ kampoj ĉi tie, kiuj provizas legi kaj skribi kapablojn. Vi eble demandas, kial ni havas legi/skribi permesojn por atributo kaj posedaĵo
legi/skribi por karakteriza valoro? Ĉu ili ne ĉiam estu la samaj? La fakto estas, ke la propraĵoj por la karakteriza valoro estas fakte nur rekomendoj por la kliento uzata en GATT kaj aplikaj tavoloj. Ĉi tiuj estas simple sugestoj pri tio, kion la kliento povus atendi de la karakteriza deklara atributo. Ni rigardu ĉi tion pli detale. Kiajn permesojn havas atributo?
1. Alirpermesoj:
- legado
— rekordo
- legi kaj skribi
2. Aŭtentikiga permeso:
- aŭtentigo bezonata
- neniu aŭtentigo necesa
3. Permeso de rajtigo:
— bezonata rajtigo
- neniu rajtigo bezonata
La ĉefa diferenco inter atribua rezolucio kaj karakterizaj propraĵoj estas, ke la unuaj validas por serviloj, kaj la dua por klientoj. La servilo povas esti permesita legi la karakterizan valoron, sed povas postuli aŭtentikigon aŭ rajtigon. Tial, kiam la kliento petas la ecojn de la karakterizaĵo, ni ricevos, ke legado estas permesita. Sed kiam ni provas legi, ni ricevas eraron. Tial ni povas sekure paroli pri la prioritato de permesoj super propraĵoj. Ĉe la kliento, ni ne povas akiri scion pri kiaj permesoj havas atributo.
Priskribilo
Ni revenu al nia tablo. Post deklarado de la valoro de karakterizaĵo, la sekvaj atributodeklaroj estas eblaj:
1. Nova deklaro de karakterizaĵoj (servo povas havi multajn trajtojn)
2. Nova servo-deklaro (povas esti multaj el ili en la tabelo)
3. Deklari tenilon
En la kazo de la korfrekvenca mezura karakterizaĵo, en nia tabelo, la deklaro de la karakteriza valoro estas akompanata de la deklaro de la priskribilo. Priskribilo estas eco kun pliaj informoj pri trajto. Estas pluraj specoj de priskribiloj. Ni parolos pri ili detale en la dua parto de ĉi tiu artikolo. Nuntempe, ni nur tuŝos la Klienta Karakterizaĵa Agordo-Priskribilo (CCCD). Ĝi havas UUID egalan al 0x2902. Uzante ĉi tiun priskribilon, la kliento havas la kapablon ebligi indikon aŭ sciigon sur la servilo. La diferenco inter ili estas malgranda, sed ankoraŭ ekzistas. Sciigo ne postulas konfirmon de kvitanco de la kliento. Indiko postulas tion, kvankam ĝi okazas ĉe la GATT-nivelo, ne atingante la aplikaĵnivelon. Kial do, vi demandas? Ve, mi ne scias ĉi tion. Mi nur diru, ke nordiaj spertuloj rekomendas uzi sciigojn. Krome, kontrolado de la integreco de la pako (uzante CRC) okazas en ambaŭ kazoj.
konkludo
Fine de la artikolo mi ŝatus diri ĉi tion. La lasta tablo estas iom konfuza. Tamen mi elektis ĝin ĉar ĝi estas cedita , je kiu mi fidas. En la dua parto de mia artikolo, mi intencas pliprofundiĝi en la specifon de BlueTooth 4.0. Pli ĝustaj diagramoj kaj desegnaĵoj atendas nin tie. En la tria parto, mi ŝatus analizi la protokolon akiritan per la programo Wireshark de unu el la aparatoj kaj vidi "vive" la tutan teorion, kiun ni studas.
Dungito de la Grupo de Kompanioj
Pecherskikh Vladimir
fonto: www.habr.com