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

🚀 گام مهم 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

🔍 نگاهی به تغییرات کد برای 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 :
یکی از قسمت‌های جالب این 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

🚀 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

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

ادامه در پست بعد ....
@Amin_Techlab

آشنایی با glibc :
کتابخانهٔ GNU C Library (glibc)، پیاده‌سازی رسمی پروژهٔ GNU از کتابخانهٔ استاندارد زبان C است.
افزون‌براین، این کتابخانه علاوه بر توابع استاندارد ISO C، بخش بزرگی از رابط‌های برنامه‌نویسی POSIX و بسیاری از قابلیت‌های اختصاصی لینوکس را نیز در اختیار برنامه‌ها قرار می‌دهد.

برای نمونه، هر زمان که در برنامهٔ خود از توابعی مانند:
• printf()
• malloc()
• free()
• open()
• read()
• write()
• pthread_create()
• getaddrinfo()
استفاده می‌کنید، در اکثر توزیع‌های لینوکس این توابع توسط glibc پیاده‌سازی شده‌اند.

اهمیت glibc :
نخست، کرنل لینوکس تنها System Callها را در اختیار برنامه‌ها قرار می‌دهد و استفادهٔ مستقیم از آن‌ها چندان ساده نیست.
در این میان، glibc نقش یک لایهٔ واسط را بر عهده می‌گیرد.
در عمل، این کتابخانه به‌عنوان یک لایهٔ انتزاعی (Abstraction Layer) میان برنامه و کرنل قرار می‌گیرد و APIهای استاندارد و قابل‌حمل را در اختیار توسعه‌دهندگان قرار می‌دهد.
در نتیجه، برنامه‌نویس بدون درگیر شدن با جزئیات معماری پردازنده یا فراخوانی مستقیم System Callها، تنها با استفاده از توابع استاندارد زبان C می‌تواند با سیستم‌عامل ارتباط برقرار کند.

قابلیت‌های glibc :
✅ پشتیبانی کامل از استاندارد ISO C
✅ پشتیبانی گسترده از POSIX
✅ مدیریت حافظه (malloc و free)
✅ مدیریت رشته‌ها و کاراکترها
✅ مدیریت فایل و عملیات ورودی/خروجی
✅ پشتیبانی از شبکه و سوکت‌ها
✅ مدیریت Threadها با POSIX Threads
✅ بارگذاری کتابخانه‌های اشتراکی (Dynamic Loader)
✅ پشتیبانی از Locale و بین‌المللی‌سازی (Internationalization)

جایگزین‌های glibc :
البته، glibc تنها کتابخانهٔ استاندارد موجود برای لینوکس نیست.
برای مثال، کتابخانه‌های زیر نیز توسعه یافته‌اند:
• musl libc
• uClibc-ng
• Bionic (مورد استفاده در اندروید)
بااین‌حال، glibc همچنان پرکاربردترین کتابخانهٔ استاندارد در توزیع‌هایی مانند Debian، Ubuntu، Fedora و RHEL محسوب می‌شود.

ارزش یادگیری glibc :
چنانچه در یکی از حوزه‌های زیر فعالیت می‌کنید:
🔹 برنامه‌نویسی سیستمی (System Programming)
🔹 توسعهٔ کرنل
🔹 Embedded Linux
🔹 امنیت نرم‌افزار
🔹 طراحی Runtime یا Compiler
🔹 مهندسی معکوس
بدانید که مطالعهٔ مستندات و حتی کدهای glibc دید بسیار عمیق‌تری نسبت به نحوهٔ ارتباط برنامه‌ها با سیستم‌عامل در اختیار شما قرار می‌دهد.


جالب است بدانید پروژهٔ glibc بیش از ۳۰ سال قدمت دارد و همچنان یکی از مهم‌ترین پروژه‌های متن‌باز دنیای لینوکس به شمار می‌رود.
امروزه، تقریباً هر برنامه‌ای که روی یک توزیع لینوکسی اجرا می‌کنید، به‌صورت مستقیم یا غیرمستقیم به این کتابخانه وابسته است.
به‌همین‌دلیل، شناخت glibc برای هر برنامه‌نویس سیستم، توسعه‌دهندهٔ لینوکس و حتی علاقه‌مندان به امنیت، یک مهارت بنیادی و ارزشمند محسوب می‌شود.

@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

🚀 هوش مصنوعی را روی کامپیوتر خودتان اجرا کنید؛ بدون اینترنت، بدون 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

🚀 اگر هنوز 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

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

🧩 کالبدشکافی فنی 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

⚙️ کالبدشکافی فنی 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
🔜 ادامه دارد...

@Amin_Techlab

⚙️ کالبدشکافی فنی 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

⚙️ کالبدشکافی فنی 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

⚙️ کالبدشکافی فنی 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

🚀 نکات کوتاه و کاربردی زبان C
اگه با C، میکروکنترلرها و سیستم‌های Embedded کار می‌کنی، این پلی‌لیست رو از دست نده! 👨‍💻⚡️
توی این مجموعه از YouTube Shorts، نکات، ترفندها و مفاهیم کاربردی زبان C رو در ویدیوهای کوتاه و سریع بررسی می‌کنیم؛ مناسب برای یادگیری و مرور سریع.

▶️ مشاهده پلی‌لیست (نکات و ترفندهای زبان |C Programming Tips)
https://www.youtube.com/playlist?list=PLf9OiDN9PuA4

@Amin_Techlab