پر شدن حافظه فلش

[hamed.rahimi]

با سلام

برنامه ای که من نوشتم 95 درصد از حافظه فلش رو پر کرده (میکرو مگا8 میباشد). در برنامه هر سه تایمر فعال هستند و کلی هم کارهای مختلف انجام میده.(حدود 700 بایت هم از SRAM برای متغیرها استفاده شده)
اگر بخوام در هنگام کامپایل optimize اش کنم حجم رو تا 85 درصد پایین میاره. اما نمیخوام از این روش استفاده کنم.

حالا سوال من اینه که آیا پر بودن فلش به اون میزانی که اشاره کردم تاثیری بر عملکرد میکرو داره یا نه؟
مثلا ممکنه که بر روی پردازش میکرو تاثیر بزاره و باعث بشه در حین کار پس از مدتی میکرو مشکل پیدا کنه و یا اینکه قاط بزنه؟!

فقط خواهشا اگر اطلاع دارید جواب بدید و از گفتن اینکه میکرو رو عوض کن و یا برنامه رو تغییر بده اجتناب کنید :biggrin:

با سپاس

[sey22]

پاسخ : پر شدن حافظه فلش

من دقیقا mega8 داشتم با چنین مشکلی نزدیک به 5 بار برنامه ام رو عوض کردم تا حجم رو کاهش بدم ، تو کامپایل هم بردمش تو مد سایز نه سرعت ............خلاصه تو طرز کار مدارم تاثیری نداشت تازه من 99.9 فلشم پر شده بود شما هنوز 5 درصد داری حیف استفاده کن پول دادی :mrgreen: راسنی با 100 درصد هم کار می کنه........

[mostafahk]

پاسخ : پر شدن حافظه فلش

اگر بخوام در هنگام کامپایل optimize اش کنم حجم رو تا 85 درصد پایین میاره. اما نمیخوام از این روش استفاده کنم.

چرا؟ optimize که خیلی خوبه. من هیچ برنامه ای رو بدون optimize ننوشتم تا حالا.

(حدود 700 بایت هم از SRAM برای متغیرها استفاده شده)

حالا سوال من اینه که آیا پر بودن فلش به اون میزانی که اشاره کردم تاثیری بر عملکرد میکرو داره یا نه؟
مثلا ممکنه که بر روی پردازش میکرو تاثیر بزاره و باعث بشه در حین کار پس از مدتی میکرو مشکل پیدا کنه و یا اینکه قاط بزنه؟!

میکرو که براش مهم نیست برنامه چند کیلو بایته.

فقط مشکل تو SRAM هستش و Stack که اگه فراخوانی توابع پشت سر هم زیاد باشه میتونه مشکل ساز بشه.
اینطور که شما تابع a رو صدا بزنید و تابع a هم تابع b رو صدا بزنه و تابع b هم c رو صدا بزنه و ... چون حدود 300 بایت از sram خالیه پس شما میتونید 150 بار این کار رو انجام بدید.
اکثر مشکلات میکروها که هنگ میکنه اینه که اینتراپت ها رو درست مدیریت نمیکنند.

[reza_agha]

پاسخ : پر شدن حافظه فلش

مشکل هنگ کردن فقط میزان استک نیست. چیزای دیگه هم میتونه باشه. مثلا خیلی ها خازن سر ریست رو نمیذارن و میگن همینجوری هم کار میکنه. درست هم میگن ولی در شرایط آزمایشگاهی. در صورتی که شرایط کاری خیلی با شرایط آزمایشگاهی فرق میکنه.
غیر از این هم خیلی جاهای برنامه فرض رو بر چیزی قرار میدیم که ممکنه در شرایطی غلط در بیاد. مثلا فرض کنین از تابع strcpy استفاده میکنیم ولی اصلا چک نمیکنیم که آیا بافر مقصد به اندازه کافی گنجایش داره یا نه. یا با فرض اینکه که روال اخذ کاراکتر از سریال روی سرعت 9600 مطمئنا خیلی کمتر از 1.2 میلی ثانیه تموم میشه میاییم وقفه ها رو مجددا استارت میکنیم. بدون اینکه حواسمون باشه که مثلا جای دیگه ای بیش از اینا وقت تلف کردیم.
از همه اینا گذشته تنها ایرادی که میشه به 80 تا 99 درصد استفاده از فلش گرفت تغییر برنامه برای تصحیح یا توسعه های آتی برنامه هست. وگرنه موردی برای میکرو پیش نمیاد. البته بهینه سازی کد هم بعضی جاها ممکنه دردسر ساز بشه. مثلا برای حجم بهینه میکنیم اما روالی که داره برای حجم بهینه میشه باید سرعت خیلی بالایی داشته باشه بنابراین باید برای سرعت بهینه بشه. اما اینکه بهینه سازی رو کلا کنار بذاریم فقط بدرد عیب یابی میخوره و بس. گرچه خیلی وقتها هم میشه با بهینه سازی عیب یابی کرد.

از تمام این گذشته یک پیغام آقای Solsal دارن که خیلی قبولش دارم:
کار خوب ، زمان متناسبی برای اجرا شدن نیاز دارد. کار سرسری و عجله ای ، ارزشمند نخواهد بود.

[hamed.rahimi]

پاسخ : پر شدن حافظه فلش

بسیار سپاسگذارم
:applause:

چرا؟ optimize که خیلی خوبه. من هیچ برنامه ای رو بدون optimize ننوشتم تا حالا.
میکرو که براش مهم نیست برنامه چند کیلو بایته.

فقط مشکل تو SRAM هستش و Stack که اگه فراخوانی توابع پشت سر هم زیاد باشه میتونه مشکل ساز بشه.
اینطور که شما تابع a رو صدا بزنید و تابع a هم تابع b رو صدا بزنه و تابع b هم c رو صدا بزنه و ... چون حدود 300 بایت از sram خالیه پس شما میتونید 150 بار این کار رو انجام بدید.
اکثر مشکلات میکروها که هنگ میکنه اینه که اینتراپت ها رو درست مدیریت نمیکنند.

برای SRAM خیلی زور زدم تا بیاد پایین. منتها دیگه تقریبا غیر ممکنه که زیر 700 تا بیاد. اوایل 1400 تا بود!!! برای همونم M32 گذاشته بودم. منتها چند تا ترفند روش پیاده کردم و بعد از 8 روز تونستم کلشو تو M8 جا بدم.
الان یه چند ساعتیه داره درست کار میکنه و هنوز مشکلی پیش نیومده.
راجع به اون توابع درهم هم نهایتش 4 تا اونم در بعضی جاها شده که خیلی خوب جواب داده.

منتها تا ازش کاملا مطمئن نشم نمیتونم بگم تموم شده! :nerd:

مشکل هنگ کردن فقط میزان استک نیست. چیزای دیگه هم میتونه باشه. مثلا خیلی ها خازن سر ریست رو نمیذارن و میگن همینجوری هم کار میکنه. درست هم میگن ولی در شرایط آزمایشگاهی. در صورتی که شرایط کاری خیلی با شرایط آزمایشگاهی فرق میکنه.
غیر از این هم خیلی جاهای برنامه فرض رو بر چیزی قرار میدیم که ممکنه در شرایطی غلط در بیاد. مثلا فرض کنین از تابع strcpy استفاده میکنیم ولی اصلا چک نمیکنیم که آیا بافر مقصد به اندازه کافی گنجایش داره یا نه. یا با فرض اینکه که روال اخذ کاراکتر از سریال روی سرعت 9600 مطمئنا خیلی کمتر از 1.2 میلی ثانیه تموم میشه میاییم وقفه ها رو مجددا استارت میکنیم. بدون اینکه حواسمون باشه که مثلا جای دیگه ای بیش از اینا وقت تلف کردیم.
از همه اینا گذشته تنها ایرادی که میشه به 80 تا 99 درصد استفاده از فلش گرفت تغییر برنامه برای تصحیح یا توسعه های آتی برنامه هست. وگرنه موردی برای میکرو پیش نمیاد. البته بهینه سازی کد هم بعضی جاها ممکنه دردسر ساز بشه. مثلا برای حجم بهینه میکنیم اما روالی که داره برای حجم بهینه میشه باید سرعت خیلی بالایی داشته باشه بنابراین باید برای سرعت بهینه بشه. اما اینکه بهینه سازی رو کلا کنار بذاریم فقط بدرد عیب یابی میخوره و بس. گرچه خیلی وقتها هم میشه با بهینه سازی عیب یابی کرد.

از تمام این گذشته یک پیغام آقای Solsal دارن که خیلی قبولش دارم:
کار خوب ، زمان متناسبی برای اجرا شدن نیاز دارد. کار سرسری و عجله ای ، ارزشمند نخواهد بود.

من خودم ریست رو پول پ میکنم اما بعد از 8051 تا حالا نشنیده بودم که خازن هم لازم باشه! oo:
برای کار از تمام پایه های میکرو استفاده شده و فقط ریست خالی مونده که اگر قرار باشه چیزی اضافه بشه اونم تبدیل میشه به I/O !

با سپاس

[reza_agha]

پاسخ : پر شدن حافظه فلش

برای استفاده از خازن سر پین ریست به مدرک Atmel AVR042 صفحه 4 پاراگراف چهارم رجوع کنید.

[Solsal]

پاسخ : پر شدن حافظه فلش

با سلام

حجم فلش را تا بایت آخرش می توانید برای برنامه استفاده کنید.
(جمله بالا را اصلاح می کنم: تا آخرین بایت ماقبل بوت لودر - با تشکر از جناب طراح )

در مطالب ذکر شده توسط دوستان ، نکات کاملا درستی ذکر شد.

اصلی ترین نکته همین است: برای تغییر و توسعه ، با همان آی سی ، دچار مشقت می شوید.

با توجه به مطالب ذکر شده درباره مقدار خالی رم ، کمبودی برای استک نخواهید داشت.

15% هم برای توسعه وتغییر ، جا در فلش دارید.

مشکلی نیست.

با سپاس

پ.ن:
بارها در 89C51rd2 تا 65525 و 65526 و .... و 65530 بایت کد ، رسیدم ولی همان نکته فوق....

در صورت وجود چشم انداز برای تکرار و توسعه پروژه/محصول ، یک نگارش هم با M16 یا M32 بسازید.( گرچه ، احتمالا قیمت تمام شده مینیمم ، مورد نظر است.)

پ.ن2:
از DOC2486 صفحه 211

Boot Loader Lock
Bits
If no Boot Loader capability is needed, the entire Flash is available for application code. The
Boot Loader has two separate sets of Boot Lock Bits which can be set independently. This gives
the user a unique flexibility to select different levels of protection.

[طراح]

پاسخ : پر شدن حافظه فلش

از آنجایی که بخش انتهایی flash به ناحیه Bootloader اختصاص دارد، به غیر بحث نوع کد نویسی و برای استفاده از حداکثر ظرفیت Flash باید از طریق فیوزبیت های BOOTSZ حجم ناحیه Bootloader تا حد امکان کاهش داده شود. مثلا در mega8 میزان 8192 بایت flash وجود دارد که 2048 بایت آن بصورت پیش فرض در اختیار ناحیه Bootloader است. بنابراین عملا یک چهارم flash بصورت پیش فرض در اختیار برنامه نیست و این بدین دلیل است که فیوزبیت های BOOTSZ10 در وضعیت 00 هستند. اما با برنامه ریزی این دو فیوزبیت در وضعیت 11، مقدار اختصاص داده شده به Bootloader به 256 بایت کاهش می یابد و عملا 1792 بایت برای بخش برنامه آزاد می شود.

مثلا خیلی ها خازن سر ریست رو نمیذارن و میگن همینجوری هم کار میکنه.

من خودم ریست رو پول پ میکنم اما بعد از 8051 تا حالا نشنیده بودم که خازن هم لازم باشه!

در کاربرد های پرنویز مناسب تر است که بعد از برنامه ریزی میکروکنترلر، پایه Reset از طریق یک Jumper بصورت مستقیم به Vcc متصل شود.

[hamed.rahimi]

پاسخ : پر شدن حافظه فلش

از آنجایی که بخش انتهایی flash به ناحیه Bootloader اختصاص دارد، به غیر بحث نوع کد نویسی و برای استفاده از حداکثر ظرفیت Flash باید از طریق فیوزبیت های BOOTSZ حجم ناحیه Bootloader تا حد امکان کاهش داده شود. مثلا در mega8 میزان 8192 بایت flash وجود دارد که 2048 بایت آن بصورت پیش فرض در اختیار ناحیه Bootloader است. بنابراین عملا یک چهارم flash بصورت پیش فرض در اختیار برنامه نیست و این بدین دلیل است که فیوزبیت های BOOTSZ10 در وضعیت 00 هستند. اما با برنامه ریزی این دو فیوزبیت در وضعیت 11، مقدار اختصاص داده شده به Bootloader به 256 بایت کاهش می یابد و عملا 1792 بایت برای بخش برنامه آزاد می شود.

در کاربرد های پرنویز مناسب تر است که بعد از برنامه ریزی میکروکنترلر، پایه Reset از طریق یک Jumper بصورت مستقیم به Vcc متصل شود.

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

برای استفاده از خازن سر پین ریست به مدرک Atmel AVR042 صفحه 4 پاراگراف چهارم رجوع کنید.

بله حرف شما کاملا صحیح است:


چه تاپیک جالبی شد!!! :applause:

با سپاس مجدد از همگی عزیزان.

[mostafahk]

پاسخ : پر شدن حافظه فلش

از آنجایی که بخش انتهایی flash به ناحیه Bootloader اختصاص دارد، به غیر بحث نوع کد نویسی و برای استفاده از حداکثر ظرفیت Flash باید از طریق فیوزبیت های BOOTSZ حجم ناحیه Bootloader تا حد امکان کاهش داده شود.

جسارتا قبول ندارم. bootloader حافظه رو block نمیکنه شما اگه bootloader ندارید آزادید از تمام فلش استفاده کنید و دوما شما کافیه bootloader رو از طریق فیوزبیت غیر فعال کنید BOOTRST .

همین الان هم فکر نکنم ایشون تو پروژشون که 85% فلش پر شده به فیوز بیتهای bootloader دست زده باشن ولی کار میکنه.
فیوزبیتهای bootloader فقط فقط فقط محل jump on reset رو تعیین میکنن.

[hamed.rahimi]

پاسخ : پر شدن حافظه فلش

جسارتا قبول ندارم. bootloader حافظه رو block نمیکنه شما اگه bootloader ندارید آزادید از تمام فلش استفاده کنید و دوما شما کافیه bootloader رو از طریق فیوزبیت غیر فعال کنید BOOTRST .

همین الان هم فکر نکنم ایشون تو پروژشون که 85% فلش پر شده به فیوز بیتهای bootloader دست زده باشن ولی کار میکنه.
فیوزبیتهای bootloader فقط فقط فقط محل jump on reset رو تعیین میکنن.

برای من هم عجیب بود اما:


این کاملا درسته که تا زمانی که از بوت لودر استفاده نکنیم فضایی بهش اختصاص داده نمیشه و انتهای فلش در دسترسه. اما برای من این ارور رو میداد. BOOTRST رو هم چک کردم. برنامه ریزی نشده بود. به هر حال من بوت سایز رو روی 128 گذاشتم و کلی هم با برنامه ور رفتم و بالاخره درست شد و الان مشکلی نداره و طبق گفته دوستان مهم نیست که 95 درصد پر شده.
ضمنا اینم بگم که من اون خطا رو در 100 درصد میگرفتم که این خودش توجیه خطا هستش که ممکنه از 100 ارور گرفته باشه

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

[طراح]

پاسخ : پر شدن حافظه فلش

جسارتا قبول ندارم. bootloader حافظه رو block نمیکنه شما اگه bootloader ندارید آزادید از تمام فلش استفاده کنید

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

فقط فقط فقط

که در عدم تفاوت این دو ناحیه عنوان کردید و به خاطر جنبه آموزشی این بحث ( که می تواند برای دیگران هم مفید باشد)، خود شما بفرمائید که آیا شرایطی وجود دارد که بزرگ شدن برنامه و وارد شدن آن به ناحیه Bootloader منجر به اختلال در عملکرد آن شود و چه نکته ای باید مد نظر قرار داده شود تا این مشکل بوجود نیاید؟

[mostafahk]

پاسخ : پر شدن حافظه فلش

خوب همونطور که ظاهرا با هم توافق داریم اگه با bootloader کاری ندارید اون هم با شما کاری نداره.
تمام میکروهایی که bootloader دارند چند فیوز بیت دارند :



BOOTRST که کلا فعال بودن Select Reset Vector رو تعیین میکنه و BOOTSIZE ها که اندازه فظای Bootloader رو تعیین میکنه.
سیستم های Bootloader دار اینطورن که شما یک برنامه bootloader مینویسی که کارش فقط پروگرام کردن خود میکرو. یعنی از پورت سریال یا USB یا هر پورت دیگه میکرو با پروتکل ابتکاری شما برنامه رو میگیره و از بایت صفر فلش تا بایت end application section تو جدول برنامه رو میریزه و بعدش jump میکنه به آدرس 0 و برنامه اجرا میشه.
یک سیستم bootloader دار همیشه باید بعد از reset از برنامه bootloader که معمولا ته فلش وجود داره کار خودش رو شروع کنه این موضوع نیاز به این داره که شما تنظیماتی رو انجام بدید.
هر بار که میکرو روشن میشه برنامه bootloader چک میکنه که آیا الان دستگاه به کامپیوتر وصله و کامپیوتر قصد تغییر برنامه اجرایی رو داره یا نه اگه ارتباط خارجی پیدا نکرد jump میکنه به 0 و برنامه قبلی همچنان ادامه پیدا میکنه و اگه ارتباطی پیدا کرد شروع به پروگرام کردم فلش میکنه.

[طراح]

پاسخ : پر شدن حافظه فلش

خوب همونطور که ظاهرا با هم توافق داریم اگه با bootloader کاری ندارید اون هم با شما کاری نداره.

اتفاقا منظور از پست قبل این مطلب بود که در شرایطی Bootloader با ما کار دارد و نوشتن در آن بدون توجه به یک مورد مشخص ممکن است موجب جواب نگرفتن از عملکرد برنامه شود. به عنوان یک راهنمایی، فرض کنید که در یک محصول تولید شده بوسیله AVR، برنامه ای نوشته شده که حجم آن کمتر از میزانی است که به ناحیه Bootloader وارد شود و میکروکنترلر این محصول بعد از برنامه ریزی، بدون مشکل وظایف خود را انجام می دهد. حال فرض کنید که به مرور زمان نرم افزار این محصول توسعه پیدا می کند و حجم آن زیادتر می شود، به نحوی که کد نوشته شده وارد بخش Bootloader می شود. سوال این است که اگر بعد از برنامه ریزی میکروکنترلر همان محصول و با فرض صحت عملکرد کد، میکروکنترلر وظایف خود را به درستی نتواند انجام دهد، چه نکته ای در این میان می تواند وجود داشته باشد که ناشی از نوشته شدن کد در این ناحیه باشد و راه بر طرف کردن آن چیست؟ به عبارت دیگر نفس نوشتن در ناحیه Bootloader در شرایطی می تواند منجر به جواب نگرفتن از برنامه باشد که منظور از این سوال بیان آن شرایط است (در مراجعه بعدی به انجمن در مورد پاسخ این سوال توضیح خواهم داد).

[mojalan]

پاسخ : پر شدن حافظه فلش

یک سیستم bootloader دار همیشه باید بعد از reset از برنامه bootloader که معمولا ته فلش وجود داره کار خودش رو شروع کنه این موضوع نیاز به این داره که شما تنظیماتی رو انجام بدید.
هر بار که میکرو روشن میشه برنامه bootloader چک میکنه که آیا الان دستگاه به کامپیوتر وصله و کامپیوتر قصد تغییر برنامه اجرایی رو داره یا نه اگه ارتباط خارجی پیدا نکرد jump میکنه به 0 و برنامه قبلی همچنان ادامه پیدا میکنه و اگه ارتباطی پیدا کرد شروع به پروگرام کردم فلش میکنه.

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