حتما برای شما هم پیش آمده که در پروژه ای به دلایل زیادی از قبیل کم بود حافظه فلش ، کمبود حافظه رم ، سرعت پایین و… مجبور شده اید میکروکنترلر را عوض کنید و زحمت برنامه نویسی مجدد را به جان بخرید در این موارد معمولا تمام کاسه کوزه ها سر میکروکنترلر شکسته می شود و محدودیت های آن مورد سرزنش و شماتت قرار می گیرد! در صورتی که همیشه اینچنین نیست. در اغلب اوقات با تغییرات جزیی در مدار یا سبک برنامه نویسی به راحتی میتوان مشکلات پیش رو حل کرد ؛
متاسفانه خیلی از دوستان و همکاران گرامی به این موضوع اشراف ندارند و به اشتباه میکروکنترلر را مقصر می دانند؛ به عنوان مثال خیلی از دوستان ، میکروکنترلر AVR را یک میکروکنترلر صنعتی نمی دانند ، در عوض میکروکنترلر PIC یا ARM را صنعتی می دانند، برای شخصی که تجربه کافی در خصوص طراحی مدارات دیجیتال و صنعتی داشته باشد ، این استدلال نه تنها بی پایه و اساس است بلکه خنده دار هم خواهد بود؛ محدودیت ها و باید و نباید های هر پردازنده ای در منوال آن ذکر شده است ، با رعایت این نکات و البته طراحی صحیح هر میکروکنترلری را می توان در هر جایی که مورد نیاز باشد استفاد کرد، البته منکر این مهم نیستم که برخی میکروکنترلر ها برای مقاصد خاصی طراحی و تولید می شوند. چه مدارات صنعتی که بر پایه همین میکروکنترلر AVR طراحی شده اند ؛ مهم نکاتی است که باید در طراحی لحاظ کرد. در این مقاله قصد داریم نشان دهیم که چقدر مدل برنامه نویسی می تواند در عملکرد یک میکروکنترلر دخیل باشد و در خیلی از هزینه ها صرفه جویی کنید پس با سیسوگ همراه باشد.
معرفی میکروکنترلر و نحوه آزمایش سبک برنامه نویسی
در این تست از میکروکنترلر ATMEGA328 در فرکانس 16 مگاهرتز (برد آردوینو البته از Gcc برای کامپایل کد استفاده خواهیم کرد نه ابزار آردوینو) استفاده خواهیم کرد و با اتصال یک عدد LCD رنگی به صورت سریال راه اندازی میشود قصد داریم سرعت رسم فریم های تصویر را اندازه گیری کنیم. برای این کار مدت زمان رسم ده فریم از تصویر را اندازه گیری میکنیم و نمایش می‌دهیم. LCD مذکور از انتقال 9 بیت سریال برای رسم تصویر استفاده می کند و واحد SPI موجود در میکروکنترلر نهایتا در حالت 8 بیتی کار می کند و نمی توانیم از آن استفاده کنیم پس این قسمت از برنامه را مجبوریم که با کدنویسی پیاده سازی کنیم. در ادامه بررسی خواهیم کرد که مدل های برنامه نویسی چه تاثیری در سرعت اجرای آن خواهند داشت.
برنامه اول ، برنامه‌ای که همه می نویسند
برای نوشتن برنامه ای که 9 بیت را به صورت سریال انتقال دهد یکی از مرسوم ترین راه ها استفاده از حلقه for می باشد. در اولین قدم ما نیز برنامه را به روش رایج می نویسیم:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | void LcdSend(uint16_t data) { cs_clr(); for(uint16_t i=0;i<9;i++) { if(data & 1<<(8-i)) sda_set(); else sda_clr(); clk_set(); clk_clr(); } cs_set(); } |
همانطور که می بینید ابتدا پایه CS را صفر میکنیم ، بعد با استفاده از حلقه For 9 بیت داده را انتقال می دهیم و سپس پایه CS را یک میکنیم!
مساله ای که برای ما حائز اهمیت است ، سرعت اجرای این کد است ، فرض کنید قصد داریم تصویر متحرکی را روی صفحه نمایش دهیم ، اگر سرعت رفرش شدن صفحه از حدی بیشتر شود ، اصلا امکان چنین کاری نیست ، با اجرای این کد خروجی زیر را خواهیم داشت
همانطور که در تصویر مشخص است ، اجرای ده فریم از تصویر (یعنی ده بار پر کردن صفحه) زمانی حدود 20465 میلی ثانیه نیاز داشته است ، به عبارتی هر بار پر کردن صفحه دوثانیه طول می کشد. در این مرحله عده ای نا امید می شوند و تقصیر را به گردن میکروکنترلر می اندازند و سراغ میکروکترلر قوی تری میروند ! اگر دید درستی به سخت افزار و نرم افزار داشته باشیم به سادگی میشه حدس زد که مشکل از کجاست و چطور میشه حلش کرد!
در این مثال بگذارید اول بررسی کنیم ، برای پر کردن صفحه از رنگی خاص چقدر زمان CPU صرف میشه ، صفحه نمایشگر ما 160 در 120 است یعنی 19200 پیکسل باید دیتا دریافت کنند ، برای پر کردن هر پیکسل نیازه که دوبار این تابع قراخوانی بشه ، میشه در واقع 38400 بار باید این تابع رو فراخوانی کنیم ! حالا چطور میتونیم برنامه رو بهینه تر کنیم ، داخل for رو نگاه کنید ! با توجه به این که دستورات درون for با هربار اجرای تابع 9 مرتبه اجرا می شوند ، برای پر کردن صفحه لازمه
345600 بار اجرا شوند. یعنی صرفه جویی در یک سیکل ماشین درون روتین حلقه ، به تعداد 345600 سیکل ما را سریعتر می کند ، با توجه به فرکانس کاری 16 مگ ، هر سیکل صرفه جویی ، معادل 21.6 میلی ثانیه خواهد بود! پس اصلا دست کم نگیریدش ! اما چطور میشه برنامه رو بهینه تر نوشت ؟
برنامه دوم ، برنامه‌ای که بعد از تفکر می نویسید
بعد از کمی فکر کردن در خصوص این که چطور میتونید برنامه رو بهینه کنید ، با مقداری هوش – برنامه رو این چنین خواهید نوشت :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | void LcdSend(uint16_t data) { static uint16_t ShiftBit[] = {0x100,0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01}; cs_clr(); for(uint16_t i=0;i<9;i++) { if(data & ShiftBit[i])) sda_set(); else sda_clr(); clk_set(); clk_clr(); } cs_set(); } |
اما چه تغییری کرد برنامه ؟ ، در واقع فرایند مقایسه را بهینه کردیم ، در برنامه قبل عملیات مقایسه به صورت زیر بود
1 | if(data & 1<<(8-i)) |
در خط فوق برای هر بیت ، اول 8 را از متغیر i کم می کردیم ، بعد عدد 1 به تعداد حاصل شیفت می دادیم به سمت چپ و بعد با مقدار data اند می کردیم و بر اساس آن خروجی را تنظیم می کردیم ! این فرایند ها را برای پر کردن صفحه 345600 بار تکرار می کردیم ! اگر بتوانید این فرایند را حذف کنیم ، قطعا تعداد سیکل خیلی زیادی صرفه جویی میکنیم. اما چطور ؟ خیلی ساده است با تعریف یک جدول مقایسه (lookup table) !
1 | static uint16_t ShiftBit[] = {0x100,0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01}; |
یعنی حاصل عبارتی را میکروکنترلر باید یک بار تفریق و یک بار شیفت را برایش انجام میداد صورت دستی محاسبه کنیم و در یک آرایه ذخیره کنیم ، و در شرط مقدار مورد نظر را از آن استخراج کنیم ، اما ببینم این کار تا چه اندازه اثر بخش خواهد بود ؟
بله ، همین کار ساده سرعت اجرای برنامه را تقریبا 2 برابر افزایش داد ؛ یعنی برای رسم هر فریم نیاز به 1 ثانیه زمان بیشتر نخواهید داشت ! اما آیا باز میشود کد را بهینه تر نوشت ؟
برنامه سوم ، برنامه‌ای که با خلاقیت و شناخت سخت افزار می نویسید
در برنامه قبلی با استفاده از یک تکنیک ساده سرعت اجرای برنامه دو برابر شد ، اما آیا راه دیگری هست که باز هم بشود برنامه را بهینه کرد ؟، اینجاست که دید شما نسبت به سخت افزار و آشنایی با معماری پردازنده به کمک شما میآد ، بیایید نگاهی به کد اسمبلی تولید شده بیندازیم
اگر دقت کنید در خط 624 و 625 دو دستور اسمبلی داریم با نام های LD ، کار این دستور ها لود کردن مقداری است که Z به اون اشاره میکنه (انتخاب اینکدس مورد نظر از آرایه تعریف شده ShiftBit) ، مطابق اونچه داخل دیتاشیت AVR موجوده هر کدام از این دستورات به 2 سیکل ماشین نیاز داره ، دستور brne که هم برای پیاده سازی if استفاده شده هم برای پیاده سازی for ، اجراش نیاز به 1 یا 2(در صورتی که پرش انجام بشه) سیکل ماشین داره ، خود پیاده سازی حلقه هم نیاز به cpc و cpi داره که هر کدوم یک سیکل ماشین رو مصرف می‌کنن !
با توصیفات بالا مشخص میشه که حذف حلقه و انتخاب از ایندکس آرایه خیلی در سیکل های ماشین مصرف شده صرفه جویی خواهد کرد ، پس برنامه را به شکل زیر تغییر می دهیم
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 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 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(); } |
بله یا یک روش ساده و حذف حلقه ؛ برنامه به شکل فوق در خواهد آمد !
همانطور که میبیتید با این تغییر سرعت اجرا باز دوبرابر شد یعنی رسم هر فریم تصویر تقریبا 550 میلی ثانیه زمان خواهد برد و این یعنی چهار برابر سریعتر از برنامه اول !
می بینید که به سادگی و فقط یا تغییر در مدل کد نویسی می توان نتیجه خیلی بهتری را از سخت افزار مورد نظر گرفت ، تاجایی که دیگر لازم به تغییر میکروکنترلر نباشد!
مقایسه سرعت بروزرسانی تصویر
چالش برنامه نویسی آخر
خوب تا اینجا دیدیم که چقدر نحوه برنامه نویسی میتونه توی نتیحه خروجی(حداقل در این مورد خاص سرعت) تاثیر گذار باشه ! به عنوان چالش برای شما ، همین برنامه را با همین ساختار باز بهینه کردم ، ولی این باز شما حدس بزنید به چطور میشه این کار رو انجام داد.
سلام من با استفاده از تعریف ساختار بیتی و دسترسی به بیت‌های پورتهای میکروکنترلر ارتباط spi رو انجام دادم
مثلاً برای ارسال بیت 4 بایت ارسالی روی پین mosi به ابن صورت عمل میکنیم
PA -> b2 = (data & 0x08)>>3 // mosi
PA -> b3 = 1
PA -> b3 = 0 // clock
مطلب عالی بود. کلی استفاده کردم.ممنون!
خواهش میکنم
سلام مهندس ممکن برنامه اول رو به صورت کامل توضیح بدین و کد کاملش رو. من مبتدیم اگر میشه بفرمایید چطور داره 8 بیت شیفت میده و ارسال می کنه و چطور پیکسل ها مقدار می گیرن. من حس میکنم فقط یک قسمت از کد را اینجا قرار دادین. ممنون
سلام روز شما بخیر
بله البته حق با شماست اینجا به تاثیر برنامه نوشته شده بر روی سرعت اجارای آن میپردازیم
اگه سورس کامل این کتایخانه رو بخواید میتوانید به مطلب
راه اندازی LCD گرافیکی Nokia 1661 و دانلود کتابخانه آن مراجعه کنید 🙂
#define NST_BYTE(x, n) ((uint8_t * ) & x)[n]
void LcdSend(uint16_t data)
{
static uint8_t ShiftBit[] = {0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01};
cs_clr();
if(NST_BYTE(data, 1) & ShiftBit[0])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[0])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[1])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[2])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[3])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[4])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[5])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[6])) sda_set(); else sda_clr();clk_set();clk_clr();
if(NST_BYTE(data, 0) & ShiftBit[7])) sda_set(); else sda_clr();clk_set();clk_clr();
cs_set();
}
البته شیفت اول باید اندیس 7 داشته باشد که اشتباها 0 تایپ شد
روش جالبی استفاده کردید – باید کد اسمبلیش رو ببینم چقدر تفاوت داره 🙂
متشکر
با سلام
یه سوالی که داشتم اینه که آیا میشه با آردوینو چیزی حدود 250 تا 400khz دیتا برداشت کرد؟ منظورم اینه که به صورت واقعی نه آن چیزی که در دیتا شیت آردوینو هست.
بله میشه
ولی ممکنه از رابط سریال نه ولی به شکل پارالل که حتما میشه
سلام
مطلبی که نوشتید خیلی خوب و مفید بود
فقط نکته ای که در مورد نویز و avr و … گفتید
ببینید، درسته که با طراحی درست و اصولی میشه از avr در محیط صنعتی هم استفاده کرد اما مسئله این نیست، مشکل اینجاست که طراحی اصولی هزینه داره، هم هزینه زمانی و هم هزینه قطعات بیشتر، حتی در موارد تغذیه جدای میکرو از بخش های دیگه
و این تو تولید انبوه خیلی خیلی مهمه وگرنه برای نمونه سازی و تولید کم و یک پروژه خاص اصلا اهمیتی نداره
ولی با توجه به اینکه تو تولید انبوه بهتره چیزی استفاده کنیم که هزینه های جانبی رو دستمون نزاره و تو پروژه های غیر انبوه هم هزینه چندان اهمیتی نداره پس بهتره میکروی بهتر و مقاومتر انتخاب بشه و کلا اساس کارمون رو بر همون مبنا بزاریم
سلام دوست عزیز
فکر میکنم هزینه تمام شده میکروکنترلر avr با در نظر گرفتن هزینه های لازم برای مقاوم سازی از pic کمتر باشه – البته خیلی وقته که خرید نکردم و ممکنه معادلات بهم ریخته باشه که من اطلاعی ندارم ازش
البته من همچین فکری نمیکنم،pic میکروهای ارزون قیمت تا گرون قیمت داره
ولی فرضا حتی اگر چنین چیزی هم باشه و شما تمام موارد رو برای avr رعایت کنید باز هم از لحاظ مقاوم سازی در برابر نویز و … مشابه pic نمیشه، حتی arm هم مشابه pic نیست
در یک پروژه موشکی که بنا به شرایط مدار با سرعت بسیار زیاد دور خودش می‌چرخید هم این مورد تست شده و هیچ میکرویی غیر از pic نتونست شرایط سخت رو تحمل کنه
ضمنا هر که طاووس خواهد جور هندوستان کشد، حتی اگر هزینه بیشتر بشه، وقتی کیفیت بالاتر بخوایم مقداری هزینه بیشتر هم منعی نداره هر چند که در اکثر موارد اینطور هم نیست
حالا فرض کنید تغذیه جدا هم برای avr نیازه باشه، حجم مدار و … !
من حساسیت خاصی روی مدل میکروکنترلر ندارم ولی این چیزی هم که شما میگید درست نیست !
الان خیلی از دیوایس های خاص و فلان و بهمان دارن از پردازنده های مدرن مثل avr و arm استفاده می کنند مثال هم تا دلتون بخواد زیاد هست و به سادگی یه سرچ توی اینترنت میتونید پیدا کنید مثال هاشو
یعنی نظرتون اینه که میکرو pic مدرن نیست یا قدیمیه !!!
اگر اینطوره که بفرمایید دیگه ادامه ندیم اصلا !
ولی اگر منظورتون این نبوده مسئله کلی اینه
وقتی بستر مناسبتر، قابل اعتمادتر، سابقه دار تر و در مواردی حتی هم قیمت و قیمت پایین تر برای کاری وجود داره اصلا چرا باید سراغ مورد ضعیفتر رفت !!! فقط صرف اینکه تو دانشگاه اونو به ما یاد دادن یا تو ایران بیشتر تو بورسه !
اونم avr ای که شرکت تولید کنندش یعنی اتمل توسط همین میکروچیپ چند ساله خریداری شده و زیر مجموعه اونه
البته منظور بین avr و pic بود نه arm، چون آرم های دیگه رو باید با آرم های microchip مقایسه کرد نه با pic هاش
نه دوست عزیز من مدرن رو در معنای دیگری به کار بردم – الان میکروکنترلرهایی از خانواده pic طراحی شدن که اخیرا طراحی شدن و منطقا تکنولوژی های روز درشون استفاده شده
تا حالا فکر کردید چرا gcc که یه کامپایلر متن باز هست از سخت افزار avr پشتیبانی میکنه از سخت افزار arm پشتیبانی میکنه ولی از pic یا 8051 یا stm8 این پشتیبانی رو نداره ؟ بخاطر معماری سخت افزاری انجام شده است ! من به این میگم مدرن – یعنی طراحی سخت افزار جوی هست که اجازه میده کامپایلر با معماری مدرن و پشتیبانی از استاندارد های به روز جهانی براش کد جنریت کنن.
بله درسته pic کامپایلر خودش رو داره که سی رو پشتیبانی میکنه و خوب هم کار میکنه اما استانداردهای متفاوتی دارند. اینا همه ابزارهایی هستند در دستان ما بهتره تعصبی روی ابزار نداشته باشم تازه اونم چیزی که خودمون طراحی و تولیدش نکردیم. بهتر ابزار ها رو بهتر بشناسیم و در جای درست ازشون استفاده کنیم.
لیست سخت افزارهایی که توسط جی سی سی پشتیبانی میشوند در لینک زیر ببینید
http://gcc.gnu.org/backends.html
الان این که gcc پشتیبانی میکنه یا نه چه ارتباطی به مقایسه pic, avr داشت
مثلا شما PLC هم بخوای کار کنی خب محیط کاری خودشو داره که در بعضی مواقع یه چیزی شبیه Fritzing رو یاد آدم میندازه اما این دلیل میشه که بگیم PLC مدرن نیست چون مثلا مستقیما با gcc کار نمیکنه یا مثل بچه ها توش نقاشی میکشی و اون برات انجام میده ؟!!!
بله منم تعصبی روی ابزار ندارم ولی شما هر کاری هم که انجام بدی نمیتونی استفاده از پراید (avr) رو بجای بنز (pic) توجیه کنی یا مثلا دلیل بیاری که با کیسه گونی (avr) هم میشه لباس دوخت و استفاده کرد و فرق زیادی با پارچه ابریشمی (pic) نداره !
مگر در مورد چیزی مثل قیمت پایین پراید که خب این موضوع در مورد میکروها زیاد موضوعیت نداره چون در خیلی موارد از نظر قیمتی اختلاف چندانی ندارند
اون چیزی که شما داری میگی در مواردیه که از نظر کیفیت و امکانات تقریبا در یک سطح باشن مثلا مقایسه بنز و بی ام و یا AMD, INTEL یا استقلال و پیروزی یا … نه چیزی مثل avr و pic
من فکر میکنم بیشترین دلیل مقاومت کسانی که avr کار می‌کنن اینه که یا تو دانشگاه بهشون تدریس شده یا به صورت گله ای و بر طبق تئوری بز (اسم یک تئوری روانشناسی هستش) دیدن همه دنبال یه چیزی بودن و یه چیزی رو گفتن و اونام همون راه رو رفتن چون همه رفتن و …
و حالا سختشونه بخوان سوئیچ کنن روی چیزی دیگه (تغییر کلا دردناکه ولی مفید)
شایدم احساس بدی بهشون دست میده از اینکه اشتباه رفتن راه رو
در صورتیکه واقعا اینطور نیست، علم الکترونیک که جای خودشه، برنامه نویسی هم که اکثرا از زبان سی استفاده میشه، قوانین میکروها هم که 90 تا 95 درصد مشابه هم هستش بنابراین برای سوئیچ اصلا نیاز به انجام کار سخت و بزرگی نیست و تمام تجربیات قبلیشون روی avr اینجا هم کاملا کاربرد داره براشون، فقط یه سخت افزار اولیه تغییر کرده، بماند که کار با میکرو pic به نظر من راحت تر از avr هم هست چون نیاز به رعایت دستورالعملهای خاص که یه موقع میکرو بدش بیاد و قهر کنه کار نکنه هم نداره !
خیلی ربط داره – بیشتر از اونچه بتونید تصور کنید ربط داره، اگر سعی کرده باشید یک کتابخانه استاندارد مثلا c11 رو که استانداردهای c11 داره توی کدی که برای pic نوشته اید استفاده کنید اون موقع متوجه منظور من میشید. (کامپایلر xc8 تازه استاندارد c99 رو داره پشتیبانی میکنه که خیلی خوبه البته)
ما داریم در مورد میکروکنترلر حرف میزنیم و البته برنامه نویسی برای یک سخت افزار نه استفاده از plc و سینتکس محدود اون. برنامه نویسی به زبان c یک سری استاندارد مشخص داره که به سادگی میتونید اونا رو توی وب جستجو کنید و جزییات هر کدوم رو ببینید. بله طراحی pic مدرن نیست دوست من – تعصب چرا، مدرن نیست چون خیلی قبل تر از avr طراحی شده همین به سادگی ثابت میکنه چقدر عقب تر از طراحی avr است. قطعا در زمان pic دانش یه چیزی بوده و در زمان طراحی avr چیز دیگه ای بوده جای بحث نداره!!
من فکر میکنم دلیل این که دوستان بیشتر از avr و امثالهم استفاده میکنند جدایی از بخش قیمت منابعی هست که این مدل میکروکنترلرها در اختیارشون میذاره – میزان رم – فلش – پرفرال ها و …. شما برید نگاه کنید زمانی که avr عرضه شده pic چه میکروهایی با چه قیمت هایی و چه مشخصاتی داشت.
+ بر خلاف چیزی که فکر میکنید عموم بیشتر به دنبال تغییر هستند ولی تغییر مثبت نه منفی همین الان نگاه کنید چقدر استفاده از میکروکنترلر arm عمومیت پیدا کرده !
اینکه اینقدر روی مثلا gcc تاکید دارید نقض حرف خودتون در این مقاله و مقاله دیگری هست که گفتید ابزار زیاد اهمیت نداره ولی الان دارید از اهمیت ابزار حرف میزنید
مورد دوم اینکه باید دید پریفرال ها به چه قیمتی در اختیارتون گذاشته میشه
یه زمانی ابزاری مثل دریل قیمت بالایی داشت و اکثرا دریل های بوش بودن و هر کسی توان خریدش رو نداشت تا اینکه به لطف برادران چینی دریل هایی تو بازار اومد که اگر مثلا دریل بوش آلمان 120 هزار تومان بود اون چینی ها رو خود ما 5 هزار تومن خریدیم !!!
اتفاقا از لحاظ امکانات از دریل بوش هم بیشتر امکانات داشت از جمله حالت چکشی و خط‌کش و …، ولی در عمل مجبور شدیم آخر بندازیمش دور چون کارایی نداشت، قدرت درستی نداشت، درست کارش رو انجام نمیداد، دود میکرد و …
پس همیشه داشتن اعداد زیاد در امکانات و پریفرال ها مهم نیست، مهم اینه که امکاناتی که گفته میشه کارش رو هم به خوبی انجام بده، همین الان موبایل با دوربین 40 مگاپیکسل هم هست و البته 100 مگاپیکسل هم اومده ولی کیفیت عکسش اصلا در حد مقایسه با یه دوربین DSLR ده مگاپیکسلی هم نیست
اینکه avr مثلا حافظه بیشتر ارائه کنه یا … مهم نیست وقتی تا بهش بگی نون از گندم مثلا دیتاهای eeprom پاک بشه یا با یه مقدار نویز محیط میکرو هنگ و ریست کنه و نیاز باشه برای رفعش هزار جور ترفند زد و هزینه کرد، مثل یه آدم نازک نارنجی که تا یه باد بهش بخوره سرما میخوره، دقت کنید که این خطاها رو میشه با طراحی سخت افزاری و برنامه‌نویسی رفع کرد اما اینکار هزینه داره هم هزینه زمانی هم هزینه قطعات اضافی احتمالی و وقتی میکرویی مثل pic هستش که نیاز به این هزینه های پنهان نداره دلیلی برای استفاده کردن از avr وجود نداره
در مدارات کاربردی مهم استخون دار بودن و قوی بودن و کار کن بودن مداره و اینکه قابلیت اطمینان بالایی داشته باشه، حالا اگر بخواد جای حساسی هم استفاده بشه که این موضوع خیلی مهمتر میشه وگرنه در موارد آموزشی خیلی مهم نیست نوع میکرو چی باشه، اصلا شما با همون آردوینو کار کنی خیلی هم راحت و سریعه
در مورد اینکه گفتید الان دنبال arm هستن هم یکی از دلایلش همین مشکلات avr هستش که تو پروژه ها اذیتشون کرده و دیگه مجبور شدن سوئیچ کنن و دلیل بعدی امکانات و سرعت و پریفرال های بیشتر آرم ها، که البته همونم اگر به سمت آرم های میکروچیپ برن باز بهتره تا آرم های دیگه
چیز ابزاری بهتر از gcc معرفی کنید – مطمین باشید بدون بحث ازش استفاده خواهم کرد 🙂 استفاده از ابزار بهتر نیاز به بحث نداره
من خودم زیاد با میکروکنترلر pic سر و کله نزدم – خیلی دوست دارم زحمت بکشید و مقاله ای در خصوص معرفی و حتی مقایسه اون با دیگر میکروکنترلرهای موجود بنویسید و مطمین باشید ما توی سیسوگ خوشحال میشیم که منتشرش کنم
امیدوارم که وقت بگذارید مقاله رو بنویسید 🙂
من همه‌ی نظرات را خوندم و خواستم شخصا نظرم را در این مورد بگم. و سعی میکنم آن چیزی که باهاش مواجه شدم و از طرفداران و مخالفان نقل شده را بگم.
خب طرفداران AVR می‌گن که این میکرو هیچ مشکلی نداره و مثل خیلی از میکروهای دیگه داره کار خودشو به خوبی انجام میده.
مخالفان AVR هم می‌گن ای بابا این میکرو دیگه چیه همش نویز می‌گیره جرات نداری کنارش راه بری یا برای رفع ایراداتش مجبوری هزارتا چیز جانبی بزاری کنارش تا اوکی بشه.
خب بزارید کمی دقیق‌تر شرحش بدم.
من به شخصه از تعدادی از طرفدارن AVR که در صنعت مشغول هستن و دستگاه‌هایی هم با میکروهای AVR تولید کردن می‌گن که هیچ مشکلی باهاش نداشتن و اگر فرض را بر این بگیریم که صادقانه همه چیز را می‌گویند پس AVR مشکلی نداره (منطقا به نظر می‌رسد که صادقانه نظرشان را گفته باشند چون که قرار نیست طرفداری از AVR سودی را عایدشان کند)
از سمت دیگر هم از تعدادی از مخالفان شنیدم که در مواجه با میکروهای AVR همش با نویز، هنگ میکرو، پاک شدن حافظه و … مواجه شدن (خب اینجا هم به نظر منطقی میرسه که صادقانه این جملات را می‌گویند چون که قرار نیست با مخالفت با AVR سودی از سمت شرکت رقیب عایدشان شود)
بعضا هم در این کانال‌های تلگرامی میبینم که یک دانشجوی کارشناسی رشته الکترونیک که هنوز در راستای کسب تجربه تلاش میکند، چنان نظرات تخصصی در موافقت یا مخالفت با میکروها می‌دهد که نه خود شرکت سازنده همچین اطلاعاتی را در داکیومنت‌هایش درج کرده و نه افرادی که چند ده سال تجربه حرفهای دارند با چنین مواردی در عمل برخورد کرده‌اند و جالب اینکه این اطلاعات بسیار تخصصی بیشتر در قالب تخصص‌های پیچیده بالاتر از مقطع کارشناسی هستش و نهایتا شرکت‌ها در داکیومنت‌هاش فقط از فیچرهاش پرده‌برداری کنن.
خب بگذریم بریم سر بحث اصلی.
خب موافقان که مشکلی با این موضوع ندارن و می‌گن که دستگاهامون خیلی اوکی داره کار میکنه. منطقا اینجا مخالفان باید آن چیزی که باهاش به مشکل خوردن را به صورت خیلی مشخص و دقیق به عنوان یه چالش مطرح کنند و از موافقان بخوان که این مشکل حل نشدنی را برطرف کنند و اگر موافقان قادر به حل آن مشکل نبودند پس حرف مخالفان درست است، در غیر این صورت من حرف مخالفان را در حد همون حرف دانشجوی کارشناسی میبینم که فقط علاقه به حرف زدن داره.
با تشکر از جناب زئوس و حامدفر عزیز.
در پاسخ Phoenix ققنوس عزیز که گفتن مخالفان باید چالش یا مشکلی رو مطرح کنن و موافقان اون رو حل کنن اینم چالش :
لطفا بدون انجام کارهای اضافی نظیر اینکه حتما بخواین خروجی های io رو ایزوله کنید با اپتوکوپلر یا …، یا تغذیه قسمتهای مختلف مدار رو از هم جدا کنید یا اینکه حتما از اسیلاتور کریستالی استفاده کنید یا اینکه خازن های مختلفی در جاهای متفاوت بکار ببرید یا اینکه بخش های مختلف مدار رو از هم فاصله بدید یا اینکه جعبه فلزی استفاده کنید یا ……
بدون انجام کارهای بالا مدارات صنعتی رو با AVR طراحی کنید و نتیجه بگیرید ازش ! تا اونموقع ببینید حتی روشن شدن یک مهتابی فلوروسنت قدیمی در فاصله چند متری مدار هم روش تاثیر میزاره یا نه
ممکنه بگین خب چرا اینکارها رو انجام ندیم، بله انجام دادن اینکارها خوب هست و البته برای AVR لازمه، ولی هزینه داره و این هزینه مخصوصا تو تولید کاملا به چشم میاد و میتونیم به زبان ساده تر بگیم بدون هزینه اضافی کاری کنید مدارتون درست کار کنه و آبروتون رو نبره وقتی به جایی ارائه کردین
هیچ عقل سلیمی قبول نمیکنه وقتی میشه کاری رو از روش مطمئن تر انجام داد بریم سراغ روش غیر مطمئن که کلی ناز و ادا برات بریزه و هزار جور مقدمه چینی براش کنی تا کار کنه
به نظر من تنها تعصب بیجا و مقاومت در برابر این احساس که پس تا حالا اشتباه میکردم و رفتار گله ای از همون نوعی که تو بورس اوراق بهادار هست، باعث میشه افراد سراغ avr برن و بعدشم دیگه فکر کنن تغییر به میکرو بهتر مانعی بزرگتر از فتح قله اورسته ! در صورتیکه واقعا اینطور نیست و 90 درصد آموخته های افراد در avr اینجا هم کارایی داره و بدردشون میخوره
سلام دوست عزیز
ممنون از شما بابت مشارکت در بحث, واقعا بحث جالبی هست
چند وقت پیش مسابقه ای بود در مورد اینکه برنامه ای که مینویسیم با کدام میکرو کنترلر سرعت بالاتری داره,
https://sisoog.com/2020/01/23/%d9%85%d8%b3%d8%a7%d8%a8%d9%82%d9%87-%d8%a7%d9%88%d9%84-%d8%af%d8%b1%da%a9-%d8%b3%d8%ae%d8%aa-%d8%a7%d9%81%d8%b2%d8%a7%d8%b1/
جوابی که ما دراوردیم و تست عملی کردیم و براش منطق علمی هم اوردیم AVR بود
یکی از دوستان مصر بود که اشتباه میکنید
بحث بصورت نوشتاری بود و بحث های معماری هم پیش اومد و استدلالهای متفاوت هم اورده میشد
حتی بحث توسط دوستمون به مسائل فرعی هم رسید.
صحبتی که بنده در اخر بحث کردم اینه که دوست عزیز هر چی منطق بیاریم و استدلال بیاریم با توجه به پیچیدگی ها موضوع میشه متناظر اون را اورد و به جواب نمیرسیم یه بسم الله بگید چند خط کد هم بیشتر نیست و شروع کنید بنویسید و خروجی را منتشر کنید و در موردش حتی یک پست مینویسیم تا بقیه هم متوجه بشند که استدلال و نحوه اجرا هم اشتباه بود….
یادم هست یکی از دوستان حرفه ای آرم کار هم مخالف این موضوع بود و شروع به تست کردند ولی به نظر به جواب مناسبی نرسیدند و …
به عنوان شخصی که تجربه دارید به نظرم یه زمانی بگذارید و در مورد این بیایید یه کار علمی و عملی بکنید من و دوستانم هم از هر نظر حمایت میکنیم و بیایید هم بصورت عملی و هم بصورت تئوری نشون بدید که PIC شرایط بهتری را داره
اون را هم بصورت یک پست مجزا و ویژه در سیسوگ منتشر خواهیم کرد.
ای دی تلگرام بنده هم sisoogos هست, در این مورد اگر نظرتون مثبت بود و کمکی نیاز داشتید لطفا به بنده پیغام بدید
جناب زئوس Zeus عزیز
خب gcc , … که کامپایلرهای زبان c هستن و ارتباطی به میکروهای ما پیدا نمی‌کنن، ما برای pic هم که برنامه بنویسیم با همون gcc یا کامپایلرهای دیگه ترجمه میشه برای همینه که گفتم اطلاعات فعلی در مورد avr اینجا هم کاملا بکار میاد
آی دی ای یا همون محیط برنامه نویسی هم خب میتونه متفاوت باشه، مثلا برای avr از CodeVision استفاده بشه و برای Pic از PICC یا آی دی ای بسیار عالی MikroC که این شرکت آی دی ای های مختلف داره برای Pic, Avr, Arm و … که همگی یه طورایی یکپارچه هستن
اما در مورد اینکه گفتید با Pic زیاد کار نکردید خب پس چرا اینهمه در دفاع از Avr پاسخ دادید، من اگر از Pic دفاع کردم با Avr هم کار کردم و به این نتایجی که گفتم رسیدم
سلام دوست عزیز 🙂
gcc یه کامپایلر استاندارده حساب میشه که سخت افزار های مختلفی رو پشتیبانی میکنه – سخت افزارهای arm و avr هم جزو سخت افزارهایی هستند که این کامپایلر پشتیبانی میکنه
MikroC رو خیییلی سال پیش نصب کردم و خوشم نیومد ازش – حدود ۷ سال پیش و پاکش کردم و بعد از اون هم دیگه سراغش نرفتم. یه چیزی رو لازمه اضافه کنم، مهم اینه که شما با نرم افزار و ابزارتون راحت باشید ، اگه با MikroC راحت هستید تا وقتی مشکل حادی وجود نداشته باشه استفاده ازش اوکیه
خیر زیاد کار نکردم تا اونجایی که دیدم بحث داره منطقی پیش میره سعی کردم همراهی کنم تا دوستان بتونن با خوندن کامنت ها استفاده کنند.
+ در خصوص پاسختون به ققنوس آیا توی منوال pic گفته بدون خازن حذف نویز و … توی مدارات صنعتی ازش استفاده کنید ؟ بعید میتونم اینطور باشه پس فرقی نمیکنه یک سری اصول استاندارد هست که باید توی طراحی رعایت بشه و باید دید بعد از رعایت اصول توصیه شده کمپانی باز میکروکنترلر درست کار میکنه یا نه
در مورد دو پاسخ اول شما که gcc یک کامپایلر استانداره و … و پاسخ دوم در مورد MikroC خب اصلا نیازی به این پاسخ ها نبود چون کسی مخالفتی با اینها نداشت
درسته gcc استاندارده ولی کامپایلرهای استاندارد دیگه هم داریم که بشه برای میکروها باهاشون کار کرد
شما از MikroC خوشتون نیومده ولی ما خیلی هم خوشمون اومده کلا از محصولات MikroE
در مورد اینکه تو منوال Pic چی گفته، کلا این چیزهایی که مطرح میشه در مورد avr هست که همش مشکل داره و باید با وصله پینه درستش کرد و در مورد pic اصلا موضوعیت نداره، خود میکروچیپ هم گفته که میکروهای Pic در برابر چیزی مثل نویز بسیار مقاوم تر هستن و البته ما هم در عمل این مورد رو در محصولاتمون دیدیم و دوستانمون هم این مورد رو در عمل و در شرایط بسیار سخت روی میکروهای مختلف تست کردن و به همین نتیجه رسیدن
🙂
چیزی که واضحه اینه که اگر بدون در نظر گرفتن تمهیدات داکیومنتیشن از یه قطعه بهره برداری بشه و اگر احتمالا مشکلی پیش بیاد مقصر مشکل عدم دانش کافیه طراح هست که قبل از مطالعه صحیح داکیومنت ها و روش بهره برداری شروع کرده از قطعه استفاده کنه! به نظر من خیلی واضح هست و نیاز به توضیح بیشتر نمی بینم !!!
+ قبلا هم گفتم با هر چیزی راحت هستند کار کنید – این بهترین انتخابه ! دوستان علاقه مندی رو دیدم که مثلا با بیسکام برنامه هایی نوشتند که خیلی از دوستان سی کار حتی خوابش رو هم نمی ببینید. پس ابزار فقط در حد ابزاره، خلاقیت شماست که تعین کننده مرز هاست.
در پاسخ به Sisoog Os عزیز:
چیزی که در اون مسابقه مطرح شده بحث سرعت بوده که با کلاک یکسان کدام میکرو سریعتره
اصلا فرض کنیم طبق گفته شما و پاسخ اون مسابقه واقعا avr از همه سریعتر باشه خب این اصلا موضوع بحث ما در اینجا نیست، موضوع ما اطمینان پذیری یا reliability میکرو هستش که آیا کاری که بهش محول شده رو بدون مشکل و هنگ و ریست و … در شرایط سخت و بدون نیاز به تمهیدات و هزینه اضافی انجام میده یا نه که در مورد avr قطعا نمیتونه ولی pic به راحتی از پس شرایط برمیاد
شما با یک موتور سیکلت سریع ممکنه بتونی سریعتر از ماشین حرکت کنی ولی قطعا امنیت و اطمینان خاطر حرکت با ماشین رو نداره و مثلا حاضر نیستی به عنوان سرویس مدرسه بچه از موتور استفاده کنی چون امنیت بچه برات خیلی مهمه درست مثل یک پروژه حساس که صحیح کارکردنش خیلی مهمه هم از جهت خود کار هم آبروی کاری ما به عنوان مجری پروژه
ضمن با فرض درست بودن جواب مسابقه، اگر هم به سرعت بالاتر هم احتیاج داشتیم به راحتی میکروی سریعتری استفاده میکنیم، مگه شما فکر کردین برای کارفرما مهمه که میکروی شما با کلاک 20 مگاهرتز کار کنه یا 40 مگاهرتز ! ، مهم اول انجام صحیح و بدون مشکل کار و دوم سرعت انجام کاره
دوست عزیز فکر کنم نتونستم منظورم را درست برسونم
منظور بنده اصلا بحث بهتر بودن AVR نبود و فکر کنم برتر بودن AVR تو اون مسابقه چنین ذهنیتی ایجاد کرده
منظور من مسیر بود دوست عزیز
اینکه شما اینجا بگید بهتره ! برتره ! شاید در حد ادعا میمونه بحث من این هست که بیایید در مورد این موارد مستند مناسب ارائه کنید و حتی بیایید به کمک هم یه سری تست ها بزنید
تست بردهای PIC با شما و حتی تست بردهای مبتنی بر AVR با ما و در اخر نتیجه گیری تئوریو عملی کنیم
در پاسخ به Sisoog Os عزیز:
دوست گرامی
انجام اینکاری که شما میگین مستلزم گذاشتن وقت به عنوان با ارزش ترین سرمایه است و در مرحله دوم هزینه که هزینه مالیش زیاد مهم نیست ولی با توجه به اینکه قبلا به صورت عملی با هر دو اینها کار شده و این نتایج حاصل شده دیگه فکر میکنم عاقلانه نیست که فقط برای چیزی شبیه مسابقه دادن یا اثبات حرف، زمان مون رو صرف کنیم و در واقع اصلا نیاز به چنین اثباتی نداریم، من حاصل تجربه خودم و دوستان که در پروژه های کاملا عملی و کاربردی و واقعی و شرایط سخت بود رو خدمت شما عرض کردم حالا شما یا سایر دوستان مایلید، استفاده کنید یا همچنان روی موضع خودتون پافشاری داشته باشید به ما نفع و ضرری نمیرسه
ولی فقط این نکته رو دقت کنید که این تجربیات رو افرادی کاملا حرفهای داشتند که با انواع میکروها کار کردند و همه رو بررسی کردن نه فقط افراد مبتدی اونم اکثرا با یک میکرو خاص !
دوست عزیز بحث اثبات حرف یا مسابقه یا شبیه این نیست و نبوده
بحث این هست که بتونیم داده های علمی خودمون را با هم شیر کنیم اون هم به روش منطقی و علمی
اینکه شما فرصت ندارید و یا تمایلی ندارید کاملا شخصی هست و بنده هم نمیتونم از شما چنین خواسته ای داشته باشم البته اینکه ما اینجا وقت میگذاریم و داده هامون را به اشتراک میگذاریم هم کاری غیر عقلانی نمیکنیم 🙂
فقط اینکه تو مباحث فنی همیشه کلی نظر و ادعا وجود داره و اگر پایه و بنیه علمی داشته باشه زمان زیادی برای ارائه اون نیاز نیست
و اینکه شما از نظر فنی و تجربی به جایی رسیدید و یه نفر دیگه به جای دیگه به منزله درست بودن روش و یا ساختار هیچ کدوم از دو طرف نیست تا وقتی از نظر علمی و ساختار هم بشه بر اون مهر تایید گذاشت.
موفق باشید
پاسخ به زئوس Zeus :
اولا فکر میکنم شاید بهتر بود یه گروه تلگرامی یا حداقل یک فروم داشتیم برای مباحث اینچنینی
مورد بعدی اینکه گفتید ابزار فقط ابزاره و اگر بدون در نظر گرفتن تمهیدات داکیومنتیشن از یه قطعه بهره برداری بشه کار درستی نیست و …
به هیچ عنوان این حرف درست نیست، درست که میشه با ابزارهای مختلف یک کار رو انجام داد، شاید یک نجار حرفه ای با اره دستی بتونه یه کابینت خیلی شیک mdf بسازه ولی واقعا به نظر شما ابزار مهم نیست ؟! هر چقدر حرفه ای باشه و کار رو تمیز در بیاره (که همونم بعید به نظر میرسه) حداقلش اینه که زمان خیلی بیشتری باید صرف کنه نسبت به کسی که از اره برقی میزی استفاده میکنه و زمان بیشتر یعنی هزینه بیشتر و صرف عمر گرانمایه
یادمه یه بنده خدایی بود خیلی با paint یا نقاش ویندوز کار میکرد، میگفت من باهاش راحتم و حتی کار تایپ رو هم با paint انجام میدم !!!
به نظر شما با وجود ابزارهایی مثل Microsoft Word واقعا درسته که اینکارو به صرف اینکه باهاش راحته یا دوستش داره انجام بده ! اصلا اون کیفیت و سرعت کار Word رو میتونه داشته باشه
فکر کنید برداشت محصول به جای کمباین با دست انجام بشه !
یا شخم زدن زمین با بیل به جای تراکتور !
با شستن دستی ظروف به جای شستن با ماشین ظرفشویی، همینطور در مورد لباس !
اصلا برای اینکه در مورد همین موضوع هم بحث کنیم بیاین برای هم نامه بنویسیم به جای استفاده از ابزار کامپیوتر و اینترنت و … !!! 🙂
و میلیون ها مورد دیگه…….
پس برای بار چندم میگم، نگین ابزار مهم نیست، اتفاقا علاوه بر میزان تخصص و تجربه فرد، ابزار خوب هم بسیار مهمه، در دنیای امروز خیلی کارها رو ابزارها انجام میدن و اگر واقعا اهل عمل و کار در بازار باشید به وضوح این مورد رو می‌بینید اما اگر در حد تئوری و کتاب بیشتر حرف میزنید بله ممکنه به این نتیجه برسید که ابزار خیلی مهم نیست
واقعا تعجب میکنم! از این که چنین موضوع واضحی رو سعی می کنید جور دیگه ای جلوه بدید.
بله مثال های شما اشتباه هستن،مثلا الان لوکس ترین ماشین های جهان به شکل دستی مونتاژ میشوند که خواهان و خریدار های بیشتری هم دارند یا ساده تر فرش های دست بافت در مقابل فرش های ماشینی (و هزاران مثال دیگه از این دست).
پس می‌بینید که ابزار در مقابل نیروی کار با تجربه هیچ حرفی برای گفتن ندارد هیچ حرفی دقیقا.
+ استفاده از ابزار بدون خواندن و در نظر گرفتن تمهیدات ذکر شده در داکیومنتش اشتباهه و اشتباهی است که معمولا توسط افراد تازه‌کار اتفاق می افته، افزاد با تجربه اول داکیومنت رو مطالعه می کنند و جنبه های مختلف رو در نظر می گیرند.
زئوس Zeus عزیز :
به نظر میرسه شما فقط قصد دفاع از مقاله ای که نوشتید رو دارید و اصلا حاضر نیستید حرف طرف مقابل رو گوش کنید و فقط دنبال راهی برای نفی حرفهای اون میگردین
اون مثالی که زدین در مورد فرش دستباف و مونتاژ دستی و … یک سری استثنائات خاص هستن ولی شما باید ببینید در دنیای واقعی کدوم مورد بهتره
به نظر شما میشه بگیم پس همه مردم برن فرش دستباف بخرن چون ارزشمندتره، یا همه برن ماشین مونتاژ دستی بخرن
ضمن اینکه به یک نکته دقت نکردین، شما گفتید فرش دستباف ارزشمندتره و بخاطر همین اونو بهتر می‌دونستید و دقیقا ما هم در مورد pic داریم همینو میگیم که pic ارزشمندتر و حرفهای تره !
ضمنا چرا با آوردن یک جمله درست سعی در صحیح جلوه دادن حرف اشتباه دارید، اینکه باید داکیومنت خونده بشه رو کسی منکرش نیست که شما از این جمله استفاده میکنید، خب pic هم داکیومنتهای خودشو داره و قطعا اونها هم مطالعه و عمل میشه، فقط avr اینطور نیست
اما خود تولید کننده pic, avr که شرکت میکروچیپ هستش داره میگه pic در برابر نویز و شرایط سخت مقاومتره، دقت کنید این حرف خود تولید کننده هر دو میکرو هستش حالا شما این وسط میخواین حرف تولید کننده رو هم نقض کنید !!! مثل اینکه شما بگی رنگ آبی رو دوست داری من بیام بگم نه اشتباه میکنی تو رنگ قرمز رو دوست داری !
ضمنا جواب ندادید، به راحتی میگین ابزار مهم نیست در موارد زیر چیکار میکنید
مثلا برای نصب سقف شیروانی یک سوله ممکنه 40000 تا پیچ نیاز باشه، چون ابزار مهم نیست ولی استادکار حرفه ای هستش پس بیایم بهش بگیم برو با دلر دستی 40000 تا سوراخ کن و بعدش با پیچ گوشتی 4000 تا پیچ سفت رو ببند و نیاز به دستگاه میخ کوب یا چیپ‌گوشتی برقی و … نیست !!!
یا مثلا یه تالار که روزانه دو وعده ناهار و شام هر کدوم 1000 تا مهمون داره بشینه دستی سیخ بزنه و 4000 تا سیخ کباب بپزه و از دستگاههای یکپارچه کباب پز استفاده نکنه چون ابزار مهم نیست دیگه، آشپز حرفه ایه !!!!!
یا مثلا قراره لوله فاضلاب کار گذاشته بشه به طول 10 کیلومتر که باید به عمق 3 متر زمین کنده بشه، به جای استفاده از بیل مکانیکی بیان کارگر افغانی بیارن بگم با بیل و کلنگ بکنید چون شما کارگران خوبی هستید و ابزار مهم نیست !!!!
اصلا اینم نگفتید که بهتر نیست منو شما با هم نامه نگاری کنیم به جای جواب دادن در سایت ؟، ابزار اینترنت و کامپیوتر و … مهم نیستن دیگه !!!!!!!!
شما که مثال فرش ماشینی و ماشین مونتاژ دستی رو میزنی این موارد بالا و صدها هزار مورد دیگه رو هم ببین
خواهشا حرفهایی نزنید که افرادی که میخونن فکر دیگه ای راجع به شما کنن، من میدونم شما فرد حرفه ای هستید ولی اصرار و پافشاری بیموردی در این قضیه دارید
چقدر این بحث داره طولانی میشه و بی نتیجه !
ببینید من هیچ کجایی توی بحث هایی که داشتیم نگفتم avr بهتره یا pic، یک بار دیگه مطالعه کنید این مهم رو ببینید. نمیدونم چرا اینطور برداشت کردید که واقعا جالبه! من گفتم هر کدوم رو راحت تر هستید(نه شما هر کسی) از همون استفاده کنید، گفتم ابزار اونقدر که فکر میکنید مهم نیست مهمتر مهارت شما در استفاده از ابزاره. همون مثال خودتون دستگاه کباب زن فوق مدرن وقتی نتونی از قابلیت هاش استفاده کنی آیا داشتن و یا نداشتنش فرقی با هم داره.
بذارید اینم بگم سایت میکروچیپ بالا پایین کردم – میکروهای pic جدید معماری RISC دارن مثلا سری های pic18k که دقیقا اولین چیزی که توی منوالش نوشته اینه “C Compiler Optimized RISC Architecture” ! دقیقا همون چیزی که من اول بحث در مورد pic های قدیمی گفتم بهتون بخاطر طراحیشون نمیتونستن از زبان سی به شکل کامل پشتیبانی کنند این میشه دلیل مستدل و بحثی توش نمی مونه! می توانستید در جواب من که گفتم قدیمی ها پشتیبانی نمی کنند همین یک مثال رو ذکر کنید و قطعا بحث به جاهای بهتری هم می‌رسید.
ولی واقعا چقدر خوب 🙂 ، شاید بعدا توی پروژه ای تجربشون کنم. همیشه دلیلم برای عدم استفاده از این میکرو همین عدم پشتیبانی کاملش از زبان c بوده که حالا واقعا به نظرم هیجان انگیزه استفاده ازش
ولی وقتی داشتم داکیومنت همین pic18k رو میخوندم چیزایی دیدم که واقعا گمراه کننده است و واقعیت رو مخفی میکنه نه حتی این که بیانش نکنه :|، جایی حرفی خلاف واقع نمیزنه ولی واقعیت رو هم نمیگه. امیدوارم فرصت کنم راجبش یه مقاله بنویسم. البته باز میگم کامنت ها رو خیلی ها مطالعه نمی کنند و برای بهتر دیده شدن حرف هاتون و نقد هاتون می تونید مقاله ای بنویسید که به عنوان پست منتشر کنیم تا همه دوستان ببینید و استفاده کنند.
+ من جز بیان واقعیت چیز دیگه ای گفتم ؟ آیا شما فکر نمی کنید اصرار بی مورد دارید ؟ توی یه بحث منطقی باید دلیل و مدرک ارائه کنید بدون دلیل مدرک معتبر که هر کسی میتونه هر چیزی بگه. کار دست کیفیت بهتری داره چون امکان اپتیمایز تک تک محصولات رو به شما میده واقعا ارزشمند تره صرفا این مثال رو زدم که ببینید اونطور هم که فکر میکنید نیست.
“اما خود تولید کننده pic, avr که شرکت میکروچیپ هستش داره میگه pic در برابر نویز و شرایط سخت مقاومتره، دقت کنید این حرف خود تولید کننده هر دو میکرو هستش حالا شما این وسط میخواین حرف تولید کننده رو هم نقض کنید !!! ”
جناب مهندس لطف میکنید اون قسمت از داکیومنت را ارجاع بدید و شیر کنید
Sisoog Os عزیز :
همونطور که گفتید اگر شما همچین کاری انجام بدید ما هم غیر عقلانی نمی‌دونیم اینکار رو
ولی خب ما هم چون قبلا انجام دادیم و دوستانمون هم در مراکز حساس اینکارو انجام دادن دیگه نیازی به انجام مجدد نمی‌بینیم
فکر کنید نوعی موشک وجود داره که موقع پرتاب، برد الکترونیکی اون که روی موشک سواره، در هر ثانیه هزاران بار دور خودش میچرخه، در چنین شرایطی تنها میکرویی که جواب داد همون pic بود، انواع میکروها از avr, arm و … تست شد و همه از کار افتادند جز pic
اینو گفتم که فکر نکنید منظور از شرایط سخت فقط نصب یک دستگاه تو محیط کارخونه است
ضمنا من در پاسخ قبلی هم گفتم، اصلا بحث ادعا داشتن نیست که قرار باشه بعدش ثابت بشه، من تجربیاتی داشتم که گفتم دوستان اگر مایل بودن استفاده کنن اگر هم نه قطعا در ادامه مسیرشون خودشون بهش میرسن
اما یه چیز که دیگه کاملا مشخصه، اینکه برای کار با avr باید هزار جور پیش نیاز در نظر گرفت که به قول Zeus عزیز، در داکیومنتش گفته شده، خب انجام اون کارها هم طراحی رو پیچیده تر میکنه هم هزینه مدار رو بالا میبره، بهرحال شما بخوای ورودی خروجی ها رو ایزوله کنی یا تغذیه جدا برای بخشهای مختلف بزاری یا چند مورد دیگه در avr باید رعایت بشه خب همه اینها یعنی هزینه و زمان
ولی وقتی میکروی pic هست که نیاز به این کارها نداره اصلا چرا باید سراغ avr بریم که بعدش نیاز باشه اون کارها و هزینه ها رو انجام بدیم و در نهایت هم مدارمون به کیفیت مدار طراحی شده با pic نرسه !
سلام استاد.
باز هم مثل همیشه عالی بود. بهتر از بهتر. دیدگاه خوب، درک درست. ممنون از مطالب مفید شما.
هر چند می دونید که من عادت ندارم فقط تعریف بنویسم. یعنی نظری که تنها بیانگر خوب و بد بودن باشد نظر ارزشمندی نخواهد بود.
ولی من در این مطلب چیزی جزئ این که تحسین کنم نمی توانستم اضافه تر بنویسم.
سپاس و دورود فراوان.
سلام دوست عزیز
ممنونم شما خیلی لطف دارید 🙂
سلام استاد خسته نباشید
من راستش حدود 7 یا 8 ماهی هست که دارم سعی میکنم قدرتم و در برنامه نویسی سی افزایش بدم و در اینکار موفقم بودم
بنده سوالی برام پیش اومده اینک از اون جایی ک نحوه برنامه نویسی سی برای سیستم عامل کاملا متفاوت تر از سی امبدد هست من بیشتر منابعی ک مشاهده کردم مربوط به سی برای سیستم عامله میخواستم بدونم شما منبع خوبی برای سی امبدد در نظر دارید (البته یک کتاب PDF به نام Embedded Programming with Modern C++ Cookbook ک نویسنده این کتاب Igor Viarheichyk هست و خب رزومه بزرگی داشتن ولی از اونجایی ک گرامر سی پلاس پلاس بهینه تر از سی هست شما نظری در این باره دارید ک بجای سی امبدد به سی پلاس پلاس امبدد روی بیارم؟؟)
ممنون از مطالب خوبتون و مرجع متن باز سیسوگ:)
سلام دوست عزیز
خوشحالم که دارید روی این مساله وقت میذارید 🙂 فکر میکنم یکی از نکات کلیدی برای حرفه ای شدن توی کار طراحی دیجیتال برنامه نویس خوب بودن هست. که متاسفانه زیاد توی رشته ما بهش توجه نمیشه.
خوب اول بذارید قاطعانه بگم که برای برنامه نویسی روی میکروکنترلر c++ گزینه چندان مناسبی نیست. توی برنامه نویسی حرفه ای مشکلات زیادی به وجود میاره و به شکل ناخود اگاه وقتی از کلاس ها استفاده می کنید حافظه زیادی رو هدر میدهید چون فراموش میکند که مثلا یک کلاس با یه متغییر ساده توی مصرف منابع چقدر متفاوت هست و مسائل خیلی زیاد دیگری که پیش میآد. برای این که بتونم دوستان منتقد نسبت به این دیدگاه رو قانع کنم باید به سادگیLinus Torvalds رو مثال بزنم که خالق هسته لینوکسه و میگه برای برنامه نویسی سطح پایین c++ واقعا وحشت ناکه و تا جای ممکن کدهای مبتنی بر c++ رو از کرنل حذف کرده.
در مورد منبع – باید بگم یکی از غنی ترین منابع موجود سورس کدهای نوشته شدی دیگران هست که توی گیت هاب میتونید پیداشون کنید.
سلام جناب زئوس
من تو این زمینه خیلی تازه کارم ولی برام جذاب بود واقعا
میشه راهنمایی کنید که برای رسیدن به این سطح از تسلط تو برنامه نویسی سخت افزار از کجا میشه شروع کرد؟
سلام دوست عزیز
فکر میکنم مهم ترین مساله اول شروع کردنه ! به دنبال این نباشید که چکار کنید تا به اصطلاح حرفه ای شوید، اول شروع کنید و سعی کنید کنجکاو باشید، مدار ها رو بررسی و آنالیز کنید، برنامه ها رو بخونید و سعی کنید بفهمید چرا به این شکل نوشته شده اند، سوال بپرسید
همه این ها برای این که بتونید توی کاری که انتخاب کرده اید موفق بشوید مهم و ضرروری هستند، سعی نکنید خودتون رو محدود کنید به کامپایلر خاص – میکروی خاص همیشه به دنبال دانش بیشتر باشید. این میشه که آنچه به دنبالش هستید رو به دست می آورید.
واقعا اینطور نیست که موفقیت یک فرمول خاص داشته باشه که من با گفتن اون شما رو به موفقیت برسونم ، موفقیت برای هر کسی متفاوته و فرمول خاص اونن فرد رو داره .
پس توصیه میکنم شروع کنید برای به چنگ آوردن موفقیت.
سلام.
من قبلا با 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 بیتی از لحاظ سرعت رقیب نداره .فقط حیف یکم قیمتش گران هست.
^_^
خیلی ممنون برای این که تجرتون رو به اشتراک گذاشتید
حالا اگر شما سری xmega رو ببینی چه خواهی گفت 🙂 هسته avr کلاک آرم خخخخ
اونم فوق العاده است مخصوصا پریفرال های متنوعی که داره گاهی دست stm32 رو هم می بنده
یه نگاهی بهش بنداز به نظرم
سلام .
شرمنده نکنید جناب زئوس .تجربه من در مقابل تجربه شما ، چیزی نیست .
اتفاقا خیلی دوست داشتم به جای آرم با xmega یا حتی avr32کار کنم .ولی
متاسفانه xmega خیلی گرانقیمت هست . و زمان اجازه نمیده روی اون وقت گذاشت.
سپاس بابت مطالب بسیار خوبی که منتشر میکنید.
خواهش میکنم 🙂 دوست عزیز
من هدر xmega خریدم و چند تایی کد روش نوشتم خیلی با avr همخوانی نداره حتی رجیسترهاش و ساختارش – به نظرم خیلی میکروی خوبی هست
احتمالا آموزشش رو از سر بگیریم توی سیسوگ
نظرات شما باعث دلگرمی ما میشه
سلام
شما اگه از متغیر های بایت استفاده کرده باشی
چون باس درگاه های stm32 32 بیتی هستش به ناچار اول stm32 میاد اون رو تبدیل به int می کنه بعدش محاسبه ی سرریزی متغیر رو می کنه بعدش روش حساب کتاب می کنه
همون بحث چالش فکر کنم سوم یا چهارم خود سیسوگ
که کدوم دستور سریعتره؟
برای همین سرعتت کم به نظر می رسه
سلام جناب زئوس .
راستش من مدتی هست که روی کتابخانه مربوط به این lcd وقت گزاشتم .
میخواستم بپرسم حداکثر سرعت رفرشی که شما با avr بهش دست پیدا کردید چقدر بوده ؟
مثلا زمان اجرای اون 10 فریم حداقل به چقدر رسیده ؟
مرسی.
سلام دوست عزیز ؛ والا من زیاد تر وقت نگذاشتم ؛ و نهایتا همون 4 ثانیه برای 10 فریم رو دریافت کردم
البته با استفاده از esp8266 تا سرعت 15 فریم به ثانیه هم رسیدم چون توی esp ما spi نه بیتی داریم 🙂
متشکر جناب زئوس
خواهش میکنم دوست عزیز.
سلام جناب زئوس .
میکرو avr کلاک 16 مگاهرتز : 11 فریم در ثانیه!!!!
نه با آور کلاک پردازنده :دی
سلام .
منظورتون رو متوجه نشدم جناب زئوس . avr و آور کلاک؟؟!!!
16مگاهرتز برای( atmega32 )avr که آور کلاک حساب نمیشه !!!
سلام
منظور از اور کلاک اعمال فرکانس بالاتر از حد مجاز برای پردازنده است – منم avr رو با فرکناس ۲۰ مگاهرتز آورکلاک کردم
منظورم این بود.
راستش جناب زئوس نفهمیدم چرا مسئله اور کلاک به ذهنتون اومده.
توی پستهای قبلیم گفته بودم میشه این سرعت سرعت رفرش lcd رو برای avr با همون فرکانس 16 مگاهرتز به 12 فریم در ثانیه رسوند !!!،اما در عمل 11 فریم در ثانیه محقق شد.
اوپس ظاهرا اشتباه متوجه شدم
خوب تا اونجا که من اطلاع دارم با روش هایی که احتمالا بعدا اگر فرصت شد بهش خواهیم پرداخت (ارسال دیتای ۹ بیتی با واحد spi سخت افزاری avr) میشه سرعت نمایش رو بهیود بخشید ولی این که چقدر بهتر بشه رو نمیدونم
سلام .
متشکر از مطلب خوبتون .
به نظرم اصلا اون آرایه رو حذف کنید ( به درد زمانی میخورد که حلقه 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میشه این حالت رو فعال کرد .
میخواستم بپرسم آیا این پینها در کانکتور ال سی دی در دسترس هستند .؟ یا اصلا به طور کلی چطور میشه این کار رو انجام داد؟
مرسی
امم قابل توجه هست ؛ ولی فکر میکنم تا اونجایی که یادم میاد کد اسمبلی ش رو بررسی کردم همچین اتفاقی رو خود کامپایلر رقم زده بود
ولی باز چکش میکنم اگر نتیجه بهتر شده بود حتما منتشر میکنیم این پیشنهاد رو
با سلام مجدد.
راستش به نظرم اومد این تابع مربوط به کتابخانه 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 رو حذف بکنه .
متشکر بابت زحمتی که میکشید و بررسی میکنید.
سلام خواهش میکنم دوست عزیز
ببنید اون خط هایی که فرمودید در واقع تابع نیستند و ماکرو هستند ؛ وقتی از ماکرو استفاده میکنیم دقیقا همین دو سیکل برای اجرایشون طول خواهد کشید.
با سلام .
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 استفاده بشه نتیجه متفاوت خواهد شد . اگر اشتباه کرده ام مرا راهنمایی کنید.
متشکر .
دقیقا این نوشته های فوق تبدیل به ماکرو میشه 🙂
سلام .
فرمایش شما درست بود کمپایلر توابع رو تبدیل به ماکرو کرده .
مرسی.
^_^
باسلام . ببخشید اون کد اشتباه هست(تریب ارسال بیتها برعکس هست )خیلی ببخشید. این درسته
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();
ابتدا تشکر می کنم بابت نوشتن این مجموعه از مقالات مفید.
من دو تا پیشنهاد دارم.
1- چون این پروتکل بصورت SPI کار می کنه پس در زمانی که دیتا داره به میکرو منتقل میشه باید پایه CS فعال باشه و در انتهای کار هم غیر فعال بشه. نیازی نیست که در هر سیکل ارسال یک 9 بیتی این پایه فعال و غیر فعال بشه. اینطوری زمان تغییر وضعیت این پایه کاهش پیدا می کنه. من این روش رو در جایی تست کردم و نتیجه گرفتم.
2- خود عملیات مقایسه چند سیکل کلاک زمان نیاز داره. میتونیم بدون اینکه نتیجه data & ShiftBit[] رو در داخل یک شرط بررسی کنیم مستقیم نتیجه رو به مقدار نیاز شیفت داده و داخل رجیستر خروجی میکروکنترلر بنویسیم. این بخش نیاز به آشنایی جزئی با رجیسترهای میکروکنترلر داره ولی تقریبا با اطمینان میتونم بگم که این کار سرعت رو افزایش میده. چون عملیات مقایسه از دو عملیات کوچکتر تفریق و مقایسه با صفر تشکیل میشه (اکثرا اینطوریه و ممکنه روشهای دیگری هم داشته باشه) در حالی که عملیات شیفت در میکروها سریعتر انجام میشه و در گام بعد نتیجه مستقیم داخل رجیستر خروجی نوشته میشه. این کار مخصوصا در مقایسه با زمانی که بخش else دستور شما اجرا میشه سریعتره.
خواهش میکنم دوست عزیز ؛ کاملا درسته ؛ دقیقا همین مساله کنترل به موقع پایه CS میتونه تاثیر زیادی داشته باشه
در مورد پیشنهاد دوم باید بگم که بله حق باشمایت ولی در صورتی که بتونیم تنها یک بیت از یک ریجیتر رو تغییر بدیدم ؛ که خود این کار نیاز به عملیات or داره که زمان بره ؛ در مجموع فرقی نمیکنه ؛ البته توی معماری avr
جالب بود ممنون؛ پیشنهاد من هم استفاده از متغیر نوع رجیستر برای آرایه هستش، و همینطور میشه به جای تابع یک ماکرو تعریف کرد. همینطور باید قسمت slave که یک tft هستش رو هم در نظر گرفت اگر نمایشگر رو پارالل ۱۶ بیتی راه اندازی کنیم سرعت خیلی بالا میره. این کار رو میشه با یه دو تا آی سی شیفت رجیستر انجام داد.
خواهش میکنم ؛ خوب با توجه به تعداد اجزاء آرایه احتمالا نمیشه از نوع رجیستر استفاده کرد ؛ شایدم بشه خیلی بستگی به CPU داره ولی پیشنهاد خوبیه !
فرض اینه که میخوایم داده های به شکل سریال ارسال کنیم ؛ اگر نه فرمایش شما کاملا صحیح است ؛ استفاده از مد پارالل نرخ رو خیلی افزایش میده
من شاید 10 درصدشو متوجه شده باشم
لطفا بازهم ازین مدل پست ها تهیه کنین طرز فکر ادمو تغییر میده
بسیار ممنونم
خواهش میکنم دوست عزیز 🙂
سعی میکنم ادامه بدم ولی اینقدر مشغله هست که آدم فراموش میکنه :/
با سلام
اگر در تعریف lookup table از کلمه کلیدی const استفاده میشد بهتر نبود؟ چراکه در اینصورت در حافظه فلش ذخیره میشد. هرچند که مطمئن نیستم که آیا این باعث کندتر خواندنش میشود یا خیر.
خوب ، البته بسته به مدل طراحی پردازنده میتونه قضیه متفاوت باشه ، ببینید حافظه RAM سریعتر است و پردازنده به صورت مستقیم معمولا بهش دسترسی داره اما حافظه Flash بسته به ساخناری که داره کندتر از RAM هست و توی برخی معماری ها پردازنده دسترسی مستقیم بهش نداره مثل خانواده های ARM پس تعریف const میتونه باعث کاهش سرعت بشه
با عرض سلام مجدد
این برنامه رو هم یکم بهینه تر میشه نوشت البته باز هم بدون استفاده از تابع یعنی:
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();
سلام
پیشنهاد خوبیه ولی اگر کد اسمبلی رو نگاه کنید موقع کامپایل خود کامپایلر کد قبلی رو به همین حالت تغییر میده ! 🙂
ببینید به عنوان راهنمایی باید بگم باید دیگه اسمبلی کدها رو بنویسید و در بهترین حالت قرار بدید
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();
}
امم خوب چی شده الان ؟ چرا یک بار بیشتر کلاک نزدید ؟
درود
به نظر من اگه واسه این کار از تابع استفاده نشه و به جای تابع 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();
درود
پیشنهاد خوبیه ، این کار بی تاثیر نیست ، شاید در حدود 20 میلی ثانیه نه 200 میلی ثانیه
ولی همین اقدامات کوچیک باعث این بهبود ها میشه 🙂