روش های اصولی و صحیح در نوشتن کتابخانه

[aivhl]

با سلام،

با اجازه دوستان و اساتید محترم، این تاپیک رو با توجه به اندک تجربیاتم پیرامون کد نویسی شروع میکنم و امیدوارم که با مشارکت همه دوستان بتونیم کمکی برای ارتقاء سطح دانش عمومی انجمن در کد نویسی باشیم.

***************************

نوشتن یک کتابخانه صرف نظر از سخت افزار و پلتفرم کامپایلر مورد استفاده، میتونه از سه جنبه حائز اهمیت باشه.

1 - در نظر گرفتن یک قالب استاندارد [قراردادی] برای نوشتن کدها
2 - رعایت انعطاف پذیری و سازگاری سخت افزاری
3 - رعایت سازگاری در پلتفرم های متفاوت کامپایلرها

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

در نظر گرفتن یک قالب استاندارد [قراردادی] برای نوشتن کدها
اولین اصل در کدنویسی، شناسنامه دار بودن کلیه فایل هاست که مثلا میتونه یک هدری به شکل زیر باشه که در اون مشخصات کلی فایل و توضیحات اولیه و در صورت لزوم، سابقه تغییرات در ورژن های مختلف، ذکر شده باشه. شاید در نظر اول، این موضوع بی اهمیت جلوه کنه، ولی به مرور متوجه خواهید شد که برعکس، از اهمیت خاصی برخورداره!

//-----------------------------------------------------------------------------
// Copyright:   
// Author:     
// Remarks:    
// known Problems: 
// Version:    
// Description:  
//                                 
//----------------------------------------------------------------------------- 

نکته بعدی اینکه از اونجایی که ممکنه، هدر فایل ها در جاهای مختلفی فراخوانی ( یا اضافه ) بشن، حتما باید مکانیزمی در نظر گرفته بشه که یک هدر فایل بطور همزمان در چند جای مختلف فراخوانی نشه، برای این منظور، باید هدر فایل ها در شرطی مشابه شرط ذیل نوشته بشن :

#ifndef _SHN_UTILS_H_
    #define _SHN_UTILS_H_
 .
 .
 .
 .
 .
#endif    //_SHN_UTILS_H_ 

نوشتن کامنت های خلاصه و کلیدی در کلیه فایل ها ( در جاهای مناسب، عنداللزوم ) نکته پر اهمیت بعدی است! اهمیت این موضوع زمانی روشن میشه که بعد از مدتی میخواهید فایل هاتون رو بررسی و یا اصلاح کنید. مضاف بر اینکه این موضوع برای استفاده کننده های بعدی هم میتونه از جنبه راهنمایی و سهولت در استفاده مهم باشه.

لزومی نداره که همه فانکشن های یک کتابخونه در دسترس عموم باشند! برخی از روتین ها جنبه استفاده داخلی دارند و به عبارتی فانکشن های Low-Level محسوب میشن. بطور نمونه در کتابخونه در حال بررسی ( کتابخونه AD7715 ) روتین های AD7715_WriteToReg و AD7715_CS پس این روتین ها رو نباید در لیست فانکشن پروتوتایپ هدر فایل کتابخونه قرار بدیم.

یک کتابخونه کامل باید طوری نوشته بشه که استفاده کننده نیازی به دستکاری در متن اصلی کدها نداشته باشه، به همین منظور باید حتی الامکان پیش بینی های لازم صورت بگیره. بطور مثال، ست کردن پارامترهای Run-Time باید توسط ماکروها و یا فانکشن ها انجام بشه، ست کردن پارامترهای Static باید در تعاریف ثابت و در یک فایل جداگانه در دسترس استفاده کننده باشه.
در این راستا توصیه میشه که هر کتابخونه حداقل شامل سه فایل باشه، یک فایل C که کدهای اصلی در اون نوشته شده، یک هدر فایل اصلی که تعاریف پایه، ساختارها و پروتوتایپ ها در اون نوشته شده ( که معمولا نیازی به اعمال تغییرات توسط کاربر نداره ) و یک هدر فایل کانفیگ که تمامی پارامترهای ثابت، فلگ ها و تعاریف سخت افزاری و غیره در اون هست و توسط کاربر تنظیم خواهد شد. بحث و بررسی بیشتر در این زمینه رو به مبحث بعدی موکول میکنم.

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

[aivhl]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

با سلام،

در ادامه قصد دارم به مبحث دوم بپردازم، البته این به این مفهوم نیست که مبحث اول تمام شده، بلکه بررسی و بحث بیشتر رو به مشارکت دوستان موکول میکنم!

و اما رعایت انعطاف پذیری و سازگاری سخت افزاری
وقتی که یک کد و یا کتابخونه نوشته میشه، در خوش بینانه ترین حالت، ممکنه که افراد مختلفی با سخت افزار های مشابه، اما آرایش های سخت افزاری مختلف، بخواهند از اون کد و یا کتابخونه استفاده کنند. مثلا کدی برای AVR مگا 32 نوشته شده ولی قراره که روی مگا 8 استفاده بشه و در بدترین حالت، ممکنه که کدی برای AVR مگا 32 نوشته شده باشه ولی قرار باشه که روی یک میکروی PIC مورد بهربرداری قرار بگیره. در چنین شرایطی، اگر کد نوشته شده از انعطاف خوبی برخوردار نباشه، استفاده کننده عطاش رو به لقاش خواهد بخشید! ( فعلا به مورد مبحث سازگاری پلتفرم ها نمی پردازم! )

یک نکته اساسی و قابل تامل اینه که کد نویسی به زبان C در تمامی احوالات ( بجز اندک موارد استثنا ) حالتی استاندارد و مستقل از کامپایلر داره ولی متاسفانه، دوستان همیشه مقوله زبان برنامه نویسی و کامپایلر رو با هم خلط میکنند. پس سعی کنیم که از این پس این دو موضوع رو با هم قاطی نکنیم! این یعنی اینکه منی که با C برای AVR کد مینویسم، از همون قواعدی استفاده میکنم که یک نفر برای کد نویسی با C برای PIC و غیره استفاده میکنه.

یک کد و یا کتابخونه ای که اصولی نوشته شده باشه، حتی الامکان سعی میکنه که از آمیختگی اصول و قواعد کد نویسی زبان برنامه نویسی با اصول و قواعد کامپایلر جلوگیری کنه. اولین قدم در این خصوص اینه که تنظیمات و تعاریف سخت افزاری از کدهای پردازشی و محاسباتی تفکیک بشه.
فرض کنید که یک LED سبز قراره که روی پین PORTD.3 تعریف و خاموش و روشن بشه. اگر به این منظور، در متن برنامه مبادرت به مقدار دهی مستقیم به اون پین بشه، چند مشکل بروز خواهد کرد. مشکل اول اینه که اگر بخواهیم موقعیت LED مورد نظر رو تغییر بدیم، باید در متن برنامه جستجو کرده و تغییرات مورد نظر رو اعمال کنیم، این امر موجب صرف وقت و احتمال بروز خطا خواهد بود. حال اگر بخواهیم منطق روشن و خاموش شدن LED مزبور رو تغییر بدهیم، مشکل دوچندان خواهد شد. و اگر پلتفرم سخت افزاری و یا کامپایلر تغییر کند، در اینصورت بهتر است که برنامه را مجددا بازنویسی کنیم!!! این مشکل ممکن است در کتابخانه در حال بررسی ( کتابخونه AD7715 ) در مورد پین CS آی سی AD7715 بروز کند. پس راهکار مناسب چیست؟

همانطور که قبلا هم اشاره شد، در این خصوص بهتر است کلیه تعاریف سخت افزاری و حتی مکانیزم های کنترلی اصلی در یک هدر فایل کانفیگ انجام و به پروژه الحاق شود. برای LED مورد مثال به شکل زیر عمل میکنیم :

//----------- Green LED (output)
#define GLED_PRT       PORTD
#define GLED_DDR       DDRD
#define GLED_BIT       3

//------------------------------------
#define GLED_init()     sbi(GLED_DDR, GLED_BIT);    sbi(GLED_PRT, GLED_BIT)

//------------------------------------
#define GLED(x)       (x ? (cbi(GLED_PRT, GLED_BIT)) : (sbi(GLED_PRT, GLED_BIT))) 

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

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

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

[aivhl]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

با سلام،

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

و رعایت سازگاری در پلتفرم های متفاوت کامپایلرها
برقراری سازگاری بین پلتفرم های مختلف سخت افزاری و کامپایلرها امری است دشوار ( اما محال نیست! ) که مستلزم آشنایی برنامه نویس با انواع سخت افزارها و کامپایلرهاست.
از اونجایی که این آشنایی کمی دور از دسترس هست، همفکری و همکاری تیمی متشکل از برنامه نویسان مسلط به انواع پلتفرم های سخت افزاری و کامپایلرهای مختلف بسیار راهگشا خواهد بود. ( البته اغلب این آشنایی در یک خانواده از سخت افزارها، مثلا مگاها و ایکس مگاها در AVR ها و کامپایلرهایی مثل WinAVR و IAR و CodeVision و Image-Craft با یکدیگر، کم و بیش وجود دارد )
اما شرط اول در تحقق این هدف، همونطوری که قبلا هم اشاره شد، دقت و کوشش در عدم اخطلات کدنویسی و موارد اختصاصی کامپایلر است ( حتی المقدور ).

بطور مثال، برنامه نویسی که با کامپایلر WinAVR کار میکنه روتین اینتراپتش اینطور میتونه باشه :

ISR(TIMER2_OVF_vect)
{
 .
 .
 .
} 

ولی همین روتین در کدویژن اینطوریه :

interrupt [TIM2_OVF] void tim2_ovf_isr(void)
{
 .
 .
 .
} 

برای رسیدن به این سازگاری، برنامه نویس اول میتونه کدهاش رو با چند تعریف و کمی تغییر، اینطوری اصلاح کنه تا برنامه نویس دوم هم با کمی تغییرات بتونه از کدهای اون استفاده کنه، اینطوری :

#define    ISR_AUP_INT()       ISR(TIMER2_OVF_vect)
.
.
.


ISR_AUP_INT()
{
 .
 .
 .
} 

و برنامه نویس دوم هم فقط با انجام این دو تعریف میتونه از اون کد بدون هیچ دستکاری اضافه ای استفاده کنه :

#define ISR(vec)         interrupt [vec] void isr##vec(void)
#define TIMER2_OVF_vect      TIM2_OVF 

و یک برنامه نویس با کامپایلر IAR هم میتونه به همین روش، با داشتن تعاریف زیر از این کدها استفاده کنه :

#define PRAGMA(x)         _Pragma( #x )
#define ISR(num)         PRAGMA(vector = num) __interrupt void isr_##num(void) 

سازگاری در بین برخی کامپایلر ها خیلی زیاده و نیاز به تغییرات اندکی داره، مثلا WinAVR و IAR و Keil و Image-Craft و در بعضی دیگر، این سازگاری کمتره ( و بعضا بسیار بعید! ) و نکته مهم دیگر، توجه به میزان سازگاری کامپایلر ها در ترجمه و تفصیر کد های اسمبلی نوشته شده در دستورات C است که در جای خودش بسیار حائز اهمیته!

خود من، برای برقراری این سازگاری بین کامپایلر های WinAVR و کدویژن ( و تا حدودی Keil-ARM ) از دو تا فایل زیر استفاده میکنم ( این دو فایل دائما در حال تغییر و تکمیل شدن هستند و گسترش و بهتر شدن اونها مستلزم همکاری سایرینی هست که در سایر پلتفرم ها کد نویسی میکنند ) :

http://s3.picofile.com/file/7839134943/app_config.h.html
http://s3.picofile.com/file/7839135478/CV_GNU_comp.h.html

استفاده از تعاریف یا همون define کردن، یکی از راهکارهایی است که کد نویسی شما رو منعطف، زیبا و قدرتمند خواهد کرد. پس سعی کنید، از این پدیده و سایر قابلیت های قدرتمند زبان C مثل تایپ ها، استراکچرها، یونیون ها، پوینترها و غیره بیشتر استفاده کنید .....

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

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

[رضا سپاس یار]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

سلام
یه موضوع دیگه که برای پرتابل شدن کتابخانه باید در نظر گرفت، نوشتن ماکرو برای دسترسی به حافظه Flash و EEPROM است که در کامپایلرهای مختلف تا حدودی با هم فرق می کنه.

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

کتابخونه ای که ایشون ارسال کردن در حقیقت دو تا مجموعه است، یک مجموعه در مورد تراشه AD7715 که این مجموعه در مبنای مجموعه ای دیگری مبتنی بر 4 کتابخونه عمومی و کلی دیگه نوشته شده که در فولدری به نام Utils ذخیره شدن. این چهار کتابخونه کاملا مستقل از افزاره انتخابی هست و به نظرم 2 هدف اصلی رو دنبال میکنن

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

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

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

با سپاس فراوان از همکاری تک تک دوستان

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

سلام.
آقای مهندس نوربخش امروز لطف کردن و تماس تلفنی با هم داشتیم. توضیحاتی رو در خصوص کتابخونه به من دادن که خلاصه اش به صورت زیر هست:
در فایل app_config تنظیمات و توابع معادل برای کامپایلرهای مختلف وجود داره. در این هدرفایل که تقریبا تماما تعاریف هست و تنظیمات و تفاوت هایی بین کامپایلرهای مختلف هست در نظر گرفته شده و با هم تطبیق داده شده. البته این هدر فایل با اقتضای پروژه های مختلف و موارد گوناگون میتونه مداوم موارد بیشتری بهش اضافه بشه.
در فایل CV_GNU_comp.h تعاریفی جهت هماهنگ شدن بردار های وقفه و یکسان سازی تعریف توابع وقفه در کامپایلرهای مختلف تعریف شده. و در ادامه اون تعاریف کدهای ارتباطی پروتکل I2C اومده که اینها همه به فراخور نیاز هست و باید به مرور تکمیل بشه.

در فایل PP_Utils تعاریف مختلف پورت های میکروها در کامپایلرهای مختلف هست. البته برخی عملیات های پرکاربرد بر روی بیت ها و بایت های پورتها هم با کمک تعاریف انجام شده در فایل SHN_utils تعریف شدن.

در فایل SHN_utils تعریف متغیر های مورد نیاز و پرکاربرد، عملیات های بیتی و بایتی و ... تعریف شدن.

بنده پیشنهادی به آقای نوربخش دادم که البته به نظر ایشون تفاوت چندانی با روش کنونی نداره.
پیشنهاد بنده این هست ما یه ادبیات مخصوص برای کتابخونه ها داشته باشیم مثلا فرض کنید برای کار با پورت یه قرار داد داشته باشیم که سینتکس به صورت زیر باشه
PD_DDR
این به معنی رجیستر DDR در پورت D هست. حالا کامپایلرهای مختلف یا میکروهای مختلف باید تطبیق داده بشن.
تا اینجا همین کاری هست که جناب نوربخش انجام دادن.
در ادامه به نظر بنده تنظیمات کامپایلرها رو از هم تفکیک کنیم. یعنی توی یک فایل نباشن. برای هر کامپایلری یه فایل جداگانه داشته باشیم. و نوع کامپایلر در هدر فایل کتابخونه تعیین بشه و با توجه به نوع کامپایلر هدرفایل متناسب با اون به برنامه اضافه بشه.
بنا هم بذاریم برای 5 تا کامپایلر مثلا
IAR
Codevision
Keil
AVRStudio
WINAVR
---
از طرف دیگه برای واسط های ارتباطی مثلا SPI و ... هم باز نیاز به کتابخونه خواهیم داشت. واسط هایی مثل SPI یا بقیه استاندارد هستن و به نظرم توی تمامی میکرو کنترلرها تنظیمات یکسانی دارن فقط اسم رجیستر ها و آدرس ها در میکرو هایی مختلف متفاوت هست. (به نظرم تقریبا هیچ وابستگی ای به کامپایلر ندارن به جز در تعریف وقفه) حالا برای این ماژول ها هم کتابخونه مجزا داشته باشیم. برخی از این ماژول ها باید متناسب با نوع میکرو تنظیم بشن مثلا تایمر ها و تعدادشون و امکاناتشون وابستگی زیادی نسبت به نوع میکرو دارن.
در هر صورت ساختاری که به ذهنم رسید به صورت شکل زیر هست:

چیزی که واضح هست اینه که پیاده سازی این کتابخونه اون هم در شروع کار بسیار زمان بر و شاید عملا غیر ممکن باشه چون این ساختار باید به مرور تکمیل بشه.
دوستان نظرشون رو در مورد این ساختار بدن. اگه موافق هستید ادبیات کدنویسی رو هم نزدیک به نرم افزارهای رایگان مثل AVR Studio یا WINAVR در نظر بگیرید چون رایگان هستن احتمالا کتابخونه های منطبق با اونها زیادتر هست و سریع تر میتونیم اونها با استاندارد سایت تطبیق بدیم.
منتظر نظرات سازنده دوستان هستیم.

[aivhl]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

با سلام،

اگر اجازه بدید، میخوام نکته ای رو اضافه کنم.

به نظر من انجام این امر مهم باید به دو بخش مجزا و اصلی تقسیم بشه، بخش اول کامپایلرهای مختلف و بخش دوم میکروهای مختلف.
این یعنی اینکه در تطبیق کتابخونه نمونه، در قدم اول فرض بر این باشه که همه ما قراره که مثلا با میکروی ATmega32 از این کتابخونه استفاده کنیم، ولی با کامپایلرهای مختلف. و در قدم دوم، با فرض استفاه از یک کامپایلر مشترک، مثلا WinAVR ولی میکروهای مختلف. و در ادامه ماجرا، تطبیق در کامپایلرها و میکروهای مختلف بطور همزمان به خودی خود اتفاق خواهد افتاد!

یادآوری :

1 - رجیسترها در میکروهای سری قدیمی AVR مثل ATmega ها و ATtiny ها تقریبا مشابه بوده و از یک الگو پیروی میکنند. سری های Xmega و سری های ARM و PIC هم هر کدام از الگوی خاص خودشان پیروی میکنند.

2 - کامپایلرهای مختلف، با استفاده از هدر فایل های خاص خود، نسبت به تعریف و نامگذاری رجیسترهای هر خانواده از میکروها اقدام مینمایند.

3 - اصول و روش های استفاده از رجیسترها، تنظیمات سخت افزاری و استفاده از امکانات میکروها در تمامی کامپایلرها یکسان و وابسته به الگوی خانوادگی میکروی مورد استفاده است. در این راستا، کامپایلرهای مختلف با ارائه هدر فایل های کمکی و جانبی، امکاناتی [نظیر ماکروها، فانکشن ها، تعاریف و ...] را جهت سهولت در استفاده از آنها فراهم میکنند که بعضا قابل انتقال و استفاده در سایر کامپایلرها هم هستند. بطور مثال، شرکت اتمل برای میکروهای سری ARM خود هدر فایل هایی را نوشته که در دسترس برنامه نویسان قرار میدهد و این هدر فایل ها قابل استفاده در تمامی کامپایلرها هستند.

درک بهتر مطالب فوق، با تجسم مثالی برای صفر و یک کردن یک پین میکرو در میکروهای خاص با استفاده از کامپایلرهای مختلف و میکروهای مختلف با یک کامپایلر خاص و ترکیب این دو ، میسر خواهد بود.

[طراح]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

نوشتن کتابخانه ها بصورتی که برای میکروکنترلرهای مختلف قابل استفاده باشد، در شرایطی مفید است که لازم نباشد برای بهینه شدن عملکرد کتابخانه، از امکانات خاص یک میکروکنترلر استفاده شود. اگر سخت افزارهای لازم در نوشتن یک کتابخانه، فقط مبتنی بر استفاده از پین های ورودی و خروجی و دسترسی به حافظه های sram و flash و eeprom و یکسری سخت افزارهای متداول مانند usart و spi و timer و مانند آن باشد، می توان کتابخانه هایی نوشت که برای بسیاری از میکروکنترلرها قابل استفاده باشد و این امر مطلوبی است. اما در مواقعی هم برای نوشتن یک کتابخانه بهینه لازم است از امکانات خاص تر یک میکروکنترلر استفاده شود که ممکن است به نوعی مختص آن خانواده باشد و نمی توان عملکرد آن را برای خانواده دیگری از میکروکنترلرها تسری داد. مثلا در سری XMEGA قابلیتی با عنوان Event System وجود دارد که مطابق آن می توان بخش های مختلف سخت افزار را به هم متصل نمود و از خروجی یک بخش به عنوان تریگر یک بخش دیگر (بدون نیاز به اجرای کد) استفاده کرد. حال اگر بخواهیم کتابخانه ای را برای XMEGA بنویسیم که به دلیل عدم وجود چنین قابلیتی در بقیه میکروکنترلرها، اصولا از Event system (در جایی که لازم است) استفاده نکنیم، در این شرایط بهینه بودن این کتابخانه برای این خانواده خاص زیر سوال می رود و این رویکرد کتابخانه نویسی با هدف استفاده عمومی برای سایر میکروکنترلرها، باعث نوشتن کتابخانه ای خواهد شد که با حداکثر امکانات سخت افزاری خانواده هدف مطابقت ندارد. یا مثال دیگر از امکانات سخت افزاری، وجود DMA در برخی خانواده ها و عدم وجود آن در سایر میکروکنترلرها است که روال سنتی کتابخانه نویسی بصورت عمومی را با چالش جدی مواجه می کند و در بسیاری مواقع نمی توان با فرض استفاده از DMA کدی را نوشت که در شرایط عدم وجود آن هم قابل اجرا باشد.
اگر بتوان کتابخانه ای را با تکیه بر امکانات خاص یک میکروکنترلر بصورت بهینه تر نوشت، لازم نیست این کتابخانه برای سایر میکروکنترلرها هم (به دلیل عدم وجود آن امکان سخت افزاری خاص) قابل استفاده باشد. بنابراین کتابخانه نویسی با فرض استفاده مشترک برای همه میکروکنترلرها، همیشه هم رویکرد مطلوبی نیست و در مواردی باعث محدود کردن استفاده از امکانات سخت افزاری در چارچوب یکسری سخت افزارهای سنتی می شود که بصورت مشترک در تمام خانواده های هدف وجود دارد.

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

پیشنهاد من این هست که کتابخونه برای خانواده های مختلف میکرو کنترلر ها به صورت مجزا تعریف بشه. مثلا در کتابخونه AD7715 که داریم روش بحث میکنیم، یه کتابخونه برای خانواده XMEGA ، یکی برا AVR و ... پورت بشه و به نظرم نیازی به تجمیع اینها نیست. ولی از طرفی قابلیت ها و ابزارهای مشترک بین میکرو کنترلر ها رو براش تعاریف مشخص داشته باشیم که شاکله ادبیات برنامه نویسی سایت رو تشکیل میده، مثلا نحوه کار با PORT ها که در اغلب میکروکنترلر ها دارای یک ساختار هست یا مثلا واسط SPI . که اینها رو هم به مرور و با توجه به نیاز باید تعریف کنیم و پیش بریم. در مورد تطبیق بین کامپایلر ها چون خودم با 2 تاشون بیشتر کار نکردم تسلط کافی روش ندارم. به نظرتون میشه هدرفایلی داشته باشیم که تطبیق کامل بین کامپایلرها رو برامون ایجاد کنه؟ آیا بهتره اینکار رو بکنیم یا اینکه کتابخونه رو برای کامپایلرهای مختلف پورت کنیم؟
من سعی میکنم با توجه به کتابخونه ای که جناب نوربخش آماده کردن یه کتابخونه رو بر مبنای میکروی مشخص و ترجیحا مستقل از نوع کامپایلر آماده کنم.

[طراح]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

آیا بهتره اینکار رو بکنیم یا اینکه کتابخونه رو برای کامپایلرهای مختلف پورت کنیم؟

اگر قرار باشد مثلا کامپایلری مانند کدویژن را مثلا با IAR هماهنگ کنیم، به دلیل وجود اختلاف در توانایی های دو کامپایلر به نظرم کار چندان مفیدی نیست. به عنوان یک مثال فرض کنیم قرار است از یک متغیر 64 بیتی از نوع long long در برنامه استفاده کنیم. در این شرایط عدم پشتیبانی از چنین متغیری در کدویژن (مطابق تصریح help آن) می تواند راه را بر استفاده از آن در IAR در جایی که لازم است، ببندد. یا به عنوان یک مثال دیگر، دستور ساده زیر را (شامل تعریف نوع متغیر در متن for) اگر در کدویژن بنویسیم خطا می دهد. اما در IAR امکان چنین تعاریفی وجود دارد:

for(unsigned char a=1;a<n;a++)

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

[محمد نحوی]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

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

[RubeuS]

پاسخ : روش های اصولی و صحیح در نوشتن کتابخانه

سلام .
من تازه این تاپیک را دیدم .

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