🧩 کالبدشکافی فنی AhuraRTOS
رویکردی نوین در طراحی RTOS برای ARM Cortex-M
بخش ۱ | معماری Kernel و فلسفه Portability
🔹 ۱. فراتر از انتزاعهای رایج در Embedded
اگر با سیستمهای نهفته کار کرده باشید، احتمالاً با یک سؤال مهم روبهرو شدهاید:
❓ چرا با تغییر معماری یا مدل پردازنده، باید بخشهایی از Kernel یک RTOS را نیز تغییر دهیم؟
در بسیاری از RTOSهای سنتی، Port کردن سیستمعامل به یک معماری جدید فقط به تغییر HAL محدود نمیشود و گاهی بخشهایی از Kernel، Scheduler یا منطق داخلی سیستمعامل نیز تحت تأثیر قرار میگیرد.
AhuraRTOS با یک فلسفه متفاوت طراحی شده است:
🎯 مرز مشخص و غیرقابل عبور بین Application و Kernel
در AhuraRTOS، Kernel بهگونهای طراحی شده که فایلهای داخلی آن نباید برای هر پروژه یا پردازنده ویرایش شوند.
پیکربندی سیستمعامل از طریق یک فایل متمرکز در سمت Application انجام میشود:
os_config.h
این موضوع باعث میشود Kernel عملاً مانند یک Static Library مستقل عمل کند؛ یعنی منطق اصلی سیستمعامل وابستگی مستقیمی به جزئیات سختافزار ندارد.
ارتباط Kernel با معماری پردازنده نیز از طریق یک Port Interface مشخص انجام میشود.
⚙️ ۲. معماری Kernel و فلسفه Portability
معماری AhuraRTOS بر پایه یک اصل مهم شکل گرفته است:
Portable Kernel + Architecture-Specific Port
یعنی منطق سیستمعامل تا حد ممکن در کد قابلحمل C باقی میماند و فقط قسمتهایی که واقعاً به معماری CPU وابسته هستند، در لایه Port قرار میگیرند.
نکته جالب اینجاست که خانواده گسترده ARM Cortex-M، از Cortex-M0 تا Cortex-M85، با تعداد محدودی پیادهسازی مشترک در لایه Port پوشش داده میشود.
در این معماری، Port فقط یک لایه ساده برای اتصال Kernel به CPU نیست؛ بلکه مسئول انجام عملیات حساس و وابسته به معماری است.
از طرف دیگر، استفاده گسترده از Inline Functions در این لایه میتواند سربار Function Call را کاهش دهد و مسیرهای حساس Kernel را سبکتر نگه دارد.
📌 تقسیم مسئولیتها
Kernel — Portable C
🔸 مدیریت Ready List و Scheduler با پیچیدگی O(1)
🔸 Mutex / Semaphore / Event و منطق IPC
🔸 Software Timer و Work Queue
🔸 مدیریت Heap
🔸 Notificationهای Task
🔸 مدیریت Priority و Priority Inheritance
در مقابل:
Port — Architecture Specific
🔸 Context Switch با استفاده از PendSV
🔸 مدیریت Tick و Timer Interrupt
🔸 Critical Section
🔸 عملیات Atomic وابسته به معماری
🔸 ایجاد Initial Stack Frame
🔸 مدیریت Registerهای خاص پردازنده مانند PSPLIM و FPU
💡 نتیجه این تفکیک چیست؟
اگر Kernel از جزئیات CPU بیخبر باشد، تغییر معماری نباید باعث تغییر منطق اصلی سیستمعامل شود.
در چنین معماریای:
Application
⬇️
os_config.h
⬇️
Portable Kernel
⬇️
Port Interface
⬇️
ARM Cortex-M
و این دقیقاً همان نقطهای است که Portability واقعی از یک شعار معماری به یک تصمیم مهندسی تبدیل میشود.
🔜 ادامه دارد...
@Amin_Techlab
5
1August 8, 2026 402 4
