لینوکس و درایور چیست؟ مسیر خواندن دما در یک دستگاه امبدد
ممکن است یک دستگاه لینوکس را اجرا کند، اما حسگرش کار نکند. مثال دماسنج انبار نشان می‌دهد برنامه، هسته و درایور هر کدام چه نقشی دارند و مشکل را از کجا بررسی کنیم.
فهرست مطالب
لینوکس به برنامه‌های یک دستگاه کمک می‌کند از حافظه، پردازنده و وسایل متصل استفاده کنند. هستهٔ لینوکس این منابع را مدیریت می‌کند و درایور، روش کار با یک وسیله را به آن می‌شناساند. برای همین ممکن است دستگاه روشن شود و برنامه اجرا شود، اما دماسنجش هنوز کار نکند: راه افتادن لینوکس، به‌تنهایی نشانهٔ آماده‌بودن همهٔ قطعات نیست.
یک دستگاه فرضی را در نظر بگیرید که دمای انبار را می‌خواند و روی صفحه نشان می‌دهد. حسگر، قطعه‌ای است که دما را به مقداری قابل خواندن تبدیل می‌کند. برد، صفحه‌ای است که قطعات و مسیرهای اتصالشان روی آن قرار دارند. پردازندهٔ روی برد دستورهای برنامه را اجرا می‌کند. این دستگاه برای یک کار مشخص ساخته شده است؛ به چنین کاربردی «امبدد» یا «تعبیه‌شده» می‌گویند. برای دنبال‌کردن مثال، خرید برد یا اجرای کد لازم نیست.
سیستم‌عامل، هسته و برنامه چه فرقی دارند؟
سیستم‌عامل مجموعهٔ نرم‌افزارهایی است که اجرای برنامه‌ها و استفاده از امکانات دستگاه را ممکن می‌کند. هسته یا Kernel بخش مرکزی آن است: تعیین می‌کند برنامه‌ها چه زمانی اجرا شوند، چه حافظه‌ای در اختیار داشته باشند و از چه راهی با سخت‌افزار ارتباط بگیرند. سخت‌افزار همان بخش‌های فیزیکی، مانند پردازنده، حافظه و حسگر است.
نام «لینوکس» گاهی برای خود هسته و گاهی برای یک سیستم کامل به کار می‌رود. سیستم کاملی که روی برد نصب می‌شود، علاوه بر هسته به فایل‌ها و برنامه‌های لازم هم نیاز دارد. برنامهٔ نمایش دما یکی از همین برنامه‌هاست؛ وظیفهٔ آن انتخاب متن، ثبت زمان و نمایش نتیجه است، نه مدیریت مستقیم همهٔ جزئیات قطعات.
درایور دقیقاً چه کاری انجام می‌دهد؟
درایور نرم‌افزاری است که جزئیات کار با یک وسیله یا خانواده‌ای از وسایل را می‌داند. برای حسگر این مثال، می‌تواند وسیله را آماده کند، داده‌اش را بخواند و نتیجه یا خطا را از رابط مشخصی در اختیار برنامه بگذارد. همهٔ درایورها جداگانه نصب نمی‌شوند؛ بعضی از ابتدا جزئی از هسته‌اند و بعضی به شکل «ماژول»، یعنی بخش قابل بارگذاریِ هسته، اضافه می‌شوند.
وجود فایل درایور کافی نیست. باید برای نسخه و تنظیمات همان هسته مناسب باشد و به وسیلهٔ درست متصل شود. لینوکس برای پیدا کردن این تطابق و آماده‌کردن وسیله، سازوکار مشخصی دارد که در مستند اتصال وسیله و درایور توضیح داده شده است. یک ماژول ساخته‌شده برای هسته‌ای دیگر را هم نباید صرفاً با کپی فایل، سازگار فرض کرد؛ ساخت ماژول خارجی به اطلاعات ساخت هستهٔ مقصد وابسته است.
اگر حسگر با I²C وصل باشد، این نام روش تبادل داده روی اتصال را مشخص می‌کند؛ درایور حسگر و پشتیبانی کنترل‌کنندهٔ I²C هر دو در مسیر خواندن نقش دارند. برای آشنایی با تفاوت این اتصال و دو روش رایج دیگر، مقایسهٔ I²C، SPI و UART را ببینید. صرف وجود یک درگاه، به معنی پشتیبانی از همهٔ وسایل قابل اتصال به آن نیست.
مثال: عدد ۲۵۴۰۰ چگونه به دمای ۲۵٫۴ درجه تبدیل می‌شود؟
فرض کنید درایورِ حسگر فرضی ما، دما را از رابط پایش سخت‌افزار لینوکس، hwmon، در اختیار برنامه می‌گذارد. این رابط، اطلاعات بعضی حسگرها را شبیه فایل‌های قابل خواندن نمایش می‌دهد. خواندن آن فایل درخواست داده از هسته است؛ فایل، سندی نیست که کسی دما را در آن تایپ کرده باشد.
برای این مثال، مستند همان درایور تأیید کرده است که مقدار دما بر حسب هزارم درجهٔ سلسیوس است. هر هزار واحد برابر یک درجه است؛ پس:
25400 / 1000 = 25.4 °C
25600 / 1000 = 25.6 °C
(25.4 + 25.6) / 2 = 25.5 °Cدو خواندن موفق داریم و میانگین آن‌ها ۲۵٫۵ درجه است. اگر خواندن سوم با خطا تمام شود، سه اندازه‌گیری معتبر نداریم. نتیجهٔ درست برای این مثال «میانگین دو مقدار معتبر: ۲۵٫۵ درجه؛ یک خطای خواندن» است. اگر خطا را صفر بگذاریم و بر سه تقسیم کنیم، به ۱۷ درجه می‌رسیم؛ عددی که هیچ‌یک از دو خواندن موفق آن را نشان نداده‌اند.
دمای واقعیِ صفر درجه با «داده نداریم» فرق دارد. برنامه باید علاوه بر مقدار، وضعیت موفق یا ناموفق خواندن و زمان آن را نگه دارد. مقدار قدیمی هم نباید بدون نمایش زمان، دمای همین لحظه معرفی شود. میانگین‌گیری تنها یک انتخاب برای نمایش داده است و درستی حسگر یا ایمنی کنترل دما را ثابت نمی‌کند.
این اعداد فرضی‌اند. در کار واقعی باید نام حسگر، محل نصب، واحد و وضعیت خطا را از مستند همان درایور بررسی کرد. همهٔ حسگرها از hwmon استفاده نمی‌کنند و حتی بعضی ورودی‌های دما در این رابط، ولتاژ را گزارش می‌کنند و به تبدیل دیگری نیاز دارند. مستند رسمی hwmon این استثنا را توضیح می‌دهد؛ تقسیم هر عددی بر هزار، دستور عمومی خواندن دما نیست.
اگر دما نمایش داده نشد، از کجا بررسی کنیم؟
«دماسنج کار نمی‌کند» هنوز علت را مشخص نمی‌کند. برای مثال انبار، این ترتیب کمک می‌کند محل مشکل را محدود کنیم:
| چیزی که می‌بینیم | بررسی بعدی | نتیجه‌ای که هنوز نمی‌توان گرفت |
|---|---|---|
| برنامه باز نمی‌شود | اجرای خود برنامه، فایل‌های لازم و اجازهٔ دسترسی | هنوز معلوم نیست حسگر یا درایورش خراب است. |
| برنامه اجرا می‌شود، اما ورودی حسگر را پیدا نمی‌کند | وجود رابط مورد انتظار، فعال‌بودن پشتیبانی وسیله و شناسایی آن | نبودن ورودی، به‌تنهایی خرابی فیزیکی حسگر را ثابت نمی‌کند. |
| ورودی وجود دارد، اما خواندن خطا می‌دهد | متن خطا، تغذیه و اتصال مطابق راهنمای برد، و پیام‌های همان درایور | نصب دوبارهٔ برنامه الزاماً مشکل اتصال را حل نمی‌کند. |
| خواندن موفق است، اما عدد عجیب است | حسگر و کانال درست، واحد، تبدیل عدد، محل نصب و زمان آخرین داده | نمایش یک عدد، نشانهٔ اندازه‌گیری درست نیست. |
این جدول مسیر عیب‌یابی است، نه تشخیص قطعی از راه دور. مثلاً خطای خواندن می‌تواند چند علت داشته باشد. پیش از تغییر تنظیمات، وضعیت قبلی و متن کامل خطا را ثبت کنید تا معلوم بماند کدام تغییر چه اثری داشته است.
چرا کرنل جدید، فایل آمادهٔ نصب روی هر برد نیست؟
کد منبع، دستورهای قابل ویرایشی است که برنامه‌نویسان نوشته‌اند. برای استفاده از هسته، این کد باید با تنظیمات مناسب به فایل اجرایی تبدیل شود؛ به این کار «کامپایل» می‌گویند. راهنمای رسمی ساخت هسته نیز انتخاب تنظیمات را بخشی از این فرایند می‌داند. فایل آمادهٔ راه‌اندازی یک برد معمولاً چیزهای بیشتری از هسته دارد.
- راه‌انداز یا Bootloader: نرم‌افزار اولیه‌ای که مسیر شروع سیستم‌عامل را آماده می‌کند. U-Boot یکی از نمونه‌هاست؛ همهٔ بردها از آن استفاده نمی‌کنند. راهنمای U-Boot نشان می‌دهد انتخاب فایل‌های راه‌اندازی بخشی از این مسیر است.
- توصیف سخت‌افزار: روی بسیاری از بردها، Device Tree اطلاعاتی دربارهٔ قطعات و اتصال‌هایشان به هسته می‌دهد. این داده جای درایور را نمی‌گیرد و سیم‌کشی اشتباه را اصلاح نمی‌کند. مستند Device Tree نقش آن را شرح می‌دهد.
- برنامه‌ها و فایل‌های سیستم: دستگاه به محیطی نیاز دارد که برنامهٔ نمایش دما و وابستگی‌هایش از آن اجرا شوند.
- فرم‌ویر مورد نیاز بعضی وسایل: برخی قطعات علاوه بر درایور، فایل نرم‌افزاری دیگری می‌خواهند که روی خود آن قطعه بارگذاری می‌شود. این کاربردِ واژهٔ firmware را با نامی که گاهی به کل نرم‌افزار دستگاه می‌دهند، اشتباه نگیریم. راهنمای firmware لینوکس نمونه‌های این نیاز را آورده است.
Mainline شاخهٔ اصلی توسعهٔ هسته است. انتشار نسخه‌ای از آن، گزارش آزمون محصول شما نیست. توضیح شاخه‌های انتشار در kernel.org نیز میان شاخهٔ اصلی، نسخه‌های اصلاحی و نگهداری بلندمدت تفاوت می‌گذارد. برای انتخاب نسخه، پشتیبانی سازندهٔ برد، اصلاحات امنیتی، درایورهای لازم و امکان بازگشت به نسخهٔ قبلی را با هم بررسی کنید؛ بزرگ‌تر بودن شمارهٔ نسخه معیار کافی نیست.
پیش از تغییر نسخه، چه نتیجه‌ای باید ثابت شود؟
برای دماسنج فرضی، ابتدا ترکیب فعلیِ مدل برد، نسخهٔ سیستم، تنظیمات و فایل‌های لازم را ثبت می‌کنیم. سپس روی نمونهٔ آزمایشی بررسی می‌کنیم که سیستم بالا می‌آید، حسگر درست شناخته می‌شود، واحد دما درست است و برنامه هنگام قطع داده، خطا را روشن نشان می‌دهد. راه‌اندازی دوباره، قطع و وصل تغذیه و مدت کار مورد نیاز محصول هم باید در برنامهٔ آزمون واقعی باشند. موفقیت در کامپایل فقط نشان می‌دهد مرحلهٔ ساخت گذشته است؛ جای این آزمون‌ها را نمی‌گیرد.
لازم نیست هر دستگاه امبدد لینوکس داشته باشد. یک کنترل‌کنندهٔ کوچک می‌تواند برنامهٔ اختصاصی خود را اجرا کند؛ دستگاهی با چند برنامه و امکانات بیشتر ممکن است از لینوکس استفاده کند. نقطهٔ شروع، کاری است که دستگاه باید انجام دهد. برای ادامه، مسیر آموزش سیستم‌های امبدد و برای فهم تفاوت عدد قابل نمایش و اندازه‌گیری قابل اعتماد، دقت، تفکیک‌پذیری و کالیبراسیون حسگر مکمل این مثال‌اند.
پرسش و پاسخ مقاله
سوال فنی خود را مطرح کنید
پرسش‌ها و پاسخ‌ها پس از بررسی مدیر منتشر می‌شوند. نویسنده، پیش‌نویس در انتظار بررسی را می‌بیند.
هنوز پرسش تاییدشده‌ای برای این مقاله ثبت نشده است.