Amin'sTechLab

⚙️ Stack Overflow در STM32 و RTOS — بخش دوم در بخش اول دیدیم که Stack Overflow زمانی اتفاق می‌افتد که مصرف Stack از ظرفیت اختصاص‌یافته بیشتر شود. اما در سیستم‌های Embedded مثل STM32، این موضوع اهمیت بسیار بیشتری دارد. چرا؟ چون منابعی مثل RAM بسیار محدود هستند. 🔹 Stack در STM32 فرض کنید برای یک Task در RTOS فقط:

Stack Size = 2 KB

در نظر گرفته‌ایم. حالا داخل Task یک آرایه بزرگ تعریف کنیم:

void task(void)
{
    uint8_t data[1500];

    process_data(data);
}

همین یک آرایه بخش قابل توجهی از Stack را مصرف می‌کند. اگر توابع دیگری هم فراخوانی شوند و آنها نیز Stack مصرف کنند، احتمال Overflow افزایش پیدا می‌کند. 🔥 مشکل فقط اندازه متغیرها نیست این ساختار را در نظر بگیرید:

Task
 ↓
function_A()
 ↓
function_B()
 ↓
function_C()
 ↓
function_D()

هر تابع می‌تواند Stack Frame خودش را ایجاد کند. بنابراین حتی اگر هیچ آرایه بزرگی هم نداشته باشیم، عمق زیاد Call Stack می‌تواند باعث مصرف قابل توجه Stack شود. ⚠️ Recursion در Embedded استفاده از Recursive Function در سیستم‌های Embedded باید با احتیاط انجام شود:

void task(void)
{
    task();
}

این کد در نهایت Stack را مصرف کرده و باعث Crash می‌شود. به همین دلیل در بسیاری از سیستم‌های Embedded، استفاده از Recursion بدون تحلیل دقیق Stack Depth انتخاب مناسبی نیست. 🔬 Stack و RTOS در RTOS معمولاً هر Task Stack مخصوص خودش را دارد:

RAM
│
├── Task A Stack
│
├── Task B Stack
│
├── Task C Stack
│
├── Kernel
│
└── Heap / Global Data

بنابراین اگر فقط Stack یک Task تمام شود، ممکن است همان Task دچار مشکل شود. این موضوع Debug کردن خطا را هم دشوار می‌کند؛ چون ممکن است برنامه در یک بخش کاملاً متفاوت Crash کند. 🛠 چگونه از Stack Overflow جلوگیری کنیم؟ ✅ اندازه Stack هر Task را متناسب با نیاز تعیین کنید. ✅ آرایه‌های بزرگ را بی‌دلیل Local تعریف نکنید. ✅ از Recursive Function بدون Base Case استفاده نکنید. ✅ عمق Call Stack را در توابع پیچیده بررسی کنید. ✅ در RTOS میزان Stack مصرف‌شده هر Task را Monitor کنید. ✅ در زمان Debug، Stack Pointer و Call Stack را بررسی کنید. 🧠 یک نکته مهم Stack Overflow و Stack Corruption را با هم اشتباه نگیریم. گاهی یک Buffer کوچک به دلیل دسترسی خارج از محدوده می‌تواند حافظه اطراف خود را خراب کند:

uint8_t buffer[10];

buffer[20] = 0xFF;

این کد یک Out-of-Bounds Write است و می‌تواند باعث Stack Corruption شود. یعنی همیشه Crash شدن برنامه به معنی Stack Overflow نیست. 🎯 جمع‌بندی در سیستم‌های Embedded، مدیریت Stack بخش مهمی از طراحی نرم‌افزار است. خصوصاً وقتی با: 🔹 STM32 🔹 RTOS 🔹 Interrupt 🔹 Recursive Function 🔹 Bufferهای بزرگ 🔹 Call Stackهای عمیق کار می‌کنیم. یک Stack کوچک می‌تواند باعث Crash شود و یک Buffer کوچک با دسترسی اشتباه می‌تواند کل Stack را خراب کند. پس در برنامه‌نویسی C فقط این مهم نیست که برنامه کار کند؛ باید بدانیم در سطح حافظه دقیقاً چه اتفاقی در حال رخ دادن است. @Amin_Techlab