BLE زیر میکروسکوپ (ATTы GATTы…)
قسمت 1، بررسی اجمالی
مدت زمان زیادی از انتشار اولین مشخصات بلوتوث 4.0 می گذرد. و اگرچه موضوع BLE بسیار جالب است، اما به دلیل پیچیدگی آن هنوز بسیاری از توسعه دهندگان را به تعویق می اندازد. در مقاله‌های قبلی‌ام، من عمدتاً به پایین‌ترین سطح، یعنی لایه پیوند و لایه فیزیکی نگاه کردم. این به ما این امکان را داد که از توسل به مفاهیم پیچیده و گیج کننده مانند پروتکل ویژگی (ATT) و نمایه ویژگی عمومی (GATT) اجتناب کنیم. با این حال، جایی برای رفتن وجود ندارد، بدون درک آنها، توسعه دستگاه های سازگار غیرممکن است. امروز می خواهم این دانش را با شما به اشتراک بگذارم. در مقاله خود به آن تکیه خواهم کرد برای مبتدیان از وب سایت Nordic. پس بیایید شروع کنیم.
چرا همه چیز اینقدر سخت است؟
به نظر من، بلافاصله مشخص شد که مدیریت دستگاه ها از طریق تلفن های هوشمند موضوعی بسیار امیدوارکننده و طولانی مدت است. بنابراین، آنها تصمیم گرفتند آن را بلافاصله و حداکثر ساختاربندی کنند. به طوری که سازندگان ابزارهای مختلف پروتکل های خود را ارائه ندهند که در این صورت ناسازگار خواهند بود. از این رو دشواری. قبلاً در مرحله اول، آنها سعی کردند همه چیز را در پروتکل BLE فشرده کنند. و مهم نیست که بعدا مفید خواهد بود یا نه. علاوه بر این، آنها امکان گسترش لیست دستگاه ها را برای آینده فراهم کردند.
بیایید به تصویری که در آن نمودار پروتکل BLE رسم شده است نگاهی بیندازیم. از چندین لایه تشکیل شده است. پایین ترین لایه فیزیکی (PHY) مسئول کانال رادیویی دستگاه است. لایه پیوند (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 بایت آدرس IP در اینترنت به خاطر دارند. در ابتدا فکر می کردیم که کافی است، اما اکنون هنوز نمی توانیم به آدرس 6 بایتی سوئیچ کنیم. برای اینکه این اشتباه تکرار نشود و دستان بازیگوش DIYers را آزاد بگذارد، SIG بلافاصله تصمیم گرفت UUID های 128 بیتی را معرفی کند. این شخص من را به یاد باند بدون مجوز 433 مگاهرتز می اندازد که از کانال رادیویی به انواع Kulibins داده شده است. در مورد ما، یک شناسه 128 بیتی از خدمات و ویژگی ها ایجاد شد. این بدان معناست که ما، برای خدمات و دستگاه های خود، می توانیم تقریباً از هر مقدار 128 بیتی استفاده کنیم. با این حال، احتمال رسیدن به یک UUID به صفر می‌رسد.
در واقع، UUID های کوتاه 16 بیتی دارای پسوند خود به مقدار 128 بیت هستند. در مشخصات این افزونه Bluetooth Base UUID نام دارد و دارای مقدار 00000000-0000-1000-8000-00805F9B34FB است. به عنوان مثال، اگر ویژگی 16 بیتی UUID دارای مقدار 0x1234 باشد، آنگاه UUID معادل 128 بیتی مقدار 00001234-0000-1000-8000-00805F9B34FB را خواهد داشت. و حتی فرمول مربوطه داده شده است:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
من نمی دانم این عدد جادویی از کجا آمده است. اگر یکی از خوانندگان می داند، در نظرات بنویسد (کاربری با نام مستعار Sinopteek قبلاً این کار را انجام داده است. نظرات را ببینید). در مورد ارائه UUID های 128 بیتی، در اصل شما می توانید از یک ویژه استفاده کنید چه کسی این کار را برای شما انجام خواهد داد
ATTy GATTy...
در واقع، پس از آن سرگرم کننده آغاز می شود. اجازه دهید یادآوری کنم که ATT بر اساس رابطه مشتری و سرور است. اکنون ما به دستگاه سرور نگاه می کنیم. این شامل اطلاعاتی مانند مقادیر سنسور، وضعیت سوئیچ نور، اطلاعات مکان و غیره است. اکنون که همه "شرکت کنندگان در رژه ما" شماره گذاری شده اند، باید آنها را به نحوی در حافظه دستگاه قرار دهیم. برای این کار آنها را در جدولی به نام جدول ویژگی قرار می دهیم. این را خوب به خاطر بسپار این قلب BLE است. این همان چیزی است که در ادامه بررسی خواهیم کرد. حالا هر خط را یک ویژگی می نامیم. این جدول در اعماق پشته قرار دارد و قاعدتاً دسترسی مستقیم به آن نداریم. ما آن را مقداردهی اولیه می کنیم و به آن دسترسی پیدا می کنیم، اما آنچه در داخل اتفاق می افتد از ما در پشت هفت مهر پنهان است.
بیایید به تصویر از مشخصات نگاه کنیم، اما قبل از آن، من می خواهم بلافاصله توجه را به سردرگمی مکرر در اصطلاحات، یعنی در توصیفگرها جلب کنم. نقش توصیفگر تکمیل کننده توصیف مشخصه است. زمانی که نیاز به گسترش قابلیت های آن باشد، از توصیفگرها استفاده می شود. آنها نیز ویژگی هستند و درست مانند خدمات و ویژگی ها در جدول ویژگی ها قرار دارند. در قسمت دوم مقاله به تفصیل آنها را بررسی خواهیم کرد. با این حال، گاهی اوقات توصیفگرها به شماره ردیف در جدول ویژگی اشاره می کنند. این را باید در نظر داشت. برای جلوگیری از سردرگمی، ما از اصطلاح "نشانگر ویژگی" برای این اهداف استفاده خواهیم کرد.
بنابراین یک ویژگی یک مقدار گسسته است که دارای ویژگی های زیر است:
1. Attribute Handle نمایه جدول مربوط به ویژگی است
2. Attribute Type یک UUID است که نوع آن را توصیف می کند
3. Attribute Value داده ای است که توسط اشاره گر ویژگی نمایه می شود
4. مجوزهای مشخصه بخشی از یک ویژگی، مجوزهایی هستند که با استفاده از پروتکل ویژگی قابل خواندن یا نوشتن نیستند.
چگونه همه اینها را بفهمیم؟ نشانگر ویژگی، به طور نسبی، شماره آن در جدول ما است.
این به مشتری اجازه می دهد تا در درخواست های خواندن یا نوشتن به یک ویژگی ارجاع دهد. ما می توانیم خطوط (ویژگی ها) خود را از 0x0001 تا 0xFFFF شماره گذاری کنیم. در ارتباط ما با قفسه کتاب، این شماره کارت در کاتالوگ کاغذی است. به طور مشابه، مانند فهرست کتابخانه، کارت ها به ترتیب افزایش تعداد مرتب شده اند. تعداد هر خط بعدی باید بیشتر از خط قبلی باشد. درست مانند کتابخانه، گاهی اوقات برخی از کارت ها گم می شوند، بنابراین با ما، ممکن است شکاف هایی در شماره گذاری خطوط وجود داشته باشد. این مجاز است. نکته اصلی این است که آنها به تدریج پیش می روند.
نوع مشخصه مشخص می کند که مشخصه چه چیزی را نشان می دهد. بر اساس قیاس با زبان C،
جایی که بولی، متغیرهای عددی و رشته‌ها وجود دارد، بنابراین اینجاست. بر اساس نوع ویژگی ما تشخیص می دهیم
با چه چیزی سر و کار داریم و چگونه می توانیم به کار با این ویژگی ادامه دهیم. در زیر به انواع خاصی از ویژگی ها نگاه خواهیم کرد. به عنوان مثال، "اعلامیه خدمات" (0x2800)، "اعلامیه مشخصه" (0x2803)، "اعلامیه توصیفگر" (0x2902).
ارزش یک صفت معنای واقعی آن است، توتولوژی را ببخشید. اگر نوع ویژگی یک رشته باشد، مقدار مشخصه می تواند به عنوان مثال، شعار "Hello World !!!" باشد. اگر نوع مشخصه یک "اعلام سرویس" باشد، ارزش آن خود سرویس است. و گاهی اوقات این اطلاعاتی در مورد مکان یافتن سایر ویژگی ها و ویژگی های آنها است.
مجوزهای ویژگی به سرور اجازه می‌دهد بفهمد که آیا دسترسی خواندن یا نوشتن مجاز است یا خیر.
توجه داشته باشید که این مجوزها فقط برای مقدار مشخصه اعمال می شود و نه برای خود نشانگر، نوع یا فیلد مجوز. آن ها اگر ضبط ویژگی مجاز باشد، می توانیم به عنوان مثال، خط "Hello World !!!" را تغییر دهیم. به خط "صبح بخیر". اما ما نمی توانیم نوشتن یک خط جدید را ممنوع کنیم یا نوع ویژگی را تغییر دهیم و خط را به عنوان "اعلامیه خدمات" تعیین کنیم. هنگامی که یک کلاینت با یک سرور تماس می گیرد، مشتری ویژگی های آن را درخواست می کند. این به مشتری اجازه می دهد تا بداند سرور چه چیزی می تواند ارائه دهد. اگرچه خواندن و نوشتن مقادیر لازم نیست.
چه چیزی به نظر می رسد
مفهوم گات این است که صفات را در یک جدول مشخصه با هم به ترتیبی بسیار خاص و منطقی گروه بندی کنیم. بیایید نگاهی دقیق‌تر به مشخصات ضربان قلب زیر بیندازیم. سمت چپ ترین ستون این جدول اختیاری است. به سادگی برای ما توضیح می دهد که این خط (ویژگی) چیست. تمام ستون های دیگر قبلاً برای ما آشنا هستند.
در بالای هر گروه ما همیشه یک ویژگی اعلام سرویس داریم. نوع آن همیشه 0x2800 است و نشانگر بستگی به این دارد که چند ویژگی از قبل در جدول وجود دارد. مجوزهای آن همیشه فقط خواندنی است، بدون هیچ گونه احراز هویت یا مجوز. کمی بعد در مورد این مفاهیم صحبت خواهیم کرد. مقدار UUID دیگری است که مشخص می کند سرویس چیست. در جدول، مقدار 0x180D است که توسط بلوتوث SIG به عنوان یک سرویس ضربان قلب تعریف شده است.
پس از اعلام سرویس، اعلام ویژگی می آید. از نظر شکل شبیه به یک اعلامیه خدمات است. UUID آن همیشه 0x2803 است و مجوزهای آن همیشه فقط خواندنی بدون هیچ گونه احراز هویت یا مجوزی است. بیایید به قسمت Attribute Value نگاهی بیندازیم که شامل برخی از داده ها است. همیشه شامل یک اشاره گر، یک UUID و مجموعه ای از ویژگی ها است. این سه عنصر، اعلام بعدی مقدار مشخصه را توصیف می کنند. اشاره گر به طور طبیعی مکان اعلان مقدار مشخصه را در جدول ویژگی نشان می دهد. UUID توصیف می کند که چه نوع اطلاعات یا ارزشی را می توانیم انتظار داشته باشیم. به عنوان مثال، مقدار دما، وضعیت کلید چراغ، یا مقدار دلخواه دیگر. و در نهایت ویژگی ها، که نحوه تعامل با مقدار مشخصه را توصیف می کنند.
یک دام دیگر در اینجا در انتظار ما است. با مجوزهای ویژگی و ویژگی های مشخصه مرتبط است. بیایید به تصویر خواص فیلد بیت از مشخصات نگاه کنیم.
همانطور که می بینید، فیلدهایی نیز در اینجا وجود دارند که قابلیت خواندن و نوشتن را ارائه می دهند. ممکن است تعجب کنید که چرا ما مجوز خواندن/نوشتن برای ویژگی و ویژگی داریم
خواندن/نوشتن برای مقدار مشخصه؟ آیا آنها نباید همیشه یکسان باشند؟ واقعیت این است که ویژگی های مقدار مشخصه در واقع فقط توصیه هایی برای مشتری هستند که در GATT و لایه های برنامه استفاده می شوند. اینها صرفاً نکاتی در مورد آنچه مشتری ممکن است از ویژگی اعلان مشخصه انتظار داشته باشد هستند. بیایید به این موضوع با جزئیات بیشتری نگاه کنیم. یک ویژگی چه نوع مجوزهایی دارد؟
1. مجوزهای دسترسی:
- خواندن
- رکورد
- خواندن و نوشتن
2. مجوز احراز هویت:
- احراز هویت مورد نیاز است
- بدون نیاز به احراز هویت
3. مجوز مجوز:
- مجوز لازم است
- بدون نیاز به مجوز
تفاوت اصلی بین وضوح ویژگی و ویژگی های مشخصه این است که اولی برای سرورها و دومی برای مشتریان اعمال می شود. سرور ممکن است مجاز به خواندن مقدار مشخصه باشد، اما ممکن است نیاز به احراز هویت یا مجوز داشته باشد. بنابراین، هنگامی که مشتری ویژگی های مشخصه را درخواست می کند، دریافت می کنیم که خواندن مجاز است. اما وقتی می خواهیم بخوانیم با خطا مواجه می شویم. بنابراین، می توانیم با خیال راحت در مورد اولویت مجوزها بر خواص صحبت کنیم. در سمت کلاینت، ما نمی توانیم اطلاعاتی در مورد مجوزهای یک ویژگی به دست آوریم.
توصیفگر
بیایید به سفره خود برگردیم. پس از اعلام مقدار یک مشخصه، اعلان ویژگی های زیر امکان پذیر است:
1. اعلام ویژگی های جدید (یک سرویس می تواند ویژگی های زیادی داشته باشد)
2. اعلامیه خدمات جدید (ممکن است تعداد زیادی از آنها در جدول وجود داشته باشد)
3. اعلام یک دسته
در مورد مشخصه اندازه گیری ضربان قلب، در جدول ما، اعلام مقدار مشخصه با اعلام توصیفگر همراه است. توصیفگر یک ویژگی با اطلاعات اضافی در مورد یک مشخصه است. چندین نوع توصیف کننده وجود دارد. در قسمت دوم این مقاله به تفصیل در مورد آنها صحبت خواهیم کرد. در حال حاضر، ما فقط بر روی توصیفگر پیکربندی ویژگی های مشتری (CCCD) می پردازیم. UUID برابر با 0x2902 دارد. با استفاده از این توصیفگر، کلاینت این امکان را دارد که نشانه یا اعلان را در سرور فعال کند. تفاوت بین آنها کم است، اما هنوز وجود دارد. اطلاع رسانی نیازی به تایید دریافت از مشتری ندارد. نشان دادن به این نیاز دارد، اگرچه در سطح گات رخ می دهد، اما به سطح برنامه نمی رسد. می پرسی چرا اینطوری؟ افسوس من این را نمی دانم. بگذارید فقط بگویم که کارشناسان نوردیک استفاده از اعلان ها را توصیه می کنند. علاوه بر این، بررسی یکپارچگی بسته (با استفاده از CRC) در هر دو مورد اتفاق می افتد.
نتیجه
در پایان مقاله می خواهم این را بگویم. جدول آخر کمی گیج کننده است. با این حال، من آن را انتخاب کردم زیرا داده شده است ، که من بر آن تکیه می کنم. در قسمت دوم مقاله خود، قصد دارم بیشتر به مشخصات بلوتوث 4.0 بپردازم. نمودارها و نقشه های صحیح تری در آنجا منتظر ما هستند. در قسمت سوم، من می خواهم گزارش به دست آمده با استفاده از برنامه Wireshark را از یکی از ابزارها تجزیه و تحلیل کنم و تمام نظریه ای را که در حال مطالعه آن هستیم به صورت زنده ببینم.
کارمند گروه شرکت ها
پچرسکیخ ولادیمیر
منبع: www.habr.com