Amin'sTechLab
رفتن به کانال در Telegram
🔬 Embedded Systems | AI | FPGA | PCB Design 🚀 Exploring tech at the edge of innovation 🧠 Founder of AminTechLab 📍Engineering the future – one bit at a time
نمایش بیشتر2 049
مشترکین
+324 ساعت
+47 روز
+1630 روز
در حال بارگیری داده...
کانال‌های مشابه
ابر برچسب‌ها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+12
در 0 کانال‌ها
سپتامبر '26
+42
در 0 کانال‌ها
Get PRO
اوت '26
+68
در 0 کانال‌ها
Get PRO
ژوئیه '26
+49
در 0 کانال‌ها
Get PRO
ژوئن '26
+27
در 0 کانال‌ها
Get PRO
مه '26
+10
در 0 کانال‌ها
Get PRO
آوریل '26
+7
در 0 کانال‌ها
Get PRO
مارس '26
+1
در 0 کانال‌ها
Get PRO
فوریه '26
+12
در 0 کانال‌ها
Get PRO
ژانویه '26
+4
در 0 کانال‌ها
Get PRO
دسامبر '25
+28
در 1 کانال‌ها
Get PRO
نوامبر '25
+36
در 1 کانال‌ها
Get PRO
اکتبر '25
+41
در 2 کانال‌ها
Get PRO
سپتامبر '25
+56
در 1 کانال‌ها
Get PRO
اوت '25
+44
در 0 کانال‌ها
Get PRO
ژوئیه '25
+20
در 0 کانال‌ها
Get PRO
ژوئن '25
+15
در 0 کانال‌ها
Get PRO
مه '25
+25
در 1 کانال‌ها
Get PRO
آوریل '25
+18
در 0 کانال‌ها
Get PRO
مارس '25
+30
در 0 کانال‌ها
Get PRO
فوریه '25
+19
در 0 کانال‌ها
Get PRO
ژانویه '25
+42
در 0 کانال‌ها
Get PRO
دسامبر '24
+34
در 0 کانال‌ها
Get PRO
نوامبر '24
+36
در 0 کانال‌ها
Get PRO
اکتبر '24
+27
در 0 کانال‌ها
Get PRO
سپتامبر '24
+17
در 0 کانال‌ها
Get PRO
اوت '24
+23
در 0 کانال‌ها
Get PRO
ژوئیه '24
+48
در 0 کانال‌ها
Get PRO
ژوئن '24
+39
در 0 کانال‌ها
Get PRO
مه '24
+44
در 0 کانال‌ها
Get PRO
آوریل '24
+32
در 0 کانال‌ها
Get PRO
مارس '24
+60
در 0 کانال‌ها
Get PRO
فوریه '24
+82
در 1 کانال‌ها
Get PRO
ژانویه '24
+48
در 2 کانال‌ها
Get PRO
دسامبر '23
+30
در 0 کانال‌ها
Get PRO
نوامبر '23
+7
در 0 کانال‌ها
Get PRO
اکتبر '23
+10
در 0 کانال‌ها
Get PRO
سپتامبر '23
+7
در 0 کانال‌ها
Get PRO
اوت '23
+5
در 0 کانال‌ها
Get PRO
ژوئیه '23
+10
در 0 کانال‌ها
Get PRO
ژوئن '23
+7
در 0 کانال‌ها
Get PRO
مه '23
+1 042
در 0 کانال‌ها
Get PRO
آوریل '23
+5
در 0 کانال‌ها
Get PRO
مارس '23
+9
در 0 کانال‌ها
Get PRO
فوریه '23
+15
در 0 کانال‌ها
Get PRO
ژانویه '23
+14
در 0 کانال‌ها
Get PRO
دسامبر '22
+1
در 0 کانال‌ها
Get PRO
نوامبر '22
+8
در 0 کانال‌ها
Get PRO
اکتبر '22
+11
در 0 کانال‌ها
Get PRO
سپتامبر '22
+7
در 0 کانال‌ها
Get PRO
اوت '22
+13
در 0 کانال‌ها
Get PRO
ژوئیه '22
+14
در 0 کانال‌ها
Get PRO
ژوئن '22
+11
در 0 کانال‌ها
Get PRO
مه '22
+18
در 0 کانال‌ها
Get PRO
آوریل '22
+14
در 0 کانال‌ها
Get PRO
مارس '22
+8
در 0 کانال‌ها
Get PRO
فوریه '22
+12
در 0 کانال‌ها
Get PRO
ژانویه '22
+12
در 0 کانال‌ها
Get PRO
دسامبر '21
+12
در 0 کانال‌ها
Get PRO
نوامبر '21
+38
در 0 کانال‌ها
Get PRO
اکتبر '21
+5
در 0 کانال‌ها
Get PRO
سپتامبر '21
+25
در 0 کانال‌ها
Get PRO
اوت '21
+27
در 0 کانال‌ها
Get PRO
ژوئیه '21
+554
در 0 کانال‌ها
Get PRO
ژوئن '21
+14
در 0 کانال‌ها
Get PRO
مه '21
+39
در 0 کانال‌ها
Get PRO
آوریل '21
+58
در 0 کانال‌ها
Get PRO
مارس '21
+88
در 0 کانال‌ها
Get PRO
فوریه '21
+112
در 0 کانال‌ها
Get PRO
ژانویه '21
+692
در 0 کانال‌ها
Get PRO
دسامبر '20
+2 352
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 07 اکتبر | 0 | |||
| 06 اکتبر | +3 | |||
| 05 اکتبر | +2 | |||
| 04 اکتبر | +2 | |||
| 03 اکتبر | +4 | |||
| 02 اکتبر | +1 | |||
| 01 اکتبر | 0 |
پست‌های کانال
🚀 اجرای AhuraRTOS روی STM32 | پروژه عملی
در این ویدیو میریم سراغ یک اجرای واقعی از AhuraRTOS روی میکروکنترلر STM32 و قدم‌به‌قدم یک پروژه RTOS را راه‌اندازی می‌کنیم.
در این پروژه با مفاهیمی مثل:
🔹 راه‌اندازی Kernel
🔹 Scheduler و Taskها
🔹 SysTick و مدیریت زمان
🔹 اجرای هم‌زمان چند Task
🔹 کنترل GPIO و LED توسط Taskهای مستقل
🔹 ساخت پروژه با STM32CubeIDE
آشنا می‌شیم.
🎬 مشاهده ویدیو
💻 سورس کامل پروژه در GitHub:
AhuraRTOS_Example
🌐 پروژه اصلی AhuraRTOS:
AhuraRTOS
ویدیو را ببینید و اگر به STM32، Embedded Systems و RTOS علاقه دارید، این مجموعه را دنبال کنید.
@Amin_Techlab
| 2 |  🚀 یک ارتقای بزرگ برای هوش مصنوعی تخصصی مهندس‌های الکترونیک!
ElectroMind AI | Skill + Laya AI | قسمت ۲
در قسمت دوم توسعه ElectroMind AI، دو قابلیت مهم به پروژه اضافه شده:
🧩 Skill System
امکان اضافه‌کردن قابلیت‌های تخصصی به‌صورت ماژولار برای حوزه‌های Electronics، Firmware و Embedded Systems.
🧠 Laya AI
برای انتخاب و مدیریت هوشمند Contextهای مرتبط در کنار RAG و Local LLM.
⚡️ معماری جدید:
Local LLM + RAG + Skill + Laya AI + Project Context
هدف همچنان ساخت یک AI Assistant تخصصی برای مهندسان الکترونیک و Embedded Systems است؛ با معماری‌ای که بتواند در آینده Skillهای بیشتری دریافت کند.
🎬 ویدیو قسمت دوم را ببینید و با روند توسعه پروژه همراه شوید.
مشاهده ویدیو اینجا کلیک کنید .
🔗 GitHub: ElectroMind AI
🌐 Website: ElectroMind AI Website
💫گاهی باید ادامه داد و قوی بود نه فقط برای خودمون بلکه برای عزیزترین کسایی که داریم و برامون با ارزش هستند و قوی بودن ما قوت قلب و خوش حالی اوناست . 😉
@Amin_Techlab | 364 |
| 3 |  هوش مصنوعی مخصوص مهندس‌های الکترونیک ساختم!
تا حالا شده برای پیدا کردن جواب یک سؤال ساده در یک پروژه Embedded، بین Datasheet، Reference Manual، Source Code و PDFهای مختلف ساعت‌ها جستجو کنی؟ 😵💫
من برای همین ایده، پروژه ElectroMind AI رو ساختم؛ یک دستیار هوش مصنوعی مخصوص مهندسی الکترونیک و Embedded Systems ⚡️
🔹 اجرای کاملاً Local و Offline
🔹 بدون نیاز به API و Cloud
🔹 پشتیبانی از RAG
🔹 کار با Datasheet و مستندات پروژه
🔹 پشتیبانی از Source Code
🔹 اجرای مدل‌های GGUF / Local LLM
🔹 مناسب برای پروژه‌های STM32 و Embedded
ایده اصلی اینه که به‌جای اینکه فقط از AI یک سؤال عمومی بپرسیم، اطلاعات و مستندات واقعی پروژه خودمون رو هم در اختیارش قرار بدیم.
🎥 توی این ویدیو ElectroMind AI رو معرفی کردم و درباره ایده، معماری و قابلیت‌های پروژه صحبت کردم.
👇 مشاهده ویدیو در یوتیوب:
مشاهده ویدیو
💻 GitHub:
https://github.com/Amin98Hosseini/ElectroMindAi
🌐 Website:
https://amin98hosseini.github.io/ElectroMindAi/
اگر به ترکیب AI + Electronics + Embedded علاقه داری، این پروژه رو از دست نده.
@Amin_Techlab | 576 |
| 4 | زبان Cyrus یک زبان برنامه‌نویسی سیستمی با نگاه متفاوت
اگر با C، C++، Rust یا Zig کار کرده باشید، احتمالاً می‌دانید که در برنامه‌نویسی سیستمی همیشه یک سؤال مهم وجود دارد:
چقدر کنترل را به زبان و کامپایلر بدهیم و چقدر خودمان کنترل را در دست داشته باشیم؟
زبان Cyrus یک زبان برنامه‌نویسی سیستمی جدید است که پاسخ متفاوتی به این سؤال می‌دهد.
این زبان با تمرکز روی کنترل صریح، عملکرد قابل پیش‌بینی و حداقل انتزاع طراحی شده است. در Cyrus بسیاری از رفتارهایی که در زبان‌های مدرن ممکن است به‌صورت خودکار اتفاق بیفتند، عمداً شفاف و قابل مشاهده هستند.
🔹 ویژگی‌های مهم Cyrus:
• مدیریت دستی حافظه و بدون Garbage Collector
• سیستم Type صریح و Static
• بدون تبدیل‌های ضمنی نوع
• کامپایل Native و Ahead-of-Time
• استفاده از LLVM در زیرساخت کامپایل
• تعامل مستقیم با C و سازگاری با C ABI
• حداقل Runtime و Abstraction
• دارای Comptime برای اجرای بخشی از منطق در زمان کامپایل
• کنترل صریح روی Allocation، Pointer و Dispatch
• طراحی Procedural و نزدیک به مدل ماشین
یکی از نکات جالب Cyrus این است که هدفش جایگزین کردن Rust یا C نیست؛ بلکه تلاش می‌کند نقطه‌ای متفاوت در فضای زبان‌های سیستمی ایجاد کند.
اگر C برایتان بیش از حد قدیمی و محدود به نظر می‌رسد، اما مدل‌هایی مثل Borrow Checker در Rust برای پروژه شما ضروری نیستند، Cyrus تلاش می‌کند امکانات مدرن‌تری را بدون کنار گذاشتن کنترل سطح پایین ارائه کند.
مثلاً یک برنامه ساده در Cyrus می‌تواند به این شکل باشد:
```Cyrus
import std::libc{printf};
fn main() {
printf("Hello, World!");
}
```
البته باید توجه داشت که Cyrus هنوز یک پروژه در حال توسعه است و برای استفاده در محیط‌های Production و پروژه‌های حساس توصیه نمی‌شود.
🧩 پروژه در حال توسعه قابلیت‌هایی مانند Self-hosting Compiler، کتابخانه استاندارد گسترده‌تر، APIهای Async، Networking و Package Ecosystem است.
🌐 وب‌سایت و مستندات رسمی:
cyrus-lang.ir
💻 GitHub:
Cyrus on GitHub
@Amin_Techlab | 435 |
| 5 |  🦅 زبان Cyrus یک مسیر متفاوت برای برنامه‌نویسی سیستمی
در اصل Cyrus یک زبان برنامه‌نویسی سیستمی مدرن است که روی کنترل بیشتر، انتزاع کمتر و عملکرد قابل‌پیش‌بینی تمرکز دارد.
در ادامه با این زبان آشنا میشویم ...
@Amin_Techlab | 314 |
| 6 | 🚀 فراتر از یک Code Editor – Zed
Zed فقط یک ادیتور سریع نیست بلکه تلاش کرده بخش زیادی از ابزارهای موردنیاز یک توسعه‌دهنده را در یک محیط یکپارچه قرار دهد.
هسته Zed با Rust توسعه داده شده و رابط کاربری آن بر پایه GPUI ساخته شده است؛ رویکردی که باعث شده تعامل با محیط ادیتور بسیار روان و سریع باشد.
🔹قابلیت Multi-buffer
با Multi-buffer می‌توانید قسمت‌هایی از چند فایل مختلف را در یک محیط مشاهده و ویرایش کنید؛ بدون اینکه دائماً بین فایل‌ها جابه‌جا شوید.
🔹 پشتیبانی قدرتمند از کد
Zed از Tree-sitter و LSP استفاده می‌کند و امکاناتی مانند Syntax Highlighting، تشخیص خطا، تحلیل کد و Code Actions را در اختیار توسعه‌دهنده قرار می‌دهد.
🔹 ابزارهای توسعه
Git، Git Worktree، Debugger مبتنی بر DAP، Terminal و Task Runner از دیگر امکاناتی هستند که مستقیماً در محیط Zed در دسترس قرار دارند.
🔹قابلیت Remote Development
برای توسعه روی سیستم‌های دیگر نیز امکان استفاده از SSH و WSL وجود دارد.
🤝 همکاری Real-time
یکی از بخش‌های جذاب Zed قابلیت همکاری هم‌زمان است. چند نفر می‌توانند روی یک پروژه کار کنند، تغییرات یکدیگر را ببینند و با Follow Mode موقعیت ویرایشگر همکارشان را دنبال کنند.
امکاناتی مانند Chat، Voice و Screen Sharing نیز برای همکاری تیمی در نظر گرفته شده‌اند.
🤖 هوش مصنوعی و Agentها
Zed در بخش AI نیز محدود به یک سرویس خاص نیست.
پشتیبانی از MCP و ACP امکان استفاده از Agentهای مختلف را فراهم می‌کند و قابلیت‌هایی مانند Edit Prediction و مدیریت Context نیز برای تجربه بهتر کار با AI در نظر گرفته شده‌اند.
🧩 افزونه و شخصی‌سازی
افزونه‌های Zed در محیط WebAssembly و Sandbox اجرا می‌شوند و برای کاربران علاقه‌مند به محیط‌های Keyboard-driven، پشتیبانی از Vim و Helix نیز وجود دارد.
🖥 در نهایت...
Zed برای Windows، Linux و macOS در دسترس است و هسته اصلی آن Open Source است.
البته اکوسیستم Extensionهای آن هنوز به گستردگی VS Code نیست؛ اما ترکیب سرعت، معماری مدرن، ابزارهای توسعه، همکاری تیمی و قابلیت‌های AI باعث شده Zed به گزینه‌ای جدی برای امتحان کردن تبدیل شود.
@Amin_Techlab | 484 |
| 7 |  ⚡️ ادیتوری متفاوت برای توسعه‌دهنده‌ها Zed
اگه سرعت و روان بودن محیط کدنویسی برات مهمه، شاید وقتشه Zed رو بشناسی.
یک ادیتور مدرن که با Rust ساخته شده و از GPU برای رندر رابط کاربری استفاده می‌کنه.
اما سرعت تنها چیزی نیست که Zed برای ارائه داره... 👀
در ادامه ببینیم چه قابلیت‌هایی باعث شده Zed مورد توجه توسعه‌دهنده‌ها قرار بگیره....
@Amin_Techlab | 382 |
| 8 |  مهاجرت به Ubuntu 26.10؛ Core Utilities به Rust کامل شد! 🦀
با Canonical در نسخه Ubuntu 26.10 مهاجرت ابزارهای پایه لینوکس به نسخه‌های مبتنی بر Rust را کامل می‌کند.
ابزارهایی مثل:
ls، cat، chmod، du، cp، mv و rm
اکنون از پروژه uutils استفاده می‌کنند.
🔐 دلیل اصلی این تغییر، امنیت بیشتر و Memory Safety است. Rust بسیاری از خطاهای مرتبط با مدیریت حافظه را در زمان کامپایل شناسایی می‌کند.
در Ubuntu 26.04، دستورات cp، mv و rm به‌دلیل مشکلات امنیتی TOCTOU هنوز روی نسخه GNU بودند؛ این مشکلات اکنون برطرف شده‌اند.
جالب اینکه هدف این مهاجرت، تغییر تجربه کاربر نیست؛ بلکه اجرای همان دستورات آشنا با یک زیرساخت امن‌تر است.
🦀 به نظر می‌رسد Rust در حال تبدیل شدن به بخش جدی‌تری از آینده Linux و Ubuntu است.
@Amin_Techlab | 501 |
| 9 |  CAN and CAN FD protocol
Browse our CAN and CAN FD transceiver
Source : https://www.ti.com/CAN
@Amin_Techlab | 627 |
| 10 | 🔹 مدیریت هوشمند فایل‌های پروژه با ".gitignore"؛ این بار برعکس فکر کنیم!
معمولاً در Git به این شکل عمل می‌کنیم:
همه فایل‌ها Track شوند و هر چیزی را که نمی‌خواهیم، داخل ".gitignore" قرار دهیم.
اما یک روش جالب دیگر هم وجود دارد! 😎
بیایید دقیقاً برعکس عمل کنیم: همه‌چیز را Ignore کنیم و فقط فایل‌های موردنیاز را Explicitly مجاز کنیم.
❓ چرا این روش می‌تواند مفید باشد؟
در پروژه‌ها معمولاً فایل‌ها و پوشه‌هایی ایجاد می‌شوند که نباید وارد Repository شوند؛ مثل:
📁 "node_modules/"
🗂️ ".DS_Store"
🔐 فایل‌های Environment
📝 فایل‌های موقت و تنظیمات Editor
📄 فایل‌هایی مثل "CLAUDE.md" و موارد مشابه
اگر مدیریت نشوند، ممکن است به‌صورت ناخواسته وارد Commit شوند و Repository را شلوغ و نامرتب کنند.
💡 یک مثال کاربردی
فرض کنید یک پروژه Go داریم و فقط می‌خواهیم فایل‌های ضروری در Git Track شوند:
*
!.gitignore
!*.go
!README.md
!go.mod
!go.sum
اینجا:
"*" → یعنی همه‌چیز Ignore شود. 🚫
و هر چیزی که با "!" شروع شود → از حالت Ignore خارج شده و اجازه Track شدن دارد. ✅
بنابراین در این مثال، فقط فایل‌های Go و فایل‌های مشخص‌شده اجازه ورود به Repository را دارند.
👍 مزایا
🔹 کنترل کامل روی فایل‌هایی که وارد Repository می‌شوند
🔹 جلوگیری از Commit شدن تصادفی فایل‌های اضافی
🔹 Repository تمیزتر و قابل‌مدیریت‌تر
🔹 مناسب برای پروژه‌های کوچک و ساختارهای مشخص
👎 معایب و نکات مهم
🔸 مدیریت آن به‌صورت دستی انجام می‌شود
🔸 با اضافه شدن فایل‌های جدید باید ".gitignore" را به‌روزرسانی کنید
🔸 برای پروژه‌های بزرگ و پیچیده ممکن است مدیریت این روش سخت‌تر شود
🔍 یک دستور کاربردی Git
اگر نمی‌دانید چرا یک فایل توسط Git نادیده گرفته شده، این دستور را اجرا کنید:
git check-ignore -v path/to/file
این دستور به شما نشان می‌دهد کدام Rule در ".gitignore" باعث Ignore شدن فایل شده است. 🧐
💡 گاهی اوقات به‌جای اینکه بگوییم «چه چیزهایی را Ignore کنم؟»، بهتر است بپرسیم:
«دقیقاً چه چیزهایی را می‌خواهم وارد Repository کنم؟»
@Amin_Techlab | 656 |
| 11 | ⚙️ 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 | 525 |
| 12 | 🧠 مفهوم Stack Overflow در زبان C — بخش اول
وقتی در زبان C یک تابع را فراخوانی می‌کنیم، برنامه برای مدیریت اجرای آن تابع به فضایی از حافظه به نام Stack نیاز دارد.
اما اگر این فضا بیش از ظرفیت خود مصرف شود، چه اتفاقی می‌افتد؟
💥 Stack Overflow
🔹 Stack چیست؟
Stack بخشی از حافظه RAM است که برای مدیریت اجرای توابع استفاده می‌شود.
در زمان اجرای یک تابع، اطلاعاتی مانند:
• متغیرهای Local
• پارامترهای تابع
• آدرس بازگشت
• برخی Registerها و اطلاعات موقتی
در Stack Frame مربوط به آن تابع قرار می‌گیرند.
مثلاً:
void test(void)
{
int x = 10;
}
متغیر x یک Local Variable است و در بسیاری از پیاده‌سازی‌ها فضای آن از Stack تأمین می‌شود.
🔥 Stack Overflow چگونه ایجاد می‌شود؟
یکی از رایج‌ترین دلایل، Recursive Function بدون شرط توقف است:
void crash(void)
{
int buffer[1000];
crash();
}
تابع crash() خودش را دوباره فراخوانی می‌کند.
در نتیجه:
crash()
↓
crash()
↓
crash()
↓
crash()
↓
...
هر فراخوانی جدید، یک Stack Frame جدید ایجاد می‌کند.
بنابراین Stack دائماً رشد می‌کند:
┌──────────────┐
│ Frame #4 │
├──────────────┤
│ Frame #3 │
├──────────────┤
│ Frame #2 │
├──────────────┤
│ Frame #1 │
├──────────────┤
│ │
│ Free RAM │
└──────────────┘
تا جایی که دیگر فضای کافی برای ایجاد Stack Frame جدید وجود نداشته باشد.
💥 نتیجه معمولاً Crash شدن برنامه است.
🔹 فقط Recursion مشکل‌ساز نیست!
تعریف متغیرهای Local بسیار بزرگ نیز می‌تواند Stack را پر کند:
void process(void)
{
char buffer[1024 * 1024];
}
اینجا برنامه تقریباً 1MB فضای Stack درخواست می‌کند.
اگر Stack برنامه ظرفیت کافی نداشته باشد، احتمال بروز مشکل بسیار زیاد است.
⚠️ نکته مهم
Stack Overflow با Heap Overflow متفاوت است.
Stack بیشتر با اجرای توابع و متغیرهای Local سروکار دارد، در حالی که Heap برای حافظه Dynamic مانند:
malloc()
calloc()
realloc()
free()
است.
در بخش دوم می‌بینیم چرا این موضوع در STM32 و RTOS اهمیت بسیار بیشتری پیدا می‌کند و چطور می‌توان مصرف Stack را بررسی کرد.
ادامه دارد...
@Amin_Techlab | 391 |
| 13 | 🧠 Lifetime و Storage Duration در زبان C — بخش دوم
در بخش اول با Automatic و Static Storage Duration و همچنین تفاوت Scope و Lifetime آشنا شدیم.
حالا برویم سراغ دو مفهوم دیگر:
Allocated
Thread
و ببینیم این موضوع چگونه می‌تواند باعث Bugهای خطرناک در C شود.
🔹 3. Allocated Storage Duration
وقتی با malloc() حافظه‌ای را تخصیص می‌دهیم، Storage مربوط به Object تا زمانی که آزاد شود باقی می‌ماند.
مثلاً:
int *p = malloc(sizeof(int));
*p = 100;
free(p);
به‌صورت مفهومی:
malloc()
↓
Storage Allocated
↓
Object exists
↓
Use Object
↓
free()
↓
Lifetime Ends
مشکل زمانی ایجاد می‌شود که free() را فراموش کنیم.
مثلاً:
int *p = malloc(sizeof(int));
*p = 100;
/* free(p) فراموش شده */
اینجا با یک Memory Leak مواجه میشویم.
⚠️ چرا Dynamic Memory در Embedded مهم است؟
در سیستم‌های Embedded و مخصوصاً RTOS، استفاده نادرست از malloc() و free() می‌تواند مشکلاتی مثل:
Memory Leak
Memory Fragmentation
Allocation Failure
Unpredictable Timing
ایجاد کند.
به همین دلیل در بسیاری از سیستم‌های Real-Time، Dynamic Memory Allocation یا محدود می‌شود یا با طراحی بسیار کنترل‌شده استفاده می‌شود.
🔹 4. Thread Storage Duration
در C11 نوع دیگری از Storage Duration وجود دارد:
_Thread_local
مثلاً:
_Thread_local int counter;
در این حالت هر Thread نسخه مخصوص خودش از Object را دارد.
یعنی:
Thread 1 → counter #1
Thread 2 → counter #2
Thread 3 → counter #3
این مفهوم در برنامه‌های Multithreaded و RTOS اهمیت پیدا می‌کند.
🔥 حالا یک Bug بسیار مهم
به این کد نگاه کنید:
int *get_value(void)
{
int value = 100;
return &value;
}
این کد مشکل دارد.
چرا؟
چون value یک Local Variable با Automatic Storage Duration است.
وقتی تابع تمام شود:
get_value()
↓
value created
↓
return
↓
function ends
↓
value lifetime ends
بنابراین Pointer برگشتی دیگر به یک Object معتبر اشاره نمی‌کند.
این وضعیت را Dangling Pointer می‌نامیم.
❌ کد خطرناک
int *get_value(void)
{
int value = 100;
return &value;
}
نباید به Objectی که Lifetime آن تمام شده، دسترسی داشته باشیم.
✅ یک روش متفاوت
می‌توان از یک Static Object استفاده کرد:
int *get_value(void)
{
static int value = 100;
return &value;
}
در این حالت value دارای Static Storage Duration است و بعد از خروج از تابع همچنان وجود دارد.
اما این روش هم باید با توجه به شرایط استفاده شود؛ مخصوصاً در برنامه‌های چندنخی، چون چند Thread می‌توانند به یک Object مشترک دسترسی داشته باشند.
🧠 Stack vs Heap
یک نکته مهم:
این عبارت‌ها را نباید با Storage Duration یکی بدانیم:
Stack
Heap
Static Memory
Storage Duration یک مفهوم استاندارد در زبان C است.
اما Stack و Heap بیشتر به نحوه پیاده‌سازی و مدیریت حافظه توسط سیستم/Compiler/Runtime مربوط هستند.
به‌صورت معمول:
Automatic Object
↓
غالباً Stack
malloc()
↓
Heap / Allocator
Static Object
↓
Static Storage Area
اما این mapping یک الزام مستقیم استاندارد C نیست.
🎯 جمع‌بندی نهایی
چهار Storage Duration اصلی در C:
┌─────────────────────────┐
│ Automatic │
│ طول عمر مرتبط با Block │
├─────────────────────────┤
│ Static │
│ طول اجرای برنامه │
├─────────────────────────┤
│ Allocated │
│ تا زمان deallocation │
├─────────────────────────┤
│ Thread │
│ مرتبط با Thread │
└─────────────────────────┘
و همیشه این سه مفهوم را از هم جدا کنید:
Scope
→ نام کجا قابل دسترسی است؟
Storage Duration
→ Storage چه مدت وجود دارد؟
Lifetime
→ Object چه مدت وجود دارد؟
💡 اگر در C با Pointer، static، malloc()، free() یا متغیرهای Local کار می‌کنید، همیشه این سؤال را از خودتان بپرسید:
«این Object چه زمانی ایجاد می‌شود و دقیقاً چه زمانی Lifetime آن تمام می‌شود؟»
درک همین موضوع می‌تواند جلوی بسیاری از مشکلات جدی در C، Embedded Systems، STM32 و RTOS را بگیرد.
@Amin_Techlab | 334 |
| 14 | 🧠مفهوم Lifetime و Storage Duration در زبان C — بخش اول
یکی از مفاهیم مهم در زبان C، مخصوصاً در Embedded Systems، درک نحوه ایجاد و از بین رفتن Objectها در حافظه است.
سه مفهوم مهم در این زمینه داریم:
Scope
Lifetime
Storage Duration
این سه مفهوم به هم مرتبط هستند، اما یکسان نیستند.
🔹 Storage Duration چیست؟
Storage Duration مشخص می‌کند که فضای ذخیره‌سازی یک Object چه مدت وجود دارد.
در استاندارد C چهار نوع Storage Duration داریم:
1. Automatic
2. Static
3. Allocated
4. Thread
در این بخش دو مورد مهم‌تر را بررسی می‌کنیم.
🔹 1. Automatic Storage Duration
یک متغیر Local معمولی معمولاً Storage Duration از نوع Automatic دارد.
مثلاً:
void test(void)
{
int value = 10;
printf("%d\n", value);
}
Object مربوط به value هنگام ورود به Block ایجاد می‌شود و با خروج از Block، Lifetime آن پایان پیدا می‌کند.
به‌صورت ساده:
Enter Block
↓
Object Created
↓
Use Object
↓
Exit Block
↓
Lifetime Ends
در بسیاری از سیستم‌ها، چنین متغیرهایی معمولاً روی Stack قرار می‌گیرند؛ البته استاندارد C محل فیزیکی ذخیره‌سازی را مشخص نمی‌کند.
🔹 2. Static Storage Duration
حالا به این مثال توجه کنید:
void counter(void)
{
static int count = 0;
count++;
printf("%d\n", count);
}
اگر تابع را سه بار اجرا کنیم:
counter();
counter();
counter();
خروجی:
1
2
3
چرا count هر بار از صفر شروع نمی‌شود؟
چون count دارای Static Storage Duration است.
یعنی Object مربوط به آن در طول اجرای برنامه وجود دارد و با خروج از تابع از بین نمی‌رود.
Program Start
↓
count exists
↓
counter() → 1
↓
counter() → 2
↓
counter() → 3
↓
Program End
↓
count lifetime ends
⚠️ یک نکته بسیار مهم
static را نباید صرفاً به معنی «ذخیره شدن در یک قسمت خاص از RAM» در نظر گرفت.
استاندارد C درباره Storage Duration صحبت می‌کند، نه الزاماً محل فیزیکی حافظه.
در یک سیستم Embedded، محل نهایی Object می‌تواند توسط Compiler و Linker تعیین شود.
🔥 Scope ≠ Lifetime
یکی از اشتباهات رایج این است که Scope و Lifetime را یکی بدانیم.
مثلاً:
void test(void)
{
static int counter = 0;
counter++;
}
نام counter فقط داخل همین Block قابل دسترسی است:
Scope
→ نام counter کجا قابل مشاهده است؟
اما Object مربوط به آن:
Static Storage Duration
→ در طول اجرای برنامه باقی می‌ماند.
بنابراین:
Scope
→ محدوده قابل مشاهده بودن نام
Storage Duration
→ مدت وجود Storage
Lifetime
→ مدت وجود یک Object مشخص
ادامه دارد ....
@Amin_Techlab | 347 |
| 15 |  🚀 آشنایی با AhuraRTOS؛ یک RTOS ایرانی برای سیستم‌های Embedded
در این ویدیو با AhuraRTOS آشنا میشویم؛ یک سیستم‌عامل بلادرنگ (RTOS) با تمرکز بر توسعه سیستم‌های نهفته و Embedded.
اگر به حوزه‌های Embedded Systems، میکروکنترلرها، RTOS، طراحی Firmware و سیستم‌های بلادرنگ علاقه‌مند هستید، این ویدیو می‌تواند شروع خوبی برای آشنایی با این پروژه باشد.
دیدن پروژه‌هایی از این جنس، علاوه بر جنبه فنی، می‌تواند قدمی برای شکل‌گیری و توسعه اکوسیستم نرم‌افزارهای Embedded در ایران باشد.
🎥 تماشای ویدیو: معرفی AhuraRTOS | اولین RTOS ایرانی برای سیستم‌های Embedded
@Amin_Techlab | 537 |
| 16 |  🚀 نکات کوتاه و کاربردی زبان C
اگه با C، میکروکنترلرها و سیستم‌های Embedded کار می‌کنی، این پلی‌لیست رو از دست نده! 👨💻⚡️
توی این مجموعه از YouTube Shorts، نکات، ترفندها و مفاهیم کاربردی زبان C رو در ویدیوهای کوتاه و سریع بررسی می‌کنیم؛ مناسب برای یادگیری و مرور سریع. 🎯
📌 C Programming Tips | نکات و ترفندهای زبان C
▶️ مشاهده پلی‌لیست:
https://www.youtube.com/playlist?list=PLf9OiDN9PuA4
@Amin_Techlab | 655 |
| 17 | +2 🎧 بررسی عمیق‌تر AhuraRTOS
در راستای معرفی و بررسی پروژه AhuraRTOS که توسعه‌ی آن توسط مهندس عسکری انجام شده، مطالبی که در ۵ بخش درباره‌ی معماری، هسته، زمان‌بندی، مدیریت منابع و قابلیت‌های این RTOS بررسی و جمع‌آوری کردم و در روزهای قبل به اشتراک گذاشتم را ، به همراه مستندات اصلی پروژه در اختیار NotebookLM قرار گرفت. نتیجه، تولید ۳ فایل صوتی تحلیلی و توضیحی است که موضوعات مطرح‌شده را از زاویه‌ای متفاوت و عمیق‌تر بررسی می‌کنند. گوش دادن به این فایل‌های صوتی خالی از لطف نیست و می‌تواند درک کامل‌تر و عمیق‌تری از ساختار و نحوه‌ی عملکرد AhuraRTOS ایجاد کند.
@Amin_Techlab | 927 |
| 18 | ⚙️ کالبدشکافی فنی 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)
@Amin_Techlab | 1 000 |
| 19 | ⚙️ کالبدشکافی فنی 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 را کاهش بده.
🔜 ادامه دارد...
@Amin_Techlab | 687 |
| 20 | ⚙️ کالبدشکافی فنی 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 نیز تلاش می‌کند سربار کم و رفتار قابل پیش‌بینی داشته باشد.
🔜 ادامه دارد...
@Amin_Techlab | 550 |
