CAN Bus (controller area network) ဆိုသည်မှာ ဆက်သွယ်ရေး စနစ် တစ်ခုဖြစ်ပြီး မိုက်ခရိုကွန်ထရိုလာများ နှင့် အခြား အီလက်ထရွန်းနစ် ကိရိယာများကို ကွန်ပျူတာ မလိုအပ်ဘဲ အချင်းချင်း ဆယ်သွယ် နိုင်ရန် ပြုလုပ်ထားသော စနစ်ဖြစ်ပါတယ်။ CAN Bus ဟာ မက်ဆေ့ (message) အပေါ်တွင် အခြေခံသော ပရိုတိုကောလ်ဖြစ်ပြီး မော်တော်ယာဉ်များတွင် အဓိက အသုံးပြုလေ့ ရှိပေမယ့် စက်ရုံများနှင့် ဆေးဘက်ဆိုင်ရာ ကိရိယာများတွင်လည်း အသုံးပြုလေ့ ရှိပါတယ်။
Showing posts with label CAN. Show all posts
Showing posts with label CAN. Show all posts
Tuesday, July 9, 2013
Wednesday, May 26, 2010
Using SPI on Low-End Microcontroller
SPI က IC အချင်းချင်း ဆက်သွယ်ဖို့ အတွက် ရိုးရှင်းပြီး ထိရောက်တဲ့ bus တစ်ခုပါ။ Real Time Clock၊ EEPROM အစရှိတဲ့ chip အများစုမှာ ဆက်သွယ်ဖို့ အတွက် SPI ဒါမှမဟုတ် I2C bus တွေ ပါလေ့ရှိပါတယ်။ ထူးခြားတဲ့ အချက် မရှိရင် တော့ SPI သုံးရတာကို I2C ထက်ပိုကြိုက်ပါတယ်။ သူက ပိုမြန်ပြီး ပိုရှင်းလို့ပါ။ သူ့ကို software နဲ့ ဖန်တီး emulate လုပ်ဖို့လဲ လွယ်ပါတယ်။
တစ်ခါက 10MHz ရှိတဲ့ SPI ပါတဲ့ LED driver chip တစ်ခုကို လုပ်ဆောင်မှု အရမ်းမမြင့်တဲ့ 4MHz microcontroller နဲ့ တွဲသုံးဖြစ်ပါတယ်။ Design လုပ်တုန်းက ဈေးသက်သာ ဖို့ အတွက် အဓိက ထားလို့ပါ။ Microcontroller ကလဲ တစ် ဒေါ်လာတောင် မပေးရပါဘူး။ ဒါပေမယ့် သူ့မှာ firmware နဲ့ font တွေသိမ်းဖို့ flash အလုံအလောက် ရှိပါတယ်။ အစကတော့ SPI ကို ဒေတာ ပို့ဖို့၊ လက်ခံဖို့ အတွက် ပုံမှန် အတိုင်းပဲ နှေးတဲ့ အဝေးပို့ RS232 တို့၊ CAN bus တို့မှာ သုံးနေကြ အတိုင်း circular buffer ကို hardware interrupt နဲ့ တွဲသုံးပါတယ်။ အဲဒါက ပုံမှန် အခြေအနေမှာ တော့ အိုကေ ပါတယ်။ ပြဿနာ က ကြီးမားတဲ့ 96x16 dot-matrix LED ဆိုင်းဘုတ် ကြီးကို တစ်စက္ကန့် ၁၂၅ ကြိမ် မောင်းချင်ပြီး CPU ကို အသုံးချ တဲ့ utilization က အရမ်းမြင့်နေတာပါ။ အကျိုးဆက် အနေနဲ့ စာသားတွေကို ဘေးတိုက် ပြေးတာ အစရှိတဲ့ ဂရပ်ဖစ် လုပ်ဆောင်မှုတွေကို ကိုင်တွယ်ရတဲ့ အခါ ကောင်းကောင်း မလုပ်နိုင်တော့ပဲ ဖုတ်လှိုက် ဖုတ်လှိုက် ဖြစ်ချင်လာ ပါတယ်။ ဒါနဲ့ပဲ အရင်းအမြစ်ကို စာရင်းစစ် ကြည့်လိုက်တော့ အဓိက အသုံးအများဆုံး ဖြစ်တဲ့၊ CPU က အမြဲတမ်းလိုလို လုပ်ဆောင်နေ ရတဲ့ SPI function က interrupt တွေ၊ circular buffer တွေနဲ့ ဖောင်းပွ နေပြီး သူ့ကို ထိရောက်အောင် ပြင်နိုင်ရင် CPU က တော်တော် သက်သာသွားမယ် ဆိုတာ တွေ့ရပါတယ်။ ပုံမှန်ကတော့ hardware interrupt ကိုသုံးတာက ပိုထိရောက်၊ ပိုမြန်တာ မှန်ပါတယ်။ ဒါပေမယ့် ဒီ ကိစ္စမှာတော့ ပုံမှန် မဟုတ်ပါဘူး နှေးတဲ့ CPU က အရမ်းမြန် အရမ်းအသုံးပြုဖို့ လိုတဲ့ SPI ကို မောင်းဖို့ လိုနေလို့ပါ။ SPI ကို ဒေတာ တစ်လုံး ပို့တိုင်း CPU cycle တွေ အရမ်းစားတဲ့ ပို့တဲ့ interrupt function၊ လက်ခံတဲ့ interrupt function တွေကို လုပ်နေရလို့ပါ။ နောက်တော့ polling ဒါမှမဟုတ် emulation ကို သုံးပြီး SPI ကို ဆက်သွယ်တာက interrupt ထက် ပိုမြန်တာကို တွေ့ရပါတယ်။ ဒါတောင် polling ကိုသုံးမယ်ဆိုရင် hardware က လက်ခံတဲ့ bus speed ကိုပဲ သုံးလို့ရမှာပါ။ ဒါနဲ့ SPI function ကို ပိုထိရောက်အောင် firmware ကို ပြင်လိုက်တော့ ကောင်းသွားပါတယ်။ ဒါကြောင့် SPI ကို emulating လုပ်ရင် ကောင်းတဲ့ အချက် တစ်ချို့ ကို ကျွန်တော် တို့ရဲ့ အတွေ့အကြုံ အရ ပြောချင်တာက
တစ်ခါက 10MHz ရှိတဲ့ SPI ပါတဲ့ LED driver chip တစ်ခုကို လုပ်ဆောင်မှု အရမ်းမမြင့်တဲ့ 4MHz microcontroller နဲ့ တွဲသုံးဖြစ်ပါတယ်။ Design လုပ်တုန်းက ဈေးသက်သာ ဖို့ အတွက် အဓိက ထားလို့ပါ။ Microcontroller ကလဲ တစ် ဒေါ်လာတောင် မပေးရပါဘူး။ ဒါပေမယ့် သူ့မှာ firmware နဲ့ font တွေသိမ်းဖို့ flash အလုံအလောက် ရှိပါတယ်။ အစကတော့ SPI ကို ဒေတာ ပို့ဖို့၊ လက်ခံဖို့ အတွက် ပုံမှန် အတိုင်းပဲ နှေးတဲ့ အဝေးပို့ RS232 တို့၊ CAN bus တို့မှာ သုံးနေကြ အတိုင်း circular buffer ကို hardware interrupt နဲ့ တွဲသုံးပါတယ်။ အဲဒါက ပုံမှန် အခြေအနေမှာ တော့ အိုကေ ပါတယ်။ ပြဿနာ က ကြီးမားတဲ့ 96x16 dot-matrix LED ဆိုင်းဘုတ် ကြီးကို တစ်စက္ကန့် ၁၂၅ ကြိမ် မောင်းချင်ပြီး CPU ကို အသုံးချ တဲ့ utilization က အရမ်းမြင့်နေတာပါ။ အကျိုးဆက် အနေနဲ့ စာသားတွေကို ဘေးတိုက် ပြေးတာ အစရှိတဲ့ ဂရပ်ဖစ် လုပ်ဆောင်မှုတွေကို ကိုင်တွယ်ရတဲ့ အခါ ကောင်းကောင်း မလုပ်နိုင်တော့ပဲ ဖုတ်လှိုက် ဖုတ်လှိုက် ဖြစ်ချင်လာ ပါတယ်။ ဒါနဲ့ပဲ အရင်းအမြစ်ကို စာရင်းစစ် ကြည့်လိုက်တော့ အဓိက အသုံးအများဆုံး ဖြစ်တဲ့၊ CPU က အမြဲတမ်းလိုလို လုပ်ဆောင်နေ ရတဲ့ SPI function က interrupt တွေ၊ circular buffer တွေနဲ့ ဖောင်းပွ နေပြီး သူ့ကို ထိရောက်အောင် ပြင်နိုင်ရင် CPU က တော်တော် သက်သာသွားမယ် ဆိုတာ တွေ့ရပါတယ်။ ပုံမှန်ကတော့ hardware interrupt ကိုသုံးတာက ပိုထိရောက်၊ ပိုမြန်တာ မှန်ပါတယ်။ ဒါပေမယ့် ဒီ ကိစ္စမှာတော့ ပုံမှန် မဟုတ်ပါဘူး နှေးတဲ့ CPU က အရမ်းမြန် အရမ်းအသုံးပြုဖို့ လိုတဲ့ SPI ကို မောင်းဖို့ လိုနေလို့ပါ။ SPI ကို ဒေတာ တစ်လုံး ပို့တိုင်း CPU cycle တွေ အရမ်းစားတဲ့ ပို့တဲ့ interrupt function၊ လက်ခံတဲ့ interrupt function တွေကို လုပ်နေရလို့ပါ။ နောက်တော့ polling ဒါမှမဟုတ် emulation ကို သုံးပြီး SPI ကို ဆက်သွယ်တာက interrupt ထက် ပိုမြန်တာကို တွေ့ရပါတယ်။ ဒါတောင် polling ကိုသုံးမယ်ဆိုရင် hardware က လက်ခံတဲ့ bus speed ကိုပဲ သုံးလို့ရမှာပါ။ ဒါနဲ့ SPI function ကို ပိုထိရောက်အောင် firmware ကို ပြင်လိုက်တော့ ကောင်းသွားပါတယ်။ ဒါကြောင့် SPI ကို emulating လုပ်ရင် ကောင်းတဲ့ အချက် တစ်ချို့ ကို ကျွန်တော် တို့ရဲ့ အတွေ့အကြုံ အရ ပြောချင်တာက
- SPI ကို software မှာ emulate လုပ်ရင် ပိုမြန်တဲ့ အခါတွေ လည်း ရှိပါတယ်။
- အရည်အသွေး လည်း ပိုကောင်းပါတယ်။ ဘာကြောင့်လဲ ဆိုတော့ ရိုးရှင်းတာရယ်၊ interrupt ကြောင့် ဖြစ်လာနိုင်တဲ့ ပြဿနာ အများစုကနေ ရှောင်ပြီးသား ဖြစ်သွားလို့ပါ။
- ရိုးရှင်းတဲ့ code လေးကို ရေးရတာ ပိုမြန်၊ ပိုလွယ်ကူ၊ ပိုပြီး အမှားနည်းနိုင်ပါတယ်။ မဟုတ်ရင် အသစ်သုံးမယ့် microcontroller တိုင်း အတွက် အမျိုးမျိုးသော register setting တွေနားလည်ဖို့ datasheet ကို အချိန်ပေး ဖတ်ဖို့ လိုမှာပါ။
- အကောင်းဆုံးကတော့ portable ဖြစ်ပြီး hardware ကို မမှီခိုတော့ တာပါပဲ။
//-------------------------------------
unsigned char spi(unsigned char d)
{
unsigned char i;
SCLK=1;
EN=1;
for(i=0;i<8;i++)
{
MOSI=(d & 0x80)?1:0;
//Delay(period/2)-optional for slower SPI bus speed
SCLK=0;
d<<=1;
d|=MISO;
//Delay(period/2)-optional for slower SPI bus speed
SCLK=1;
}
EN=0;
return d;
}
//-------------------------------------
Subscribe to:
Posts (Atom)