AVR, Cute, توصیه شده, مقاله

میکروکنترلر مقصر نیست مقصر برنامه نویسی است

حتما برای شما هم پیش آمده که در پروژه ای به دلایل زیادی از قبیل کم بود حافظه فلش ، کمبود حافظه رم ، سرعت پایین و… مجبور شده اید میکروکنترلر را عوض کنید و زحمت برنامه نویسی مجدد را به جان بخرید در این موارد معمولا تمام کاسه کوزه ها سر میکروکنترلر شکسته می شود و محدودیت های آن مورد سرزنش و شماتت قرار می گیرد! در صورتی که همیشه اینچنین نیست. در اغلب اوقات با تغییرات جزیی در مدار یا سبک برنامه نویسی به راحتی میتوان مشکلات پیش رو حل کرد ؛ متاسفانه خیلی از دوستان و همکاران گرامی به این موضوع اشراف ندارند و به اشتباه میکروکنترلر را مقصر می دانند؛ به عنوان مثال خیلی از دوستان ، میکروکنترلر AVR را یک میکروکنترلر صنعتی نمی دانند ، در عوض میکروکنترلر PIC یا ARM را صنعتی می دانند، برای شخصی که تجربه کافی در خصوص طراحی مدارات دیجیتال و صنعتی داشته باشد ، این استدلال نه تنها بی پایه و اساس است بلکه خنده دار هم خواهد بود؛ محدودیت ها و باید و نباید های هر پردازنده ای در منوال آن ذکر شده است ، با رعایت این نکات و البته طراحی صحیح هر میکروکنترلری را می توان در هر جایی که مورد نیاز باشد استفاد کرد، البته منکر این مهم نیستم که برخی میکروکنترلر ها برای مقاصد خاصی طراحی و تولید می شوند. چه مدارات صنعتی که بر پایه همین میکروکنترلر AVR طراحی شده اند ؛ مهم نکاتی است که باید در طراحی لحاظ کرد. در این مقاله قصد داریم نشان دهیم که چقدر مدل برنامه نویسی می تواند در عملکرد یک میکروکنترلر دخیل باشد و در خیلی از هزینه ها صرفه جویی کنید پس با سیسوگ همراه باشد.

معرفی میکروکنترلر و نحوه آزمایش سبک برنامه نویسی

بورد میکروکنترلر مورد استفاده تست مبتنی بر آردوینو
در این تست از میکروکنترلر ATMEGA328 در فرکانس 16 مگاهرتز (برد آردوینو البته از Gcc برای کامپایل کد استفاده خواهیم کرد نه ابزار آردوینو) استفاده خواهیم کرد و با اتصال یک عدد LCD رنگی به صورت سریال راه اندازی می‌شود قصد داریم سرعت رسم فریم های تصویر را اندازه گیری کنیم. برای این کار مدت زمان رسم ده فریم از تصویر را اندازه گیری می‌کنیم و نمایش می‌دهیم. LCD مذکور از انتقال 9 بیت سریال برای رسم تصویر استفاده می کند و واحد SPI موجود در میکروکنترلر نهایتا در حالت 8 بیتی کار می کند و نمی توانیم از آن استفاده کنیم پس این قسمت از برنامه را  مجبوریم که با کدنویسی پیاده سازی کنیم. در ادامه بررسی خواهیم کرد که مدل های برنامه نویسی چه تاثیری در سرعت اجرای آن خواهند داشت.

برنامه اول ، برنامه‌ای که همه می نویسند

برای نوشتن برنامه ای که 9 بیت را به صورت سریال انتقال دهد یکی از مرسوم ترین راه ها استفاده از حلقه for می باشد. در اولین قدم ما نیز برنامه را به روش رایج می نویسیم: همانطور که می بینید ابتدا پایه CS را صفر میکنیم ، بعد با استفاده از حلقه For 9 بیت داده را انتقال می دهیم و سپس پایه CS را یک می‌کنیم! مساله ای که برای ما حائز اهمیت است ، سرعت اجرای این کد است ، فرض کنید قصد داریم تصویر متحرکی را روی صفحه نمایش دهیم ، اگر سرعت رفرش شدن صفحه از حدی بیشتر شود ، اصلا امکان چنین کاری نیست ، با اجرای این کد خروجی زیر را خواهیم داشت سرعت اجرای برنامه اول نوکیا
همانطور که در تصویر مشخص است ، اجرای ده فریم از تصویر (یعنی ده بار پر کردن صفحه) زمانی حدود 20465 میلی ثانیه نیاز داشته است ، به عبارتی هر بار پر کردن صفحه دوثانیه طول می کشد. در این مرحله عده ای نا امید می شوند و تقصیر را به گردن میکروکنترلر می اندازند و سراغ میکروکترلر قوی تری میروند ! اگر دید درستی به سخت افزار و نرم افزار داشته باشیم به سادگی میشه حدس زد که مشکل از کجاست و چطور میشه حلش کرد! در این مثال بگذارید اول بررسی کنیم ، برای پر کردن صفحه از رنگی خاص چقدر زمان CPU صرف میشه ، صفحه نمایشگر ما 160 در 120 است یعنی 19200 پیکسل باید دیتا دریافت کنند ، برای پر کردن هر پیکسل نیازه که دوبار این تابع قراخوانی بشه ، میشه در واقع 38400 بار باید این تابع رو فراخوانی کنیم ! حالا چطور میتونیم برنامه رو بهینه تر کنیم ، داخل for رو نگاه کنید ! با توجه به این که دستورات درون for با هربار اجرای تابع 9 مرتبه اجرا می شوند ، برای پر کردن صفحه لازمه 345600 بار اجرا شوند. یعنی صرفه جویی در یک سیکل ماشین درون روتین حلقه ، به تعداد 345600  سیکل ما را سریعتر می کند ، با توجه به فرکانس کاری 16 مگ ، هر سیکل صرفه جویی ، معادل 21.6 میلی ثانیه خواهد بود! پس اصلا دست کم نگیریدش ! اما چطور میشه برنامه رو بهینه تر نوشت ؟

برنامه دوم ، برنامه‌ای که بعد از تفکر می نویسید

بعد از کمی فکر کردن در خصوص این که چطور میتونید برنامه رو بهینه کنید ، با مقداری هوش – برنامه رو این چنین خواهید نوشت : اما چه تغییری کرد برنامه ؟ ، در واقع فرایند مقایسه را بهینه کردیم ، در برنامه قبل عملیات مقایسه به صورت زیر بود در خط فوق برای هر بیت ، اول 8 را از متغیر i کم می کردیم ، بعد عدد 1 به تعداد حاصل شیفت می دادیم به سمت چپ و بعد با مقدار data اند می کردیم و بر اساس آن خروجی را تنظیم می کردیم ! این فرایند ها را برای پر کردن صفحه 345600  بار تکرار می کردیم ! اگر بتوانید این فرایند را حذف کنیم ، قطعا تعداد سیکل خیلی زیادی صرفه جویی می‌کنیم. اما چطور ؟ خیلی ساده است با تعریف یک جدول مقایسه (lookup table) ! یعنی حاصل عبارتی را میکروکنترلر باید یک بار تفریق و یک بار شیفت را برایش انجام می‌داد صورت دستی محاسبه کنیم و در یک آرایه ذخیره کنیم ، و در شرط مقدار مورد نظر را از آن استخراج کنیم ، اما ببینم این کار تا چه اندازه اثر بخش خواهد بود ؟ برنامه بهینه و سرعت اجرای برنامه دوم
بله ، همین کار ساده سرعت اجرای برنامه را تقریبا 2 برابر افزایش داد ؛ یعنی برای رسم هر فریم نیاز به 1 ثانیه زمان بیشتر نخواهید داشت ! اما آیا باز میشود کد را بهینه تر نوشت ؟

برنامه سوم ، برنامه‌ای که با خلاقیت و شناخت سخت افزار می نویسید

در برنامه قبلی با استفاده از یک تکنیک ساده سرعت اجرای برنامه دو برابر شد ، اما آیا راه دیگری هست که باز هم بشود برنامه را بهینه کرد ؟، اینجاست که دید شما نسبت به سخت افزار و آشنایی با معماری پردازنده به کمک شما میآد ، بیایید نگاهی به کد اسمبلی تولید شده بیندازیم اسمبلی میکروکنترلر AVR
اگر دقت کنید در خط 624 و 625 دو دستور اسمبلی داریم با نام های LD ، کار این دستور ها لود کردن مقداری است که Z به اون اشاره میکنه (انتخاب اینکدس مورد نظر از آرایه تعریف شده ShiftBit) ، مطابق اونچه داخل دیتاشیت AVR موجوده هر کدام از این دستورات به 2 سیکل ماشین نیاز داره ، دستور brne که هم برای پیاده سازی if استفاده شده هم برای پیاده سازی for ، اجراش نیاز به 1 یا 2(در صورتی که پرش انجام بشه) سیکل ماشین داره ، خود پیاده سازی حلقه هم نیاز به cpc و cpi داره که هر کدوم یک سیکل ماشین رو مصرف می‌کنن ! با توصیفات بالا مشخص میشه که حذف حلقه و انتخاب از ایندکس آرایه خیلی در سیکل های ماشین مصرف شده صرفه جویی خواهد کرد ، پس برنامه را به شکل زیر تغییر می دهیم بله یا یک روش ساده و حذف حلقه ؛ برنامه به شکل فوق در خواهد آمد !   برنامه آخر بهینه سازی آخر
همانطور که میبیتید با این تغییر سرعت اجرا باز دوبرابر شد  یعنی رسم هر فریم تصویر تقریبا 550 میلی ثانیه زمان خواهد برد و این یعنی چهار برابر سریعتر از برنامه اول ! می بینید که به سادگی و فقط یا تغییر در مدل کد نویسی می توان نتیجه خیلی بهتری را از سخت افزار مورد نظر گرفت ، تاجایی که دیگر لازم به تغییر میکروکنترلر نباشد!
مهم نیست از چه میکروکنترلری استفاده می کنید؛ ARM یا AVR مهم این است که چقدر در کار با آن تجربه و تبحر دارید!

مقایسه سرعت بروزرسانی تصویر

 

چالش برنامه نویسی آخر

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

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

شما نیز میتوانید یکی از نویسندگان سیسوگ باشید.   همکاری با سیسوگ

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

55 دیدگاه در “میکروکنترلر مقصر نیست مقصر برنامه نویسی است

  1. hmd گفت:

    سلام
    مطلبی که نوشتید خیلی خوب و مفید بود
    فقط نکته ای که در مورد نویز و avr و … گفتید
    ببینید، درسته که با طراحی درست و اصولی میشه از avr در محیط صنعتی هم استفاده کرد اما مسئله این نیست، مشکل اینجاست که طراحی اصولی هزینه داره، هم هزینه زمانی و هم هزینه قطعات بیشتر، حتی در موارد تغذیه جدای میکرو از بخش های دیگه
    و این تو تولید انبوه خیلی خیلی مهمه وگرنه برای نمونه سازی و تولید کم و یک پروژه خاص اصلا اهمیتی نداره
    ولی با توجه به اینکه تو تولید انبوه بهتره چیزی استفاده کنیم که هزینه های جانبی رو دستمون نزاره و تو پروژه های غیر انبوه هم هزینه چندان اهمیتی نداره پس بهتره میکروی بهتر و مقاومتر انتخاب بشه و کلا اساس کارمون رو بر همون مبنا بزاریم

    1. زئوس Zeus زئوس Zeus گفت:

      سلام دوست عزیز
      فکر میکنم هزینه تمام شده میکروکنترلر avr با در نظر گرفتن هزینه های لازم برای مقاوم سازی از pic کمتر باشه – البته خیلی وقته که خرید نکردم و ممکنه معادلات بهم ریخته باشه که من اطلاعی ندارم ازش

      1. hmd گفت:

        البته من همچین فکری نمی‌کنم،pic میکروهای ارزون قیمت تا گرون قیمت داره
        ولی فرضا حتی اگر چنین چیزی هم باشه و شما تمام موارد رو برای avr رعایت کنید باز هم از لحاظ مقاوم سازی در برابر نویز و … مشابه pic نمیشه، حتی arm هم مشابه pic نیست
        در یک پروژه موشکی که بنا به شرایط مدار با سرعت بسیار زیاد دور خودش می‌چرخید هم این مورد تست شده و هیچ میکرویی غیر از pic نتونست شرایط سخت رو تحمل کنه
        ضمنا هر که طاووس خواهد جور هندوستان کشد، حتی اگر هزینه بیشتر بشه، وقتی کیفیت بالاتر بخوایم مقداری هزینه بیشتر هم منعی نداره هر چند که در اکثر موارد اینطور هم نیست
        حالا فرض کنید تغذیه جدا هم برای avr نیازه باشه، حجم مدار و … !

        1. زئوس Zeus زئوس Zeus گفت:

          من حساسیت خاصی روی مدل میکروکنترلر ندارم ولی این چیزی هم که شما میگید درست نیست !
          الان خیلی از دیوایس های خاص و فلان و بهمان دارن از پردازنده های مدرن مثل avr و arm استفاده می کنند مثال هم تا دلتون بخواد زیاد هست و به سادگی یه سرچ توی اینترنت میتونید پیدا کنید مثال هاشو

          1. hmd گفت:

            یعنی نظرتون اینه که میکرو pic مدرن نیست یا قدیمیه !!!
            اگر اینطوره که بفرمایید دیگه ادامه ندیم اصلا !

            ولی اگر منظورتون این نبوده مسئله کلی اینه

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

            البته منظور بین avr و pic بود نه arm، چون آرم های دیگه رو باید با آرم های microchip مقایسه کرد نه با pic هاش

          2. زئوس Zeus زئوس Zeus گفت:

            نه دوست عزیز من مدرن رو در معنای دیگری به کار بردم – الان میکروکنترلرهایی از خانواده pic طراحی شدن که اخیرا طراحی شدن و منطقا تکنولوژی های روز درشون استفاده شده
            تا حالا فکر کردید چرا gcc که یه کامپایلر متن باز هست از سخت افزار avr پشتیبانی میکنه از سخت افزار arm پشتیبانی میکنه ولی از pic یا 8051 یا stm8 این پشتیبانی رو نداره ؟ بخاطر معماری سخت افزاری انجام شده است ! من به این میگم مدرن – یعنی طراحی سخت افزار جوی هست که اجازه میده کامپایلر با معماری مدرن و پشتیبانی از استاندارد های به روز جهانی براش کد جنریت کنن.
            بله درسته pic کامپایلر خودش رو داره که سی رو پشتیبانی میکنه و خوب هم کار میکنه اما استانداردهای متفاوتی دارند. اینا همه ابزارهایی هستند در دستان ما بهتره تعصبی روی ابزار نداشته باشم تازه اونم چیزی که خودمون طراحی و تولیدش نکردیم. بهتر ابزار ها رو بهتر بشناسیم و در جای درست ازشون استفاده کنیم.
            لیست سخت افزارهایی که توسط جی سی سی پشتیبانی میشوند در لینک زیر ببینید
            http://gcc.gnu.org/backends.html

          3. hmd گفت:

            الان این که gcc پشتیبانی میکنه یا نه چه ارتباطی به مقایسه pic, avr داشت

            مثلا شما PLC هم بخوای کار کنی خب محیط کاری خودشو داره که در بعضی مواقع یه چیزی شبیه Fritzing رو یاد آدم میندازه اما این دلیل میشه که بگیم PLC مدرن نیست چون مثلا مستقیما با gcc کار نمیکنه یا مثل بچه ها توش نقاشی میکشی و اون برات انجام میده ؟!!!

            بله منم تعصبی روی ابزار ندارم ولی شما هر کاری هم که انجام بدی نمیتونی استفاده از پراید (avr) رو بجای بنز (pic) توجیه کنی یا مثلا دلیل بیاری که با کیسه گونی (avr) هم میشه لباس دوخت و استفاده کرد و فرق زیادی با پارچه ابریشمی (pic) نداره !

            مگر در مورد چیزی مثل قیمت پایین پراید که خب این موضوع در مورد میکروها زیاد موضوعیت نداره چون در خیلی موارد از نظر قیمتی اختلاف چندانی ندارند

            اون چیزی که شما داری میگی در مواردیه که از نظر کیفیت و امکانات تقریبا در یک سطح باشن مثلا مقایسه بنز و بی ام و یا AMD, INTEL یا استقلال و پیروزی یا … نه چیزی مثل avr و pic

            من فکر می‌کنم بیشترین دلیل مقاومت کسانی که avr کار می‌کنن اینه که یا تو دانشگاه بهشون تدریس شده یا به صورت گله ای و بر طبق تئوری بز (اسم یک تئوری روانشناسی هستش) دیدن همه دنبال یه چیزی بودن و یه چیزی رو گفتن و اونام همون راه رو رفتن چون همه رفتن و …
            و حالا سختشونه بخوان سوئیچ کنن روی چیزی دیگه (تغییر کلا دردناکه ولی مفید)
            شایدم احساس بدی بهشون دست میده از اینکه اشتباه رفتن راه رو

            در صورتیکه واقعا اینطور نیست، علم الکترونیک که جای خودشه، برنامه نویسی هم که اکثرا از زبان سی استفاده میشه، قوانین میکروها هم که 90 تا 95 درصد مشابه هم هستش بنابراین برای سوئیچ اصلا نیاز به انجام کار سخت و بزرگی نیست و تمام تجربیات قبلیشون روی avr اینجا هم کاملا کاربرد داره براشون، فقط یه سخت افزار اولیه تغییر کرده، بماند که کار با میکرو pic به نظر من راحت تر از avr هم هست چون نیاز به رعایت دستورالعملهای خاص که یه موقع میکرو بدش بیاد و قهر کنه کار نکنه هم نداره !

          4. زئوس Zeus زئوس Zeus گفت:

            خیلی ربط داره – بیشتر از اونچه بتونید تصور کنید ربط داره، اگر سعی کرده باشید یک کتابخانه استاندارد مثلا c11 رو که استانداردهای c11 داره توی کدی که برای pic نوشته اید استفاده کنید اون موقع متوجه منظور من میشید. (کامپایلر xc8 تازه استاندارد c99 رو داره پشتیبانی میکنه که خیلی خوبه البته)
            ما داریم در مورد میکروکنترلر حرف میزنیم و البته برنامه نویسی برای یک سخت افزار نه استفاده از plc و سینتکس محدود اون. برنامه نویسی به زبان c یک سری استاندارد مشخص داره که به سادگی میتونید اونا رو توی وب جستجو کنید و جزییات هر کدوم رو ببینید. بله طراحی pic مدرن نیست دوست من – تعصب چرا، مدرن نیست چون خیلی قبل تر از avr طراحی شده همین به سادگی ثابت میکنه چقدر عقب تر از طراحی avr است. قطعا در زمان pic دانش یه چیزی بوده و در زمان طراحی avr چیز دیگه ای بوده جای بحث نداره!!
            من فکر میکنم دلیل این که دوستان بیشتر از avr و امثالهم استفاده میکنند جدایی از بخش قیمت منابعی هست که این مدل میکروکنترلرها در اختیارشون میذاره – میزان رم – فلش – پرفرال ها و …. شما برید نگاه کنید زمانی که avr عرضه شده pic چه میکروهایی با چه قیمت هایی و چه مشخصاتی داشت.
            + بر خلاف چیزی که فکر میکنید عموم بیشتر به دنبال تغییر هستند ولی تغییر مثبت نه منفی همین الان نگاه کنید چقدر استفاده از میکروکنترلر arm عمومیت پیدا کرده !

          5. hmd گفت:

            اینکه اینقدر روی مثلا gcc تاکید دارید نقض حرف خودتون در این مقاله و مقاله دیگری هست که گفتید ابزار زیاد اهمیت نداره ولی الان دارید از اهمیت ابزار حرف میزنید

            مورد دوم اینکه باید دید پریفرال ها به چه قیمتی در اختیارتون گذاشته میشه
            یه زمانی ابزاری مثل دریل قیمت بالایی داشت و اکثرا دریل های بوش بودن و هر کسی توان خریدش رو نداشت تا اینکه به لطف برادران چینی دریل هایی تو بازار اومد که اگر مثلا دریل بوش آلمان 120 هزار تومان بود اون چینی ها رو خود ما 5 هزار تومن خریدیم !!!

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

            پس همیشه داشتن اعداد زیاد در امکانات و پریفرال ها مهم نیست، مهم اینه که امکاناتی که گفته میشه کارش رو هم به خوبی انجام بده، همین الان موبایل با دوربین 40 مگاپیکسل هم هست و البته 100 مگاپیکسل هم اومده ولی کیفیت عکسش اصلا در حد مقایسه با یه دوربین DSLR ده مگاپیکسلی هم نیست

            اینکه avr مثلا حافظه بیشتر ارائه کنه یا … مهم نیست وقتی تا بهش بگی نون از گندم مثلا دیتاهای eeprom پاک بشه یا با یه مقدار نویز محیط میکرو هنگ و ریست کنه و نیاز باشه برای رفعش هزار جور ترفند زد و هزینه کرد، مثل یه آدم نازک نارنجی که تا یه باد بهش بخوره سرما میخوره، دقت کنید که این خطاها رو میشه با طراحی سخت افزاری و برنامه‌نویسی رفع کرد اما اینکار هزینه داره هم هزینه زمانی هم هزینه قطعات اضافی احتمالی و وقتی میکرویی مثل pic هستش که نیاز به این هزینه های پنهان نداره دلیلی برای استفاده کردن از avr وجود نداره

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

            در مورد اینکه گفتید الان دنبال arm هستن هم یکی از دلایلش همین مشکلات avr هستش که تو پروژه ها اذیتشون کرده و دیگه مجبور شدن سوئیچ کنن و دلیل بعدی امکانات و سرعت و پریفرال های بیشتر آرم ها، که البته همونم اگر به سمت آرم های میکروچیپ برن باز بهتره تا آرم های دیگه

          6. زئوس Zeus زئوس Zeus گفت:

            چیز ابزاری بهتر از gcc معرفی کنید – مطمین باشید بدون بحث ازش استفاده خواهم کرد 🙂 استفاده از ابزار بهتر نیاز به بحث نداره
            من خودم زیاد با میکروکنترلر pic سر و کله نزدم – خیلی دوست دارم زحمت بکشید و مقاله ای در خصوص معرفی و حتی مقایسه اون با دیگر میکروکنترلرهای موجود بنویسید و مطمین باشید ما توی سیسوگ خوشحال میشیم که منتشرش کنم
            امیدوارم که وقت بگذارید مقاله رو بنویسید 🙂

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

            خب طرفداران AVR می‌گن که این میکرو هیچ مشکلی نداره و مثل خیلی از میکروهای دیگه داره کار خودشو به خوبی انجام می‌ده.

            مخالفان AVR هم می‌گن ای بابا این میکرو دیگه چیه همش نویز می‌گیره جرات نداری کنارش راه بری یا برای رفع ایراداتش مجبوری هزارتا چیز جانبی بزاری کنارش تا اوکی بشه.

            خب بزارید کمی دقیق‌تر شرحش بدم.

            من به شخصه از تعدادی از طرفدارن AVR که در صنعت مشغول هستن و دستگاه‌هایی هم با میکروهای AVR تولید کردن می‌گن که هیچ مشکلی باهاش نداشتن و اگر فرض را بر این بگیریم که صادقانه همه چیز را می‌گویند پس AVR مشکلی نداره (منطقا به نظر می‌رسد که صادقانه نظرشان را گفته باشند چون که قرار نیست طرفداری از AVR سودی را عایدشان کند)

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

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

            خب بگذریم بریم سر بحث اصلی.

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

            با تشکر از جناب زئوس و حامدفر عزیز.

  2. Mohammad Noori noorsun0035 گفت:

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

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

    1. زئوس Zeus زئوس Zeus گفت:

      سلام دوست عزیز
      ممنونم شما خیلی لطف دارید 🙂

  3. احسان گفت:

    سلام استاد خسته نباشید
    من راستش حدود 7 یا 8 ماهی هست که دارم سعی میکنم قدرتم و در برنامه نویسی سی افزایش بدم و در اینکار موفقم بودم
    بنده سوالی برام پیش اومده اینک از اون جایی ک نحوه برنامه نویسی سی برای سیستم عامل کاملا متفاوت تر از سی امبدد هست من بیشتر منابعی ک مشاهده کردم مربوط به سی برای سیستم عامله میخواستم بدونم شما منبع خوبی برای سی امبدد در نظر دارید (البته یک کتاب PDF به نام Embedded Programming with Modern C++ Cookbook ک نویسنده این کتاب Igor Viarheichyk هست و خب رزومه بزرگی داشتن ولی از اونجایی ک گرامر سی پلاس پلاس بهینه تر از سی هست شما نظری در این باره دارید ک بجای سی امبدد به سی پلاس پلاس امبدد روی بیارم؟؟)
    ممنون از مطالب خوبتون و مرجع متن باز سیسوگ:)

    1. زئوس Zeus زئوس Zeus گفت:

      سلام دوست عزیز
      خوشحالم که دارید روی این مساله وقت میذارید 🙂 فکر میکنم یکی از نکات کلیدی برای حرفه ای شدن توی کار طراحی دیجیتال برنامه نویس خوب بودن هست. که متاسفانه زیاد توی رشته ما بهش توجه نمیشه.
      خوب اول بذارید قاطعانه بگم که برای برنامه نویسی روی میکروکنترلر c++ گزینه چندان مناسبی نیست. توی برنامه نویسی حرفه ای مشکلات زیادی به وجود میاره و به شکل ناخود اگاه وقتی از کلاس ها استفاده می کنید حافظه زیادی رو هدر میدهید چون فراموش میکند که مثلا یک کلاس با یه متغییر ساده توی مصرف منابع چقدر متفاوت هست و مسائل خیلی زیاد دیگری که پیش میآد. برای این که بتونم دوستان منتقد نسبت به این دیدگاه رو قانع کنم باید به سادگیLinus Torvalds رو مثال بزنم که خالق هسته لینوکسه و میگه برای برنامه نویسی سطح پایین c++ واقعا وحشت ناکه و تا جای ممکن کدهای مبتنی بر c++ رو از کرنل حذف کرده.
      در مورد منبع – باید بگم یکی از غنی ترین منابع موجود سورس کدهای نوشته شدی دیگران هست که توی گیت هاب میتونید پیداشون کنید.

  4. سعید سعید گفت:

    سلام جناب زئوس
    من تو این زمینه خیلی تازه کارم ولی برام جذاب بود واقعا
    میشه راهنمایی کنید که برای رسیدن به این سطح از تسلط تو برنامه نویسی سخت افزار از کجا میشه شروع کرد؟

    1. زئوس Zeus زئوس Zeus گفت:

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

  5. حسین گفت:

    سلام.
    من قبلا با avr کار کرده بودم ولی تحت تاثیر استفاده از تجهیزات جدید و عدم تطابقشون با avr و قیمت گرانش کمی از چشمم افتاد و رفتم سروقت stm32 . البته هنوز هم زیاد خوشم نمیاد ازش . منتها فکر میکردم چون از لحاظ سرعت کلاک از avr قویتره ( از جهت پریفرالها که صد در صد قویتره )
    بهتره وقتم رو بگزارم روی stm32 . تا اینکه همین کتابخانه lcd رو برای stm32 ( با شبیه سازی spi به صورت نرم افزاری ) باز نویسی کردم . نتیجه شوکه کننده بود . سرعت رفرش lcd با avr و کلاک 16 مگاهرتز از stm32 با کلاک 48 مگاهرتز و بهینه سازی روی سرعت اگر نگم بیشتر بود . کمتر هم نبود . به صورت چشمی حتی به نظر میومد avr سریعتر هست .
    خیلی جالب بود این میکروکنترلر فسقلی stm32 رو به چالش کشید . وقتی توی کدها دقیق شدم علتش رو فهمیدم .
    avr تنها با یک دستور اسمبلی که فقط 1 کلاک زمان میبره هر پین رو تغیر وضعیت میداد در حالی که این برای stm32 با 3تا 4 دستور اسمبلی مقدور بود (تازه با بهینه سازی به این نتیجه رسیده بود) که هرکدوم از دستورات هم به زور استفاده از پایپ لاین ، یک کلاک زمان لازم داره و در حالت عادی بیشتر زمان میبره . یعنی زمان تغییر وضعیت 1 پایه با avr با کلاک 16 مگ ازstm32 با 48 مگ کلاک ، حتی مقداری کمتر بود .
    اون موقع واقعا متوجه شدم avr چیست . کلی عزت و احترام پیشم پیدا کرد .

    این چیپ فسقلی یک اژدهای خفته است .

    طراحی هسته ش و دستوراتش خیلی عالی بوده .
    یعنی اگر کلاکش رو به اندازه stm32 برسونن . و با همین باس دیتای 8 بیتی ، در یک تعداد زیادی از موارد میکرو های32 stm همرده خودش( از نظر کلاک) رو از نظر سرعت ، قورت میده .
    واقعا توی میکروهای 8 بیتی از لحاظ سرعت رقیب نداره .فقط حیف یکم قیمتش گران هست.

    1. زئوس Zeus زئوس Zeus گفت:

      ^_^
      خیلی ممنون برای این که تجرتون رو به اشتراک گذاشتید
      حالا اگر شما سری xmega رو ببینی چه خواهی گفت 🙂 هسته avr کلاک آرم خخخخ
      اونم فوق العاده است مخصوصا پریفرال های متنوعی که داره گاهی دست stm32 رو هم می بنده
      یه نگاهی بهش بنداز به نظرم

      1. حسین گفت:

        سلام .
        شرمنده نکنید جناب زئوس .تجربه من در مقابل تجربه شما ، چیزی نیست .
        اتفاقا خیلی دوست داشتم به جای آرم با xmega یا حتی avr32کار کنم .ولی
        متاسفانه xmega خیلی گرانقیمت هست . و زمان اجازه نمیده روی اون وقت گذاشت.
        سپاس بابت مطالب بسیار خوبی که منتشر میکنید.

        1. زئوس Zeus زئوس Zeus گفت:

          خواهش میکنم 🙂 دوست عزیز
          من هدر xmega خریدم و چند تایی کد روش نوشتم خیلی با avr‌ همخوانی نداره حتی رجیسترهاش و ساختارش – به نظرم خیلی میکروی خوبی هست
          احتمالا آموزشش رو از سر بگیریم توی سیسوگ
          نظرات شما باعث دلگرمی ما میشه

  6. حسین گفت:

    سلام جناب زئوس .
    راستش من مدتی هست که روی کتابخانه مربوط به این lcd وقت گزاشتم .
    میخواستم بپرسم حداکثر سرعت رفرشی که شما با avr بهش دست پیدا کردید چقدر بوده ؟
    مثلا زمان اجرای اون 10 فریم حداقل به چقدر رسیده ؟
    مرسی.

    1. زئوس Zeus زئوس Zeus گفت:

      سلام دوست عزیز ؛ والا من زیاد تر وقت نگذاشتم ؛ و نهایتا همون 4 ثانیه برای 10 فریم رو دریافت کردم
      البته با استفاده از esp8266 تا سرعت 15 فریم به ثانیه هم رسیدم چون توی esp ما spi نه بیتی داریم 🙂

      1. حسین گفت:

        متشکر جناب زئوس

        1. زئوس Zeus زئوس Zeus گفت:

          خواهش میکنم دوست عزیز.

      2. حسین گفت:

        سلام جناب زئوس .
        میکرو avr کلاک 16 مگاهرتز : 11 فریم در ثانیه!!!!

        1. زئوس Zeus زئوس Zeus گفت:

          نه با آور کلاک پردازنده :دی

          1. حسین گفت:

            سلام .
            منظورتون رو متوجه نشدم جناب زئوس . avr و آور کلاک؟؟!!!
            16مگاهرتز برای( atmega32 )avr که آور کلاک حساب نمیشه !!!

          2. زئوس Zeus زئوس Zeus گفت:

            سلام
            منظور از اور کلاک اعمال فرکانس بالاتر از حد مجاز برای پردازنده است – منم avr رو با فرکناس ۲۰ مگاهرتز آورکلاک کردم
            منظورم این بود.

          3. حسین گفت:

            راستش جناب زئوس نفهمیدم چرا مسئله اور کلاک به ذهنتون اومده.
            توی پستهای قبلیم گفته بودم میشه این سرعت سرعت رفرش lcd رو برای avr با همون فرکانس 16 مگاهرتز به 12 فریم در ثانیه رسوند !!!،اما در عمل 11 فریم در ثانیه محقق شد.

          4. زئوس Zeus زئوس Zeus گفت:

            اوپس ظاهرا اشتباه متوجه شدم
            خوب تا اونجا که من اطلاع دارم با روش هایی که احتمالا بعدا اگر فرصت شد بهش خواهیم پرداخت (ارسال دیتای ۹ بیتی با واحد spi سخت افزاری avr) میشه سرعت نمایش رو بهیود بخشید ولی این که چقدر بهتر بشه رو نمیدونم

  7. حسین گفت:

    سلام .
    متشکر از مطلب خوبتون .
    به نظرم اصلا اون آرایه رو حذف کنید ( به درد زمانی میخورد که حلقه for استفاده شده بود ) و مستقیما از مقادیر 0x01 , 0x02 و غیره … استفاده بشه . و دستورات داخل توابع رو به جای توابع نوشت .کدش این میشه :
    CBI(LCD_PORT, LCD_CS);///_cs_clr();

    if(data & 0x001) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x002) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x004) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x008) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x010) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x020) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x040) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    if(data & 0x080) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK );CBI(LCD_PORT,LCD_CLK);

    if(data & 0x100) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

    SBI(LCD_PORT, LCD_CS);
    من یک حساب سر انگشتی کردم . با وضعیت فعلی ، دستورات داخل تابع 326 پالس کلاک احتیاج داره ولی در صورتی که تغیراتی که گفتم انجام بشه فقط به 85 پالس کلاک احتیاج داره 326/85=3.8 یعنی تقریبا سرعت 4 برابر میشه .
    یعنی به جای 4 فریم در 2 ثانیه میشه 16 فریم در 2 ثانیه یا 8 فریم در ثانیه . که تقریبا میشه باهاش انیمیشن نمایش داد.
    متاسفانه من خودم امکانش رو ندارم که این موضوع رو روی سخت افزار تست کنم اگر جناب زئوس این کاررو انجام بدن و زمان رو اندازه گیری کنن
    و نتیجه رو در یک پست به نمایش بگزارن بسیار عالی میشه .
    و یک نکته دیگه اینکه اگر بشه در مد spi …
    8بیتی راه اندازیش کرد سرعت باز هم بیشتر میشه به این دلیل که با تغیراتی که گفتم برای ایجادیک پالس کلاک روی پین میکرو باید 4 پالس هزینه بشه ( 2 پالس برای 1 کردن پین و 2 پالس برای 0 کردنش) که این فرکانس کلاک میکرو رو ربع میکنه ولی اگر از spi میکرو استفاده بشه
    ( به این دلیل که حداکثر فرکانس spi نصف کلاک میکرو هست ) فرکانس پالس کلاک تولیدی نصف فرکانس کلاک خود میکرو میشه که در حالت ایده آل 2 برابر و با درنظر گرفتن بقیه عوامل حدود 1.5 برابرمیشه . توی دیتاشیت درایور خوندم که با وصل کردن یک تعداد پین به gnd و vccمیشه این حالت رو فعال کرد .
    میخواستم بپرسم آیا این پینها در کانکتور ال سی دی در دسترس هستند .؟ یا اصلا به طور کلی چطور میشه این کار رو انجام داد؟
    مرسی

    1. زئوس Zeus زئوس Zeus گفت:

      امم قابل توجه هست ؛ ولی فکر میکنم تا اونجایی که یادم میاد کد اسمبلی ش رو بررسی کردم همچین اتفاقی رو خود کامپایلر رقم زده بود
      ولی باز چکش میکنم اگر نتیجه بهتر شده بود حتما منتشر میکنیم این پیشنهاد رو

      1. حسین گفت:

        با سلام مجدد.
        راستش به نظرم اومد این تابع مربوط به کتابخانه lcd نوکیا 1661 باشه که شما زحمتش رو کشیدین و این مطلب رو با این فرض نوشتم که این تابع مربوط به اون کتابخانه هست اگر اشتباه هست عذر خواهی میکنم . اونقدری که من از کد فهمیدم ، اینا sda_set(); sda_clr();clk_set();clk_clr(); cs_clr();cs_set(); که داخل تابع LCDsend هستن خودشون تابع هستن ولی دستور داخل این توابع یک کد اسمبلی اینلاین 2 بایتی هست . اما به تابع در حالت اسمبلی توجه کنیم میبینم که جزء ثابتش دوتا دستور call و ret هست . که هرکدوم 4 پالس کلاک توی avr زمان میبره . یعنی ما داریم 8 پالس کلاک هزینه میکنیم که یک دستور 2 پالسی اجرا بشه !!!!!
        من کاری که کردم اون 8 پالس کلاک اضافه رو حذف کردم . گمان نمیکنم کمپایلرخودش ret و call رو حذف بکنه .
        متشکر بابت زحمتی که میکشید و بررسی میکنید.

        1. زئوس Zeus زئوس Zeus گفت:

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

          1. حسین گفت:

            با سلام .
            lcd pin functions
            */
            #define LCD_PIN_FUNC(a, b) \
            void _ ## a ## _set() { SBI(LCD_PORT,(LCD_ ## b)); } \
            void _ ## a ## _clr() { CBI(LCD_PORT,(LCD_ ## b)); }

            LCD_PIN_FUNC(rst, RST)
            LCD_PIN_FUNC(cs, CS)
            LCD_PIN_FUNC(sda, SDA)
            LCD_PIN_FUNC(clk, CLK)

            راستش من هر چی دقت میکنم میبینم این چهار دستور آخر توابع رو تعریف میکنند( LCD_PIN_FUNC ماکرویی هست که توابع ست و ریست را برای پایه های مربوط به پین های lcd تعریف میکند) فکر میکنم اگر از خود دستورات cbi و sbi استفاده بشه نتیجه متفاوت خواهد شد . اگر اشتباه کرده ام مرا راهنمایی کنید.
            متشکر .

          2. زئوس Zeus زئوس Zeus گفت:

            دقیقا این نوشته های فوق تبدیل به ماکرو میشه 🙂

          3. حسین گفت:

            سلام .
            فرمایش شما درست بود کمپایلر توابع رو تبدیل به ماکرو کرده .
            مرسی.

      2. حسین گفت:

        باسلام . ببخشید اون کد اشتباه هست(تریب ارسال بیتها برعکس هست )خیلی ببخشید. این درسته
        CBI(LCD_PORT, LCD_CS);///_cs_clr();

        if(data & 0x100) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x080) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x040) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x020) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x010) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x008) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x004) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        if(data & 0x002) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK );CBI(LCD_PORT,LCD_CLK);

        if(data & 0x001) SBI(LCD_PORT, LCD_SDA ); else CBI(LCD_PORT, LCD_SDA);SBI(LCD_PORT,LCD_CLK ); CBI(LCD_PORT,LCD_CLK);

        SBI(LCD_PORT, LCD_CS);//_cs_set();

  8. محمد آصف گفت:

    ابتدا تشکر می کنم بابت نوشتن این مجموعه از مقالات مفید.
    من دو تا پیشنهاد دارم.
    1- چون این پروتکل بصورت SPI کار می کنه پس در زمانی که دیتا داره به میکرو منتقل میشه باید پایه CS فعال باشه و در انتهای کار هم غیر فعال بشه. نیازی نیست که در هر سیکل ارسال یک 9 بیتی این پایه فعال و غیر فعال بشه. اینطوری زمان تغییر وضعیت این پایه کاهش پیدا می کنه. من این روش رو در جایی تست کردم و نتیجه گرفتم.
    2- خود عملیات مقایسه چند سیکل کلاک زمان نیاز داره. میتونیم بدون اینکه نتیجه data & ShiftBit[] رو در داخل یک شرط بررسی کنیم مستقیم نتیجه رو به مقدار نیاز شیفت داده و داخل رجیستر خروجی میکروکنترلر بنویسیم. این بخش نیاز به آشنایی جزئی با رجیسترهای میکروکنترلر داره ولی تقریبا با اطمینان میتونم بگم که این کار سرعت رو افزایش میده. چون عملیات مقایسه از دو عملیات کوچکتر تفریق و مقایسه با صفر تشکیل میشه (اکثرا اینطوریه و ممکنه روشهای دیگری هم داشته باشه) در حالی که عملیات شیفت در میکروها سریعتر انجام میشه و در گام بعد نتیجه مستقیم داخل رجیستر خروجی نوشته میشه. این کار مخصوصا در مقایسه با زمانی که بخش else دستور شما اجرا میشه سریعتره.

    1. زئوس Zeus زئوس Zeus گفت:

      خواهش میکنم دوست عزیز ؛ کاملا درسته ؛ دقیقا همین مساله کنترل به موقع پایه CS میتونه تاثیر زیادی داشته باشه
      در مورد پیشنهاد دوم باید بگم که بله حق باشمایت ولی در صورتی که بتونیم تنها یک بیت از یک ریجیتر رو تغییر بدیدم ؛ که خود این کار نیاز به عملیات or داره که زمان بره ؛ در مجموع فرقی نمیکنه ؛ البته توی معماری avr

  9. امین گفت:

    جالب بود ممنون؛ پیشنهاد من هم استفاده از متغیر نوع رجیستر برای آرایه هستش، و همینطور میشه به جای تابع یک ماکرو تعریف کرد. همینطور باید قسمت slave که یک tft هستش رو هم در نظر گرفت اگر نمایشگر رو پارالل ۱۶ بیتی راه اندازی کنیم سرعت خیلی بالا میره. این کار رو میشه با یه دو تا آی سی شیفت رجیستر انجام داد.

    1. زئوس Zeus زئوس Zeus گفت:

      خواهش میکنم ؛ خوب با توجه به تعداد اجزاء آرایه احتمالا نمیشه از نوع رجیستر استفاده کرد ؛ شایدم بشه خیلی بستگی به CPU داره ولی پیشنهاد خوبیه !
      فرض اینه که میخوایم داده های به شکل سریال ارسال کنیم ؛ اگر نه فرمایش شما کاملا صحیح است ؛ استفاده از مد پارالل نرخ رو خیلی افزایش میده

  10. نوید گفت:

    من شاید 10 درصدشو متوجه شده باشم
    لطفا بازهم ازین مدل پست ها تهیه کنین طرز فکر ادمو تغییر میده
    بسیار ممنونم

    1. زئوس Zeus زئوس Zeus گفت:

      خواهش میکنم دوست عزیز 🙂
      سعی میکنم ادامه بدم ولی اینقدر مشغله هست که آدم فراموش میکنه :/

  11. علی گفت:

    با سلام
    اگر در تعریف lookup table از کلمه کلیدی const استفاده میشد بهتر نبود؟ چراکه در اینصورت در حافظه فلش ذخیره میشد. هرچند که مطمئن نیستم که آیا این باعث کندتر خواندنش میشود یا خیر.

    1. زئوس Zeus زئوس Zeus گفت:

      خوب ، البته بسته به مدل طراحی پردازنده میتونه قضیه متفاوت باشه ، ببینید حافظه RAM سریعتر است و پردازنده به صورت مستقیم معمولا بهش دسترسی داره اما حافظه Flash بسته به ساخناری که داره کندتر از RAM هست و توی برخی معماری ها پردازنده دسترسی مستقیم بهش نداره مثل خانواده های ARM پس تعریف const میتونه باعث کاهش سرعت بشه

  12. محمد گفت:

    با عرض سلام مجدد
    این برنامه رو هم یکم بهینه تر میشه نوشت البته باز هم بدون استفاده از تابع یعنی:
    cs_clr();

    if(data & 0x100)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x80)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x40)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x20)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x10)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x08)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x04)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x02)) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & 0x01)) sda_set(); else sda_clr();clk_set();clk_clr();

    cs_set();

    1. زئوس Zeus زئوس Zeus گفت:

      سلام
      پیشنهاد خوبیه ولی اگر کد اسمبلی رو نگاه کنید موقع کامپایل خود کامپایلر کد قبلی رو به همین حالت تغییر میده ! 🙂
      ببینید به عنوان راهنمایی باید بگم باید دیگه اسمبلی کدها رو بنویسید و در بهترین حالت قرار بدید

    2. محمد گفت:

      void LcdSend(uint16_t data)
      {
      static uint16_t ShiftBit[] = {0x100,0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01};
      cs_clr();

      if(data & ShiftBit[0])) sda_set();
      else if(data & ShiftBit[1])) sda_set();
      else if(data & ShiftBit[2])) sda_set();
      else if(data & ShiftBit[3])) sda_set();
      else if(data & ShiftBit[4])) sda_set();
      else if(data & ShiftBit[5])) sda_set();
      else if(data & ShiftBit[6])) sda_set();
      else if(data & ShiftBit[7])) sda_set();
      else if(data & ShiftBit[8])) sda_set();
      else sda_clr();
      clk_set();
      clk_clr();

      cs_set();
      }

      1. زئوس Zeus زئوس Zeus گفت:

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

  13. محمد گفت:

    درود
    به نظر من اگه واسه این کار از تابع استفاده نشه و به جای تابع lcd_send از خود دستورات به جای فراخوانی تابع استفاده بشه سرعت بالاتر خواهد رفت چون دستور پرش به یک زیر برنامه و بازگشت به برنامه اصلی چند سیکل رو توی برنامه تلف میکنه و راه حل استفاده نکردن از تابع برای دستیابی به حداکثر سرعت هستش.
    static uint16_t ShiftBit[] = {0x100,0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01};
    cs_clr();

    if(data & ShiftBit[0])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[1])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[2])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[3])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[4])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[5])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[6])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[7])) sda_set(); else sda_clr();clk_set();clk_clr();
    if(data & ShiftBit[8])) sda_set(); else sda_clr();clk_set();clk_clr();

    cs_set();

    1. زئوس Zeus زئوس Zeus گفت:

      درود
      پیشنهاد خوبیه ، این کار بی تاثیر نیست ، شاید در حدود 20 میلی ثانیه نه 200 میلی ثانیه
      ولی همین اقدامات کوچیک باعث این بهبود ها میشه 🙂