مهندسی طور



خب داریم به آخرین مراحل آماده سازی یه کد برای پیاده سازی روی سخت افزار میرسیم.تا اینجا یه سری فایل های باینری از جاهای مختلف رسیده دستمون که میخوایم همه رو تبدیل به یه فایل کرده تقدیم سخت افزار کنیم! این کار وظیفه اصلی Linker هستش.برای انجام این مرحله یه Linker file هم در کنار بقیه فایل ها در اختیار لینکر قرار میگیره تا با کمک این فایل بتونه این مسئولیت رو انجام بده.ما میتونیم از طریق ترمینال این فایل رو با فلگ T- بهش بدیم.

سوالی که ممکنه پیش بیاد اینه که داخل این فایل چیا قرار میگیره؟

به صورت مختصر موارد زیر رو میتونیم داخل این فایل ببینیم :

  1. مپ کردن بخش های کد به نواحی مختلف حافظه
  2. آدرس شروع و اندازه نواحی حافظه
  3. پارامترهای دسترسی برای نواحی مختلف حافظه
  4. بررسی اینکه مساله over allocation رخ نداده باشه و در صورت رخداد اطلاع دادن
  5. مشخص کردن نقطه شروع برنامه

نکته جالب اینه که تو فرایند لینک کردن به تشخیص خود لینکر یه سری کتابخونه ها به پروژه اضافه میشه که برای بعضی قسمتا ضروریه.مثلا اینکه برنامه از تابع main شروع به اجرا کنه و در پایان این تابع هم متوقف بشه چیزی هست که تو یکی از همین کتابخونه ها معرفی شده به نحوی که اگه شما این کتابخونه رو به لینکر بگید اضافه نکنه(دیفالت اضافه میکنه خودش) تو اجرای برنامه با ارور مواجه میشین چون برنامه نمیدونه دقیقا از کجا باید شروع کنه به اجرا :)

بعضی از فلگ های مورد استفاده برای لینکر رو میتونید تو تصویر زیر ببینید :

 

راجع به دو فلگ آخر این جدول نحوه استفاده ازشون به صورت زیر هستش:

در نهایت وارد فرایند locating میشیم که منابع سخت افزاری رو(عمدتا فضای حافظه)در اختیار برنامه میذاره تا ازش استفاده کنه.خب طبیعتا این مرحله وابستگی زیادی به معماری سخت افزار پیدا میکنه.در وهله اول این اختصاص منابع به صورت نمادهایی (symbols) برای قسمت های مختلف حافظه صورت میگیره و در مرحله نهایی این نمادها به آدرس مستقیم حافظه مورد نظر تبدیل میشه و خب تو این مرحله تقریبا فرایند ما به اتمام میرسه!

فایل اجرایی که در نهایت تولید میشه میتونه به فرمت های مختلفی باشه :

  • executable and linker format (ELF)
  • common object file format (COFF)
  • Intel Hex Record
  • Motorola S Record (SREC)
  • ARM Image file (AIF)
  • خب فکر کنم تا همین جا کافی باشه.ایشالا در ادامه میریم سراغ معماری حافظه و نکات مرتبط باهاش!

خب در ادامه مطالب قبلی میخوایم تو این قسمت ببینیم چطور میشه یه هدر فایل برای پروژه مون ایجاد کنیم و اینکه اصولا تو نوشتن یه هدر فایل رعایت چه نکاتی اهمیت پیدا میکنه.خب اولین موضوعی که لازمه بهش بپردازیم اینه که هدفمون از این کار چیه؟

تو برنامه نویسی اصولی معمولا رسم بر این هستش که تا جایی که ممکنه کدهایی رو که مینویسیم به نحوی باشه که بتونیم تو پروژه های دیگه و یا برای پلتفرم های دیگه هم استفاده شون کنیم یا به عبارت بهتر Portable باشن به همین خاطر هم مهندسای نرم افزار به سمت برنامه نویسی ماژولار حرکت کردند.یکی از ارکان اصلی برنامه نویسی ماژولار هم هدرفایل ها هستند که در شامل اطلاعاتی هستند که در فایل اصلی پروژه آورده نمیشن و تنها به include کردن همین هدر فایل بسنده میکنن.

ساختار یک هدر فایل رو به صورت زیر معمولا مینویسن :

#ifndef __TEST_H__

#define __TEST_H__

.

#endif /*__TEST_H__*/

اولین خط این کد مربوط به موضوعی هست به اسم "include guard" که باعث میشه اگه به اشتباه این هدر فایل رو در بیش از یک جا تعریف کنیم خطای کامپایل ازمون نگیره و تنها یک مورد رو به عنوان بدنه هدر فایل انتخاب کنه و بقیه رو نادیده بگیره.البته برای این موضوع روش دیگه ای هم هست به این صورت که کافیه در ابتدای این هدر فایل عبارت pragma once# رو قرار بدیم.البته این روش مشکلی که داره عدم پشتیبانی برخی از کامپایلرها از Pragma هستش که خب باعث میشه کدمون قابلیت حمل پذیری(Portable) رو از دست بده.

برای نام گذاری هم تو ساختاری که معرفی شد معمولا به این صورت عمل میکنن که اسم فایل رو با حروف بزرگ قرار میدن.مثلا تو همین مثال احتمالا اسم هدرفایل که این کد رو داخلش داره test.h بوده!

برای تعریف متغیرها از هدرفایل استفاده نمیکنیم چون به ازای هربار Include شدنش این متغیرها هم تعریف میشن که ممکنه باعث از دست رفتن بخشی از حافظه بشه که خب تو سیستم های امبدد برامون اهمیت زیادی داره!

لازمه تو هدر فایل برای افزایش خوانایی کامنت هایی رو برای توابع قرار بدیم که توضیحاتی راجع به عملکرد اون تابع،ورودی هاش و خروجی های تولیدیش رو داشته باشه.تو تصویر زیر میتونید نمونه از این نوع کامنت رو ببینید :

به عنوان آخرین نکته هم اینکه ما چون تو سیستم های امبدد به علت محدودیت های حافظه ای موجود نیاز داریم تا بهینه ترین و کم حجم ترین کدها رو بنویسیم لازمه با انواع کتابخونه های از پیش کامپایل شده که میتونن به پروژه مون اضافه بشن هم اطلاعاتی کسب کنیم.اولین نوع از کتابخونه ها اونایی هستن که بهشون میگن static و به صورت مستقیم به فایل اجرایی ما لینک میشن و برروی پلتفرم قرار میگیرن.نوع دوم که بیشتر برای پردازنده هایی با قابلیت اجرای سیستم عامل استفاده میشن Shared library ها هستند که به صورت دینامیک و در run time برنامه اضافه میشن.این کتابخونه ها به صورت پیشفرض روی سخت افزار برخی از پلتفرم ها پیاده سازی شدند.خب طبیعیه نوع دوم کتابخونه ها باعث میشه حجم فایل اجرایی کاهش چشمگیری پیدا کنه که خب یه مزیت محسوب میشه اگرچه نیاز به یه سیستم عامل داریم که خب خودش دردسرهای خاص خودشو داره :/

 

 

 


خب بعد اینکه با فرایند کامپایل به صورت کلی آشنا شدیم قبل اینکه بریم سراغ توضیح جزییات مراحل کامپایل لازمه قبلش یه خورده راجع به ابزار ها هم باهم صحبت کنیم.

به طور کلی دو دسته کامپایلر وجود داره تو طراحی امبدد.اولین نوع کامپایلر که بچه های کامپیوتری خیلی ازش استفاده میکنن Native compiler ها هستند که برای کدهایی استفاده میشن که قراره روی همون ماشین (host machine) اجرا بشن.خب طبیعتا این کامپایلرها نمیتونن کدهایی رو برای پردازنده ARM یا AVR روی ماشینی با پردازنده X86 کامپایل کنن.برای کامپایل کدهای این معماری ها با Native compiler ها لازمه ابتدا این کامپایلر روی پردازنده موردنظر (فرضا ARM) نصب بشه و اونموقع کدها رو برای اون معماری خاص کامپایل کنیم.خب بنا به دلایل مختلف (مثلا کم بودن منابع در دسترس برای سیستم های امبدد) اصولا این کار انجام شدنی نیست و یا اگه هم انجام بشه تو پردازنده های با قابلیت های بالاتر به کار میره.پس این نوع کامپایلر ها به درد ما سخت افزاریا نمیخورن زیاد! کامپایلر معروف این خانواده GCC هستش که با نام gcc – 4.8 (که 4.8 ورژنش هستش) شناخته میشن.

نوع دوم کامپایلر ها که تقریبا تمامی محیط های توسعه از این نوع استفاده میکنن Cross compiler ها هستند که بهمون این امکان رو میدن که بتونیم کدهای مربوط به یک پردازنده با یک معماری خاص رو روی یک پردازنده دیگه با معماری متفاوت کامپایل کنیم.این دقیقا کاریه که محیط های توسعه مثه Keil یا Ateml studio انجام میدن.دو کامپایلر معروف این خانواده از کامپایلرها که برای پردازنده های ARM به کار میرن رو در اینجا معرفی میکنیم.ما در ادامه این سری از نوشتار ها هم تمرکز رو روی همین نوع کامپایلر ها میذارم و به خانواده قبلی کامپایلر ها زیاد کاری نداریم (اگرچه خیلی از چیزایی که گفته میشه مشترکه بین این دو خانواده از کامپایلرها)

نامگذاری این کامپایلر ها هم معمولا از فرمت زیر طبعیت میکنه :

<ARCH> - <VENDOR> - <OS> - <ABI>

کامپایلر اول به صورت زیر هستش :

Arm – none – eabi – gcc

Arch : ARM

Vendor : N/A

OS : None (Bare – metal)

ABI : EABI

راجع به موارد بالا فقط این نکته رو بگم که Bare-metal ینی کد نوشته شده قراره مستقیما روی سخت افزار پیاده شه و سیستم عاملی این وسط وجود نداره.در واقع همون کاری که ما خیلی از اوقات میخوایم انجام بدیم.

دومین کامپایلر هم :

Arm – linux – gnueabi – gcc

Arch : ARM

Vendor : N/A

OS : Linux OS

ABI : GNUEABI

برای کامپایل کردن یه برنامه با ابزار gcc کافیه از دستور زیر استفاده کنیم :

$ gcc [options] [file]

استفاده کردن از یه سری flag ها باعث میشه بتونیم تو روند کامپایل تغییراتی رو ایجاد کنیم. مثلا استفاده ازفلگ S-  باعث میشه صرفا فایل اسمبلی تولید شه و بقیه مراحل کامپایل انجام نشه. تو تصویر پایین میتونید یه سری از فلگ های کلی کامپایلر رو ببینید :

تو تصویر زیر هم برخی از Flag ها که برای معماری های خاص استفاده میشن رو میتونید ببینید :

خب فکر میکنم تا همین جا کافی باشه برا این قسمت.امیدوارم مفید بوده باشه!

ادامه دارد.

کامنت لطفا یادتون نره :)


 

راستش خیلی وقت بود دنبال یه آموزش مناسب بودم که با دیدنش بتونم بفهمم دقیقا چرا ما از زیون C داریم برای برنامه نویسی میکروکنترلر ها استفاده میکنیم و اگه زبون دیگه ای هم به کار میره خیلی از جاها به مشکلاتی میخوره که برای زبون C اصلا مشکل به حساب نمیاد!

خیلی هامون شنیدیم زبون C یه زبون intermediate هستش یا به عبارتی زبونیه که نه خیلی سطح بالاس (مثه پایتون) و نه خیلی سطح پایین (مثه اسمبلی) و همین دلیل هم باعث شده بین برنامه نویس های سخت افزار (به اصطلاح مهندسای امبدد) خیلی محبوب باشه و کلی ازش استفاده شه.ولی خب سوالی که پیش میاد اینه که این مطلب دقیقا چه کمکی به ما تو توسعه اپلیکیشن های امبدد میکنه؟ و اینکه چطور میشه از این قابلیت ها برای توسعه اپلیکیشن ها با کارایی بالاتر استفاده کنیم؟ (ایشالا تصمیم دارم بعد این موضوع برم سراغ روش هایی تو برنامه نویسی C که میتونه باعث بشه برنامه ای که روی ARM با 72 مگاهرتز فرکانس به سختی اجرا میشه روی AVR با فرکانس 8 مگاهرتز که خیلیا اصن بهش توجهی نمیکنن با سرعت قابل قبولی اجرا شه! ولی خب قبلش لازمه پیشنیاز این داستان که فهم دقیق قابلیت های زبون C هستش رو به دست بیاریم :) )

احتمالا میدونید برنامه ای که ما مینویسیم به صورت مستقیم قابلیت اجرا روی سخت افزار رو نداره و باید بعد طی کردن مراحلی به زبان ماشین تبدیل شه و اونموقع هستش که میتونیم این برنامه رو روی سخت افزار پیاده سازی کنیم.کاری که خیلی از محیط های توسعه میکروکنترلر ها انجام میدن در واقع همینه که میان این فرایند رو برامون انجام میدن تا ما به صورت مستقیم با این فرایند درگیر نشیم ولی مساله ای که هست اینه که خیلی از بهبودهایی که توی کد ما انجام میشه در واقع تو همین مراحل انجام میشه و اگه ما اطلاعات دقیقی از این پروسه داشته باشیم میتونیم بعضی قسمت های رو بهتر کنیم.هرچی باشه کاری رو که ما میتونیم انجام بدیم شاید کامپیوتر نتونه به اون خوبی انجام بده!

خب بریم سراغ توضیح این مراحل!

اولین قدم برا برنامه نویسی سخت افزار نوشتن کد C در قالب یه فایل با پسوند *.C هستش.حالا اگه بخواید فایل های دیگه یا کتابخونه هایی رو هم به پروژه تون اضافه کنید یه سری فایل با پسوند *.h هم خواهید داشت.تا اینجا کاریه که شما به عنوان برنامه نویس انجام میدین.باقی مراحل رو کامپایلر نصب شده روی سیستم شما انجام میده براتون!

کامپایلر با گرفتن این فایل ها در قدم اول فرایند Preprocessing رو انجام میده.تو این فرایند یه فایل با پسوند *.i تولید میشه که در واقع همون کدی هستش که شما نوشتید ولی یه سری تغییرات توش داده میشه.مثلا اینکه شما یه ثابت رو در ابتدای کد با نام TEST تعریف کردید و تو باقی کد هرجا خواستید ازش استفاده کنید به جای نوشتن مقدار اون ثابت صرفا کلمه TEST رو نوشتید.تو فرایند پیس پردازش (اینو همین الان اختراع کردم براش منظورم همون Preprocessing عه!) میاد تمام جاهایی که شما TEST رو نوشتید مقدار اصلیش رو قرار میده.البته این مرحله و مراحل بعدی رو ایشالا در ادامه به صورت کاملتر توضیح خواهم داد.

بعد تولید این فایل کامپایلر وارد عمل میشه و کدهای موجود رو تبدیل میکنه به زبون اسمبلی (هنوز کد برای قرارگیری روی سخت افزار آماده نشده!) و یه فایل با پسوند *.s تولید میکنه.طبیعتا برای ترجمه کدهای C به اسمبلی لازمه کامپایلر با ISA مربوط به سخت افزار مورد نظر ما کاملا آشنا باشه تا بتونه از instruction هایی استفاده کنه که ساختار اون پردازنده پشتیبانی میکنه!

خب تو این مرحله اسمبلر کارشو شروع میکنه و فایل اسمبلی ورودی رو تبدیل میکنه به یه object file با پسوند *.o که تقریبا میشه گفته مشابه چیزی هستش که روی سخت افزار پیاده میشه.داخل این فایل هم یه سری کد به فرمت هگز هستش که در واقع همون کد اسمبلی تولیدی ماست که به این روز دراومده!

تو قسمت بعدی این سریال(!) کار Linker شروع میشه.در واقع هدف از وجود لینکر اینه که ما بتونیم تمام فایل هایی رو که داریم و این فایل ها بعضا به هم ارتباط هم دارن(مثه include هایی که توی کد انجام میدیم و یه فایل دیگه رو فراخوانی میکنیم) تجمیع کنه و به صورت یه فایل شسته رفته بهمون تحویل بده.از اسمش هم تقریبا مشخصه که چی کارس!

آخرین قسمت این اپیزود هم متعلق هستش به ابزاری به اسم Locator که این فایل شسته رفته تحویل گرفته شده از Linker رو تبدیل به یه فایل اجرایی میکنه که قابل پیاده سازی روی سخت افزار باشه.به عبارت بهتر میاد و امکانات سخت افزار رو در اختیار کد قرار میده و فضاهای حافظه رو به بخش های مختلف کد اختصاص میده.خروجی این مرحله هم یه فایل اجرایی هستش که برای معماری های مختلف پسوندهاش متفاوت میتونه باشه (برای میکروهای AVR پسوند معروفش *.hex هستش)

خب تا اینجا با مراحل مختلف روند تولید کد سخت افزار از ابتدا تا انتها آشنا شدیم.توقسمت های بعدی ایشالا این مراحل رو به صورت کامل با تمام جزییات لازم بررسی میکنیم.

ادامه دارد.

کامنت یادتون نره!


امروز روز سوم ماه مبارک بود و منم برا اولین بار تو ایام روزه داری تصمیم گرفتم یه ریسک انجام بدم و برم دوچرخه سواری البته با دهان روزه :)

یه خورده مراعات کنی و به خودت زیادی فشار نیاری کار خاصی نمیشه.حداقل من تجربش کردم امروز!

دوچرخه سواری که میرم معمولا اینطوریه که بعد یه خورده مسیر طی کردن میشینم یه جای دنج و فکر میکنم.به چیزای مختلف.به زندگی و اینکه قراره چی بشه.امروز تصمیم گرفتم قبل از شروع هر برنامه جدیدی پروژه های که انجام دادم ولی به دلایل مختلف تموم نشده رو تموم کنم.به عنوان اولین قدم اجرایی این طرح هم تصمیم گرفتم برد پروگرامر میکروکنترلر AVR که تقریبا از اولای شروع اپیدمی کرونا طراحیش رو آغاز کرده بودم تموم کنم و الان به لطف خدا کاملا تموم شد و آماده ارسال برای چاپ هستش :) ایشالا در اولین فرصت فایل های مرتبط باهاش رو اینجا میذارم تا اگه کسی خواست برا خودش این برد رو بسازه بتونه دانلود کنه و بده چاپ کنن براش

چیز جالبی که امشب یادگرفتم هم نحوه ارسال یه برد برای شرکت های چاپ PCB هستش.اینکه چه فایلایی رو لازمه بفرستی و از این حرفا.ایشالا تصمیم دارم یه توضیح جامع بنویسم راجع بهش همین جا.فکر میکنم مشکل خیلی از اونایی که مثه خودم تازه کار هستن حل میشه!

در هر حال حس خوبیه که یه کار جدید رو یادبگیری انجام بدی =))


سلام!

امروز بعد مدت ها تصمیم گرفتم یه خورده حال و هوای وبلاگمو عوض کنم و تو اولین قدم از تغییر سرویس دهنده وبلاگ از بلاگفا به بیان شروع کردم.باید اعتراف کنم واقعا امکانات خیلی خوبی رو برای استفاده کاربرا فراهم کرده و خب اگه زودتر میدونستم قطعا خیلی وقت پیش از بلاگفا میومدم بیرون به خصوص که اون تبلیغ گوشه صفحه همیشه آزاردهنده بود برام :/

سعی میکنم تو این وبلاگ علاوه بر نوشتن روزنوشت هام که خب شاید یه روز با خوندن شون خاطرات شیرینی برام زنده شه یه بخش رو هم اختصاص بدم به نوشتن مطالب آموزشی که تو نت با بدبختی گیر میاد و منم بعد کلی گشتن تونستم یادبگیرمشون.امیدوارم اتفاقای خوبی رقم بخوره

راستی دارم تلاش میکنم مطالب وبلاگ قبلیم رو به این وبلاگ انتقال بدم.هنوز موفق نشدم و تو احراز هویت نرم افزار مهاجر گیر کردم ولی خب امیدوارم حل شه و بتونم این کار رو انجام بدم تا مطالب اون ولاگ که کلی از خاطراتم رو برام تداعی میکنه رو هم از دست ندم!

چند روز پیش کتاب "فرهنگ اتصال" از سوره مهر رو سفارش دادم.کتاب خوب و جالبی به نظر میومد.الانم منتظرم برسه دستم تو فرصت مناسب شروع کنم به خوندنش.ایشالا اینجا هم ازش بیشتر خواهم نوشت :)

 


از اونجا که پروژه های بزرگ برای تولید خروجی نهایی ممکنه زمان زیادی رو از تیم برنامه نویس بگیره و همچنین احتمال رخداد خطاهای انسانی تو این فرایند هم بالاست به همین خاطر ناچارهستیم از ابزار سودمندی که GNU برای استفاده منتشر کرده استفاده کنیم.این ابزار عنوان های مختلفی داره که مهمترین شون Build management software هستش که فک میکنم این اسم به خوبی هدف از به کارگیری این ابزار رو مشخص میکنه!

تو سایت رسمی GNU ابزار Make رو اینطور تعریف کرده :

Tool that controls the generation of executable and other non-source files of a program from the program's source files.

برای استفاده از این ابزار لازمه فایل(یا فایلهایی) تحت عنوان Make files در اختیار این ابزار قرار بگیره.این فایل ها در واقع به این خاطر استفاده میشن که به ابزار Make بفهمونن چطوری باید فرایند Build یه پروژه خاص رو انجام بده.

اهمیت مهم دیگه Make file ایجاد امکانی هستش که تو فرایند Version Control خیلی میتونه موثر باشه.بذارید بیشتر توضیح بدم.فرض کنید شما کدتون رو تو یه محیط اشتراک کد مثه Github قرار دادید و یه make file هم براش نوشتید و کنارش گذاشتین.حالا بعد یه مدت بعضی از قسمت های کدتون رو تغییر میدین به نحوی که تو فرایند کامپایل هم این تغییرات تاثیرگذار هستند مثلا یه سری فلگ ها رو باید تو دستوراتتون تغییر بدین.کاری که میشه انجام داد اینه که خیلی ساده فقط این فلگ ها رو توی Make file عوض کنید.به این ترتیب هرکس که اون Make file رو اجرا کنه بدون اینکه بدونه در گذشته چه بلاهایی سر کد در اومده میتونه خروجی مطلوب رو دریافت کنه.

خب حالا که با این ابزار تا حدی آشنا شدیم ببینیم اصولا چطوری کار میکنه و ما چطور میتونیم ازش استفاده کنیم؟

داخل Make file تعداد build rule وجود داره که به فرمت زیر هستند:

Target : prerequisite1 prerequisite2 prerequisite3 …

Command1

Command2

برای مثال یه build rule رو به صورت زیر تصور کنید :

My_file.o : my_file.c my_file.h

Gcc –c my_file.c –o my_file.o

خب حالا اگه دستور زیر رو توی ترمینال وارد کنیم :

$ make my_file.o

با اجرای این دستور ابزار Make میاد تو make file دنبال تارگتی به اسم my_file.o میگرده و اگه prerequisite هایی که براش مشخص شده هم برقرار باشه (تو این مثال فایلهای my_file.c  و my_file.h داخل دایرکتوری پروژه وجود داشته باشن) اونوقت میره ودستورات این build rule رو اجرا میکنه.

ساختاری که برای نوشتن Make file به کار میره :

  • استفاده از # برای نوشتن کامنت ها
  • میتونه یه سری Make file دیگه رو include کنه داخل خودش
  • میتونه متغیر داخلش تعریف بشه و از این متغیرها هم استفاده شه
  • میتونه Build rule های مختلفی رو داخلش داشته باشه
  • دستورات اجرایی هر Build rule با یه tab نسبت به خط اول نوشته میشن
  • برای ادامه خط ها در خط بعد از  "\" استفاده میشه

در تصویر زیر مثالی از یک Make file ساده رو میتونید ببینید :

خب احتمالا تا همین مرحله کافیه اگرچه نوشتن Make file کلی بحث های پیشرفته دیگه هم داره که اینجا بهش پرداخته نشد.

در انتها هم به معرفی یه سری از ابزار های GNU میپردازیم که میتونه تو روند برنامه نویسی و دیباگ کردن پروژه ها به خصوص به منظور انجام بهینه سازی ها کمک قابل توجهی کنه.البته اینم بگم که GNU ابزارهای خیلی زیادی برای توسعه نرم افزارها داره که ما اینجا صرفا به اونایی اشاره میکنیم که مهندسای سخت افزار به کارشون میاد!

اولین ابزار که بهمون کمک میکنه سایز بخش های مختلف تو کد کامپایل شده رو بفهمیم به صورت زیر قابل استفادست.طبیعتا استفاده از این ابزار با توجه به شناختی که نسبت به معماری حافظه داریم باعث میشه قسمت هایی از کد که Performance رو کاهش میده پیدا کنیم و براشون چاره ای بیندیشیم!

arm–none-eabi-size –Atd demo.out

ابزار بعدی objdump هستش که با دریافت آبجکت فایل میتونه کد اسمبلی هر قسمت رو به صورت جداگونه نمایش بده.آخرین ابزاری هم که معرفی خواهیم کرد readelf هست که اطلاعات مهمی رو میتونه از فایل های خروجی با پسوند *.elf استخراج کنه و نمایش بده.اطلاعاتی راجع به بخش های کامپایل شده،بخش های حافظه،جدول نمادها(symbol table)و در نهایت اطلاعات معماری سخت افزار.برای استفاده از این ابزارها هم دستوری مثل دستور زیر رو میتونیم به کار ببریم :

arm-none-eabi-readelf demo.out –all

در انتها هم لازمه عرض کنم تمامی این ابزارها رو میشه تحت عنوان پکیج GNU binutils پیداکرد.

امیدوارم این مطلب براتون مفید بوده باشه :)


سلام!

امشب فهمیدم اصولا وبلاگ نویس خوبی نیستم چون به کل فراموش کرده بودم اینجا رو :-)

بعضی وقتا یه سری چیزا برات اهمیت زیادی پیدا میکنن.بعضی آدما شاید.ولی درست که فکر میکنی دلیلش رو متوجه نمیشی.واقعا چرا آخه این آدم باید برام مهم باشه!

میگن بنی آدم و اعضا و اینا یک گوهرند ولی مساله چیز دیگس.چن وقت پیش داشتم با ن ن صحبت میکردم.بهش گفتم ازت دلخورم که خیلی دیر به دیر پیام میدی بهم (یا شایدم من پیام ندم تو کلا یادت میرم!) برداشت بهم گفت نمیفهمم چرا باید پیام بدم :)

اولش جا خوردم ولی بعد که درست فکر کردم دیدم درست میگه.چرا من باید بهش پیام بدم؟چرا اون باید به من پیام بده یا چرا باید اینکه حالمون خوبه یا نه رو به هم اطلاع بدیم؟

چه میشه کرد با چراهایی که تو زندگیت پیش میاد و جوابی نداری براش!

ولی خداروشکر

تا وقتی امیدی برای زندگی دارم و ایده ای برای فکر کردن بهش هیچ وقت به درگاه خدا گلایه نمیکنم.شاید ن ن آدم اشتباهی زندگیم بود که به زور سعی داشتم نگهش دارم ولی خب به قول حافظ "بسوختیم در این آرزوی خام و نشد ."

 

بیخیال میگذره

راستی کتاب "فرهنگ اتصال" هم به دستم رسید ولی اصلا برام جذاب نبود.فکر میکردم داستان طور باشه ولی دیدم یه تحلیل اجتماعیه :/


سلام!

 

همونطور که احتمالا میدونید رزبری پای وقتی برای اولین بار سیستم عامل رو روی SD کارتش میریزی و بوت میکنیش بهت اجازه ارتباط از طریق SSH رو نمیده و برای اینکه این دسترسی رو فعال کنی باید مانیتور و ماوس به بردت وصل کنی و اونموقع از تو تنظیمات سیستم این قابلیت رو فعال کنی.خب حالا اومدیم یه بابایی مانیتور و ماوس نداشت در لحظه.تکلیف چیه؟!

 

راهکار سادس.باید SD کارت مذکور رو تو سیستم لبتابت مثلا باز کنی و یه فایل خالی با نام SSH در قسمت boot بسازی.توجه کن اسم این فایل هیچ پسوند و پیشوندی نباید داشته باشه.حالا به سادگی میتونی ارتباط SSH رو با رزبری برقرار کنی و کلی کیف کنی باهاش :)


آخرین ارسال ها

آخرین جستجو ها