අන්වීක්ෂයක් යටතේ BLE (ATTы GATTы...)
1 කොටස, දළ විශ්ලේෂණය
බ්ලූටූත් 4.0 සඳහා පළමු පිරිවිතර නිකුත් කර බොහෝ කාලයක් ගත වී ඇත. තවද, BLE මාතෘකාව ඉතා සිත්ගන්නා සුළු වුවද, එය තවමත් එහි සංකීර්ණත්වය හේතුවෙන් බොහෝ සංවර්ධකයින් කල් දමයි. මගේ කලින් ලිපි වල මම ප්රධාන වශයෙන් බැලුවේ පහලම මට්ටම වන Link Layer සහ Physical Layer. මෙමගින් Attribute Protocol (ATT) සහ General Attribute Profile (GATT) වැනි සංකීර්ණ සහ ව්‍යාකූල සංකල්ප වෙත යොමු වීම වළක්වා ගැනීමට අපට හැකි විය. කෙසේ වෙතත්, යන්නට තැනක් නැත, ඒවා තේරුම් නොගෙන, අනුකූල උපාංග සංවර්ධනය කළ නොහැක. අද මම ඔබ සමඟ මෙම දැනුම බෙදා ගැනීමට කැමතියි. මගේ ලිපියෙන් මම විශ්වාසය තබමි Nordic වෙබ් අඩවියෙන් ආරම්භකයින් සඳහා. එහෙනම් අපි පටන් ගනිමු.
සෑම දෙයක්ම එතරම් අපහසු ඇයි?
මගේ මතය අනුව, ස්මාර්ට් ෆෝන් හරහා උපාංග කළමනාකරණය කිරීම ඉතා පොරොන්දු වූ සහ දිගුකාලීන මාතෘකාවක් බව වහාම පැහැදිලි විය. එමනිසා, ඔවුන් එය වහාම සහ උපරිම ලෙස සකස් කිරීමට තීරණය කළහ. එබැවින් විවිධ උපකරණ නිෂ්පාදකයින් ඔවුන්ගේම ප්‍රොටෝකෝල ඉදිරිපත් නොකරන අතර එය නොගැලපේ. ඒ නිසා අමාරුයි. දැනටමත් පළමු අදියරේදී, ඔවුන් BLE ප්රොටෝකෝලය තුළට හැකි සෑම දෙයක්ම මිරිකා ගැනීමට උත්සාහ කළහ. එය පසුව ප්රයෝජනවත් වේ ද නැද්ද යන්න ප්රශ්නයක් නොවේ. ඊට අමතරව, අනාගතය සඳහා උපාංග ලැයිස්තුව පුළුල් කිරීමේ හැකියාව ඔවුන් විසින් සපයන ලදී.
BLE ප්‍රොටෝකෝල රූප සටහන ඇඳ ඇති පින්තූරය දෙස බලමු. එය ස්ථර කිහිපයකින් සමන්විත වේ. උපාංගයේ රේඩියෝ නාලිකාව සඳහා වගකිව යුතු පහළම, භෞතික ස්ථරය (PHY). Link Layer(LL) සම්ප්‍රේෂණය කරන ලද පණිවිඩයේ සම්පූර්ණ බයිට් අනුපිළිවෙල අඩංගු වේ. කලින් ලිපිවල අපි මේ ගැන හරියටම අධ්‍යයනය කළා. ධාරක පාලක අතුරුමුහුණත (HCI) යනු පාලකය සහ ධාරකය විවිධ චිප් මත ක්‍රියාත්මක කරන්නේ නම් BLE ස්ථර හෝ චිප් අතර හුවමාරු ප්‍රොටෝකෝලයකි. තාර්කික සබැඳි පාලනය සහ අනුවර්තනය කිරීමේ ප්රොටෝකෝලය (L2CAP) පැකට් සෑදීම, රාමු කිරීම, දෝෂ පාලනය සහ පැකට් එකලස් කිරීම සඳහා වගකිව යුතුය. පැකට් සංකේතනය කිරීම සඳහා ආරක්ෂක කළමනාකරු ප්රොටෝකෝලය (SMP) වගකිව යුතුය. සාමාන්‍ය ප්‍රවේශ පැතිකඩ (GAP) "කවුද" යන්න තීරණය කිරීම සඳහා උපාංග අතර මූලික දත්ත හුවමාරුව සඳහා වගකිව යුතුය. ස්කෑන් කිරීම සහ ප්‍රචාරණය ද එයට ඇතුළත් ය. මෙම ලිපියෙන් මම ප්‍රොටෝකෝලයේ ඉතිරි කොටස් දෙක කෙරෙහි අවධානය යොමු කරමි - GATT සහ ATT. GATT යනු ATT හි උපරිව්‍යුහයකි, එබැවින් ඒවා එකිනෙකට සමීපව බැඳී ඇත.
කතාව සරල කිරීමට, මම සාදෘශ්‍යයකට හැරවීමට කැමතියි. මම එය කොතැනක හෝ අසා ඇති අතර එයට සහාය වීමට කැමැත්තෙමි. BLE උපාංගයක් රාක්ක කිහිපයක් සහිත පොත් පෙට්ටියක් ලෙස සිතන්න. සෑම රාක්කයක්ම වෙනම තේමාවකි. උදාහරණයක් ලෙස, අපට විද්‍යා ප්‍රබන්ධ, ගණිතය සහ විශ්වකෝෂ සහිත රාක්ක තිබේ. සෑම රාක්කයකම නිශ්චිත මාතෘකාවක් සහිත පොත් තිබේ. තවද සමහර පොත්වල සටහන් සහිත කඩදාසි පිටු සලකුණු පවා ඇත. ඊට අමතරව, සියලුම පොත්වල කුඩා කඩදාසි නාමාවලියක් අප සතුව ඇත. ඔබට මතක නම්, පාසල් පුස්තකාල යනු කඩදාසි කාඩ්පත් සහිත පටු පෙට්ටියකි. මෙම ප්‍රතිසමය සමඟ, කැබිනට්ටුව අපගේ උපාංගයේ පැතිකඩයි. රාක්ක යනු සේවා, පොත් යනු ලක්ෂණ, සහ නාමාවලිය යනු ගුණාංග වගුවකි. පොත්වල පිටු සලකුණු විස්තර කරන්නන් වන අතර, මම පසුව වඩාත් විස්තරාත්මකව කතා කරමි.
බොහෝ ව්‍යාපෘති වල සමාන කේත කෑලි ඇති බව උපාංග සංවර්ධනය කර ඇති ඕනෑම අයෙකු දනී. කාරණය වන්නේ බොහෝ උපාංගවලට සමාන ක්රියාකාරිත්වයක් ඇති බවයි. උදාහරණයක් ලෙස, උපාංග බැටරි මගින් බලගන්වන්නේ නම්, ඒවායේ මට්ටම ආරෝපණය කිරීම සහ අධීක්ෂණය කිරීමේ ගැටළුව සමාන වේ. සංවේදක සඳහාද එය එසේම වේ. ඇත්ත වශයෙන්ම, ක්‍රමලේඛනය සඳහා වස්තු-නැඹුරු ප්‍රවේශයකි "දේපල සහ හැසිරීම් ඒකාබද්ධ කරන වස්තු නිර්මාණය කිරීමට හැකියාව ලබා දෙන අතර එය නැවත භාවිතා කළ හැකි ස්වයං අන්තර්ගත සමිතියක් බවට පත් කරයි". මගේ මතය අනුව, BLE සමාන ප්රවේශයක් උත්සාහ කළේය. බ්ලූටූත් විශේෂ උනන්දුවක් දක්වන කණ්ඩායම (SIG) විසින් පැතිකඩ සංවර්ධනය කරන ලදී. එකම පැතිකඩ ඇති විවිධ නිෂ්පාදකයින්ගේ උපාංග දුෂ්කරතාවයකින් තොරව එකිනෙකා සමඟ වැඩ කළ යුතුය. ප්‍රොෆයිල්, අනෙක් අතට, විස්තර කරන්නන් මගින් පරිපූරණය කරන ලද සේවාවන් සහ ලක්ෂණවල සේවාවන් වලින් සමන්විත වේ. පොදුවේ, එය මේ වගේ විය හැකිය:
උදාහරණයක් ලෙස, හෘද ස්පන්දන වේගය මොනිටරයක (යෝග්‍යතා බ්‍රේස්ලට්) පැතිකඩ රූප සටහන සලකා බලන්න. එය සේවා දෙකකින් සහ ලක්ෂණ කිහිපයකින් සමන්විත වේ. එයින් පැතිකඩ ධූරාවලිය වහාම පැහැදිලි වේ. මුරපොල ලක්ෂණය මුළු කැලරි වියදම් ගණන බිංදුවට නැවත සකසයි.
1. හෘද ස්පන්දන සේවාවෙහි ලක්ෂණ තුනක් (0x180D) ඇතුළත් වේ:
අ) අනිවාර්ය හෘද ස්පන්දන ලක්ෂණය (0x2A37)
ආ) විකල්ප ශරීර සංවේදක පිහිටුම් ලක්ෂණය (0x2A38)
ඇ) හෘද ස්පන්දන පාලන ලක්ෂ්‍යයේ කොන්දේසි සහිත ලක්ෂණ (0x2A39)
2. බැටරි නඩත්තු සේවාව (0x180F):
අ) අනිවාර්ය බැටරි ආරෝපණ මට්ටමේ ලක්ෂණය (0x2A19)
UUID
අපට පැතිකඩ මූලද්‍රව්‍ය (සේවා, ලක්ෂණ සහ විස්තර) අනන්‍ය ලෙස ප්‍රවේශ වීමට නම්, අපි ඒවා සියල්ල කෙසේ හෝ අංකනය කළ යුතුය. මේ සඳහා Universally Unique ID (UUID) හෝ Universally Unique Identifier වැනි සංකල්පයක් හඳුන්වා දෙනු ලැබේ. UUID එක් එක් පේළියේ වරහන් තුළ දක්වා ඇත. ඒ වගේම මෙහි එක් විශේෂත්වයක් තියෙනවා. UUID සඳහා, අපි බිටු 16 සහ 128 ක කේතයක් භාවිතා කිරීමට තීරණය කළෙමු. ඇයි, ඔබ අහන්නේ? BLE ප්රොටෝකෝලය තුළ, සෑම දෙයක්ම බලශක්ති සංරක්ෂණය පිළිබඳ වේ. එබැවින්, බිටු 16 ක මානය තරමක් සාධාරණ ය. නුදුරු අනාගතයේ දී 65 දහසකට වඩා නිර්මාණය වනු ඇතැයි සිතිය නොහැක. අද්විතීය සේවාවන් සහ ලක්ෂණ. මේ මොහොතේ, ඔවුන්ට දැනටමත් ගණන් කළ හැකි සියල්ල (මෙය පැමිණියේ කොහෙන්දැයි මතක තබා ගන්න - “ඔහු ඔබවත් ගණන් කළේය” :-)) අංකිත මූලද්‍රව්‍ය , , и ඔබට සබැඳි දෙස බැලිය හැකිය.
කොහොම වුනත් අන්තර්ජාලයේ බයිට් 4ක අයිපී ඇඩ්‍රස් තියෙන කතාව හැමෝටම මතක ඇති කියලා හිතනවා. මුලදී අපි එය ප්රමාණවත් බව සිතුවෙමු, නමුත් දැන් අපට තවමත් 6-byte ලිපිනයකට මාරු විය නොහැක. මෙම වැරැද්ද නැවත නොකිරීමට සහ DIYers ගේ සෙල්ලක්කාර දෑත්වලට නිදහස් පාලනයක් ලබා දීම සඳහා, SIG වහාම 128-bit UUIDs හඳුන්වා දීමට තීරණය කළේය. ගුවන්විදුලි නාලිකාවෙන් සියලු වර්ගවල කුලිබින් සඳහා ලබා දුන් බලපත්‍ර රහිත 433 MHz කලාපය මෙය මට පුද්ගලිකව මතක් කර දෙයි. අපගේ නඩුවේදී, සේවා සහ ලක්ෂණ පිළිබඳ 128-bit හඳුනාගැනීමක් වගා කර ඇත. මෙයින් අදහස් කරන්නේ අපට, අපගේ සේවාවන් සහ උපාංග සඳහා, ඕනෑම 128-bit අගයක් භාවිතා කළ හැකි බවයි. සියල්ලටම වඩා, එකම UUID සමඟ පැමිණීමේ සම්භාවිතාව බිංදුවට නැඹුරු වේ.
ඇත්ත වශයෙන්ම, කෙටි 16-bit UUIDs ඒවායේ දිගුව 128-bit අගයක් දක්වා ඇත. පිරිවිතරයේ, මෙම දිගුව Bluetooth Base UUID ලෙස හඳුන්වන අතර එහි අගය 00000000-0000-1000-8000-00805F9B34FB ඇත. උදාහරණයක් ලෙස, 16-bit attribute UUID හි අගය 0x1234 නම්, ඊට සමාන 128-bit UUID ට 00001234-0000-1000-8000-00805F9B34FB අගය ඇත. ඊට අනුරූප සූත්‍රය පවා ලබා දී ඇත:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
මෙම මැජික් අංකය පැමිණියේ කොහෙන්දැයි මම නොදනිමි. පාඨකයින් කවුරුන් හෝ දන්නවා නම්, ඔවුන්ට අදහස් ලිවීමට ඉඩ දෙන්න (Sinopteek යන අන්වර්ථ නාමය ඇති පරිශීලකයෙකු දැනටමත් මෙය කර ඇත. අදහස් බලන්න). 128-bit UUIDs සමඟ එන පරිදි, ප්‍රතිපත්තිමය වශයෙන් ඔබට විශේෂ එකක් භාවිතා කළ හැකිය ඔබ වෙනුවෙන් එය කරන්නේ කවුද?
ATTy GATTy...
ඇත්ත වශයෙන්ම, විනෝදය ආරම්භ වේ. ATT පදනම් වී ඇත්තේ සේවාදායක-සේවාදායක සම්බන්ධතාවයක් මත බව මම ඔබට මතක් කරමි. දැන් අපි සේවාදායක උපාංගය දෙස බලමු. එහි සංවේදක අගයන්, ආලෝක ස්විච් තත්ත්වය, ස්ථාන දත්ත ආදිය වැනි තොරතුරු අඩංගු වේ. දැන් සියලුම "අපගේ පෙළපාළියේ සහභාගිවන්නන්" අංකනය කර ඇති අතර, අපි ඔවුන් කෙසේ හෝ උපාංගයේ මතකයේ තැබිය යුතුය. මෙය සිදු කිරීම සඳහා, අපි ඒවා attribute වගුවක් ලෙස හඳුන්වන වගුවක තබමු. මේක හොඳට මතක තියාගන්න. මෙය BLE හි හදවතයි. අපි තවදුරටත් සලකා බලන්නේ මෙයයි. දැන් අපි සෑම පේළියක්ම ගුණාංගයක් ලෙස හඳුන්වමු. මෙම වගුව තොගයේ ගැඹුරින් පිහිටා ඇති අතර, නීතියක් ලෙස, අපට එයට සෘජු ප්රවේශයක් නොමැත. අපි එය ආරම්භ කර එයට ප්‍රවේශ වන්නෙමු, නමුත් ඇතුළත සිදුවන දේ මුද්‍රා හතක් පිටුපස අපට සැඟවී ඇත.
පිරිවිතරයෙන් පින්තූරය දෙස බලමු, නමුත් ඊට පෙර, යෙදුම්වල, එනම් විස්තරවල නිතර පවතින ව්‍යාකූලත්වය කෙරෙහි වහාම අවධානය යොමු කිරීමට මම කැමැත්තෙමි. විස්තර කරන්නාගේ කාර්යභාරය වන්නේ ලක්ෂණයේ විස්තරය සම්පූර්ණ කිරීමයි. එහි හැකියාවන් පුළුල් කිරීමට අවශ්ය වූ විට, විස්තර කරන්නන් භාවිතා කරනු ලැබේ. ඒවා ද ගුණාංග වන අතර, සේවා සහ ලක්ෂණ මෙන්, ඒවා ගුණාංග වගුවේ පිහිටා ඇත. ලිපියේ දෙවන කොටසේදී අපි ඒවා විස්තරාත්මකව විමසා බලමු. කෙසේ වෙතත්, සමහර විට විස්තර කරන්නන් ගුණාංග වගුවේ පේළි අංකයට යොමු කරයි. මෙය මතක තබා ගත යුතුය. ව්‍යාකූලත්වය වළක්වා ගැනීම සඳහා, අපි මෙම අරමුණු සඳහා "උපරිගණක දර්ශකය" යන යෙදුම භාවිතා කරමු.
එබැවින් උපලක්ෂණයක් යනු එයට සම්බන්ධ පහත ගුණාංග ඇති විවික්ත අගයකි:
1. Attribute Handle යනු ගුණාංගයට අනුරූප වගු දර්ශකයයි
2. Attribute Type යනු එහි වර්ගය විස්තර කරන UUID එකකි
3. Attribute Value යනු attribute pointer මගින් සුචිගත කර ඇති දත්ත වේ
4. Attribute Permissions යනු attribute protocol භාවිතයෙන් කියවීමට හෝ ලිවීමට නොහැකි ගුණාංගයක කොටසකි.
මේ සියල්ල තේරුම් ගන්නේ කෙසේද? ගුණාංග දර්ශකය, සාපේක්ෂව කථා කිරීම, අපගේ වගුවේ එහි අංකය වේ.
එය සේවාලාභියෙකුට කියවීමේ හෝ ලිවීමේ ඉල්ලීම් වල ගුණාංගයක් යොමු කිරීමට ඉඩ සලසයි. අපට අපගේ රේඛා (ගුණාංග) 0x0001 සිට 0xFFFF දක්වා අංකනය කළ හැකිය. පොත් පෙට්ටිය සමඟ අපගේ ඇසුරේ, කඩදාසි නාමාවලියෙහි කාඩ්පත් අංකය මෙයයි. ඒ හා සමානව, පුස්තකාල නාමාවලියෙහි මෙන්, කාඩ්පත් අංක අනුපිළිවෙලින් සකස් කර ඇත. එක් එක් ඊළඟ පේළියේ අංකය පෙර එකට වඩා වැඩි විය යුතුය. පුස්තකාලයේ මෙන්, සමහර විට සමහර කාඩ්පත් නැති වී යයි, එබැවින් අප සමඟ, පේළි අංකනයෙහි හිඩැස් තිබිය හැකිය. මෙය අවසර ඇත. ප්රධාන දෙය නම් ඔවුන් ක්රමානුකූලව ගමන් කිරීමයි.
ගුණාංග වර්ගය මගින් ගුණාංගය නියෝජනය කරන්නේ කුමක්ද යන්න තීරණය කරයි. C භාෂාව හා සමානව,
boolean, numeric variables සහ strings ඇති තැන, එය මෙහි ඇත. ගුණාංග වර්ගය අනුව අපි හඳුනා ගනිමු
අප ගනුදෙනු කරන්නේ කුමක්ද සහ මෙම ගුණාංගය සමඟ අපට දිගටම වැඩ කළ හැක්කේ කෙසේද. පහත දැක්වෙන්නේ අපි විශේෂිත ගුණාංග වර්ග කිහිපයක් දෙස බලමු. උදාහරණයක් ලෙස, "සේවා ප්රකාශය" (0x2800), "ලක්ෂණ ප්රකාශනය" (0x2803), "විස්තර ප්රකාශනය" (0x2902).
ගුණාංගයක වටිනාකම එහි සැබෑ අරුතයි, tautology සමාවන්න. උපලක්ෂණ වර්ගය තන්තුවක් නම්, ගුණාංග අගය, උදාහරණයක් ලෙස, “Hello World !!!” සටන් පාඨය විය හැක. ගුණාංග වර්ගය “සේවා ප්‍රකාශයක්” නම්, එහි වටිනාකම සේවාවම වේ. සමහර විට මෙය වෙනත් ගුණාංග සහ ඒවායේ ගුණාංග සොයා ගත හැකි ස්ථානය පිළිබඳ තොරතුරු වේ.
ගුණාංග අවසර මඟින් සේවාදායකයට කියවීමට හෝ ලිවීමට ප්‍රවේශය අවසර තිබේද යන්න තේරුම් ගැනීමට ඉඩ සලසයි.
මෙම අවසරයන් අදාළ වන්නේ උපලක්ෂණ අගයට පමණක් වන අතර, දර්ශකයට, වර්ගයට හෝ අවසර ක්ෂේත්‍රයටම නොවන බව සලකන්න. එම. ගුණාංග පටිගත කිරීමට අවසර තිබේ නම්, අපට වෙනස් කළ හැකිය, උදාහරණයක් ලෙස, "Hello World !!!" "සුබ උදෑසනක්" යන රේඛාවට. නමුත් අපට නව පේළියක් ලිවීම තහනම් කිරීම හෝ ගුණාංග වර්ගය වෙනස් කිරීම සහ රේඛාව "සේවා ප්‍රකාශයක්" ලෙස නම් කිරීම කළ නොහැක. සේවාදායකයෙකු සේවාදායකයක් සම්බන්ධ කර ගන්නා විට, සේවාදායකයා එහි ගුණාංග ඉල්ලා සිටී. සේවාදායකයාට සැපයිය හැකි දේ දැන ගැනීමට මෙය සේවාදායකයාට ඉඩ සලසයි. අගයන් කියවීමට හා ලිවීමට අවශ්ය නැති වුවද.
ඒක මොන වගේද
GATT හි සංකල්පය වන්නේ ගුණාංග වගුවක ඇති ගුණාංග ඉතා නිශ්චිත සහ තාර්කික අනුපිළිවෙලකට කාණ්ඩගත කිරීමයි. පහත හෘද ස්පන්දන පැතිකඩ දෙස සමීපව බලමු. මෙම වගුවේ වම් කෙළවරේ ඇති තීරුව විකල්ප වේ. මෙම රේඛාව (ගුණාංගය) යනු කුමක්දැයි එය සරලව අපට විස්තර කරයි. අනෙක් සියලුම තීරු දැනටමත් අපට හුරුපුරුදුය.
සෑම කණ්ඩායමකම ඉහළින්ම අපට සැමවිටම සේවා ප්රකාශ කිරීමේ ගුණාංගයක් ඇත. එහි වර්ගය සෑම විටම 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 එකක් ඇත. මෙම විස්තරය භාවිතා කරමින්, සේවාදායකයාට ඇඟවීම හෝ දැනුම්දීම සක්‍රීය කිරීමට සේවාදායකයාට හැකියාව ඇත. ඔවුන් අතර වෙනස කුඩා නමුත් තවමත් පවතී. දැනුම්දීම සේවාලාභියාගෙන් ලදුපත තහවුරු කිරීම අවශ්ය නොවේ. ඇඟවීමට මෙය අවශ්ය වේ, එය GATT මට්ටමේ සිදු වුවද, යෙදුම් මට්ටමට ළඟා නොවේ. ඇයි එහෙම, ඔබ අහන්නේ? අහෝ, මම මෙය නොදනිමි. නෝර්ඩික් විශේෂඥයින් දැනුම්දීම් භාවිතා කිරීම නිර්දේශ කරන බව මට කියන්නට ඉඩ දෙන්න. එපමණක් නොව, පැකේජයේ අඛණ්ඩතාව පරීක්ෂා කිරීම (CRC භාවිතා කිරීම) අවස්ථා දෙකේදීම සිදු වේ.
නිගමනය
ලිපිය අවසානයේ මම මෙය පැවසීමට කැමැත්තෙමි. අන්තිම වගුව ටිකක් අවුල් සහගතයි. කෙසේ වෙතත්, එය ලබා දී ඇති නිසා මම එය තෝරා ගත්තෙමි , මම විශ්වාසය තබන. මගේ ලිපියේ දෙවන කොටසේදී, මම BlueTooth 4.0 පිරිවිතරයන් ගැඹුරින් සොයා බැලීමට අදහස් කරමි. වඩාත් නිවැරදි රූප සටහන් සහ චිත්‍ර එහි අපව බලා සිටී. තෙවන කොටසේදී, මම එක් ගැජට් එකකින් Wireshark වැඩසටහන භාවිතයෙන් ලබාගත් ලොගය විග්‍රහ කර අප අධ්‍යයනය කරන සියලුම න්‍යාය “සජීවී” බැලීමට කැමතියි.
සමාගම් සමූහයේ සේවකයා
Pecherskikh ව්ලැඩිමීර්
මූලාශ්රය: www.habr.com