اینم نتیجه زحمات شما

خیلی ممنونم بابت تمام زحماتی که میکشید و نتیجه ای که انشالله که در آینده صنعت الکترونیک ایران عزیزمون شاهدش خواهیم بود

پروژه تجاری شده آقای مهندس رزگار صالح زاده دانشپذیر دوره «طراحی فیبرهای مدارچاپی با نرم افزار Altium Designer»
آمپلی فایر ۶۰ وات ۴ کانال خودرو

تبلیغ ما نتیجه کار ماست...

تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com

نصب سیستم عامل «اهورا» روی کیوب
طراحی مهندس نیما عسگری
@Nimaltd

واقعا زحمت کشیدن و جای تقدیر داره🌹

https://github.com/AhuraRTOS/AhuraRTOS/blob/main/doc/stm32cubemx.md

🚀 معرفی یک پروژه مهم در دنیای Embedded Systems؛ AhuraRTOS
دوستانی که در حوزه الکترونیک و سیستم‌های Embedded فعالیت می‌کنیم، احتمالاً با پروژه‌ها و کتابخانه‌های مهندس عسکری (nimaltd) آشنا هستیم و در بسیاری از پروژه‌ها از کتابخانه‌های ایشان استفاده کرده‌ایم.
حالا مهندس عسگری یک پروژه بزرگ و جذاب را توسعه داده‌اند با نام AhuraRTOS؛ یک پروژه در حوزه Real-Time Operating System برای سیستم‌های Embedded که ارزش بررسی و آشنایی بیشتری دارد.
در پست‌های بعدی قصد داریم AhuraRTOS را قدم‌به‌قدم بررسی کنیم و درباره معماری، قابلیت‌ها، ساختار پروژه و نحوه استفاده از آن بیشتر صحبت کنیم.
🔗 GitHub:
AhuraRTOS

🧩 کالبدشکافی فنی 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 واقعی از یک شعار معماری به یک تصمیم مهندسی تبدیل می‌شود.
🔜 ادامه دارد...

⚙️ کالبدشکافی فنی AhuraRTOS
بخش ۲ | Scheduling، Priority و Context Switching

🧠 ۳. مکانیسم Scheduling و مدیریت Priority
یکی از ویژگی‌های مهم AhuraRTOS، استفاده از Scheduler با پیچیدگی O(1) است.
یعنی زمان انتخاب Task بعدی به تعداد Taskهای سیستم وابسته نیست؛ چه ۲ Task داشته باشیم و چه ۳۲ Task، انتخاب Task آماده با زمان ثابت انجام می‌شود.
🔹 ۳۲ سطح Priority
AhuraRTOS از ۳۲ سطح اولویت، از 0 تا 31، استفاده می‌کند. این ساختار با یک 32-bit Bitmap هماهنگ است و وضعیت Taskهای Ready را به‌صورت فشرده نگهداری می‌کند.
🔹 Bitmap + CLZ
برای پیدا کردن بالاترین Priority آماده، Bitmap بررسی می‌شود. در ARMv7-M و معماری‌های بالاتر، دستور سخت‌افزاری CLZ (Count Leading Zeros) می‌تواند برای پیدا کردن موقعیت بیت موردنظر استفاده شود.
در نتیجه Scheduler به‌جای بررسی Priorityها به‌صورت ترتیبی، مستقیماً به Priority مناسب دسترسی پیدا می‌کند.
🔹 Round-Robin
اگر چند Task دارای Priority یکسان باشند، AhuraRTOS امکان اجرای چرخشی آن‌ها را فراهم می‌کند.
پارامتر:
OS_CONFIG_TIME_SLICE_TICKS
تعداد Tickهای مربوط به Time Slice را مشخص می‌کند. با قرار دادن مقدار آن روی 0، Round-Robin غیرفعال شده و سربار Context Switching کاهش پیدا می‌کند.

🛡 ۴. چرا PendSV و نه SVC؟
در بسیاری از RTOSها از SVC برای ورود به Kernel یا شروع اولین Task استفاده می‌شود.
اما AhuraRTOS رویکرد متفاوتی دارد:
SVC → Application
PendSV → Context Switching
در این طراحی، SVC برای Application آزاد باقی می‌ماند و RTOS برای Context Switch از PendSV استفاده می‌کند.
حتی شروع اولین Task نیز از مسیر PendSV انجام می‌شود. Kernel با بررسی وضعیت PSP می‌تواند تشخیص دهد که آیا هنوز Taskای اجرا نشده است یا خیر.
⚡️ Context Switch در سطح پایین
در PendSV، وضعیت Context مربوط به Task فعلی ذخیره و Context مربوط به Task بعدی بازیابی می‌شود.
رجیسترهای:
R4 – R11
در این فرآیند مدیریت می‌شوند.
همچنین مدیریت FPU به‌صورت هوشمند انجام می‌شود تا در Taskهایی که از محاسبات Floating-Point استفاده نمی‌کنند، هزینه اضافی Context Switching ایجاد نشود.
🎯 در نهایت، این طراحی سه هدف مهم را دنبال می‌کند:
O(1) Scheduling
Context Switching بهینه
آزاد ماندن SVC برای Application
🔜 ادامه دارد...

⚙️ کالبدشکافی فنی AhuraRTOS
بخش ۳ | IPC، Preemption، Atomics و مدیریت حافظه

🔐 ۵. ارتباطات بین‌تسکی و کنترل Preemption
در یک RTOS، فقط انتقال داده بین Taskها مهم نیست؛ نحوه محافظت از داده‌های مشترک هم اهمیت زیادی دارد.
AhuraRTOS برای این کار دو مکانیزم متفاوت در اختیار برنامه‌نویس قرار می‌دهد:
🔹 Scheduler Lock
با:
os_kernel_lock()
Scheduler متوقف می‌شود، اما Interruptها همچنان فعال هستند.
یعنی Task دیگری نمی‌تواند جای Task فعلی را بگیرد، اما ISRها می‌توانند اجرا شوند.
این روش برای محافظت از داده‌هایی که فقط بین چند Task مشترک هستند مناسب است، چون باعث افزایش غیرضروری Interrupt Latency نمی‌شود.
🔹 Critical Section
با:
os_critical_enter()
Interruptها نیز Mask می‌شوند.
بنابراین زمانی کاربرد دارد که داده‌ای بین یک Task و ISR به‌صورت مشترک استفاده می‌شود و باید از دسترسی هم‌زمان جلوگیری شود.
تفاوت کلیدی:
Scheduler Lock → جلوگیری از Context Switch
Critical Section → جلوگیری از Interrupt + Context Switch
🔒 Mutex و Priority Inheritance
یکی از مشکلات کلاسیک RTOSها، Priority Inversion است.
فرض کنید:
Low Priority Task → Mutex را در اختیار دارد
و هم‌زمان:
High Priority Task → منتظر همان Mutex است
در این حالت یک Task با Priority متوسط می‌تواند باعث شود Task با Priority بالا برای مدت طولانی منتظر بماند.
AhuraRTOS برای کاهش این مشکل از Single-level Priority Inheritance استفاده می‌کند.
یعنی Priority مالک Mutex، به‌صورت موقت تا سطح Task منتظر افزایش پیدا می‌کند و پس از آزاد شدن Mutex، Priority به حالت قبلی برمی‌گردد.
📬 Task Notification
برای ارتباطات ساده و سریع، AhuraRTOS از Task Notification استفاده می‌کند.
Notification مستقیماً داخل TCB (Task Control Block) قرار دارد و می‌تواند مانند یک Mailbox بسیار کوچک عمل کند.
مزیت اصلی:
⚡️ بدون نیاز به ساخت یک Object جداگانه IPC
⚡️ مصرف حافظه کمتر
⚡️ مسیر سریع برای بیدار کردن یک Task

⚛️ ۶. اما Atomics و مدیریت حافظه
AhuraRTOS بین معماری‌های مختلف ARM در پیاده‌سازی عملیات Atomic تفاوت قائل می‌شود.
🔹 ARMv6-M — Cortex-M0/M0+
به دلیل محدودیت‌های این معماری، عملیات Atomic با استفاده از Critical Section پیاده‌سازی می‌شود.
🔹 ARMv7-M و بالاتر
از قابلیت‌های سخت‌افزاری ARM مانند LDREX/STREX برای پیاده‌سازی عملیات Atomic استفاده می‌شود و امکان اجرای Lock-free فراهم می‌شود.

🧠 مدیریت Kernel Heap
مدیریت Heap در AhuraRTOS از الگویی مشابه heap_4 استفاده می‌کند، اما یک نکته مهم دارد:
Address-ordered Free List
بلوک‌های آزاد بر اساس آدرس مدیریت می‌شوند؛ بنابراین هنگام آزاد شدن حافظه، بلوک‌های مجاور می‌توانند با یکدیگر Coalesce شوند.
نتیجه:
Free Block + Adjacent Free Block → Larger Free Block
این کار به کاهش Fragmentation کمک کرده و امکان استفاده مجدد بهتر از حافظه را فراهم می‌کند.
📦 Queue و جلوگیری از Silent Overflow
در Queueهای Static، استفاده از:
OS_QUEUE_DEFINE_STATIC
باعث می‌شود اندازه آیتم و ظرفیت Queue مستقیماً از آرایه و با استفاده از sizeof مشخص شود.
این رویکرد احتمال خطاهایی را کاهش می‌دهد که در آن توسعه‌دهنده ظرفیت Queue را بیشتر از حافظه واقعی تعریف می‌کند؛ خطایی که ممکن است در ظاهر بدون مشکل اجرا شود اما در زمان اجرا باعث Memory Corruption شود.

🎯 در این بخش دیدیم که AhuraRTOS فقط روی Scheduler تمرکز ندارد؛ بلکه در لایه‌های IPC، Synchronization، Atomic Operations و Memory Management نیز تلاش می‌کند سربار کم و رفتار قابل پیش‌بینی داشته باشد.
🔜 ادامه دارد...

⚙️ کالبدشکافی فنی AhuraRTOS
بخش ۴ | Security، TrustZone و فلسفه Debugging

🛡 ۷. امنیت و قابلیت‌های پیشرفته
در نسل‌های جدید ARM، امنیت فقط یک قابلیت نرم‌افزاری نیست و بخشی از آن مستقیماً در سخت‌افزار پردازنده پیاده‌سازی شده است.
در ARMv8-M و پردازنده‌هایی مانند Cortex-M33، قابلیت‌هایی مثل TrustZone امکان جداسازی محیط Secure و Non-Secure را فراهم می‌کنند.
AhuraRTOS برای این معماری از قابلیت‌هایی مانند PSPLIM (Process Stack Pointer Limit) نیز استفاده می‌کند.
PSPLIM یک Limit سخت‌افزاری برای Stack Pointer ایجاد می‌کند و می‌تواند در تشخیص Stack Overflow نقش داشته باشد.
🔐 TrustZone و Context
برای پشتیبانی از TrustZone، AhuraRTOS امکان استفاده از Callbackهای:
context_save()
و
context_restore()
را فراهم می‌کند تا وضعیت مربوط به Secure State در زمان Context Switching مدیریت شود.
البته پشتیبانی از این بخش در برخی پلتفرم‌ها هنوز نیازمند بررسی و اعتبارسنجی سخت‌افزاری است.
🧩 Core Affinity
در سیستم‌های چند‌هسته‌ای، فقط انتخاب Task کافی نیست؛ گاهی باید مشخص شود هر Task روی کدام CPU اجرا شود.
قابلیت Core Affinity اجازه می‌دهد اجرای یک Task به هسته یا مجموعه‌ای از هسته‌های مشخص محدود شود.
این قابلیت در سیستم‌های چند‌هسته‌ای می‌تواند برای:
⚡️ مدیریت بهتر Performance
🔋 بهینه‌سازی مصرف توان
🎯 کنترل دقیق‌تر اجرای Taskها
مورد استفاده قرار گیرد.

🧪 ۸. فلسفه Debugging و Linker Error
یکی از تصمیم‌های جالب AhuraRTOS این است که بعضی خطاها را به‌جای زمان اجرا، در Link Time آشکار می‌کند.
برای مثال، اگر یک Callback حیاتی مانند:
os_assert_failed_cb()
در Application پیاده‌سازی نشده باشد، پروژه ممکن است در مرحله Link با خطا مواجه شود.
این رویکرد یک مزیت مهم دارد:
❌ خطای پنهان در Runtime
✅ خطای مشخص در Build/Link
یعنی مشکل قبل از اجرای Firmware مشخص می‌شود و احتمال رسیدن سیستم به یک Silent Halt کاهش پیدا می‌کند.
📊 Self-Test و اندازه‌گیری Cycle-Accurate
AhuraRTOS همچنین یک ماژول Self-Test دارد که برای بررسی عملکرد Kernel و Port روی سخت‌افزار جدید کاربرد دارد.
این تست‌ها می‌توانند Benchmarkهای Cycle-Accurate ارائه کنند و حتی سربار خودِ عملیات اندازه‌گیری را در نظر بگیرند.
در نتیجه مهندس می‌تواند قبل از توسعه Application، مواردی مانند:
🔹 عملکرد Port
🔹 هزینه Context Switch
🔹 زمان اجرای توابع Kernel
🔹 و Worst-Case Execution Time یا WCET
را روی سخت‌افزار واقعی بررسی کند.

🎯 فلسفه کلی این بخش را می‌توان این‌طور خلاصه کرد:
خطا را زودتر پیدا کن، عملکرد را اندازه بگیر و وابستگی به رفتارهای غیرقابل‌پیش‌بینی Runtime را کاهش بده.

🔜 ادامه دارد...

⚙️ کالبدشکافی فنی AhuraRTOS
بخش ۵ | Integration و جمع‌بندی نهایی

🔧 ۹. راهنمای یکپارچه‌سازی با STM32CubeMX
اگر قصد دارید AhuraRTOS را به پروژه‌ای مبتنی بر STM32CubeMX اضافه کنید، دو نکته مهم را باید در نظر بگیرید:
1️⃣ PendSV باید در اختیار RTOS باشد
در تنظیمات NVIC، تولید Handler مربوط به PendSV را غیرفعال کنید.
چرا؟
چون AhuraRTOS از PendSV برای Context Switching استفاده می‌کند و Kernel باید کنترل این Exception را در اختیار داشته باشد.
به‌صورت ساده:
PendSV → AhuraRTOS Kernel
نه Application.
2️⃣ انتقال HAL Timebase
AhuraRTOS از SysTick برای Tick سیستم استفاده می‌کند.
بنابراین بهتر است Timebase مربوط به STM32 HAL روی یک Timer جداگانه، مانند:
TIM6
قرار بگیرد.
در غیر این صورت، دو مکانیزم مختلف ممکن است از یک Timebase استفاده کنند و مدیریت Tick و توابعی مانند:
HAL_Delay()
با RTOS تداخل پیدا کند.
نتیجه احتمالی این تداخل می‌تواند Timing Drift، تأخیرهای نادرست و رفتار غیرقابل‌پیش‌بینی باشد.

🎯 ۱۰. جمع‌بندی
AhuraRTOS تلاش می‌کند با یک معماری شفاف، وابستگی‌های پنهان و پیچیدگی غیرضروری Kernel را کاهش دهد.
مهم‌ترین ویژگی‌هایی که در این بررسی دیدیم:
🔹 O(1) Scheduler مبتنی بر Bitmap ۳۲ بیتی
🔹 استفاده از PendSV برای Context Switching
🔹 آزاد ماندن SVC برای Application
🔹 تفکیک دقیق Scheduler Lock و Critical Section
🔹 استفاده از PSPLIM برای محافظت از Stack در ARMv8-M
🔹 طراحی Kernel مستقل از جزئیات معماری
🔹 تمرکز بر Portability، Performance و Predictability
در نهایت، فلسفه AhuraRTOS را می‌توان در یک جمله خلاصه کرد:
Kernel باید ساده، قابل‌پیش‌بینی و مستقل از Application باشد؛ در حالی که کنترل منابع همچنان در اختیار مهندس سیستم باقی بماند.
اگر با ARM Cortex-M، Firmware و سیستم‌های Real-Time کار می‌کنید، AhuraRTOS می‌تواند پروژه جالبی برای بررسی یک رویکرد متفاوت در طراحی RTOS باشد.

🔗 پروژه AhuraRTOS:
https://github.com/AhuraRTOS/AhuraRTOS

👤 توسعه‌دهنده: مهندس عسکری (nimaltd)

توضیحات فوق آشنایی و نحوه راه اندازی سیستم عامل اهورا می باشد که اقای مهندس امین خادم الحسینی زحمت کشیدن

@amin98hosseini

اجرای یک تمرین منزل، درایو VGA و کنترل رنگ با ADC در دوره FPGA و نظر مهندس سروش بندانی در رابطه دوره اموزشی تخصصی «تراشه های FPGA»
مدرس: مهندس حمید نجفی
مجتمع آموزشی گارد

تبلیغ ما نتیجه کار ماست...

تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com

شروع ثبت نام
دوره آموزشی حضوری «طراحی مدارهای منطقی کاربردی»
مدرس: مهندس حمید نجفی

دوشنبه ها ۹ الی ۱۳
یک دوره تخصصی عالی طراحی دیجیتال و کلیه نیازهای پایه ای در این الکترونیک دیجیتال
این دوره پیشنیاز دوره FPGA بوده بعد از این دوره در همین روز و‌ ساعت دوره FPGA برگزار می گردد.
بهمراه مدرک معتبر و فنی حرفه ای

لینک سرفصل ها و ثبت نام:
https://gard-academy.com/presence-digital

لینک تقویم آموزشی کلیه دوره های در حال ثبت نام:
https://gard-academy.com/eduction-calendar

تلفن های مشاوره و ثبت نام:
۴۴۲۰۴۱۱۴
۴۴۲۰۴۱۱۵
۰۹۳۰۳۳۱۰۵۳۳

تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com

معرفی قطعات کاربردی
TPS51206

تامین کننده تغذیه های لازم تراشه های:
DDR2
DDR3
DDR3L
DDR4

تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com

دوره های آنلاین و حضوری بدون مجوز ۲ تا ۵ سال زندان!
تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com

آخرین نسخه کتابخونه التیوم دیزاینر  مجموعه زتابرد

تهیه شده توسط مهندس مهدی رحیمی عزیز از مهندسین توانمند و زحمت کش صنعت الکترونیک🌹
@zataboard

تو یاد می گیری چطور فکر کنی...
You learn how to think...

@GARD_Academy
GARD-Academy.com