برنامه نویسی به زبان اسمبلی

[Faramarz M-Sّ]

پاسخ : برنامه نویسی به زبان اسمبلی

سلام،
تو کامپایلر کدویژن نیاز به ضرب 32 بیت در 32 بیت داشتم و حاصل رو داخل یه رشته 64 بیتی(8بایتی) بریزه، چون کدویژن متغیر 64 بیتی نداره، این ضرب رو داخل Atmel Studio انجام دادم و کد های اسمبلی تابع رو به کد ویژن منتقل کردم.
حالا یه تابع سی دارم که از کلا دستورات اسمبلی هستش،
سوالی که دارم حین انجام عملیات ضرب مقادیر رجیسترها (R0-R32)تغییر میکنه، این تغییرات روی ادامه برنامه تاثیر می ذاره ؟ تو خود Atmel Studio که نگاه کردم همه رجیستر هایی که استفاده کرده بود رو push و pop نکرده بود؟!
اصلا من اگه کل 32 تا رجیستر رو اول تابع push کنم و آخرش pop کنم حله؟؟ مشکلی پیش نمیاد ؟؟؟
با تشکر

[طراح]

پاسخ : برنامه نویسی به زبان اسمبلی

به غیر push و pop کردن رجیسترها باید مراقب باشید که در بین انجام عملیات، وقفه ای ایجاد نشود و محتوای رجیستر ها تغییر نکنند.

[mori64]

پاسخ : برنامه نویسی به زبان اسمبلی

در چند جا در این تاپیک دیدم که گفته شده بود در XMEGA نیازی به مقدار دهی اولیه به STACK نیست .
این منحصر به XMEGA نیست و در دیگر سری های جدید AVR هم به همین صورت است .
بطور مثال MEGA88PA با RAMEND مقدار دهی اولیه شده است .

[Hamed Gh]

پاسخ : برنامه نویسی به زبان اسمبلی

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

[mori64]

پاسخ : برنامه نویسی به زبان اسمبلی

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

توجه کنید وقتی میگیم بصورت خودکار انجام میشه یعنی با RAMEND مقدار اولیه دارد (initial value)
نه مقدار دهی نرم افزاری
استک پوینتر mega88pa :




استک mega16 :
که مقدار اولیه 0 وباید نرم افزاری مقدار دهی بشه

[Hamed Gh]

پاسخ : برنامه نویسی به زبان اسمبلی

This Stack space in the data SRAM must be defined by the program before
any subroutine calls are executed or interrupts are enabled. The Stack Pointer must be set to
point above 0x0100, preferably RAMEND

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

البته در خروجی کامپایلر برای Xmega هم این مقدار دهی انجام شده!!

[mori64]

پاسخ : برنامه نویسی به زبان اسمبلی

For AVR devices with SRAM, the stack pointer must be set to point at the last address in SRAM. On new devices it is automaticly initialized to RAMEND during reset, while on other devices this must be handled by the user code. See the initial stack pointer value in datasheet of your device.
In assembly, initializing the stack pointer is done like this:

ldi R16,low(RAMEND) ; Load the low byte of the stack pointer in R16 
out SPL,R16 ; Output the value to the stack pointer 
ldi R16,high(RAMEND) ; Load the high byte of the stack pointer in R16 
out SPH,R16 ; Comment out if the AVR have <256 bytes SRAM

In "C" the stack pointer is automatically set up in the startup code. Note that the linker configuration file defines where the stack pointer is located.

[طراح]

پاسخ : برنامه نویسی به زبان اسمبلی

در متن آخرین نسخه از دیتاشیت Atmega88pa (صفحه 60) برنامه ای قرار داده شده که در متن آن به SP مقداردهی اولیه شده است. با توجه به سابقه اشکالات بیشمار در متون Atmel و عدم ذکر صریح مقداردهی اولیه به SP بصورت خودکار در متن دیتاشیت، با قاطعیت نمی توان نتیجه گرفت که ذکر RAMEND به عنوان initial value برای SP حتما به معنای مقداردهی اولیه بصورت خودکار به این رجیستر است و برای احراز این مسئله یا باید بصورت عملی آزمایش شود (مثلا مقدار اولیه SP قبل از مقداردهی خوانده شده و روی دو پورت قرار داده شود) و یا از طریق مکاتبه با Atmel می توان از این مورد مطمئن شد.

[siyavash2k]

پاسخ : پاسخ : برنامه نویسی به زبان اسمبلی

در این پست قصد دارم جزئیات نسبتا طولانی یک مشکل مشاهده شده در جریان برنامه نویسی اسمبلی را به عنوان تجربه ای برای مخاطبین محدود این موضوع توضیح دهم.
در عملکرد کد مفصلی که به منظور استفاده از حداکثر ظرفیت پردازشی XMEGA با زبان اسمبلی نوشته شده، مشکل عجیبی مشاهده شد به این ترتیب که در ابتدای روز و بعد از اولین بار بعد از روشن کردن برد، ارتباط RS485 با برد برقرار نمی شد و عملکرد آن متوقف می شد. اما با تغییراتی در نرم افزار و تست های مجدد، مسئله ظاهرا حل می شد. با این وجود در روز بعد مجددا بعد از روشن کردن سیستم همین مشکل برقرار بود. در گام اول این مورد به نظر رسید که مشکل ناشی از تغییر فرکانس کلاک سیستم به دلیل تغییر حرارت محیط و سرد شدن هوا در طول شب است. بنابراین منبع کلاک از یک کریستال خارجی و سپس رساندن آن با PLL به فرکانس بالاتر انتخاب شد. اما با عدم رفع مشکل، این مورد به نظر رسید که شاید PLL در سری A به هر دلیلی درست عمل نمی کند. پس سری AU جایگزین آن گردید. با برقرار بودن مشکل این احتمال مطرح شد که شاید اصولا PLL دارای مشکلی در پایداری است. بنابراین بجای فرکانس 32 مگاهرتز، فرکانس کلاک به 16 مگاهرتز با تامین مستقیم از کریستال خارجی کاهش داده شد. اما همچنان در روز بعد ارتباط سریال به درستی برقرار نمی شد. نکته قابل تامل این بود که در زمان جواب دادن برد، با قطع و وصل تغذیه همچنان برد عمل می کرد. اما با گذشت یک روز این مشکل خود را نشان می داد. برای بررسی بیشتر تاثیر دما، از روش قرار دادن برد در فریزر و تست آن استفاده شد که بنا به مشاهدات بعد از هربار قرار دادن برد در فریزر و گذشت مدت زمانی این مشکل خود را نشان می داد. در این مرحله بجای صبر یکروزه برای تست هرگونه تغییرات نرم افزاری و سخت افزاری، امکان تست عملکرد در فاصله زمانی کوتاهتر فراهم شد. مورد بسیار عجیب در این مرحله این بود که بعد از سرد شدن برد و ایجاد مشکل، اگر نرم افزار قبلی مجددا پروگرام می شد، با وجود سرد بودن برد مشکل برطرف می گردید. اما اگر قبل از پروگرام شدن، میکروکنترلر ریست می شد، تاثیری در درست عمل کردن نرم افزار نداشت. در این وضعیت این سوال پیش آمد که آیا ممکن است سرمای موجود باعث پاک شدن محتوای flash شود؟ برای پاسخ به این سوال در وضعیت بوجود آمدن مشکل ناشی از سرما، برنامه verify شد که محتوای flash صحیح بود. سوال مطرح در این شرایط این بود که چرا در بردهای مشابه مبتنی بر AVR چنین مسئله ای مشاهده نمی شود و برای تست یک برد AVR در فریزر قرار داده شد که باز هم به خوبی عمل می کرد. در این مرحله این سوال ایجاد شد که شاید مشکلی در رابطه با خانواده XMEGA در دماهای پائین وجود داشته باشد. برای تست این مسئله برد XMEGA دیگری با سخت افزار و نرم افزار متفاوت در فریزر قرار داده شد. اما هیچ مشکلی در عملکرد آن مشاهده نشد.
بعد از صرف زمان بسیار زیاد مشخص شد که این سرما نیست که منجر به بروز چنین وضعیتی می شود. بلکه اگر تمام خازن های موجود روی برد تخلیه شوند، در همان دمای معمول هم عملکرد نادرست فورا خود را نشان می دهد. در نهایت بعد از انجام آزمایش های متعدد و بررسی همه جانبه مشخص شد که همه این مشکلات ناشی از عدم مقداردهی اولیه به یک متغیر تعریف شده در sram است که باعث می شود بر اساس یک دستور IJMP پرشی به یک نقطه نامشخص از flash انجام شود و عملکرد خروجی برنامه مختل شود. با اصلاح این مقداردهی همان سری A هم با فعال کردن PLL با مرجع کریستال خارجی به خوبی جواب داد و هیچ مشکلی در دماهای مختلف هم مشاهده نشد. اما سوال اصلی در این داستان طولانی این است که چرا سیستم در پایان هر روز جواب می داد، اما در روز بعد و یا تخلیه خازن های آن مشکل ایجاد می شد؟ پاسخ تمام سوالات این است که با خاموش ماندن برد در زمان طولانی و یا تخلیه خازن های آن، محتوای sram پاک می شود و دارای مقدار نامشخصی می شود (محتوای sram بعد از reset پاک نمی شود) که باعث بروز مشکل می گردد. اما ظاهرا پروگرام کردن توسط پروگرامر mkii باعث صفر کردن محتوای sram هم می شود که سبب عملکرد درست نرم افزار می شود و در پایان هر روز که برد بدون مشکل عمل می کرد، قبل از آن حتما یکبار پروگرام شده بود و آدرس مورد نظر دارای مقدار صفر شده بود. اما در صبح روز بعد حافظه کلا پاک شده بود و پرش به آدرس غیر مشخص انجام می شد که حاصل آن عمل نکردن خروجی نرم افزار بود.
ممکن است این سوال برای برخی مخاطبین مطرح شود که آیا نمی شد به جای استفاده از ابزار برنامه نویس اسمبلی از کامپایلر های سطح بالا برای پیاده سازی مورد نظر استفاده کرد تا چنین مشکلاتی ایجاد نشود؟ پاسخ این سوال منفی است. به این ترتیب که برای انجام منظور مورد نظر چنان بار پردازشی به cpu تحمیل می شود که در صورت لزوم استفاده از XMEGA نمی توان به روش دیگری این برنامه نویسی را انجام داد و تنها چاره کار با فرض استفاده از XMEGA همین شیوه برنامه نویسی بوده است.
در هر صورت کل این پروسه حداقل بیش از 50 ساعت کاری از من زمان گرفت و به نظرم رسید شاید نقل آن بتواند برای برخی دوستان خاص مفید باشد.

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

[Study]

پاسخ : برنامه نویسی به زبان اسمبلی

شروع این تاپیک چندین سال پیش بود، متاسفانه مدت قابل توجهی بنا به دلایل مختلف از میکرو دور بودم و کم و بیش لازمم میشد و هر از گاهی با زبان C کد مینوشتم و کار رو انجام میدادم، مدتی هست که برگشتم و برنامه هام و کتاب ها و کلیه منابع رو مرور میکنم تا اطلاعات از دست رفته رو برگردانم و تکمیل کنم، یادم بود که چندین سال پیش این تاپیک و چند تاپیک مشابه توسط جناب کی نژاد آغاز شد و کمی دنبال کردم ولی متاسفانه به دلایل مختلف نتونستم کلا همراهی کنم، حالا که مدت کوتاهی هست بعد از چند سال به انجمن برگشتم کلی دنبال این تاپک ها در بخش AVR گشتم در نهایت دیدم تو بخش XMEGA هست!!
حالا که بحث هایی در راستای اهمیت زبان اسمبلی و تجربیات با ارزش در این مورد پیش اومد گفتم شاید بد نباشه من هم تجربه ای رو بگم.
حدود سال 2009 روی سیستم پایدار کننده پرنده های 4 ملخه کوادکوپتر کار میکردم که کنترلر دستی هم داشتند، برای پایداری بهتر این نوع پرنده باید در کوتاه ترین زمان ممکن یکسری ورودی ها خوانده میشد، آنالیز میشد و بعد از پردازش و اعمال ضرایب مناسب به متغییرهای سیستم نتایج به خروجی ها اعمال میشد، ورودی ها 6 کانال دیجیتال pwm بود که باید هر 6 کانال اسکن میشدند و پهنای پالسشون به دست میومد و ذخیره میشد، 3 کانال آنالوگ که از شتاب سنج 3 محوره خوانده میشد که هر کانال باید فیلتر نرم افزاری میشد به این صورت که چندین نمونه خوانده میشد و میانگین گیری انجام میشد و در نهایت مولفه های اصلی استاتیک استخراج میشد، یک رشته از TWI خوانده میشد که مقادیر 3 محور سنسور جایرو ازش استخراج میشد و یک ماژول قطب نما هم باز با TWI باید خوانده میشد، تمامی این موارد به عنوان ورودی خوانده میشدند و بعد از فیلتر شدن داده اصل به دست میومد که باید وارد حلقه پایدار کننده نرم افزاری میشد و بعد از انجام محاسبات به صورت 4 پالس pwm در خروجی برای درایور موتورهای براشلس تبدیل میشد. کل این فرایند که انجام میشد از زمان شروع اسکن کانال ها تا اعمال پالس اصلاح شده به موتورهای براشلس یک سیکل کامل سیستم بود، طبیعتا مدت زمان تکمیل این سیکل خیلی اهمیت داشت، در ابتدا با برنامه سی این سیستم رو انجام دادم و در زمان نسبتا مناسبی به جواب رسیدم اما هنوز تکمیل سیکل من نسبت به چیزی که انتظار داشتم بیشتر زمان میبرد، به همین خاطر سعی کردم کل سیستم رو با اسمبلی بنویسم، خیلی وقت گذاشتم تقریبا 2 هفته شبانه روز صرف بهینه سازی کد اسمبلی کردم اما در نهایت تونستم با کدهای اسمبلی مدت زمان ریفرش کل سیکل رو 8 برابر کم کنم!! اسمبلی به من این اجازه رو داد که با علم به اینکه روتین های تودرتو و وقفه های متعدد در چه زمانی و به چه صورت اتفاق میفتند و چه قسمت هایی از حافظه رو تحت تاثیر قرار میدن بتونم برنامه رو بهتر مدیریت کنم و از زمان های از دست رفته استفاده کنم. اینکار رو با PIC18 انجام داده بودم و نکته جالب اینجاست که زمانی که همین کار رو با dspic30f به زبان سی انجام دادم باز هم تفاوت چندانی با اسمبلی PIC18 برام نکرد چون اگرچه سرعت پردازش بیشتر بود و پردازش ها به صورت 16 بیتی و به سرعت به مراتب بالاتر انجام میشد اما نتونستم در برنامه نویسی C برنامه رو چندان پیچیده و تودرتو بنویسم و عملا بعضی کارها که در اسمبلی PIC18 داشتند همزمان صورت میگرفتند در برنامه سی مجبور بودند به صورت مجزا انجام شوند. اگرچه همون برنامه C هم حتی در میکروهای PIC18 یا پایینتر میتونست پرنده رو تقریبا پایدار کنه اما اون کجا و این کجا!!
امیدوارم فرصت بشه و با همکاری دوستان بحث های پایه و اینچنینی میکروکنترلرها و برنامه نویسی بیشتر مطرح و در موردشون بحث بشه، با دانستن زبان های سطح بالا میشه خیلی از پروژه ها رو به راحتی و سریع تر انجام داد اما بالاخره جاهایی پیش میاد که اونا جوابگوی کار نیستن و اینجور کارها رو فقط کسانی میتوانند انجام دهند که میکرو و برنامه نویسی اصلی اون یعنی اسمبلی رو خوب شناخته باشند و بتوانند کنترل کنند که امیدوارم من هم روزی به این دانش برسم :agree:

[طراح]

پاسخ : برنامه نویسی به زبان اسمبلی

در تائید مطالب شما، برنامه نویسی اسمبلی در برخی کاربردها چنان امکاناتی را برای برنامه نویس ایجاد می کند که رسیدن به همان خروجی با برنامه نویسی سطح بالا نیاز به میکروکنترلری با چندین برابر کلاک دارد. من در حوزه فعالیت های عملی خود با کاربردهایی مواجه بوده ام که اگر از روش برنامه نویسی اسمبلی استفاده نمی شد، اگر کلاک میکروکنترلر دو یا سه برابر هم بود با برنامه نویسی سطح بالا قابل انجام نبود. در واقع یکی از دلایل استفاده از ابزار برنامه نویسی سطح بالا، ناتوانی و محدودیت مغز انسان و محدود بودن زمان است که استفاده از برنامه نویسی سطح بالا را در بسیاری از موارد توجیه پذیر می کند. اما اگر نوع کاربرد به صورتی باشد که استفاده از حداکثر ظرفیت پردازشی پردازنده مورد نظر باشد و به لحاظ درجه سختی و حجم کار، در توان برنامه نویس باشد که از زبان اسمبلی برای پیاده سازی مقصود مورد نظر استفاده کند، نتیجه حاصل از برنامه نویسی اسمبلی با برنامه نویسی سطح بالا به کلی می تواند متفاوت باشد.
یک نکته اساسی در این رابطه این است که حتی برنامه نویسی به زبان سطح بالا هم با علم و اطلاع کامل از کدهای معادل اسمبلی می تواند بسیار بهینه تر باشد. یک مصداق عملی برای این بحث همین صورت مسئله اخیر در مورد پخش فیلم با XMEGA است که مقداری برای آن وقت گذاشتم. در کد اولیه ای که برای نمایش تصویر وجود داشت، نشان دادن یک عکس یا فریم زمانی حدود یک ثانیه (یا کمتر) را به خود اختصاص می داد. اما با توجه کردن به این موضوع که نوع کد نویسی باید چگونه باشد تا کد های ماشین معادل کمتری تولید کند، این زمان تا چند برابر کاهش پیدا کرد. مثلا اگر بدانیم که اجرای هر زیربرنامه بسته به سایز Program counter و استفاده از دستورات RCALL یا CALL برای اجرا بین 6 تا 9 سیکل زمان نیاز دارد، در این صورت برای نمایش نقاط روی LCD در همان زبان سطح بالا از تابع استفاده نمی کنیم. چرا که اگر بنا باشد برای 76800 نقطه روی LCD از یک یا چند تابع استفاده شود، به ازای هر بار احضار یک تابع بیش از 400000 تا 700000 سیکل (بسته به شرایط) از cpu زمان اشغال می شود و بنابراین در چنین کاربردهایی باید از استفاده از توابع خودداری کنیم (یا اگر ممکن باشد تابع را بصورت inline بنویسیم). زیرا استفاده از تابع به دلیل اینکه بصورت معادل باعث احضار زیر برنامه در سطح اسمبلی می شود، وقت cpu را به میزان زیادی اشغال می کند. البته کامپایلرها دارای این قابلیت هستند که در مواقع لازم کد توابع را از شکل زیریرنامه خارج کنند. اما در همین مثال با وجود استفاده از کامپایلر IAR و قرار دادن سطح optimization سرعت در حداکثر، باز هم با مراجعه به کدهای معادل اسمبلی مشاهده شد که در صورت استفاده از تابع از زیربرنامه استفاده شده است (حتی با inline تعریف کردن تابع هم بهینه ترین نحوه اجرا بدست نیامد). یا مثال های مختلف دیگری که ذکر آنها نیاز به زمان دیگری دارد و نتیجه آن این مسئله است که تسلط به برنامه نویسی اسمبلی حتی برای برنامه نویسی سطح بالا هم می تواند بسیار مفید و راهگشا باشد.

[sejil]

پاسخ : پاسخ : برنامه نویسی به زبان اسمبلی

مثلا اگر بدانیم که اجرای هر زیربرنامه بسته به سایز Program counter و استفاده از دستورات RCALL یا CALL برای اجرا بین 6 تا 9 سیکل زمان نیاز دارد، در این صورت برای نمایش نقاط روی LCD در همان زبان سطح بالا از تابع استفاده نمی کنیم

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

[Study]

پاسخ : برنامه نویسی به زبان اسمبلی

به نظر من اول از همه در صورت امکان مطالعه دیتاشیت و لیست دستورالعمل ها لازم هست و همچنین خواندن نوت های مربوطه که از خود اتمل منتشر میشه.
در مرحله بعد همین تاپیک رو که جناب کی نژاد زحمت کشیدند و راه اندازی کردند مطالعه کنید علی الخصوص که خودشون هم خداروشکر هنوز فعال هستند و سوالی داشته باشید پاسخ خواهند داد، اما در زمینه کتاب فارسی اگر منبعی میخواید من کتاب های زیر رو مطالعه کردم و بهتون پیشنهاد میکنم:
اول از همه کتاب میکروکنترلرهای AVR برنامه نویسی به زبانی اسمبلی و C از دکتر محمد علی مزیدی که به دو زبان انگلیسی و فارسی هست ( ترجمه فارسی در کشور ما از انتشارات نص در کتابفروشی ها هست ) من نگارش کتاب های آقای مزیدی رو خیلی دوست دارم، کتاب های 8051 و PIC ایشون رو قبلا مطالعه کردم و معمولا توضیحاتشون هم کامل و هم کاربردی هست، این کتاب در کل 688 صفحه داره و زبان اسمبلی رو با مثال های خوبی توضیح داده و همچنین برنامه نویسی C رو هم در محیط avr studio با کامپایلر winavr بررسی کرده و آموزش داده اما به نظرم بیشتر روی اسمبلی تمرکز کرده تا اینکه جزئیات زبان C رو آموزش بده.
کتاب دیگر از میکروکنترلرهای AVR از دکتر حسن سید رضی انتشارات ناقوس هست که ایشان هم کتابهای خوبی در زمینه دیجیتال و پردازشگرها و FPGA نوشتند، این کتاب هم تقریبا 685 صفحه هست، خیلی کامل هست ولی به نظرم بیشتر بدرد محیط دانشگاهی میخوره سبک توضیحاتش تا کاربردی باشه ولی در کل کتاب خوبی هست و اگر بتونید هزینه کنید داشتنش خوبه!
اکر زیاد نمیتونید هزینه کنید کتاب میکروکنترلرهای AVR سری MEGA از مولفان ( مهندس سعید شجاعی و مهندس نادر مهرا ) از دیباگران تهران رو پیشنهاد میکنم که 316 صفحه بیشتر نیست اما خیلی خلاصه و مفید هست و علیرغم کمتر بودن صفحات توضیحاتش مفید و مهم هست.
کتابهای دیگری هم هستند که بیشتر به زبان های دیگه توجه کردند اما بینش اسمبلی هم توضیح دادن، اونا زیاد مرجع خوبی برای یادگیری اسمبلی نیستند اما زمانی که اسمبلی شما خوب بشه و مفاهیم رو درک کنید میتونید با مشاهده مثال های اسمبلیشون توانایی های برنامه نویسی خودتون رو ارتقا بدید.
همچنین میتونید از لینک زیر کمک بگیرید:
http://www.avr-asm-tutorial.net/avr_en/index.html
موفق باشید

[Study]

پاسخ : برنامه نویسی به زبان اسمبلی

ضمنا در اسمبلر avr شما مجاز به داشتن حداکثر 10 پارامتر هستید یعنی @0 تا @9

با تشکر از توضیحات شما، این محدودیت مربوط به avr assembler 1 هست و در avr assembler 2 این تعداد نا محدود هست ( طبق توضیحات راهنمای avr studio در بخش Macro Improvments )
نکته دیگری در مورد ماکروها اینه که هر بار که شما ماکرو را در برنامه استفاده می کنید همون اندازه کد در آن قسمت برنامه قرار میگیره، به عنوان مثال اگر یک ماکرو 20 بایتی رو 4 دفعه در برنامه استفاده کنید 80 بایت فضا میگیره اما زمانی که کد مشابه آن را در زیر روال ایجاد میکنید هرچند بار که صدا بزنید فقط به اندازه دستور CALL شما فضای اشغالی برنامه اضافه میشه، اما در عوض فراخوانی زیر روال خودش 3 الی 4 سیکل ماشین و بازگشتش توسط RET نیز 4 سیکل ماشین زمان نیاز داره که تقریبا هر بار که زیرروال را صدا بزنید تقریبا 8 سیکل زمان اضافه نیاز هست در صورتی که ماکرو این زمان را نمیگیره. در مواقعی که از ماکرویی زیاد استفاده میکنید و بنا به هر دلیلی نمیتونید یا نمیخواید زیر روال معادلی بجاش بنویسید میشه ماکروها رو به عنوان یک زیر روال قرار بدید و صداش بزنید که حجم کد زیادی به خاطر تکرار مکرر ماکرو از حافظه برنامه اشغال نشود

[siyavash2k]

پاسخ : برنامه نویسی به زبان اسمبلی

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