အဏုကြည့်မှန်ဘီလူးအောက်တွင် BLE (ATTы GATTы…)

အဏုကြည့်မှန်ဘီလူးအောက်တွင် BLE (ATTы GATTы…)

အပိုင်း ၁၊ ခြုံငုံသုံးသပ်ချက်

Bluetooth 4.0 အတွက် ပထမဆုံး specification ထွက်လာပြီးကတည်းက အချိန်အတော်ကြာခဲ့ပါပြီ။ BLE ခေါင်းစဉ်သည် အလွန်စိတ်ဝင်စားစရာကောင်းသော်လည်း၊ ၎င်းသည် ၎င်း၏ရှုပ်ထွေးမှုကြောင့် developer အများအပြားကို ဖယ်ထားဆဲဖြစ်သည်။ ကျွန်ုပ်၏ယခင်ဆောင်းပါးများတွင်၊ အနိမ့်ဆုံးအဆင့်ဖြစ်သော Link Layer နှင့် Physical Layer ကို အဓိကအားဖြင့် ကြည့်ခဲ့ပါသည်။ ၎င်းသည် ကျွန်ုပ်တို့အား Attribute Protocol (ATT) နှင့် General Attribute Profile (GATT) ကဲ့သို့သော ရှုပ်ထွေးပြီး ရှုပ်ထွေးသော အယူအဆများကို မှီခိုအားထားရန် ရှောင်ရှားနိုင်စေခဲ့သည်။ သို့သော် ၎င်းတို့ကို နားမလည်ဘဲ လိုက်ဖက်ညီသော ကိရိယာများကို တီထွင်ရန် မဖြစ်နိုင်သည့် နေရာလည်း မရှိပါ။ ဒီနေ့ ဒီဗဟုသုတလေးကို မျှဝေပေးချင်ပါတယ်။ ငါ့ဆောင်းပါးမှာ ငါအားကိုးမယ်။ ကြောငျးစာအုပျ Nordic website မှစတင်သူများအတွက်။ ဒါဆို စလိုက်ရအောင်။

အရာအားလုံးကဘာကြောင့်ဒီလောက်ခက်ခဲနေရတာလဲ။

ကျွန်တော့်အမြင်အရ၊ စမတ်ဖုန်းများမှတစ်ဆင့် စက်ပစ္စည်းများကို စီမံခန့်ခွဲခြင်းသည် အလွန်အလားအလာရှိပြီး ကြာရှည်ခံသည့်အကြောင်းအရာတစ်ခုဖြစ်ကြောင်း ချက်ချင်းပင် ရှင်းပါသည်။ ထို့ကြောင့် ၎င်းတို့သည် ချက်ချင်းနှင့် အမြင့်ဆုံးအထိ တည်ဆောက်ရန် ဆုံးဖြတ်ခဲ့ကြသည်။ ထို့ကြောင့် အမျိုးမျိုးသော gadget များထုတ်လုပ်သူများသည် ၎င်းတို့၏ကိုယ်ပိုင် protocols များကိုမရရှိနိုင်စေရန်၊ ထို့နောက် သဟဇာတမဖြစ်တော့ပါ။ ဒါကြောင့် အခက်အခဲ ဖြစ်တယ်။ ပထမအဆင့်တွင်ရှိပြီးသား၊ ဖြစ်နိုင်သမျှအားလုံးကို BLE ပရိုတိုကောသို့ ညှစ်ရန်ကြိုးစားခဲ့သည်။ နောက်မှအသုံးဝင်မှာလား မဆိုင်ဘူးလားဆိုတာ အရေးမကြီးပါဘူး။ ထို့အပြင်၊ ၎င်းတို့သည် အနာဂတ်အတွက် စက်ပစ္စည်းများစာရင်းကို တိုးချဲ့နိုင်ခြေအတွက် ပံ့ပိုးပေးထားသည်။

BLE protocol diagram ရေးဆွဲသည့်ပုံကို ကြည့်ကြပါစို့။ အလွှာပေါင်းများစွာ ပါဝင်သည်။ အနိမ့်ဆုံး၊ ရုပ်ပိုင်းဆိုင်ရာအလွှာ (PHY) သည် စက်ပစ္စည်း၏ ရေဒီယိုချန်နယ်အတွက် တာဝန်ရှိသည်။ လင့်ခ်အလွှာ(LL) သည် ပို့လွှတ်သော မက်ဆေ့ဂျ်တွင် ဘိုက်အစီအစဥ် တစ်ခုလုံးပါရှိသည်။ အရင်ဆောင်းပါးတွေမှာလည်း ဒါကို အတိအကျ လေ့လာခဲ့ပါတယ်။ Host Controller Interface (HCI) သည် Controller နှင့် Host ကို မတူညီသော ချစ်ပ်များတွင် အသုံးပြုပါက BLE အလွှာများ သို့မဟုတ် ချစ်ပ်များအကြား ဖလှယ်သည့် ပရိုတိုကောတစ်ခုဖြစ်သည်။ Logical Link Control နှင့် Adaptation Protocol (L2CAP) သည် packet ဖွဲ့စည်းခြင်း၊ ဘောင်သွင်းခြင်း၊ အမှားအယွင်း ထိန်းချုပ်ခြင်းနှင့် ပက်ကက်စည်းခြင်းအတွက် တာဝန်ရှိပါသည်။ လုံခြုံရေးမန်နေဂျာပရိုတိုကော (SMP) သည် ပက်ကတ်များကို စာဝှက်ခြင်းအတွက် တာဝန်ရှိသည်။ အထွေထွေအသုံးပြုခွင့်ပရိုဖိုင် (GAP) သည် “မည်သူဖြစ်သည်” ကိုဆုံးဖြတ်ရန် စက်များအကြား ကနဦးဒေတာဖလှယ်မှုအတွက် တာဝန်ရှိသည်။ စကင်န်ဖတ်ခြင်းနှင့် ကြော်ငြာခြင်းတို့လည်း ပါဝင်သည်။ ဤဆောင်းပါးတွင် ကျွန်ုပ်သည် ပရိုတိုကော၏ ကျန်ရှိသည့် အစိတ်အပိုင်းနှစ်ခုဖြစ်သည့် GATT နှင့် ATT ကို အာရုံစိုက်ပါမည်။ GATT သည် ATT ၏ superstructure တစ်ခုဖြစ်သောကြောင့် ၎င်းတို့သည် နီးကပ်စွာရောယှက်နေသည်။

ဇာတ်လမ်းကို ရိုးရှင်းစေရန်၊ ဥပမာတစ်ခုသို့ လှည့်ကြည့်လိုပါသည်။ တစ်နေရာရာမှာ ကြားပြီး ထောက်ခံချင်ပါတယ်။ စင်များစွာပါသော BLE စက်ကို စာအုပ်စင်အဖြစ် တွေးပါ။ စင်တစ်ခုစီသည် သီးခြားဆောင်ပုဒ်တစ်ခုဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် သိပ္ပံစိတ်ကူးယဉ်၊ သင်္ချာနှင့် စွယ်စုံကျမ်းများပါရှိသည်။ စင်တစ်ခုစီတွင် သတ်မှတ်ထားသော အကြောင်းအရာတစ်ခုပါသော စာအုပ်များရှိသည်။ အချို့စာအုပ်များတွင် မှတ်စုများပါသော စာရွက်စာတန်းများပါရှိသည်။ ထို့အပြင် ကျွန်ုပ်တို့တွင် စာအုပ်အားလုံး၏ စက္ကူကတ်တလောက်ငယ်တစ်ခုရှိသည်။ မှတ်မိလျှင် ကျောင်းစာကြည့်တိုက်များသည် စက္ကူကတ်များပါသော ကျဉ်းမြောင်းသော သေတ္တာတစ်ခုဖြစ်သည်။ ဤဥပမာဖြင့်၊ ကက်ဘိနက်သည် ကျွန်ုပ်တို့၏စက်ပစ္စည်း၏ ပရိုဖိုင်ဖြစ်သည်။ စင်များသည် ဝန်ဆောင်မှုများ၊ စာအုပ်များသည် ထူးခြားချက်များဖြစ်ပြီး ကတ်တလောက်သည် ရည်ညွှန်းချက်ဇယားတစ်ခုဖြစ်သည်။ စာအုပ်များရှိ စာညှပ်များသည် သရုပ်ဖော်သူများဖြစ်ပြီး၊ နောက်ပိုင်းတွင် ကျွန်ုပ်လည်း အသေးစိတ် ထပ်မံပြောပြပါမည်။

ပရောဂျက်များစွာတွင် အလားတူကုဒ်အပိုင်းအစများ ပါရှိသည်ကို စက်ပစ္စည်းများကို တီထွင်ဖူးသူတိုင်း သိပါသည်။ အမှန်မှာ စက်များစွာတွင် အလားတူလုပ်ဆောင်နိုင်စွမ်းရှိသည်။ ဥပမာအားဖြင့်၊ စက်ပစ္စည်းများကို ဘက်ထရီဖြင့် အားသွင်းပါက အားသွင်းခြင်းနှင့် စောင့်ကြည့်ခြင်းဆိုင်ရာ ပြဿနာသည် တူညီမည်ဖြစ်သည်။ အာရုံခံကိရိယာတွေမှာလည်း အလားတူပါပဲ။ တကယ်တော့၊ ပရိုဂရမ်းမင်းကို object-oriented ချဉ်းကပ်မှု "ဂုဏ်သတ္တိများနှင့် အပြုအမူများကို ပေါင်းစပ်ပြီးနောက် ပြန်လည်အသုံးပြုနိုင်သည့် ကိုယ်ပိုင်ပါရှိသော ပြည်ထောင်စုတစ်ခုအဖြစ် အရာဝတ္တုများကို ဖန်တီးနိုင်သည်". ကျွန်တော့်အမြင်အရတော့ BLE က အလားတူချဉ်းကပ်မှုကို ကြိုးစားခဲ့ပါတယ်။ ပရိုဖိုင်များကို Bluetooth Special Interest Group (SIG) မှ ဖန်တီးထားပါသည်။ တူညီသော ပရိုဖိုင်များပါသည့် မတူညီသော ထုတ်လုပ်သူမှ စက်ပစ္စည်းများသည် အခက်အခဲမရှိဘဲ တစ်ခုနှင့်တစ်ခု လုပ်ဆောင်သင့်သည်။ တစ်ဖန် ပရိုဖိုင်များတွင် ဝန်ဆောင်မှုများ၊ ဖော်ပြချက်များဖြင့် ဖြည့်စွက်ထားသော ဝိသေသလက္ခဏာများ ဝန်ဆောင်မှုများ ပါဝင်ပါသည်။ ယေဘူယျအားဖြင့်၎င်းသည်ဤကဲ့သို့သောပုံရသည်-

ဥပမာအားဖြင့်၊ နှလုံးခုန်နှုန်းမော်နီတာ (ကြံ့ခိုင်မှုလက်ကောက်) ၏ ပရိုဖိုင်ပုံကြမ်းကို သုံးသပ်ကြည့်ပါ။ ၎င်းတွင် ဝန်ဆောင်မှုနှစ်ခုနှင့် လက္ခဏာများစွာ ပါဝင်သည်။ ၎င်းမှ ပရိုဖိုင် အထက်အောက် ချက်ခြင်း ရှင်းလင်းလာသည်။ စစ်ဆေးရေးဂိတ်လက္ခဏာသည် စုစုပေါင်းကယ်လိုရီအသုံးစရိတ်ကို သုညသို့ ပြန်လည်သတ်မှတ်သည်။

1. နှလုံးခုန်နှုန်းဝန်ဆောင်မှုတွင် လက္ခဏာသုံးရပ် (0x180D) ပါဝင်သည်။
    က) မဖြစ်မနေ နှလုံးခုန်နှုန်း လက္ခဏာ (0x2A37)
    ခ) ရွေးချယ်နိုင်သော ကိုယ်ထည် အာရုံခံ အနေအထား လက္ခဏာ (0x2A38)
    ဂ) နှလုံးခုန်နှုန်းထိန်းချုပ်မှုအမှတ် (0x2A39) ၏အခြေအနေဆိုင်ရာလက္ခဏာများ
2. ဘက်ထရီ ပြုပြင်ထိန်းသိမ်းခြင်း ဝန်ဆောင်မှု (0x180F):
    က) မဖြစ်မနေ အားသွင်းရမည့် ဘက်ထရီ အဆင့် လက္ခဏာ (0x2A19)

UUID

ကျွန်ုပ်တို့သည် ပရိုဖိုင်ဒြပ်စင်များ (ဝန်ဆောင်မှုများ၊ လက္ခဏာများနှင့် ဖော်ပြချက်များ) တို့ကို တမူထူးခြားစွာ ဝင်ရောက်နိုင်စေရန်အတွက် ၎င်းတို့အားလုံးကို တစ်နည်းတစ်ဖုံ ဂဏန်းတွက်ရန် လိုအပ်ပါသည်။ ဤရည်ရွယ်ချက်အတွက်၊ Universally Unique ID (UUID) သို့မဟုတ် Universally Unique Identifier ကဲ့သို့သော သဘောတရားကို မိတ်ဆက်ပေးခဲ့သည်။ UUID ကို စာကြောင်းတစ်ခုစီ၏ ကွင်းစကွက်များတွင် ညွှန်ပြထားသည်။ ပြီးတော့ ဒီနေရာမှာ ထူးခြားချက်တစ်ခုရှိတယ်။ UUID အတွက်၊ အရှည် 16 နှင့် 128 bits ရှိသော ကုဒ်တစ်ခုကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ မင်းဘာလို့မေးတာလဲ။ BLE ပရိုတိုကောတွင်၊ အရာအားလုံးသည် စွမ်းအင်ထိန်းသိမ်းမှုနှင့်ပတ်သက်သည်။ ထို့ကြောင့် 16 bits ၏အတိုင်းအတာသည် အလွန်သင့်လျော်ပါသည်။ မဝေးတော့သောအနာဂတ်တွင် 65 ကျော်ကိုဖန်တီးနိုင်လိမ့်မည်မထင်ပါ။ ထူးခြားသောဝန်ဆောင်မှုများနှင့်ဝိသေသလက္ခဏာများ။ လောလောဆယ်မှာ သူတို့အားလုံး ရေတွက်ပြီးသွားပြီ (ဒါက ဘယ်ကလာတာလဲ သတိရပါ - "သူလည်း မင်းကို ရေတွက်တယ်" :-)) နံပါတ်တပ်ထားတဲ့ အချက်တွေ၊ ပရိုဖိုင်များ, န်ဆောင်မှုများ, ဝိသေသလက္ခဏာများ и ဖော်ပြချက်များ links တွေမှာ ကြည့်ရှုနိုင်ပါတယ်။

ဒါပေမယ့် အင်တာနက်မှာ IP လိပ်စာ 4 bytes ပါတဲ့ ဇာတ်လမ်းကို လူတိုင်းမှတ်မိကြမယ်ထင်တယ်။ အစတုန်းကတော့ လုံလောက်တယ်လို့ ထင်ခဲ့ပေမယ့် အခု 6-byte လိပ်စာကို ပြောင်းလို့မရသေးပါဘူး။ ဤအမှားကို ထပ်ခါတလဲလဲမလုပ်ရန်နှင့် ဆော့ကစားတတ်သော DIYers များထံ အခမဲ့ ချုပ်နှောင်မှုမပြုရန် SIG သည် 128-bit UUID များကို မိတ်ဆက်ရန် ချက်ချင်းဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် ရေဒီယိုချန်နယ်မှ Kulibins အမျိုးအစားအားလုံးကို ပေးအပ်ထားသည့် လိုင်စင်မဲ့ 433 MHz တီးဝိုင်းအကြောင်း ကျွန်ုပ်အား ကိုယ်တိုင်ကိုယ်ကျ အမှတ်ရစေသည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ဝန်ဆောင်မှုများနှင့် လက္ခဏာရပ်များ၏ 128-bit ခွဲခြားသတ်မှတ်မှုကို ဖော်ထုတ်ခဲ့သည်။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများနှင့် စက်များအတွက် 128-bit တန်ဖိုးကိုမဆို အသုံးပြုနိုင်ပါသည်။ အားလုံးအတူတူပါပဲ၊ တူညီတဲ့ UUID နဲ့တက်လာနိုင်ခြေဟာ သုညပါပဲ။

တကယ်တော့၊ တိုတောင်းသော 16-bit UUID များသည် ၎င်းတို့၏ extension ကို 128-bit တန်ဖိုးသို့ ရှိသည်။ သတ်မှတ်ချက်တွင်၊ ဤတိုးချဲ့မှုကို Bluetooth Base UUID ဟုခေါ်ပြီး တန်ဖိုး 00000000-0000-1000-8000-00805F9B34FB ရှိသည်။ ဥပမာအားဖြင့်၊ 16-bit ရည်ညွှန်းချက် UUID တွင် တန်ဖိုး 0x1234 ရှိပါက၊ ညီမျှသော 128-bit UUID တွင် တန်ဖိုး 00001234-0000-1000-8000-00805F9B34FB ရှိပါမည်။ ဆက်စပ်ဖော်မြူလာကိုပင် ပေးသည်-

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

ဒီမှော်နံပါတ်က ဘယ်ကလာမှန်းမသိဘူး။ စာဖတ်သူများ သိရှိပါက မှတ်ချက်များတွင် ရေးပေးကြပါ (Sinopteek ဟူသော အမည်ပြောင်ဖြင့် အသုံးပြုသူတစ်ဦးက ၎င်းကို လုပ်ဆောင်ပြီးဖြစ်သည်။ မှတ်ချက်များကို ကြည့်ပါ)။ 128-bit UUID များနှင့်အတူ ထွက်ပေါ်လာခြင်းအတွက်မူအရ သင်သည် အထူးတစ်ခုကို အသုံးပြုနိုင်သည်။ မီးစက်မင်းအတွက် ဘယ်သူလုပ်ပေးမလဲ။

ATTy GATty...

တကယ်တော့, ထို့နောက်ပျော်စရာစတင်။ ATT သည် ဖောက်သည်-ဆာဗာ ဆက်ဆံရေးအပေါ် အခြေခံထားကြောင်း သတိပေးပါရစေ။ ယခုကျွန်ုပ်တို့သည်ဆာဗာကိရိယာကိုကြည့်ရှုနေသည်။ ၎င်းတွင် အာရုံခံတန်ဖိုးများ၊ အလင်းခလုတ်အခြေအနေ၊ တည်နေရာဒေတာစသည့် အချက်အလက်များပါရှိသည်။ ယခု "ကျွန်ုပ်တို့၏ချီတက်ပွဲတွင်ပါဝင်သူများ" အားလုံးကို ရေတွက်ပြီးသောအခါ၊ ၎င်းတို့ကို စက်၏မှတ်ဉာဏ်တွင် တစ်နည်းနည်းဖြင့် ထားရှိရန် လိုအပ်ပါသည်။ ဒါကိုလုပ်ဖို့၊ သူတို့ကို attribute table လို့ခေါ်ပါတယ်။ ဒါကို ကောင်းကောင်းမှတ်ထားပါ။ ဒါက BLE ရဲ့ နှလုံးသားပါ။ ဒါက ကျနော်တို့ နောက်ထပ် စဉ်းစားရမယ့်အချက်ပါ။ ယခု ကျွန်ုပ်တို့သည် စာကြောင်းတစ်ကြောင်းစီကို attribute ဟုခေါ်ပါမည်။ ဤဇယားသည် stack တွင်နက်ရှိုင်းစွာတည်ရှိပြီးစည်းမျဉ်းအရ၊ ကျွန်ုပ်တို့သည် ၎င်းကိုတိုက်ရိုက်ဝင်ရောက်ခွင့်မရှိပါ။ ကျွန်ုပ်တို့ ၎င်းကို အစပြုပြီး ၎င်းကို ဝင်ရောက်ကြည့်ရှုနိုင်သော်လည်း အတွင်း၌ ဖြစ်ပျက်နေသည့်အရာသည် တံဆိပ်ခုနစ်ခုနောက်ကွယ်တွင် ကျွန်ုပ်တို့ထံမှ ဝှက်ထားသည်။

သတ်မှတ်ချက်မှ ရုပ်ပုံအား ကြည့်ကြပါစို့၊ သို့သော် ထိုမတိုင်မီတွင်၊ ဖော်ပြချက်များ၌ မကြာခဏ ရှုပ်ထွေးနေသော ဝေါဟာရများကို ချက်ချင်းအာရုံစိုက်စေလိုပါသည်။ သရုပ်ဖော်သူ၏ အခန်းကဏ္ဍသည် ဝိသေသ၏ ဖော်ပြချက်ကို ဖြည့်စွက်ရန် ဖြစ်သည်။ ၎င်း၏စွမ်းရည်များကို ချဲ့ထွင်ရန် လိုအပ်သောအခါတွင် ဖော်ပြချက်များကို အသုံးပြုသည်။ ၎င်းတို့သည် attribute များဖြစ်ပြီး ဝန်ဆောင်မှုများနှင့် လက္ခဏာများကဲ့သို့ပင်၊ ၎င်းတို့သည် attribute table တွင်တည်ရှိပါသည်။ ဆောင်းပါး၏ ဒုတိယအပိုင်းတွင် ၎င်းတို့ကို အသေးစိတ် စစ်ဆေးပါမည်။ သို့သော် တစ်ခါတစ်ရံတွင် ဖော်ပြသူများသည် attribute ဇယားရှိ အတန်းနံပါတ်ကို ရည်ညွှန်းပါသည်။ ဒါကို စိတ်ထဲမှာ ထားရမယ်။ ရှုပ်ထွေးမှုများကို ရှောင်ရှားရန် ဤရည်ရွယ်ချက်များအတွက် "attribute pointer" ဟူသော ဝေါဟာရကို အသုံးပြုပါမည်။


ထို့ကြောင့် attribute သည် ၎င်းနှင့်ဆက်စပ်နေသော အောက်ပါဂုဏ်သတ္တိများပါရှိသော သီးခြားတန်ဖိုးတစ်ခုဖြစ်သည်။
1. Attribute Handle သည် attribute နှင့် သက်ဆိုင်သော table index ဖြစ်သည်။
2. Attribute Type သည် ၎င်း၏အမျိုးအစားကိုဖော်ပြသော UUID တစ်ခုဖြစ်သည်။
3. Attribute Value သည် attribute pointer မှ indexed data ဖြစ်သည်။
4. Attribute Permissions များသည် attribute protocol ကို အသုံးပြု၍ ဖတ်ခြင်း သို့မဟုတ် ရေးသား၍မရသော ခွင့်ပြုချက်များ၊

ဒါတွေအားလုံးကို ဘယ်လိုနားလည်ရမလဲ။ attribute pointer သည် ကျွန်ုပ်တို့ဇယားရှိ ၎င်း၏နံပါတ်ဖြစ်သည်။
၎င်းသည် သုံးစွဲသူတစ်ဦးအား ဖတ်ရှုရန် သို့မဟုတ် စာရေးတောင်းဆိုမှုများတွင် အရည်အချင်းတစ်ခုအား ကိုးကားရန်ခွင့်ပြုသည်။ 0x0001 မှ 0xFFFF မှ ကျွန်ုပ်တို့၏လိုင်းများ (attributes) ကို ရေတွက်နိုင်ပါသည်။ စာအုပ်စင်နှင့် ကျွန်ုပ်တို့၏ဆက်စပ်မှုတွင်၊ ဤသည်မှာ စာရွက်ကတ်တလောက်ရှိ ကတ်နံပါတ်ဖြစ်သည်။ အလားတူ၊ စာကြည့်တိုက်ကတ်တလောက်တွင်ကဲ့သို့ ကတ်များကို အရေအတွက် တိုးလာစေရန် စီစဥ်ထားသည်။ နောက်ဆက်တွဲစာကြောင်းတစ်ခုစီ၏ အရေအတွက်သည် ယခင်စာကြောင်းထက် ပိုများနေရပါမည်။ စာကြည့်တိုက်တွင်ကဲ့သို့ပင် တစ်ခါတစ်ရံတွင် အချို့သောကတ်များ ပျောက်ဆုံးသွားသောကြောင့် ကျွန်ုပ်တို့နှင့်အတူ၊ လိုင်းနံပါတ်တပ်ခြင်းတွင် ကွာဟချက်ရှိနိုင်ပါသည်။ ဒါကို ခွင့်ပြုတယ်။ အဓိက ကတော့ သူတို့က အဆင့်ဆင့် လျှောက်သွားနေတာ။

ရည်ညွှန်းချက်အမျိုးအစားသည် ရည်ညွှန်းချက်အား ကိုယ်စားပြုသည့်အရာကို ဆုံးဖြတ်သည်။ C language နဲ့ ယှဉ်ကြည့်ခြင်းအားဖြင့်၊
boolean၊ numeric variables နှင့် strings များရှိရာ၊ ဤနေရာတွင် ရှိနေပါသည်။ ရည်ညွှန်းချက်အမျိုးအစားအားဖြင့် ကျွန်ုပ်တို့အသိအမှတ်ပြုပါသည်။
ကျွန်ုပ်တို့သည် အဘယ်အရာနှင့် ဆက်ဆံနေရသနည်း၊ ဤအရည်အချင်းဖြင့် ကျွန်ုပ်တို့ မည်သို့ဆက်လက်လုပ်ဆောင်နိုင်မည်နည်း။ အောက်တွင် ကျွန်ုပ်တို့သည် အချို့သော သီးခြား attribute အမျိုးအစားများကို ကြည့်ပါမည်။ ဥပမာအားဖြင့်၊ "ဝန်ဆောင်မှုကြေငြာချက်" (0x2800)၊ "ထူးခြားသောကြေငြာချက်" (0x2803)၊ "ဖော်ပြချက်ကြေငြာချက်" (0x2902)။

attribute တစ်ခု၏တန်ဖိုးသည် ၎င်း၏အမှန်တကယ်အဓိပ္ပာယ်ဖြစ်ပြီး tautology ကို ခွင့်လွှတ်ပါ။ attribute အမျိုးအစားသည် string တစ်ခုဖြစ်ပါက၊ attribute value သည် ဥပမာ၊ ဆောင်ပုဒ် “Hello World !!!” ဖြစ်နိုင်ပါသည်။ အကယ်၍ attribute အမျိုးအစားသည် "ဝန်ဆောင်မှုကြေငြာချက်" ဖြစ်ပါက ၎င်း၏တန်ဖိုးသည် ဝန်ဆောင်မှုကိုယ်တိုင်ဖြစ်သည်။ တစ်ခါတစ်ရံတွင် ၎င်းသည် အခြား attribute များနှင့် ၎င်းတို့၏ ဂုဏ်သတ္တိများကို မည်သည့်နေရာတွင် ရှာဖွေရမည်နည်း။

ရည်ညွှန်းချက်ခွင့်ပြုချက်များသည် ဆာဗာအား ဖတ်ရန် သို့မဟုတ် စာရေးဝင်ရောက်ခွင့်ကို ခွင့်ပြုထားခြင်းရှိမရှိ နားလည်နိုင်စေပါသည်။
ဤခွင့်ပြုချက်များသည် အမှတ်အသား၊ အမျိုးအစား သို့မဟုတ် ခွင့်ပြုချက်အကွက်တွင်သာမဟုတ်ဘဲ ရည်ညွှန်းချက်တန်ဖိုးနှင့်သာ သက်ဆိုင်ကြောင်း သတိပြုပါ။ အဲဒါတွေ။ attribute recording ကို ခွင့်ပြုပါက၊ ဥပမာ၊ “Hello World!!!” လိုင်းကို ပြောင်းနိုင်သည်။ "မင်္ဂလာနံနက်ခင်းပါ" လိုင်းသို့ သို့သော် ကျွန်ုပ်တို့သည် စာကြောင်းအသစ်ရေးသားခြင်း သို့မဟုတ် attribute အမျိုးအစားကို ပြောင်းလဲပြီး လိုင်းကို "ဝန်ဆောင်မှုကြေငြာချက်" အဖြစ် သတ်မှတ်၍မရပါ။ ဖောက်သည်တစ်ဦးသည် ဆာဗာကို ဆက်သွယ်သောအခါ၊ ဖောက်သည်သည် ၎င်း၏ အရည်အချင်းများကို တောင်းဆိုသည်။ ၎င်းသည် သုံးစွဲသူအား ဆာဗာမှ ပေးဆောင်နိုင်သည်များကို သိနိုင်စေပါသည်။ တန်ဖိုးတွေကို ရေးတတ်ဖတ်တတ်ဖို့ မလိုအပ်ပေမယ့်။

ဘယ်လိုပုံစံလဲ။

GATT ၏ သဘောတရားသည် အလွန်တိကျပြီး ယုတ္တိရှိသော အစီအစဥ်တစ်ခုဖြင့် attribute ဇယားတစ်ခုတွင် attribute များကို အုပ်စုဖွဲ့ရန်ဖြစ်သည်။ အောက်ဖော်ပြပါ နှလုံးခုန်နှုန်းပရိုဖိုင်ကို အနီးကပ်လေ့လာကြည့်ရအောင်။ ဤဇယား၏ ဘယ်ဘက်ဆုံးကော်လံသည် စိတ်ကြိုက်ရွေးချယ်နိုင်သည်။ ဤစာကြောင်း (attribute) သည် ကျွန်ုပ်တို့အား ရိုးရှင်းစွာ ဖော်ပြသည်။ အခြားကော်လံများအားလုံးသည် ကျွန်ုပ်တို့နှင့်ရင်းနှီးပြီးသားဖြစ်သည်။

အဖွဲ့တစ်ခုစီ၏ထိပ်တွင် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကြေငြာခြင်းရည်ညွှန်းချက်တစ်ခု အမြဲရှိသည်။ ၎င်း၏ အမျိုးအစားသည် အမြဲတမ်း 0x2800 ဖြစ်ပြီး ညွှန်ပြချက်သည် ဇယားတွင် ရှိနေပြီးသား အရည်အချင်းများ မည်မျှရှိသည်အပေါ် မူတည်သည်။ ၎င်း၏ခွင့်ပြုချက်များသည် စစ်မှန်ကြောင်း သို့မဟုတ် ခွင့်ပြုချက်မရှိဘဲ အမြဲတမ်းဖတ်ရန်သာဖြစ်သည်။ ဒီသဘောတရားတွေအကြောင်း နည်းနည်းကြာမှ ပြောပါမယ်။ တန်ဖိုးသည် ဝန်ဆောင်မှုကို ခွဲခြားသိမြင်နိုင်သော အခြား UUID ဖြစ်သည်။ ဇယားတွင်၊ တန်ဖိုးသည် 0x180D ဖြစ်ပြီး၊ Bluetooth SIG မှ နှလုံးခုန်နှုန်းဝန်ဆောင်မှုအဖြစ် သတ်မှတ်သည်။

ဝန်ဆောင်မှုကြေငြာပြီးနောက်၊ အင်္ဂါရပ်၏ကြေငြာချက်ထွက်ပေါ်လာသည်။ ၎င်းသည် ဝန်ဆောင်မှုကြေငြာချက်ပုံစံနှင့် ဆင်တူသည်။ ၎င်း၏ UUID သည် အမြဲတမ်း 0x2803 ဖြစ်ပြီး ၎င်း၏ခွင့်ပြုချက်များသည် စစ်မှန်ကြောင်း သို့မဟုတ် ခွင့်ပြုချက်မရှိဘဲ အမြဲတမ်းဖတ်ရန်သာဖြစ်သည်။ အချက်အလက်အချို့ပါဝင်သည့် Attribute Value အကွက်ကို ကြည့်ကြပါစို့။ ၎င်းတွင် ညွှန်ပြချက်တစ်ခု၊ UUID နှင့် ဂုဏ်သတ္တိအစုံပါရှိသည်။ ဤအချက်သုံးချက်သည် တန်ဖိုး၏နောက်ဆက်တွဲဖော်ပြချက်ကို ဖော်ပြသည်။ ညွှန်ပြချက်သည် attribute ဇယားရှိ ဝိသေသတန်ဖိုးကြေငြာချက်၏တည်နေရာကို သဘာဝကျကျဖော်ပြသည်။ UUID သည် ကျွန်ုပ်တို့မျှော်လင့်နိုင်သည့် အချက်အလက်အမျိုးအစား သို့မဟုတ် တန်ဖိုးကို ဖော်ပြသည်။ ဥပမာအားဖြင့်၊ အပူချိန်တန်ဖိုး၊ အလင်းခလုတ်၏ အခြေအနေ သို့မဟုတ် အခြားထင်သလိုတန်ဖိုးအချို့။ နောက်ဆုံးတွင် ဝိသေသတန်ဖိုးနှင့် မည်ကဲ့သို့ အကျိုးသက်ရောက်နိုင်သည်ကို ဖော်ပြသည့် ဂုဏ်သတ္တိများ။

နောက်ထပ် ချို့ယွင်းချက်တစ်ခုက ကျွန်ုပ်တို့ကို ဤနေရာတွင် စောင့်ကြိုနေပါသည်။ ၎င်းသည် attribute ခွင့်ပြုချက်များနှင့် ဝိသေသဂုဏ်သတ္တိများနှင့် ဆက်စပ်နေသည်။ Specification မှ bit field properties ၏ပုံကို ကြည့်ရအောင်။

သင်တွေ့မြင်ရသည့်အတိုင်း၊ ဤနေရာတွင် စာရေးခြင်းစွမ်းရည်ကို ပေးစွမ်းနိုင်သော နယ်ပယ်များလည်း ရှိပါသည်။ ကျွန်ုပ်တို့တွင် ရည်ညွှန်းချက်နှင့် ပစ္စည်းဥစ္စာပိုင်ဆိုင်မှုအတွက် အဘယ်ကြောင့် ဖတ်/ရေးခွင့်ပြုချက်များ ရှိသည်ကို သင်အံ့သြနေပေမည်။
လက္ခဏာတန်ဖိုးအတွက် ဖတ်/ရေးမလား။ အမြဲတမ်း တူနေသင့်သလား။ အမှန်မှာ ဝိသေသတန်ဖိုးများအတွက် ဂုဏ်သတ္တိများသည် အမှန်တကယ်တွင် GATT နှင့် အပလီကေးရှင်းအလွှာများတွင် အသုံးပြုသည့် client အတွက် အကြံပြုချက်များသာဖြစ်သည်။ ဤအရာများသည် လက္ခဏာကြေညာခြင်း ရည်ညွှန်းချက်မှ ဖောက်သည်သည် မျှော်လင့်နိုင်ဖွယ်ရှိသည့် အရိပ်အမြွက်များဖြစ်သည်။ ဒါကို ပိုပြီးအသေးစိတ်ကြည့်ရအောင်။ ရည်ညွှန်းချက်တစ်ခုတွင် မည်သည့်ခွင့်ပြုချက်အမျိုးအစားများ ရှိသနည်း။

1. အသုံးပြုခွင့်များ-
     - စာဖတ်ခြင်း
     - မှတ်တမ်း
     - အရေးအဖတ်
2. အထောက်အထားစိစစ်ခြင်းခွင့်ပြုချက်-
     - စစ်မှန်ကြောင်းအထောက်အထားလိုအပ်သည်။
     - စစ်မှန်ကြောင်းအထောက်အထားမလိုအပ်ပါ။
3. ခွင့်ပြုချက်ခွင့်ပြုချက်-
     - ခွင့်ပြုချက်လိုအပ်သည်။
     - ခွင့်ပြုချက်မလိုအပ်ပါ။

attribute resolution နှင့် characteristic properties များကြား အဓိက ကွာခြားချက်မှာ ယခင် servers များတွင် သက်ရောက်ပြီး နောက်ပိုင်း clients များအတွက် ဖြစ်သည်။ ဆာဗာသည် လက္ခဏာတန်ဖိုးကို ဖတ်ရန် ခွင့်ပြုထားသော်လည်း စစ်မှန်ကြောင်း သို့မဟုတ် ခွင့်ပြုချက် လိုအပ်နိုင်သည်။ ထို့ကြောင့်၊ ဖောက်သည်သည် ဝိသေသ၏ဂုဏ်သတ္တိများကို တောင်းဆိုသောအခါ၊ ကျွန်ုပ်တို့သည် ၎င်းကို ဖတ်ရှုခွင့်ကို ရရှိမည်ဖြစ်သည်။ ဒါပေမယ့် ဖတ်ဖို့ကြိုးစားတဲ့အခါ အမှားအယွင်းတွေ ကြုံလာရတယ်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ပိုင်ဆိုင်မှုများထက် ခွင့်ပြုချက်များ၏ ဦးစားပေးအကြောင်း လုံခြုံစွာ ပြောဆိုနိုင်ပါသည်။ ကလိုင်းယင့်ဘက်တွင်၊ ရည်ညွှန်းချက်တစ်ခုတွင် မည်သည့်ခွင့်ပြုချက်များပါရှိသည်ကို ကျွန်ုပ်တို့ မသိရှိနိုင်ပါ။

ဖော်ပြချက်

ငါတို့စားပွဲကိုပြန်ကြရအောင်။ ဝိသေသတစ်ခု၏တန်ဖိုးကို ကြေငြာပြီးနောက်၊ အောက်ပါ attribute ကြေငြာချက်များကို ဖြစ်နိုင်သည်-
1. ဝိသေသလက္ခဏာများ ကြေငြာချက်အသစ် (ဝန်ဆောင်မှုတစ်ခုတွင် လက္ခဏာများစွာရှိနိုင်သည်)
2. ဝန်ဆောင်မှုကြေငြာချက်အသစ် (ဇယားတွင် ၎င်းတို့အများအပြားရှိနိုင်သည်)
3. လက်ကိုင်တစ်ခုကြေငြာခြင်း။

နှလုံးခုန်နှုန်းတိုင်းတာခြင်းဆိုင်ရာ ဝိသေသကိစ္စတွင်၊ ကျွန်ုပ်တို့၏ဇယားတွင်၊ လက္ခဏာတန်ဖိုး၏ကြေငြာချက်ကို ဖော်ပြသူ၏ကြေငြာချက်ဖြင့် လိုက်ပါသွားပါသည်။ ဖော်ပြချက်သည် အင်္ဂါရပ်တစ်ခုအကြောင်း ထပ်လောင်းအချက်အလက်များပါရှိသော အရည်အချင်းတစ်ခုဖြစ်သည်။ ဖော်ပြချက်အမျိုးအစားများစွာရှိသည်။ ဤဆောင်းပါး၏ ဒုတိယအပိုင်းတွင် ၎င်းတို့အကြောင်း အသေးစိတ် ဆွေးနွေးပါမည်။ ယခုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် Client Characteristic Configuration Descriptor (CCCD) ပေါ်တွင်သာ ထိတွေ့ပါမည်။ ၎င်းတွင် 0x2902 နှင့် ညီမျှသော UUI ရှိသည်။ ဤဖော်ပြချက်ကို အသုံးပြု၍ သုံးစွဲသူသည် ဆာဗာပေါ်တွင် ညွှန်ပြမှု သို့မဟုတ် အသိပေးချက်ကို ဖွင့်နိုင်သည်။ သူတို့ကြားက ကွာခြားချက်က သေးသေးလေးဘဲ။ အကြောင်းကြားချက်သည် သုံးစွဲသူထံမှ ပြေစာအတည်ပြုချက် မလိုအပ်ပါ။ ၎င်းသည် GATT အဆင့်တွင်ဖြစ်ပေါ်သော်လည်း လျှောက်လွှာအဆင့်သို့မရောက်ရှိဘဲ ညွှန်ပြရန်လိုအပ်သည်။ ဘာလို့အဲလိုမေးတာလဲ။ သြော် ငါ ဒါကို မသိဘူး။ Nordic ပညာရှင်များက အသိပေးချက်များကို အသုံးပြုရန် အကြံပြုထားကြောင်း ပြောပါရစေ။ ထို့အပြင်၊ ပက်ကေ့ဂျ် (CRC ကိုသုံး၍) ၏ခိုင်မာမှုကိုစစ်ဆေးခြင်းသည် ကိစ္စရပ်နှစ်ခုစလုံးတွင် ဖြစ်ပေါ်ပါသည်။

ကောက်ချက်

ဆောင်းပါးရဲ့ အဆုံးမှာတော့ ဒီလိုပြောချင်ပါတယ်။ နောက်ဆုံး စားပွဲက နည်းနည်းတော့ ရှုပ်တယ်။ ဒါပေမယ့် ပေးထားတာဆိုတော့ ရွေးလိုက်တယ်။ ဆောင်းပါးငါအားကိုးသော။ ကျွန်ုပ်၏ဆောင်းပါး၏ဒုတိယအပိုင်းတွင်၊ ကျွန်ုပ်သည် BlueTooth 4.0 သတ်မှတ်ချက်ကိုပိုမိုနက်ရှိုင်းစွာလေ့လာရန်ရည်ရွယ်ပါသည်။ နောက်ထပ် မှန်ကန်သော ကားချပ်များနှင့် ပုံများ သည် ကျွန်ုပ်တို့ကို ထိုနေရာတွင် စောင့်ကြိုနေပါသည်။ တတိယအပိုင်းတွင်၊ Wireshark ပရိုဂရမ်ကို အသုံးပြု၍ ရရှိသော မှတ်တမ်းကို ဂက်ဂျက်တစ်ခုမှ ခွဲခြမ်းစိပ်ဖြာပြီး ကျွန်ုပ်တို့ လေ့လာနေသည့် သီအိုရီအားလုံးကို “တိုက်ရိုက်” ကြည့်ပါ။

ကုမ္ပဏီအုပ်စု၏ ဝန်ထမ်း "ဆီဇာဂြိုလ်တု"
Pecherskikh ဗလာဒီမာ

source: www.habr.com