لیست مقاله‌ها

چند روز پیش می‌خواستم که یه su - خیلی سریع انجام بِدم، پس با عجله یه پنجره‌ی جدید از Konsole رو باز کردم و داخلش cd - رو نوشتم و Enter زدم… گفتش که bash: cd: OLDPWD not set :| ها؟! :)) اولش یه لحظه‌ی کوتاهی جا خوردم و خُب سریع متوجه اشتباهم داخل تایپ دستور شدم، ولی بعدش اون پیغام خطا توجهم رو جلب کرد… دوباره یه نگاه به قیافه‌ی cd - انداختم و با توجه به اینکه خطا، داخل یه پنجره‌ی کاملاً جدید رخ داده بود، یادم به یه مقاله‌ای افتاد که چندین ماه پیش یه مروری روش داشتم، ولی دیگه تقریباً فراموشش کرده بودم: نحوه‌ی بَک (back) زدن داخل شِل (shell) لینوکس…

قطعاً جواب درست اینه: «بستگی داره»! ولی خیلی از افراد، وقتی کلمه‌ی «lead» رو ببینن، اون رو درجا به‌صورت /liːd/ یا /لید/ تلفظ می‌کنن. خُب در خیلی از کاربردهای اسمی، فعلی، و وصفی این کلمه، همین تلفظ درسته دیگه… اما حالا داخل خیلی از سایت‌ها که نگاه کنید، می‌بینید که سیم لحیم «بدون سُرب» یا «lead-free» رو به‌شکل «لید-فری» نوشته یا مثلاً باتری‌های «سرب-اسید» یا «lead-acid» رو به‌عنوان «لید-اسید» معرفی می‌کنن… از قضای روزگار، چون که داخل هر دو تای این مثال‌ها، کلمه‌ی «lead» به معنای «سرب» به کار رفته، بایستی به‌شکل /lɛd/ یا /لِد/ تلفظ بشه و خوندن و نوشتن اون به‌صورت «لید» در این کاربرد، اشتباهه. کلاً داخل بحث‌های الکترونیکی و رباتیکی، در دو تا زمینه‌ی مجزا به کلمه‌ی «lead» بَر می‌خوریم: یکی به همین معنی «فلز سرب»، که درباره‌ی سیم لحیم و باتری‌ها مطرح می‌شه و مورد بعدی، در معنی «پایه‌ی» قطعات الکترونیکی هست که البته براش از کلمه‌ی «pin» هم استفاده می‌کنیم. نکته‌ای که باید بهش توجه کرد (ولی متأسفانه معمولاً نادیده گرفته می‌شه)، اینه که تلفظ این کلمه در این دو کاربرد، متفاوته… بیاید امروز یه‌کمی «lead» رو در کاربردهای الکترونیکی و رباتیکی‌اش برررسی کنیم.

بَسه دیگه!!! چقدر کامپیوتر و برنامه‌نویسی و میکروکنترلر و ماسفِت؟؟!! هر چیزی حدی داره! بیاید امروز یه‌کمی از فضای کار تخصصی دور بشیم و یه قضیه‌ی متفاوت رو بررسی کنیم! ناسلامتی قراره ما درباره‌ی DIY هم صحبت کنیم دیگه... :)) اگه گفتین چی از شیرکاکائو بهتره؟؟؟ «شیرکاکائوی غلیظ»!!! :)) اگه شما هم مثل من به کاکائو و شیرکاکائو علاقه‌ی خاصی دارید، شاید از غلیظ‌تر شدنش لذت مضاعفی ببرید. طی چند سال قبل، یه سری آزمایش‌هایی برای درست کردن شیرکاکائو و افزایش غلظتش انجام داده‌ام و به نتایج خوبی رسیده‌ام که رضایت بیشتری رو برام به همراه داشته! گفتم شاید بد نباشه که این موارد رو با شما هم در میون بذارم.

برخلاف خیلی چیزهای دیگه درباره‌ی ماسفِت (MOSFET)، نام پایه‌های این قطعه رو خیلی خوب انتخاب کرده‌اند! :)) اگر یه‌کمی به معنی کلماتی فکر کنیم که به‌عنوان اسم پایه‌های ماسفت انتخاب شده‌اند، می‌تونیم یه درک خوبی از رفتار پایه‌ها و ترانزیستور پیدا کنیم. علاوه‌بر این، نام‌ها طوری انتخاب شده‌اند که با کارکرد معمول و رایج قطعه هم‌خوانی داشته باشن؛ به همین خاطر، وقتی که معنی اسم پایه‌ها رو درک کنیم، می‌تونیم جهت جریان رو داخل استفاده‌های معمول از ماسفت، استنتاج کنیم. داخل این مقاله، اول یه بررسی زبانی روی معنی اسم پایه‌های ماسفت داریم. با این کار، علت نام‌گذاری پایه‌ها برامون مشخص می‌شه. بعدش با استفاده از دانشی که درباره‌ی اسم پایه‌ها به دست آورده‌ایم، جهت معمول جریان رو داخل ماسفت تعیین می‌کنیم. دیگه هیچ نیازی به حفظ کردن نداریم! :)

نماد الکترونیک ترانزیستورها می‌تونه حامل اطلاعات قابل توجهی درباره‌ی نوع اون ترانزیستور، پایه‌هاش، جهت جریان عبوری ازش، کارکردش، و حتی ساختار داخلیش باشه. باید این توانایی رو در خودمون ایجاد کنیم تا بتونیم با نگاه کردن به نماد ترانزیستور، ویژگی‌های اون ترانزیستور رو استخراج کنیم. با این کار، هم مدارهایی رو که می‌بینیم، بهتر درک می‌کنیم و هم موقع ترسیم نماد قطعات، احتمال اشتباهاتمون کمتر می‌شه. یه قاعده‌ی خیلی مهم که برای درک نماد قطعات نیمه‌هادی بهش نیاز داریم، خودش رو به‌سادگی داخل نماد دیود نشون می‌ده. پس بهتره که یه مروری روی مفاهیم پایه‌ی نماد نیمه‌هادی‌ها و به‌خصوص، نماد الکترونیک دیود داشته باشیم. این مطالعه، إن‌شاءالله یه شروعی می‌شه برای درک بهتر نماد الکترونیک قطعات نیمه‌هادی.

وقتی که فقط دو تا زبان ورودی برای کیبورد تعریف کرده باشیم (مثلاً «فارسی» و «انگلیسی»)، جابه‌جایی بین اون‌ها به‌سادگی با استفاده از Alt + Shift انجام می‌شه (یا حالا هر میان‌بُر دیگه‌ای که شما بهش عادت دارید). اما زمانی که تعداد زبان‌ها از دو تا بیشتر بشه، دیگه Alt + Shift خیلی راه‌حل جالبی نیست، چون که ما رو مجبور می‌کنه تا داخل لیست زبان‌های ورودی کیبورد، دور بزنیم تا به زبون مورد نظرمون برسیم. داخل این جور موارد، راه‌حل بهتر می‌تونه استفاده از کلیدهای میان‌بُر برای انتخاب مستقیم هر زبان ورودی باشه. این امکان، هم در ویندوز و هم در لینوکس وجود داره. اما علاوه بر اون، KDE یه امکانی تحت عنوان «Spare layouts» ارائه می‌ده که داخل بعضی از سناریوهای استفاده از کیبورد، می‌تونه همون راحتی Alt + Shift رو دوباره به ما هدیه کنه! :)

یادمه بچه که بودم، تلاش می‌کردم که تایپ لمسی یا تایپ ده‌انگشتی رو با استفاده از یه نرم‌افزاری یاد بگیرم که تحت محیط Command ویندوز اجرا می‌شد. احتمالاً این برنامه رو هم روی ویندوز 98، هم روی Me، و بعدها هم روی XP اجرا کرده باشم… شاید حتی خیلی بعدش روی ویندوز 7 هم ادامه داشته… راستش دقیق یادم نیست… خلاصه، ایده اینه که احتمالاً مدت‌زمان قابل توجهی رو -هرچند نامنظم- به یادگیری تایپ لمسی مشغول بوده‌ام… اما یه جورایی هیچ‌وقت حس خوبی نسبت به این قضیه نداشتم، انگار احساس پیشرفت نمی‌کردم و به نظرم می‌رسید که اون چیزی که مثلاً داخل یه درس تمرین می‌کنم، بعد از یه مدتی از یادم می‌ره… البته احتمالاً مثل هر بحث دیگه‌ای، عوامل خیلی مختلفی داخل این قضیه دخیل بوده‌اند… اما جالبه که این داستان، یه نقطه‌ی عطف خیلی غیرمنتظره برای من داشت: فقط زمانی پیشرفت رو در خودم احساس کردم که قانون اساسی تایپ لمسی رو موقع تمرین، زیر پا گذاشتم! :D

وقتی وارد دنیای سخت‌افزار یا الکترونیک می‌شی و می‌خوای یه مقداری سیم بخری، پیشِ خودت فکر می‌کنی که «مگه خریدی راحت‌تر از خرید سیم هم ممکنه وجود داشته باشه؟»… ولی بعد از کمی جست‌وجوی اینترنتی یا فیزیکی، متوجه می‌شی که خرید سیم، «یه تیکه سیم ناقابل»، با اون قیافه‌ی ساده و فریب‌کارانه‌اش، اصلاً کار راحتی نیست…

در بخش قبلی این مقاله، دیدیم که می‌تونیم رجیسترهای پریفرال میکروکنترلر STM32F030K6T6 رو به‌صورت ماکروهای کاملاً مجزا تعریف کنیم؛ اما تعریف تک‌تک رجیسترها به‌صورت ماکرو، تنها راه نیست. یکی دیگه از روش‌هایی که می‌شه پیش گرفت، استفاده از struct هست. در این مقاله، روش استفاده از struct رو برای دسترسی به رجیسترهای پریفرال سیستم، بررسی می‌کنیم.

یکی از اون الگوهای رایجی که خیلی جاها می‌بینیم، ترکیب کردن تعریف یه struct با یه اعلان typedef هست؛ اما واقعاً معنی و مفهوم این تعریف‌ها چیه؟ چرا ممکنه که بخوایم تعریف یه struct رو با یه typedef همراه کنیم؟ در این مقاله تلاش می‌کنیم تا إن‌شاءالله به این سؤالات پاسخ بدیم.

گاهی‌اوقات یه ساختار مشابه رو داخل نرم‌افزارها، برنامه‌ها، و libraryهای مختلف می‌بینیم و اصلاً نمی‌دونیم که چرا اون الگو، هِی تکرار می‌شه. داخل مهندسی نرم‌افزار هم مثل بقیه‌ی جاها، ما خیلی‌اوقات برای حل مشکلات تکراری و رایج، از روش‌های تکراری و راه‌حل‌های شناخته‌شده استفاده می‌کنیم؛ پس وقتی که یه الگوی تکراری رو می‌بینیم، باید بدونیم که به احتمال خیلی زیادی، یه مشکل رایج وجود داره و از اون ساختار، برای حل اون مشکل استفاده می‌شه. یکی از این الگوهای خیلی‌خیلی متداولی که همیشه داخل فایل‌های هِدِر (header) می‌بینیمش، ساختار #include guard هست. در این مقاله، یه مشکل همیشگی که داخل استفاده از فایل‌های هدر وجود داره مطرح می‌شه و بعدش، ما الگوی #include guard رو برای حل اون مشکل، معرفی و بررسی می‌کنیم. نکات مختلف و راه‌حل احتمالی دیگه‌ای هم برای حل این مسأله، بیان خواهد شد.

توصیه می‌شه که همیشه از بلاک برای محتوای ساختارهای کنترلی استفاده کنید؛ یعنی همیشه از یک‌جفت آکولاد برای if، else، for، while، و do استفاده کنید؛ حتی اگر فقط یک خط داخل بلاک قرار بگیره و حتی اگر هیچ خطی داخل بلاک، وجود نداشته باشه! خلاصه ایده‌ی اساسی اینه که تلاش کنیم تا هیچ‌وقت، آکولادها رو جا نندازیم. هیچ شکی نیست که این مسائل، خیلی سلیقه‌ایه؛ اما این توصیه، یه دلیل خیلی مهم داره: زمانی که بخوایم محتوای ساختار کنترلی رو تغییر بدیم و خطوطی رو کم یا زیاد کنیم، دیگه این امکان وجود نداره که آکولادها رو جا بندازیم و ناخواسته، روال برنامه رو تغییر بدیم؛ اتفاقی که برای اغلب ما، اصلاً ناآشنا نیست!

در بخش قبلی این مقاله، بررسی کردیم که چطوری می‌تونیم با استفاده از ماکروها، به آدرس‌های حافظه و رجیسترهای پریفرال سیستم دسترسی پیدا کنیم. تا اینجا برای سادگی، ما فقط به یکی از رجیسترهای سیستم کار داشتیم. در بخش ۳ این مقاله، می‌خوایم حالت واقعی‌تری رو بررسی کنیم که در اون، سیستم ما تعداد زیادی رجیستر و پریفرال داره و لازمه که همه‌ی اون‌ها رو تعریف کنیم.

داکیومنت‌های رسمی مربوط به میکروکنترلرهای STM32 و کلاً داکیومنت‌های رسمی مربوط به میکروکنترلرهای ARM، برخلاف داکیومنت(های) رسمی میکروکنترلرهای دیگه‌ای مثل ATmega328P، خیلی زیاد هستن و شاید کمی درهم به‌نظر برسن. معمولاً بیشتر اطلاعات مورد نیاز برای استفاده از ATmega328P درون یه داکیومنتی تحت عنوان دِیْتاشیت (Data Sheet یا Datasheet) وجود داره و معمولاً مراجعه به همون یه‌دونه داکیومنت، کافیه. اما وقتی وارد دنیای ARM بشید، با تعداد زیاد و حجیمی داکیومنت مواجه می‌شین. دیگه خبری از یه تک‌داکیومنت دیتاشیت نیست. گاهی برای پیدا کردن اطلاعات مورد نیاز خودتون، باید مثلاً ۳تا داکیومنت رو بررسی کنید.

معمولاً آدرس رجیسترهای پریفرال یه سیستم، به‌صورت آماده در دسترس ما هست و ما، به‌عنوان توسعه‌دهنده‌های Embedded Software یا Firmware، بدون اینکه بدونیم از اون آدرس‌ها استفاده می‌کنیم؛ اما اگر نقش توسعه‌دهنده‌ی فایل‌های هِدِر (header) یا libraryها رو به عهده گرفتیم یا با یه سیستم ناآشنا مواجه شدیم، دیگه ممکنه به اون آدرس‌های آماده و شسته‌رُفته دسترسی نداشته باشیم. مفاهیم مربوط به محاسبه‌ی آدرس‌ها، ممکنه برای افرادی که به‌تازگی وارد برنامه‌نویسی سطح پایین شده‌اند، مبهم باشه. در این مقاله، نحوه‌ی محاسبه‌ی آدرس رجیسترهای پریفرال و مفاهیم مرتبط با اون رو بررسی می‌کنیم.

در بخش ۱ این مقاله گفتیم که برای دسترسی به هر آدرسی از فضای حافظه، از جمله آدرس‌های مربوط به رجیسترهای پریفرال، می‌تونیم از متغیرهای اشاره‌گر استفاده کنیم. کافیه که آدرس رجیستر مورد نظر خودمون رو داخل متغیر اشاره‌گر بریزیم و بهش دسترسی پیدا کنیم. در اون مقاله، از همین روش استفاده کردیم و یه مقداری رو ریختیم روی رجیستر MODER از GPIOA داخل میکروکنترلر STM32F030K6T6. اما همون‌طوری که در پایان اون مقاله گفتیم، استفاده از «متغیر» برای یه همچین کاری معایب خودش رو داره؛ مثلاً ممکنه که فضای ارزشمند RAM رو هدر بده، ناخواسته به یه متغیر global تبدیل بشه و مشکلات دیگه‌ای برامون به‌وجود بیاره، یا شاید فرصت بهینه‌سازی رو از کامپایلر بگیره. خلاصه این که استفاده از «متغیر» اشاره‌گر برای دسترسی به رجیسترهای پریفرال، راه‌حل مطلوبی نیست. ای کاش که متغیر اشاره‌گر حذف می‌شد و یه‌جوری مستقیم به آدرس‌های حافظه دسترسی پیدا می‌کردیم… ای کاش…

یکی از کارهای خیلی متداول در برنامه‌نویسی سطح پایین، دسترسی به رجیسترهای مربوط به پریفرال‌های یه میکروکنترلره. برای انجام این کار در زبان C، چه انتخاب‌هایی وجود داره؟ در این مقاله، قصد داریم تا به یه رجیستر از یه پریفرال پرکاربرد در میکروکنترلر STM32F030K6T6 دسترسی پیدا کنیم.

در این مقاله می‌خوایم ببینیم که CMSIS چطوری رجیسترهای پریفرال (Peripheral) رو تعریف کرده. برای این منظور، یکی-دو تا از Core Peripheralها رو بررسی می‌کنیم که داخل خیلی از میکروکنترلرهای Cortex-M0 وجود دارن. توجه کنیم که هدف این مقاله، معرفی و بررسی خود این پریفرال‌ها نیست، بلکه ما اینجا فقط قصد داریم تا نحوه‌ی تعریف این پریفرال‌ها و رجیسترهاشون رو بررسی کنیم. این کار می‌تونه به ما، به عنوان مهندس‌های Firmware و Embedded Software و توسعه‌دهنده‌های سطح پایین (Low-level) در درک سورس‌کدهای مختلف و توسعه‌ی سورس‌کدهای جدید کمک کنه.