Amin'sTechLab

🎧 بررسی عمیق‌تر AhuraRTOS در راستای معرفی و بررسی پروژه AhuraRTOS که توسعه‌ی آن توسط مهندس عسکری انجام شده، مطالبی که در ۵ بخش درباره‌ی معماری، هسته، زمان‌بندی، مدیریت منابع و قابلیت‌های این RTOS بررسی و جمع‌آوری کردم و در روزهای قبل به اشتراک گذاشتم را ، به همراه مستندات اصلی پروژه در اختیار NotebookLM قرار گرفت. نتیجه، تولید ۳ فایل صوتی تحلیلی و توضیحی است که موضوعات مطرح‌شده را از زاویه‌ای متفاوت و عمیق‌تر بررسی می‌کنند. گوش دادن به این فایل‌های صوتی خالی از لطف نیست و می‌تواند درک کامل‌تر و عمیق‌تری از ساختار و نحوه‌ی عملکرد AhuraRTOS ایجاد کند. @Amin_Techlab

⚙️ کالبدشکافی فنی AhuraRTOS بخش ۴ | Security، TrustZone و فلسفه Debugging 🛡 ۷. امنیت و قابلیت‌های پیشرفته در نسل‌های جدید ARM، امنیت فقط یک قابلیت نرم‌افزاری نیست و بخشی از آن مستقیماً در سخت‌افزار پردازنده پیاده‌سازی شده است. در ARMv8-M و پردازنده‌هایی مانند…

⚙️ کالبدشکافی فنی AhuraRTOS بخش ۳ | IPC، Preemption، Atomics و مدیریت حافظه 🔐 ۵. ارتباطات بین‌تسکی و کنترل Preemption در یک RTOS، فقط انتقال داده بین Taskها مهم نیست؛ نحوه محافظت از داده‌های مشترک هم اهمیت زیادی دارد. AhuraRTOS برای این کار دو مکانیزم متفاوت…

⚙️ کالبدشکافی فنی AhuraRTOS بخش ۲ | Scheduling، Priority و Context Switching 🧠 ۳. مکانیسم Scheduling و مدیریت Priority یکی از ویژگی‌های مهم AhuraRTOS، استفاده از Scheduler با پیچیدگی O(1) است. یعنی زمان انتخاب Task بعدی به تعداد Taskهای سیستم وابسته نیست؛…

🧩 کالبدشکافی فنی AhuraRTOS رویکردی نوین در طراحی RTOS برای ARM Cortex-M بخش ۱ | معماری Kernel و فلسفه Portability 🔹 ۱. فراتر از انتزاع‌های رایج در Embedded اگر با سیستم‌های نهفته کار کرده باشید، احتمالاً با یک سؤال مهم روبه‌رو شده‌اید: ❓ چرا با تغییر معماری…

🚀 معرفی یک پروژه مهم در دنیای Embedded Systems؛ AhuraRTOS دوستانی که در حوزه الکترونیک و سیستم‌های Embedded فعالیت می‌کنیم، احتمالاً با پروژه‌ها و کتابخانه‌های مهندس عسکری (nimaltd) آشنا هستیم و در بسیاری از پروژه‌ها از کتابخانه‌های ایشان استفاده کرده‌ایم.…

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

🚀 اگر هنوز FreeRTOS را فقط یک کتابخانه می‌دانید، این ویدیو را از دست ندهید! در پروژه‌های حرفه‌ای STM32H7، دیگر Super Loop پاسخگو نیست. اما چرا RTOS تا این حد اهمیت دارد؟ و چرا تقریباً تمام پروژه‌های صنعتی به سمت FreeRTOS رفته‌اند؟ در قسمت نهم مسترکلاس Embedded، بدون ورود به کدنویسی پیچیده، مفهوم RTOS را از پایه بررسی می‌کنیم و یاد می‌گیرید: ⚡️ تفاوت Bare-Metal و RTOS ⚡️ مفاهیم Task، Scheduler و Context Switch به زبان ساده ⚡️ دلیل اهمیت FreeRTOS در STM32H7 و سیستم‌های Dual-Core ⚡️ چرا یادگیری RTOS برای ورود به پروژه‌های صنعتی ضروری است. 🎥 تماشا در یوتیوب: https://youtu.be/C0GHtBfRsuY اگر قصد دارید STM32 را به‌صورت حرفه‌ای یاد بگیرید، این قسمت یکی از مهم‌ترین ویدیوهای این مجموعه است. @Amin_Techlab

🚀 هوش مصنوعی را روی کامپیوتر خودتان اجرا کنید؛ بدون اینترنت، بدون API و کاملاً رایگان! اگر فکر می‌کنید برای استفاده از مدل‌های زبانی بزرگ (LLM) حتماً باید از سرویس‌های ابری استفاده کنید، وقت آن رسیده نظرتان عوض شود. در این آموزش، قدم‌به‌قدم یاد می‌گیرید چگونه با LM Studio مدل‌های متن‌باز هوش مصنوعی را به‌صورت کاملاً Local روی ویندوز، لینوکس یا macOS اجرا کنید. 💡 در این ویدیو یاد می‌گیرید: • چرا LM Studio برای بسیاری از کاربران جایگزین مناسبی برای Ollama است. • چگونه LM Studio را دانلود و نصب کنید. • چگونه مدل‌های محبوب مانند Llama، Mistral، Gemma، Qwen، DeepSeek و ده‌ها مدل دیگر را جستجو، دانلود و اجرا کنید. • نحوه مدیریت مدل‌ها و اجرای آن‌ها بدون نیاز به اینترنت یا API. • آشنایی با محیط توسعه (Developer Mode) و قابلیت‌های کاربردی LM Studio برای برنامه‌نویسان. ✅ مزایای اجرای Local AI: 🔹 بدون هزینه API 🔹 حفظ کامل حریم خصوصی 🔹 اجرای آفلاین 🔹 مناسب برای توسعه، تست و تحقیق 🔹 پشتیبانی از صدها مدل متن‌باز 🎥 مشاهده آموزش: https://youtu.be/qS1Lwh6BwSk کانال YouTube را سابسکرایب کنید . @Amin_Techlab

🚀 چرا یادگیری Vim هنوز یک مهارت ضروری است؟ اگر با Linux، SSH، DevOps، Embedded Linux یا مدیریت سرور کار می‌کنید، احتمالاً دیر یا زود در شرایطی قرار می‌گیرید که تنها ابزار در دسترس شما Vim باشد. تصور کنید با یک ارتباط SSH پر تأخیر (High Latency) به یک سرور متصل شده‌اید و فقط می‌خواهید فایل‌هایی مانند موارد زیر را ویرایش کنید: /etc/ssh/sshd_config /etc/nginx/nginx.conf /etc/fstab /etc/systemd/*.service در چنین شرایطی، ویرایشگرهای ساده مانند Nano برای فایل‌های بزرگ یا جابه‌جایی‌های متعدد چندان کارآمد نیستند. اما Vim دقیقاً برای چنین سناریوهایی طراحی شده است. چرا Vim؟ ✅ پرش مستقیم به هر خط :100 یا 100G بدون اسکرول کردن، مستقیماً به خط موردنظر می‌روید. ✅ جستجوی سریع در فایل /keyword و حرکت بین نتایج: n N ✅ جایگزینی سراسری متن :%s/old/new/g ✅ کپی، حذف و Paste تنها با چند کلید yy Copy Line dd Delete Line p Paste ✅ اجرای سریع روی تقریباً تمام توزیع‌های لینوکس در اکثر سرورها، ماشین‌های مجازی، تجهیزات شبکه، Embedded Linux و حتی محیط‌های Recovery، Vim به‌صورت پیش‌فرض نصب است و به رابط گرافیکی وابسته نیست. اما Vim فقط یک ویرایشگر متن نیست. به طور کلی Vim یک Modal Editor است؛ یعنی برای هر نوع عملیات (حرکت، ویرایش، انتخاب و فرمان‌ها) حالت‌های اختصاصی دارد. همین معماری باعث می‌شود پس از یادگیری، سرعت و دقت ویرایش فایل‌ها چندین برابر شود. به همین دلیل بسیاری از توسعه‌دهندگان Kernel، برنامه‌نویسان Embedded، مدیران سیستم و مهندسان DevOps هنوز هم Vim را ابزار اصلی خود می‌دانند. اگر می‌خواهید مهارت خود را تقویت کنید، این منابع را از دست ندهید: 🎯 Vim Genius https://vimgenius.com/ 🎮 Vim Hero https://www.vim-hero.com/ 📖 OpenVim https://openvim.com/ 🏌️ VimGolf AI https://vimgolf.ai/ 🕹 Vim Adventures (یادگیری Vim با بازی) https://vim-adventures.com 💡 نکته: شاید امروز از Nano استفاده کنید، اما روزی که مجبور شوید روی یک سرور Remote، یک Container، یک Router یا یک سیستم Recovery فقط با Vim کار کنید، از زمانی که برای یادگیری آن گذاشته‌اید، قدردانی خواهید کرد. @Amin_Techlab

راز پشت هر برنامه لینوکس glibC : اگر تاکنون با زبان‌های C یا ++C روی لینوکس برنامه‌نویسی کرده باشید، احتمالاً بدون اینکه متوجه شوید از glibc استفاده کرده‌اید. اما glibc دقیقاً چیست و چرا تا این اندازه اهمیت دارد؟ ادامه در پست بعد .... @Amin_Techlab

راز پشت هر برنامه لینوکس glibC : اگر تاکنون با زبان‌های C یا ++C روی لینوکس برنامه‌نویسی کرده باشید، احتمالاً بدون اینکه متوجه شوید از glibc استفاده کرده‌اید. اما glibc دقیقاً چیست و چرا تا این اندازه اهمیت دارد؟ ادامه در پست بعد .... @Amin_Techlab

🚀 AMTerminal v1.0.0 منتشر شد! بعد از مدت‌ها توسعه، اولین نسخه عمومی AMTerminal  آماده است. AMTerminal  یک شل (Shell) و محیط خط فرمان (CLI) مدرن است که با زبان Rust  توسعه داده شده و روی Windows، Linux و macOS اجرا می‌شود. ✨ برخی از قابلیت‌ها: • پشتیبانی از Pipe (|) • پشتیبانی از Redirection (>, >>, <) • همراهPrompt هوشمند با نمایش وضعیت Git • تکمیل خودکار (Tab Completion) • ذخیره و جستجوی History • رنگ‌بندی و Prompt کاملاً قابل شخصی‌سازی • اجرای دستورات داخلی و خارجی • عملکرد سریع و سبک 📥 از شما دعوت می‌کنم نسخه اول را دانلود و امتحان کنید. https://github.com/Amin98Hosseini/AMTerminal_Rust/releases/tag/AMT-v1.0.0-rc.1 💬 اگر باگ، پیشنهاد یا ایده‌ای برای بهتر شدن AMTerminal دارید، حتماً در GitHub ثبت کنید یا برای من ارسال کنید. بازخورد شما نقش مهمی در توسعه نسخه‌های بعدی خواهد داشت. ⭐️ اگر پروژه را دوست داشتید، فراموش نکنید به آن در GitHub یک Star بدهید.   لینک گیت هاب پروژه : https://github.com/Amin98Hosseini/AMTerminal_Rust @Amin_Techlab

🦀 برسی کدهای اضافه شده Rust : یکی از قسمت‌های جالب این RFC، نحوه طراحی APIها در Rust است. تقریباً تمام بخش‌های Unsafe فقط در مرز ارتباط با کدهای C قرار گرفته‌اند و منطق Driver کاملاً با Safe Rust نوشته شده است. ۱- Wrapper ایمن روی APIهای C به جای اینکه Driver مستقیماً تابع C زیر را فراخوانی کند: i2c_smbus_read_byte_data(...) یک Wrapper امن در I2cClient اضافه شده است: pub fn smbus_read_byte_data(&self, command: u8) -> Result<u8> { let ret = unsafe { bindings::i2c_smbus_read_byte_data(self.as_raw(), command) }; if ret < 0 { Err(Error::from_errno(ret)) } else { Ok(ret as u8) } } در اینجا تنها بخش Unsafe همان فراخوانی تابع C است. بعد از آن، مقدار بازگشتی به یک Result<u8> استاندارد Rust تبدیل می‌شود و Driver دیگر نیازی به بررسی کدهای خطای C ندارد. ۲- پیاده‌سازی الگوی معروف Read → Modify → Write یکی از متدهای بسیار کاربردی که اضافه شده: pub fn smbus_update_bits(...) درون آن ابتدا مقدار رجیستر خوانده می‌شود: let old = self.smbus_read_byte_data(command)?; سپس فقط بیت‌های موردنظر تغییر می‌کنند: let new = (old & !mask) | (value & mask); و تنها در صورتی که مقدار واقعاً تغییر کرده باشد: if new != old { self.smbus_write_byte_data(command, new)?; } نوشتن روی سخت‌افزار انجام می‌شود. این دقیقاً همان الگویی است که تقریباً در اکثر Driverهای C لینوکس نیز دیده می‌شود. ۳- طراحی Driver با Trait به جای استفاده از Structهای متعدد و Callbackهای C، تنها کافی است Driver این Trait را پیاده‌سازی کند: pub trait Driver { const NAME: &'static CStr; const TYPE: Type; const PROPERTIES: &'static [Property]; fn get_property(...) } این طراحی باعث می‌شود هر Driver فقط روی منطق خود تمرکز کند و تمام جزئیات مربوط به Power Supply Core در پشت Abstraction پنهان بماند. ۴- استفاده از RAII برای مدیریت Driver در Rust یک Struct به نام Registration معرفی شده است. نکته جالب این است که هنگام از بین رفتن این شیء: impl Drop for Registration { fn drop(&mut self) { unsafe { bindings::power_supply_unregister(self.psy); } } } تابع power_supply_unregister() به صورت خودکار اجرا می‌شود. در نتیجه توسعه‌دهنده دیگر نگران آزادسازی منابع یا فراموش کردن Unregister کردن Driver نخواهد بود؛ این کار به کمک مکانیزم Drop در Rust انجام می‌شود. ۵- تعریف Driver واقعی فقط در چند خط در Driver مربوط به SMB347 تنها با چند ثابت می‌توان مشخص کرد که Driver چه قابلیت‌هایی دارد: const NAME: &'static CStr = c"smb347-mains"; const PROPERTIES: &'static [Property] = &[ PROP_STATUS, PROP_ONLINE, PROP_CHARGE_TYPE, ]; و سپس تنها تابعی که باید پیاده‌سازی شود: fn get_property(...) که وضعیت شارژر را از رجیسترهای سخت‌افزار می‌خواند و آن را به Power Supply Framework گزارش می‌دهد. این طراحی باعث شده حجم زیادی از کدهای تکراری Driverهای C حذف شوند و توسعه Driver بیشتر شبیه پیاده‌سازی یک Trait در Rust باشد تا کار با Callbackها و Pointerهای متعدد. ۶- نکته‌ای که توجه Maintainerها را جلب کرد یکی از جالب‌ترین قسمت‌های Review این RFC مربوط به همین چند خط بود: pub fn register<T: Driver + 'static>(dev: &Device) Alice Ryhl پیشنهاد داد که به جای &Device از &Device<Bound> استفاده شود تا از نظر Type System تضمین شود که Driver فقط روی Deviceهایی که کاملاً Bind شده‌اند ثبت می‌شود. همچنین پیشنهاد کرد این تابع به جای یک تابع آزاد، به شکل: Registration::new(...) بازطراحی شود تا با سایر APIهای Rust Kernel هماهنگ باشد. این بازخوردها نشان می‌دهد که در پروژه Rust for Linux، علاوه بر عملکرد، طراحی API و سازگاری با الگوهای Rust نیز اهمیت بسیار زیادی دارد. @Amin_Techlab

🔍 نگاهی به تغییرات کد برای Power Supply و اولین Driver شارژر باتری با Rust : این RFC تنها یک ایده تئوری نیست؛ در مجموع بیش از ۳۷۰ خط کد جدید به هسته لینوکس اضافه می‌کند که شامل دو ماژول Rust جدید و یک Driver کامل است. در Patch اول، کلاس I2cClient قابلیت‌های جدیدی برای کار با رجیسترهای سخت‌افزار دریافت می‌کند. سه متد جدید شامل: smbus_read_byte_data() smbus_write_byte_data() smbus_update_bits() اضافه شده‌اند. دو تابع اول، Wrapperهای ایمن (Safe Wrapper) روی توابع C مربوط به SMBus هستند و تمامی عملیات Unsafe و FFI را در داخل خود مخفی می‌کنند. به این ترتیب، توسعه‌دهنده Driver بدون نیاز به کار با Pointerها یا فراخوانی مستقیم APIهای C می‌تواند رجیسترهای سخت‌افزار را بخواند یا تغییر دهد. تابع smbus_update_bits() نیز یکی از پرکاربردترین الگوهای توسعه Driver را پیاده‌سازی می‌کند؛ یعنی عملیات Read → Modify → Write. این تابع ابتدا مقدار رجیستر را می‌خواند، تنها بیت‌های موردنظر را تغییر می‌دهد و در صورتی که مقدار واقعاً تغییر کرده باشد، دوباره آن را روی سخت‌افزار می‌نویسد. این همان الگویی است که در بسیاری از Driverهای C کرنل نیز استفاده می‌شود. در Patch دوم، فایل جدید rust/kernel/power_supply.rs اضافه شده که در واقع یک لایه Abstraction برای زیرسیستم Power Supply است. در این فایل یک Trait جدید با نام Driver تعریف شده که هر Driver تنها کافی است چهار بخش اصلی را پیاده‌سازی کند: نام Device نوع Power Supply لیست Propertyهای قابل پشتیبانی تابع get_property() سپس یک Callback عمومی (get_property_trampoline) ارتباط بین Power Supply Core که در C نوشته شده و Driver نوشته‌شده با Rust را برقرار می‌کند. به این ترتیب تمام جزئیات FFI در یک نقطه متمرکز شده و بقیه Driver کاملاً Safe Rust باقی می‌ماند. یکی دیگر از نکات جالب این Patch، استفاده از الگوی RAII است. ساختار Registration مسئول ثبت Driver در Power Supply Core است و هنگام Drop شدن، به صورت خودکار power_supply_unregister() را فراخوانی می‌کند. بنابراین مدیریت چرخه عمر Driver نیز مطابق الگوهای Rust انجام می‌شود. در Patch سوم نیز یک Driver واقعی برای شارژر SMB347 پیاده‌سازی شده است. این Driver مجموعه‌ای از ثابت‌های مربوط به رجیسترهای سخت‌افزار، بیت‌ها و وضعیت‌های مختلف چیپ را تعریف می‌کند و سپس با استفاده از Abstractionهای جدید، وضعیت شارژ، آنلاین بودن منبع تغذیه و نوع شارژ را از روی رجیسترهای سخت‌افزار استخراج کرده و از طریق Power Supply Framework در اختیار فضای کاربر قرار می‌دهد. در واقع این Driver اولین مصرف‌کننده (First Consumer) از Abstraction جدید Power Supply است و نشان می‌دهد که API طراحی‌شده واقعاً برای توسعه Driverهای واقعی قابل استفاده است، نه صرفاً یک نمونه آزمایشی. @Amin_Techlab

🚀 گام مهم Rust for Linux: اولین Abstraction برای Power Supply و اولین Driver شارژر باتری با Rust پروژه Rust for Linux یک RFC جدید منتشر کرده که یکی از مهم‌ترین قدم‌ها برای گسترش Rust در زیرسیستم‌های کرنل محسوب می‌شود. در این RFC، سه تغییر مهم پیشنهاد شده است: ✅ اضافه شدن APIهای SMBus برای I2C در Rust ✅ طراحی اولین Abstraction برای Power Supply Class ✅ پیاده‌سازی اولین Driver شارژر باتری (SMB347) با زبان Rust چرا این RFC مهم است؟ تا امروز، اگر قصد داشتید یک Driver مربوط به باتری یا شارژر را با Rust بنویسید، دو مانع اساسی وجود داشت: • هیچ Abstraction امنی برای Power Supply Class در Rust وجود نداشت. • I2C Client فقط عملیات مدیریت Device را انجام می‌داد و امکان خواندن یا نوشتن Registerهای سخت‌افزار را فراهم نمی‌کرد. در نتیجه، توسعه Driverهای واقعی تقریباً غیرممکن بود. بخش اول: توسعه APIهای I2C در این RFC توابعی مانند: • smbus_read_byte_data() • smbus_write_byte_data() • smbus_update_bits() به I2C Client اضافه شده‌اند. تابع smbus_update_bits() همان الگوی معروف Read → Modify → Write را پیاده‌سازی می‌کند؛ الگویی که تقریباً در تمام Driverهای کرنل برای تغییر بخشی از بیت‌های یک Register استفاده می‌شود. بخش دوم: Power Supply Abstraction مهم‌ترین قسمت این RFC، معرفی یک Abstraction جدید برای زیرسیستم Power Supply است. در این طراحی، Driver فقط کافی است: • نام Device را مشخص کند. • نوع Power Supply را تعیین کند. • لیست Propertyهای قابل پشتیبانی را معرفی کند. • تابع get_property() را پیاده‌سازی کند. تمام جزئیات ارتباط با Power Supply Core در پشت یک API ایمن پنهان شده است. علاوه بر این، Registration نیز با الگوی RAII طراحی شده تا فرآیند Register و Unregister شدن Driver به‌صورت خودکار مدیریت شود. بخش سوم: اولین Driver واقعی برای اثبات کارایی این Abstraction، توسعه‌دهنده یک نسخه Rust از Driver مربوط به شارژر Summit SMB347 پیاده‌سازی کرده است. این Driver: • از طریق I2C با چیپ ارتباط برقرار می‌کند. • Registerهای وضعیت را می‌خواند. • وضعیت شارژ را به Power Supply Core گزارش می‌دهد. • اطلاعاتی مانند: STATUS ONLINE CHARGE_TYPE را از طریق مسیر استاندارد: /sys/class/power_supply در اختیار فضای کاربر قرار می‌دهد. از دید کاربران لینوکس، این Driver دقیقاً مانند Driverهای نوشته‌شده با C رفتار می‌کند. نکته جالب در فرآیند Review، یکی از توسعه‌دهندگان Rust for Linux پیشنهاد کرد که APIهای SMBus به‌صورت توابع مستقل اضافه نشوند و در عوض، I2cClient مستقیماً Trait استاندارد kernel::io::Io را پیاده‌سازی کند. نویسنده RFC نیز این پیشنهاد را پذیرفت و اعلام کرد که نسخه بعدی Patch بر اساس معماری جدید بازنویسی خواهد شد. این دقیقاً همان چیزی است که توسعه کرنل لینوکس را جذاب می‌کند؛ طراحی APIها قبل از Merge شدن، چندین بار توسط Maintainerها بازبینی و اصلاح می‌شوند تا در نهایت بهترین معماری ممکن وارد Mainline شود. اگر این RFC در نهایت پذیرفته شود، یکی از زیرسیستم‌های مهم کرنل یعنی Power Supply نیز به فهرست بخش‌هایی اضافه خواهد شد که توسعه Driverهای آن با Rust امکان‌پذیر است؛ گامی دیگر در مسیر گسترش تدریجی Rust در هسته لینوکس. @Amin_Techlab

Harmonic Firmware Initiative (HFI) aims to create, standardize, and maintain — for RISC-V systems — something the x86 world has taken for granted for forty years: a genuine power-on firmware experience @Amin_Techlab