گزارش میکرو از وضعیت خودش task manager؟؟؟؟

[seyed saeed]

سلام
این سوال می تونه مربوط به هر میکرویی باشه
فرض کنید برنامه نوشته اید که می تونه در هر لحظه مقدار خاصی از RAM رو اشغال کنه و شما می خواهید گزارش داشته باشد که الان به طور مثال چه قدر
از فضای RAM اشغال شده و مثلا روی LCD یا توسط یوزرات یا هر چیزی اون رو نشون بدید
چی کار میشه کرد ؟؟؟ چه در میکروی arm چه در میکروی avr

[tiranoid]

پاسخ : گزارش میکرو از وضعیت خودش task manager؟؟؟؟

سلام
این سوال می تونه مربوط به هر میکرویی باشه
فرض کنید برنامه نوشته اید که می تونه در هر لحظه مقدار خاصی از RAM رو اشغال کنه و شما می خواهید گزارش داشته باشد که الان به طور مثال چه قدر
از فضای RAM اشغال شده و مثلا روی LCD یا توسط یوزرات یا هر چیزی اون رو نشون بدید
چی کار میشه کرد ؟؟؟ چه در میکروی arm چه در میکروی avr

قبلا بهش فکر نکرده بودم ولی ایده میشه داد. بهتره دوستان نظر بدن ببینیم کدوم شدنی تره . چون سیستم عامل نداریم، هیپ به اون مفهوم درستش نداریم پس سنجش رم کمی سخت میشه.

1) با خوندن استک پوینتر، میشه حدودی متوجه شد که چقدر رم اشغال شده یا چقدر توابع همزمان در حال اجرا داریم. در اصل، از پروسس های [تقریبا] همزمان میشه متوجه شد. مقادیر ثابت رم، بعد از کامپایل مشخص میشن و نمیشه قبلش بفهمه میکرو. شاید بشه خوندن آخرین خونه رم رو در نظر گرفت ولی این ایده مناسبی نیست. چون کامپایلر به ترتیب نمیچینه گتره ای میچینه و برای هر میکرو، آدرس باید تطبیق داده بشه با فضای آدرس دهی رمش. عملا همون استک پوینتر بهترین ایده میتونه باشه.

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

بدیهیه که این ایده ها، خطاپذیر هستن و جای کار دارن. مثلا داشتن delay باعث میشه اندازه گیریا اشتباه بشه. هرچند میشه یه تابع دیلی جدید [براساس تابع دیلی در دسترس] نوشت که در هر سیکل دیلی، مقدار تایمر رو صفر کنه که تایمر، دیلی ها رو نشماره و صرفا "غیر دیلی" ها رو بشماره. یا اگر بین خوندن مقدار تایمر و صفر کردنش یه وقفه زمانبر پیش بیاد، اون نمونه اشتباه میشه و ممکنه میانگین رو هم خراب کنه. مگر اینکه میانگین از تعداد زیاد باشه، یا میانه استفاده بشه.
نکته اینکه سیستم عامل ها از ایده هایی شبیه همینا برای فهمیدن وضعیت استفاده میکنن.

[seyed saeed]

پاسخ : گزارش میکرو از وضعیت خودش task manager؟؟؟؟

1) با خوندن استک پوینتر، میشه حدودی متوجه شد که چقدر رم اشغال شده یا چقدر توابع همزمان در حال اجرا داریم. در اصل، از پروسس های [تقریبا] همزمان میشه متوجه شد. مقادیر ثابت رم، بعد از کامپایل مشخص میشن و نمیشه قبلش بفهمه میکرو. شاید بشه خوندن آخرین خونه رم رو در نظر گرفت ولی این ایده مناسبی نیست. چون کامپایلر به ترتیب نمیچینه گتره ای میچینه و برای هر میکرو، آدرس باید تطبیق داده بشه با فضای آدرس دهی رمش. عملا همون استک پوینتر بهترین ایده میتونه باشه.
نکته اینکه سیستم عامل ها از ایده هایی شبیه همینا برای فهمیدن وضعیت استفاده میکنن.

تا جایی که بنده یادم هست یکی از وظایف استک پوینتر ذخیره سازی آخرین محلی که توش بوده هست
ولی حتما رمی که توسط میکرو استفاده میشه یه جایی آدرس داره دیگه مثلا یه جایی شما وسط کار اومدید malloc کردید و مثلا 10 بایت حافظه اختصاص دادید این مقدار مثلا شروع و شاید پایانش در جایی باید ذخیره شده باشه
که سی پی یو بتونه بهش دسترسی داشته باشه

[tiranoid]

پاسخ : گزارش میکرو از وضعیت خودش task manager؟؟؟؟

تا جایی که بنده یادم هست یکی از وظایف استک پوینتر ذخیره سازی آخرین محلی که توش بوده هست
ولی حتما رمی که توسط میکرو استفاده میشه یه جایی آدرس داره دیگه مثلا یه جایی شما وسط کار اومدید malloc کردید و مثلا 10 بایت حافظه اختصاص دادید این مقدار مثلا شروع و شاید پایانش در جایی باید ذخیره شده باشه
که سی پی یو بتونه بهش دسترسی داشته باشه

استک پوینتر، دقیقا میزان پر شدن استک رو نشون میده. استک رو نمیشه بصورت نامتقارن پر کرد. malloc به استک کاری نداره به heap مربوطه.
روش استک پوینتر که گفتم، گویای میزان "دقیق" رم نیست. استک پوینتر، یه حدود هم از رم و هم از پروسس میده.

در یک مدت زمان خاص، از 256 بایت استک یه میکروکنترلر، 160 تاش پره. در یه بازه ی زمانی دیگه کمتر از 40 تاش پره. این به ما نمیگه که مصرف رم تو بازه اول لزوما بیشتر بوده. یا قطعا پردازش بیشتری تو اون بازه داشته انجام میشده، ولی بهمون میگه پروسه های تودرتو (توابع و وقفه های در حال اجرا) در بازه اول قطعا بیشتر از بازه دوم بوده. با توجه به محتوای کدمون، پس حدودی میتونیم بفهمیم که این ملاک، ملاک خوبی بوده یا نه.

[seyed saeed]

پاسخ : گزارش میکرو از وضعیت خودش task manager؟؟؟؟

استک پوینتر، دقیقا میزان پر شدن استک رو نشون میده. استک رو نمیشه بصورت نامتقارن پر کرد. malloc به استک کاری نداره به heap مربوطه.
روش استک پوینتر که گفتم، گویای میزان "دقیق" رم نیست. استک پوینتر، یه حدود هم از رم و هم از پروسس میده.

در یک مدت زمان خاص، از 256 بایت استک یه میکروکنترلر، 160 تاش پره. در یه بازه ی زمانی دیگه کمتر از 40 تاش پره. این به ما نمیگه که مصرف رم تو بازه اول لزوما بیشتر بوده. یا قطعا پردازش بیشتری تو اون بازه داشته انجام میشده، ولی بهمون میگه پروسه های تودرتو (توابع و وقفه های در حال اجرا) در بازه اول قطعا بیشتر از بازه دوم بوده. با توجه به محتوای کدمون، پس حدودی میتونیم بفهمیم که این ملاک، ملاک خوبی بوده یا نه.

بذارید با مثال بریم جلو
فرض کنید در حین نوشتن برنامه 100 بایت از sramرا برای کاری اختصاص داده ایم مثلا ذخیره اعدادی
خب این 100 بایت کجای رم را اشغال کرده اند و چه کسی می دونه کجاست که به cpuبگه برو اون جا اعداد اون تو هستند یا اون جا ذخیره کن این آدرس فکر می کنم باید تو فلش باشه یعنی حین
اجرا cpu کدی رو می گیره که متوجه میشه حالا باید بره سراغ فلان آدرس رم
حالا در همین برنامه فرضی 100 بایت هم در حال اجرای برنامه یعنی مثلا وقتی فلان شرط برقرار شد از فضای رم برای کار دیگری اختصاص پیدا می کنه که این مسلما آدرسی در فلش وجود نداره و میکرو وظیفه داره آدرسش رو برای بازبینی های دفعات بعدی در جایی نگه داری کنه این کجاست ؟؟؟