OpenThread سیستم عامل و پلتفرم آگنوستیک است، با یک لایه انتزاعی پلتفرم باریک (PAL). این PAL تعریف می کند:
- رابط زنگ برای تایمر آزاد با زنگ هشدار
- رابط های اتوبوس (UART، SPI) برای برقراری ارتباط پیام های CLI و Spinel
- رابط رادیویی برای ارتباطات IEEE 802.15.4-2006
- روال های اولیه سازی ویژه GCC
- آنتروپی برای تولید اعداد تصادفی واقعی
- سرویس تنظیمات برای ذخیره سازی پیکربندی غیر فرار
- رابط ورود به سیستم برای ارسال پیام های گزارش OpenThread
- روال های اولیه سازی خاص سیستم
همه APIها باید بر اساس بسته پشتیبانی ساخت (BSP) لایه انتزاعی سخت افزاری (HAL) پیاده سازی شوند.
فایل های API باید در دایرکتوری های زیر قرار گیرند:
| تایپ کنید | فهرست راهنما |
|---|---|
| پیاده سازی PAL مخصوص پلتفرم | /openthread/examples/platforms/ platform-name |
| فایل های سرصفحه - API ذخیره سازی غیر فرار | /openthread/examples/platforms/utils |
| همه فایل های هدر دیگر | /openthread/include/openthread/platform |
| HAL BSP | /openthread/third_party/ platform-name |
زنگ خطر. هشدار
اعلامیه API:
/openthread/include/openthread/platform/alarm-milli.h
Alarm API خدمات اساسی زمان بندی و هشدار را برای اجرای تایمر لایه بالایی ارائه می دهد.
دو نوع خدمات هشدار وجود دارد، میلی ثانیه و میکروثانیه . میلی ثانیه برای یک پلت فرم سخت افزاری جدید مورد نیاز است. میکرو ثانیه اختیاری است.
UART
اعلامیه API:
/openthread/examples/platforms/utils/uart.h
UART API ارتباطات پورت سریال اساسی را از طریق رابط UART پیاده سازی می کند.
در حالی که افزونه های OpenThread CLI و NCP برای تعامل با طرف میزبان به رابط UART وابسته هستند، پشتیبانی UART API اختیاری است. با این حال، حتی اگر قصد استفاده از این افزونه‌ها را در نمونه پلتفرم سخت‌افزاری جدید خود ندارید، به چند دلیل به شما توصیه می‌کنیم که پشتیبانی اضافه کنید:
- CLI برای تأیید صحت عملکرد پورت مفید است
- ابزار اتوماسیون هارنس از رابط UART برای کنترل OpenThread برای اهداف آزمایش و صدور گواهی استفاده می کند.
اگر پلتفرم سخت افزاری هدف به جای UART از ماژول CDC USB پشتیبانی می کند، مطمئن شوید که:
- درایور صحیح USB CDC را در سمت میزبان نصب کنید
- پیاده سازی UART API را با درایور CDC USB (همراه با BSP) در سمت OpenThread، با استفاده از نمونه های اولیه عملکرد مشابه جایگزین کنید.
رادیو
اعلامیه API:
/openthread/include/openthread/platform/radio.h
Radio API تمام توابع لازم را که توسط لایه MAC بالای IEEE 802.15.4 فراخوانی شده است، تعریف می کند. تراشه رادیویی باید به طور کامل با مشخصات IEEE 802.15.4-2006 2.4GHz مطابقت داشته باشد.
به دلیل بهبود ویژگی کم مصرف، OpenThread به همه پلتفرم‌ها نیاز دارد که به طور پیش‌فرض قاب خودکار در انتظار (انتقال غیرمستقیم) را پیاده‌سازی کنند، و جدول مطابقت آدرس منبع نیز باید در فایل منبع radio.h شود.
با این حال، اگر نمونه پلت فرم سخت افزاری جدید شما با منابع محدود باشد، جدول آدرس منبع را می توان به عنوان طول صفر تعریف کرد. برای اطلاعات بیشتر به قاب خودکار در انتظار مراجعه کنید.
متفرقه/تنظیم مجدد
اعلامیه API:
/openthread/include/openthread/platform/misc.h
Misc/Reset API روشی را برای بازنشانی نرم افزار روی تراشه و جویا شدن دلیل آخرین تنظیم مجدد ارائه می دهد.
آنتروپی
اعلامیه API:
/openthread/include/openthread/platform/entropy.h
Entropy API یک مولد اعداد تصادفی واقعی (TRNG) برای لایه بالایی فراهم می کند که برای حفظ دارایی های امنیتی برای کل شبکه OpenThread استفاده می شود. API باید تضمین کند که یک شماره تصادفی جدید برای هر فراخوانی تابع تولید می شود. دارایی های امنیتی تحت تأثیر TRNG عبارتند از:
- AES CCM هیچ
- لرزش تصادفی تاخیری
- آدرس گسترده دستگاه ها
- دوره تصادفی اولیه در تایمر قطره ای
- شناسه های رمز/پیام CoAP
توجه داشته باشید که بسیاری از پلتفرم‌ها قبلاً یک مولد اعداد تصادفی را ادغام کرده‌اند که API را در بسته BSP خود نشان می‌دهد. در صورتی که پلتفرم سخت افزاری هدف از TRNG پشتیبانی نمی کند، از نمونه گیری ماژول ADC برای تولید یک عدد تصادفی با طول ثابت استفاده کنید. در صورت لزوم برای برآوردن الزامات TRNG (uint32_t) از چندین تکرار نمونه برداری کنید.
هنگامی که ماکرو MBEDTLS_ENTROPY_HARDWARE_ALT روی 1 تنظیم می شود، این API باید روشی را نیز برای تولید آنتروپی سخت افزاری مورد استفاده در کتابخانه mbedTLS ارائه دهد.
ذخیره سازی غیر فرار
اعلامیه های API:
/openthread/include/openthread/platform/flash.h
یا
/openthread/include/openthread/platform/settings.h
نیاز ذخیره سازی غیر فرار را می توان با اجرای یکی از دو API ذکر شده در بالا برآورده کرد. Flash API یک درایور حافظه فلش را پیاده سازی می کند، در حالی که Settings API عملکردهایی را برای اجرای عملیات فلش زیرین در لایه بالایی ارائه می دهد.
این API ها در معرض لایه بالایی قرار می گیرند:
- اندازه ذخیره‌سازی غیر فرار موجود که برای ذخیره داده‌های برنامه استفاده می‌شود (به عنوان مثال، مجموعه داده عملیاتی فعال/در انتظار، پارامترهای شبکه فعلی و اعتبار دستگاه‌های رشته برای اتصال مجدد پس از تنظیم مجدد)
- خواندن، نوشتن، پاک کردن، و پرس و جو عملیات وضعیت فلش
از OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE در فایل پیکربندی هسته نمونه پلت فرم خود استفاده کنید تا مشخص کنید پلتفرم از کدام API باید استفاده کند. اگر روی 1 تنظیم شود، Flash API باید اجرا شود. در غیر این صورت، تنظیمات API باید پیاده سازی شود.
این پرچم باید در /openthread/examples/platforms/ platform-name /openthread-core- platform-name -config.h شود.
ورود به سیستم
اعلامیه API:
/openthread/include/openthread/platform/logging.h
Logging API عملکرد ثبت و اشکال زدایی OpenThread را با سطوح مختلف خروجی اشکال زدایی در دسترس اجرا می کند. اگر قصد ندارید از ورود OpenThread در نمونه پلت فرم سخت افزاری جدید خود استفاده کنید، این API اختیاری است.
بالاترین و دقیق ترین سطح OPENTHREAD_LOG_LEVEL_DEBG است که تمام اطلاعات بسته های خام را چاپ می کند و خطوط را از طریق پورت سریال یا در ترمینال ثبت می کند. سطح اشکال زدایی را انتخاب کنید که به بهترین وجه نیازهای شما را برآورده کند.
سیستم خاص
اعلامیه API:
/openthread/examples/platforms/openthread-system.h
API خاص سیستم در درجه اول عملیات اولیه سازی و اولیه سازی را برای پلت فرم سخت افزاری انتخاب شده ارائه می دهد. این API توسط خود کتابخانه OpenThread فراخوانی نمی شود، اما ممکن است برای سیستم/RTOS شما مفید باشد. همچنین می توانید مقدار دهی اولیه ماژول های دیگر (به عنوان مثال UART، Radio، Random، Misc/Reset) را در این فایل منبع پیاده سازی کنید.
پیاده سازی این API بستگی به مورد استفاده شما دارد. اگر می خواهید از برنامه های CLI و NCP تولید شده برای یک پلتفرم نمونه استفاده کنید، باید این API را پیاده سازی کنید. در غیر این صورت، هر API را می توان برای ادغام نمونه درایورهای پلتفرم در سیستم/RTOS شما پیاده سازی کرد.