پاسخ : معرفی بهترین کامپایلر برای c
اخیرا مشغول نوشتن یک کتابخانه LCD کاراکتری برای XMEGA و در کامپایلر IAR هستم و به همین دلیل به منابع و کتابخانه های موجود برای LCD مراجعه می کنم. از جمله در مطالعه نحوه عملکرد کتابخانه LCD در نرم افزار کدویژن نسخه 2.4.4 به نکته ای برخورد کردم که به عنوان یک مصداق می توان از روی آن قضاوت کرد که آیا این کامپایلر تا چه حد حرفه ای طراحی شده و آیا فرمایش آقای سپاس یار در مورد درجه دوم بودن این کامپایلر را در این مثال به خصوص می توان مشاهده کرد یا خیر.
اصولا برای ارتباط با LCD کاراکتری می توان دو راهکار خواندن Busy Flag و یا تاخیر زمانی را انتخاب کرد که روش اول در جایی بکار می رود که حداکثر سرعت ارتباط با LCD مورد نظر باشد و به محض آماده شدن آن، بقیه مراحل انجام شود. در کدویژن ارتباط با LCD از نوع اول است و بنابراین انتظار می رود روتین ارتباط آن به گونه ای نوشته شده باشد که بصورت بهینه و با حداقل تاخیر عمل کند. تابع انتظار برای خارج شدن LCD از وضعیت Busy در کدویژن بصورت زیر است:
در این تابع بین تغییرات وضعیت سیگنال های کنترلی از تابع دیگری با نام lcd_delay_ استفاده شده است.
توجه به کد اسمبلی موجود در تابع نشان می دهد که اجرای آن 45 سیکل زمان می برد و چند سیکل هم برای فراخوانی آن زمان صرف می شود. نکته قابل تامل آن است که در این شیوه برنامه نویسی بجای تعریف یک تاخیر ثابت که به کلاک سیستم وابسته نباشد، از تاخیر متغیری استفاده شده که هرچه کلاک سیستم کمتر باشد، این تاخیر هم بیشتر می شود و سرعت ارتباط با LCD کندتر می شود. این درحالی است که هر برنامه نویس متوسطی باید بداند که تاخیرهای سیستم باید مستقل از کلاک آن باشد و با تغییر کلاک، کم و زیاد نشود. این شیوه برنامه نویسی نشان دهنده آن است که پشتوانه چندان حرفه ای (حداقل در سطح این مصداق) در نوشتن کدویژن وجود ندارد و حتی همین یک مورد هم که بر حسب اتفاق با آن برخورد شد، اصولی و حرفه ای بودن این کامپایلر را به شدت زیر سوال می برد.
اخیرا مشغول نوشتن یک کتابخانه LCD کاراکتری برای XMEGA و در کامپایلر IAR هستم و به همین دلیل به منابع و کتابخانه های موجود برای LCD مراجعه می کنم. از جمله در مطالعه نحوه عملکرد کتابخانه LCD در نرم افزار کدویژن نسخه 2.4.4 به نکته ای برخورد کردم که به عنوان یک مصداق می توان از روی آن قضاوت کرد که آیا این کامپایلر تا چه حد حرفه ای طراحی شده و آیا فرمایش آقای سپاس یار در مورد درجه دوم بودن این کامپایلر را در این مثال به خصوص می توان مشاهده کرد یا خیر.
اصولا برای ارتباط با LCD کاراکتری می توان دو راهکار خواندن Busy Flag و یا تاخیر زمانی را انتخاب کرد که روش اول در جایی بکار می رود که حداکثر سرعت ارتباط با LCD مورد نظر باشد و به محض آماده شدن آن، بقیه مراحل انجام شود. در کدویژن ارتباط با LCD از نوع اول است و بنابراین انتظار می رود روتین ارتباط آن به گونه ای نوشته شده باشد که بصورت بهینه و با حداقل تاخیر عمل کند. تابع انتظار برای خارج شدن LCD از وضعیت Busy در کدویژن بصورت زیر است:
کد:
void _lcd_ready(void)
{
#asm
in r26,__lcd_direction
andi r26,0xf ;set as input
out __lcd_direction,r26
sbi __lcd_port,__lcd_rd ;RD=1
cbi __lcd_port,__lcd_rs ;RS=0
__lcd_busy:
#endasm
_lcd_delay();
#asm
sbi __lcd_port,__lcd_enable ;EN=1
#endasm
_lcd_delay();
#asm
in r26,__lcd_pin
cbi __lcd_port,__lcd_enable ;EN=0
#endasm
_lcd_delay();
#asm
sbi __lcd_port,__lcd_enable ;EN=1
#endasm
_lcd_delay();
#asm
cbi __lcd_port,__lcd_enable ;EN=0
sbrc r26,__lcd_busy_flag
rjmp __lcd_busy
#endasm
}
در این تابع بین تغییرات وضعیت سیگنال های کنترلی از تابع دیگری با نام lcd_delay_ استفاده شده است.
کد:
static void _lcd_delay(void)
{
#asm
ldi r31,15
__lcd_delay0:
dec r31
brne __lcd_delay0
#endasm
}
توجه به کد اسمبلی موجود در تابع نشان می دهد که اجرای آن 45 سیکل زمان می برد و چند سیکل هم برای فراخوانی آن زمان صرف می شود. نکته قابل تامل آن است که در این شیوه برنامه نویسی بجای تعریف یک تاخیر ثابت که به کلاک سیستم وابسته نباشد، از تاخیر متغیری استفاده شده که هرچه کلاک سیستم کمتر باشد، این تاخیر هم بیشتر می شود و سرعت ارتباط با LCD کندتر می شود. این درحالی است که هر برنامه نویس متوسطی باید بداند که تاخیرهای سیستم باید مستقل از کلاک آن باشد و با تغییر کلاک، کم و زیاد نشود. این شیوه برنامه نویسی نشان دهنده آن است که پشتوانه چندان حرفه ای (حداقل در سطح این مصداق) در نوشتن کدویژن وجود ندارد و حتی همین یک مورد هم که بر حسب اتفاق با آن برخورد شد، اصولی و حرفه ای بودن این کامپایلر را به شدت زیر سوال می برد.











دیدگاه