PT2262 ile PT2272-XY bir encoder-decoder çiftidir. PT2262 paralel uygulanan data ve adres bitlerini belirli bir kurala göre kodlar, PT2272 ise kodlanmış verinin içerisindeki adres bilgisiyle kendisine uygulanmış adres bilgisini karşılaştırır, tutuyorsa kodlanmış verinin içinden vericinin gönderdiği bitleri çözer ve data çıkışına yansıtır. Basit RF modüller ile 4-6 bit paralel bilgi iletilmesi bu çiftin kullanıldığı yerlere güzel bir örnektir. Kodlama işlemi katalogda anlatılmış, yapılan işlem lojik1 biti yerine 10001000, lojik 0 biti yerine 11101110 bitlerini göndermek gibi bir işlem yoksa PT lerin herhangi bir şifreleme özelliği yoktur.

Öncelikle kodlama ile şifrelemeyi ayırmak gerekir. Haberleşmede veriyi direkt göndermek yerine kodlama-kod çözme işlemini araya koymanın birkaç nedeni vardır:

1) Sağlamlık: Çeşitli kodlama teknikleriyle, data bitlerine eklenen bitler(parite bitleri) sayesinde kanalda olası bir hatanın alıcı tarafta sezilmesi ve hatta düzeltilmesi mümkün olabiliyor (Popüler kodlama yöntemleri: cyclic codes, convolutional codes).
2) Donanımsal: RF veya IR haberleşmede kodlama, haberleşmeyi daha sağlıklı yapabiliyor. Mesela lojik 1 leri 10, lojik 0 ları ise 01 şeklinde kodlamak hızı düşürse de donanımın daha az hatalı çalışmasını sağlayabiliyor.

Şifreleme(kriptolama) ise PT lerle ilgisi olmayan bambaşka bir konu, genel olarak kriptolamada sadece alıcıda ve verici tarafında bilinen bir anahtar olur. Verici taraf bu anahtara ve belirli bir algoritmaya göre datayı(kırmızı bilgiyi) kriptolar, alıcı taraf da bu anahtara göre datayı çözer.

PT serisi daha çok donanımsal sebeplerden ve adresleme amaçlı kullanılıyor[Bu cümleyi düzelttim]. PT2272 alıcısı adres bilgisi uyuşmadığı sürece datayı çözmediğinden alıcının hata yapma ihtimali düşüyor ancak buradaki güvenliğin şifreleme ile ilgisi yok, nitekim adres ve data bitleri 3. kişiler tarafından rahatça görülebilecek/kayıt edilebilecek şekilde olduğu gibi kodlanmaktadır.

Bu yazıda bahsedeceğim denemelerimde PT2262 ile PT2272-M4 ve PT2272-L4 kullandım.

PT2272 nin 2 tipi var, (M)omentary ve (L)atched. PT2272 adından sonra gelen M ve L harfleri tipi belirtiyor. Hemen sonra gelen sayı ise data bit sayısını belirtiyor. PT2272-M6, momentary tip 6 bit data alabilen demek oluyor.

Alıcı-verici çiftinin çalışabilmesi için iki tarafın osilatör frekanslarının uyumlu olması gerekiyor(PT2272 nin 2.5~8 kat daha hızlı olması gerekiyormuş). Frekansları belirleyen dirençler için tavsiye edilen değerler datasheet ten de görülebileceği gibi tabloda verilmiş:

Ben 1.2M ve 200k seçeneğini kullandım.

PT2262 Tarafından Üretilen Dalga Şekilleri

Sistemin çalışmasına geçmeden önce PT2262 tarafından üretilen dalga şekillerine bir göz bakalım. Ayrıntılı katalogda verildiği üzere bir kod sözcüğü aşağıdaki bitlerden oluşmaktadır.

Görüldüğü üzere adres ve bilgi bitleri direkt gönderilmektedir. Buradaki bitlerin PT2262 tarafından nasıl kodlandığı ise aşağıda gösterilmiştir:

A3 ve A7 bitleri lojik1 diğer adres bitleri lojik0 olduğu durumdaki örnek bir kod sözcüğünün adres bitleri aşağıda görülmektedir:

Aşağıda da yazdığım üzere VCC, /TE şartları sağlandığı sürece kod sözcüğü tekrar tekrar gönderilmekte:

Kod sözcüğünün tüm bitleri bir osiloskopta veya daha güzeli PICKIT2 ayarında lojik analizörlerle gözlenebilir.

Sistemin Çalışması

2262 de /TE ucunu toprağa çektiğimizde iletim aktif oluyor, toprakta kaldığı sürece tekrar tekrar gönderiyor, gözlediğime göre her 16ms de tekrar gönderiyor.

Momentary tip alıcının(PT2272-Mx) data çıkışlarında, vericiden gönderdiğiniz veriyi sadece gönderildiği sürece görebilirsiniz. Çıkışları bir süreliğine görmek isterseniz bu süre boyunca /TE yi toprağa çekerek gönderim yapmanız gerekir(alıcıda bir süre “valid transmission” ledini yakmış olacaksınız).  Örneğin uzaktan kumandalı araba yapmak isterseniz;) momentary alıcı kullanmanız daha uygun olur. /TE yi topraktan çeker çekmez(iletimi durdurur durdurmaz) alıcı taraf OFF oluyor(çıkışlar floating). PT2272-M4 ün çalışmasının kısa bir videosu şöyle:

Vericide(2262) iletim aktifken datayı değiştirdiğinizde gönderilen veri güncellenmiyor. /TE toprağa çekildiğinde PT2262 o anda girişlerde gördüğü datayı kodluyor ve /TE toprakta kaldığı sürece girişlerin değişmesi çıkışı değiştirmiyor. Yani /TE ucu sanki bir örnekleme işlemi gibi toprağa çekildiğinde datayı örnekleyip kodlamaya başlıyor. Güncellenme için /TE nin yenilenmesi(1>0 yapılması) veya beslemenin resetlenmesi gerekiyor yani iletimin kesilip yeniden açılması gerekiyor. PT2262 nin datasheetinde diyotlar yardımıyla sadece butona basıldığında entegreye besleme uygulayan devrenin şeması var yani sadece düğmeye basılıyken entegrenin beslemesi veriliyor. Bu mantık güç tasarrufu açısından faydalı, sadece butona basıldığında enerji gitmesi data güncellenmesi problemini tek butona basılacaksa ortadan kaldırıyor ancak buton basılı tutulduğu esnada diğer bir butona basılması halinde veri güncellenmiyor(yukarıda bahsettiğimiz örnekleme problemi). Dolayısıyla uzaktan kumandalı arabanıza ileri komutu basılı iken bir süre sonra sağa dön komutu verdiğinizde dönmeyecektir! Eliniz çekip iki düğmeye birden basmanız gerekmektedir. Keyifsiz bir sürüş!  Bu durumu yukarıda verdiğim videonun son bölümünde göstermek istedim.

Latched tip alıcıda(PT2272-Lx) ise durum şöyle: PT2262 gönderdiği veriyi bir defalığına PT2272-L4 e ulaştırabilirse(alıcıdaki valid transmission ledini bir anlık yakabilirse) artık PT2272-L4 o data çıkışlarını vericiden bağımsız olarak sürekli tutar, PT2262 nin beslemesini çekseniz de PT2272-L4 ün çıkışları devam eder. Latched versiyonun çalışmasının kısa bir videosu şöyle:

Tahmin edeceğiniz gibi bir buton basılıyken diğer butonun işlevsiz kalması problemi burada da var(videoda gösterilmedi) ancak bu problem latch tipte momentary tipteki kadar kritik bir problem değil.

PT2262 nin data uçlarının birinden UART veri girip PT2272 den almak akla gelebilir ancak PT çifti bu konuda çok yavaş kalıyor daha doğrusu o iş için tasarlanmamış. Düğmelerle denediğim uygulamada düğme yerine 50Hz lik bir kare dalga uyguladığımda bile 2272 nin data ucunda bu kare dalgayı göremiyorum, RF modülsüz direkt kablo bağlantısı yapılmışken.

PT2262 ve PT2272 nin detaylı datasheetleri önceki bir yazıda da verildiği üzere bu bağlantıdan indirilebilir.

Son olarak PT serisinin pek de sevimli olmayan datasheetlerini dirtikleyip şema çıkarmaya üşenen(!) arkadaşlar için denemesini yaptığım devrenin şemasını veriyorum:

Yazıyı burada bitiriyoruz. Bu sefer de ertelememeyi deneyelim;) Çalışma hevesiniz daim olsun.

Ek notlar: Arkadaşlar katalogdaki örnek devre şemalarında adres bitleri hep “floating” bırakılmış. Girişler 3state olduğundan boş bırakmak da mümkün ancak ben denemelerimi adres bitlerini toprağa çekerek yaptığımı söylemiştim. Adres bitlerini değiştirmek istediğimde, mesela bir adres bitini dirençsiz +VCC ye çektiğimde PT2262 nin VCC verilmeksizin(herhangi bir düğmeye basılmadığı durum)(/TE toprakta tabi) veriyi kodlayıp gönderdiğini(entegrenin çalıştığını) gözledim, 10k ile çektiğimde  DOUT çıkışında genliğin 2V a düştüğünü ama yine de entegrenin çalıştığını gördüm. Bu durumlar(VCC pini bağlanmaksızın entegrenin çalışması) muhtemelen, girişleri korumak için konulmuş clamp diyotlar yüzünden olmaktadır. Dolayısıyla eğer adres bitlerini lojik1 yapmak istiyorsanız adres bitlerini çektiğiniz besleme gerilimi, sadece düğmeye basıldığında verilen besleme ile aynı olsun, VCC pini olabilir mesela. Yani düğmeye basıldığında entegre enerjilenmişti, adres bitleri de o zaman lojik1 olsun. Adres bitini sabit bir 5V a çekerseniz düğmeye basmasanız da(VCC gitmese de) adres girişlerinden entegre enerjileniyor ve kodlama/gönderme işlemi sürekli yapılıyor. Örnek şema:

Son olarak,  PT çiftinin kodlama ve kod çözme işlemleri, günümüz mikrodenetleyicileriyle yazılım ile de gerçeklenebilir.

Frekans, periyot ve “duty cycle” ölçüm uygulamalarında çeşitli mikrodenetleyiciler kullanıyoruz. Kullandığımız mikrodenetleyicilerde bu ölçümlerin yapılmasını kolaylaştıracak yardımcı özel donanımlar bulunuyor. PIC serisinden bildiğimiz “timer” lar, ccp modüller bu donanımlardan… Frekans, periyot ve “duty cycle” ölçmenin genel olarak uygulanan yöntemleri var, microchip yayınladığı bir uygulama notunda bu tarz ölçümlerin PIC mikrolarla kolayca yapılması için yöntemler önermiş, aşağıdaki linkten bu dökümana bakabilirsiniz:
CCP and ECCP Tips and Tricks

Biz de AT89S52 ile frekans ölçmek için mikromuzun timer1, timer2 sini kullandık. AT89S52 de “timer” ların çeşitli çalışma modları var. timer2  nin de “autoreload” diye bir modu var. Bu modda timer2 yi taştıktan sonra belirlediğiniz bir değerden başlatabiliyorsunuz.  Biz bu değeri timer2 her 50 ms de bir taşacak şekilde ayarladık. timer2 taşma kesmelerinin sayısı 20 yi bulduğunda 1 saniyelik süreç dolmuş demektir. Bu sayede net bir 1 saniyelik süreç elde ettik. Bu bir saniye içerisinde gelen kenar sayısını Port 3.5 pini vasıtasıyla timer1e saydırdık, böylece frekansı bulmuş olduk.

Timer1i 16 bitlik counter modunda kullandığımızdan en fazla 65535 Hz i saydırabildik. timer1 taşma kesmesi kullanarak bant genişliği kolayca 65535*2 Hz e veya daha yüksek değerlere çıkarılabilir. Öte yandan frekans bölücü entegreler yardımıyla “auto-scale” özelliği eklenerek daha büyük bant genişlikleri elde edilebilir. Ama biz bunlara zaman bulamadık ve 65535 Hz de en basit haliyle bıraktık.

Bu frekansmetrenin temel özellikleri:
*65535 hz bant genişliği
*Waveform dan bağımsız herhangi TTL işaretin frekansını ölçebilmesi
*LCD görüntü

Not: Kaynak kodda hex sayının bcd ye(binary codded decimal) çevrilmesi fonksiyonunda 8052.com daki bazı örneklerden faydalandık. Diğer kısımlar bize aittir.

İlgili dosyalar:
Proteus Simülasyon Dosyası + freq_met.asm + freq_met.hex
AT89S52 katalog
Proje Raporu(ing!)

Rf modüllerle veriyi sürekli gönderdiğimizi düşünelim, alıcı tarafta bu verilerin bir kısmı doğru alınırken bir kısmı yanlış alınıyor. Ama şöyle bir 5-10 elemanlık diziye baktığınızda gönderilen elemanı kestirebiliyorsunuz. Ben de dedim ki bu gelen 5-10 elemanı bir diziye dizeyim, sonra da dizi içinde en fazla geçen elemanı bulayım. Öncü veriyi yine kullanıyoruz ve arkasından “derinlik” adedince aynı veriyi gönderiyoruz, alıcı tarafta öncü veri geldikten sonra gelen “derinlik” adedince elemanı bir diziye yerleştiriyoruz, sonra da dizide en çok olan ve sayısı en az “enaz” değişkeni kadar olan veriyi bizim gönderdiğimiz veridir diye alıyoruz. Eğer öncü veri gelir de -ki siz göndermeseniz de gürültüden gelebiliyor- arkasındaki dizide “enaz” değişkeni kadar geçen eleman olmazsa fonksiyon 0 döndürüyor.

Kodda da görebileceğiniz gibi algoritmanın “derinlik” ve “enaz” adında iki temel parametresi var. Bu parametreler şunu diyor: Gelen “derinlik” tane elemanı bir diziye diz, sayısı “enaz” veya daha fazla olan elemanı seç.

Örn: ‘A’ verisini derinlik=10, enaz=3 ve öncü=’x’ olduğu durumda nasıl gönderildiğine bakalım:
rfgonder(‘A’);
TX: ªªxxAAAAAAAAAA
‘ª’ lar uyandırma işareti için-hiç kullanmayacağınız bir işaret seçebilirsiniz-, ‘x’ i ben öncü veri olarak seçtim. “derinlik” adedince ‘A’ arka arkaya gönderiliyor.

Alıcı tarafta ise en son görülen öncü veriden sonra alınan “derinlik” adedince veri diziye yerleştiriliyor. Örn alınan data şöyle olsun:
xc£#AA~A¥σAAЦ……
Bu gelen datanın en son görülen öncüden(bu örnekte zaten bir tane var) sonraki ilk 10 elemanı diziye yerleştirildi, şu anda dizide:
c£#AA~A¥σA elemanları var.
En çok geçen elemana bakıldı A, geçme sayısı 4, 3 ten büyük. Demek ki gönderilen verimiz ‘A’ dır.

Tabi bu şekilde veriyi daha güvenli iletirken hızımızı da düşürmüş oluyoruz.

Bu fonksiyon genel ve basit bir fonksyion, C ile yazıldı ve seri haberleşen herhangi iki modül arasında kullanılabilir. Ben CCS C de PIC ler arasında rf modül haberleşmesi üzerinden kullandım.

Alıcı ve verici tarafta bulunması gereken ortak parametreler:

#define oncu 'x'
#define derinlik 10

“derinlik” değişkenini iletişim hassasiyetinize göre belirleyebilirsiniz ve algoritmanın doğru çalışması için öncü veriyi haberleşmede kullanmayacağımız bir karakter seçmeliyiz.
Verici tarafta olması gerekenler:
prototip bildirimi:

void rf_gonder(int data);

fonksyionun kendisi:

void rf_gonder(int data){
int i=0;
putc(0b10101010);//alfanumerik olmayan bir karakter
putc(0b10101010);
putc(oncu);
putc(oncu);
   for(i=1;i<=derinlik;i++){
     putc(data);
 
   }
}

Kullanımı:

rf_gonder(veri);

Alıcı taraf:
Ben verileri serialdata kesmesiyle aldım, şart değil, uart olmayan mikrolar için sonsuz döngü içerisinde de veri alarak bu fonksiyonu kullanabilirsiniz(o şekilde de denedim).

enaz değişkenini hassasiyetinize göre istediğiniz bir değer yapabilirsiniz, fonksiyon prototipi ve gerekli bazı değişkenler:

#define enaz 3
int diziden_sec();
int gelen,i,durum=0; //durum=0 oncu verinin beklendiği durum
int dizi[derinlik];

Gelen verileri kesme ile aldığımı söylemiştim:

#INT_RDA
void data_geldi(){
gelen=getc();
if(gelen==oncu){
   durum=1;
   i=0;
}
else if(durum==1){
   dizi[i]=gelen;
   i++;
   if(i==derinlik-1){//veriler diziye yerleşti, degerlendirelim:
      durum=0;
      if(diziden_sec()){
        putc(diziden_sec());
      }
   }
}
 
}

Ve fonksiyonumuz:

int diziden_sec(){ //dizide en az "enaz" kadar geçen elemanı döndürür aksi durumlarda 0 döndürür.
int max=0,a=0,b=0,temp=0,indis=0;
for(a=0;a<derinlik;a++){
   for(b=0;b<derinlik;b++){
      if(dizi[b]==dizi[a]){
      temp++;
      }
   }
   if(temp>max && temp>=enaz){
      max=temp;
      indis=a;
   }
   temp=0;
 
}
if(max<=1){//hata oluştu, öncü alındı ama arkasından gelen dizi anlamsız
   return 0;
}
else{
   return dizi[indis];
}
}

Ben bu algoritmayı hem basit bir devrede hem de simülasyonda denedim. Derinlik=10, enaz=3 olduğunda alıcı tarafta beklemediğim hiçbir veriyle karşılaşmadım.
Simülasyon dosyası ve alıcı.c-verici.c dosyalarını burdan indirebilirsiniz.

Büyük resimden görüldüğü üzere servolarımızın üç girişi var, ikisi besleme üçüncüsü data(veya pwm) girişi yani darbe genişliği uyguladığımız giriştir. Hobi servomuzu kontrol etmek için bir kare dalga işaretinin darbe genişliğini belirli sınırlar içerisinde değiştiririz, yani ismini koymak gerekirse darbe-genişlik modülasyonu yaparız. Renklerden hangi pin ne işe yarıyor görebiliyoruz. Nitekim bizim servomuzda kahverengi:toprak, kırmızı:+, turuncu:data. Diğer hobi servolarda renkler nasıl bilmiyorum ama kırmızı(+) ve siyah(toprak) kablolar varsa kalan girişin pwm girişi olduğunu söyleyebiliriz.
Her şeyden önce servomuzu genel olarak nasıl sürüyoruz? Bu sorunun çoğu hobi servo için geçerli bir cevabı var:
20ms periyotlu bir kare dalga işaretimizin darbe genişliğini 1ms ile 2ms arasında değiştirerek hobi servomuza 0 ile 180 derece arasında açı veririz. Başka bir deyişle periyodu 20ms olan ve “duty cycle” ı %5 ile %10 arasında değişebilen pwm(darbe genişlik modülasyonu) işareti uygularız. Pwm demek istemiyorum çünkü bizim burda anlatmak istediğimiz sürme metodu “duty cycle” ayarlanmasından ziyade darbe genişliğinin mikrosaniyeler mertebesinden değiştirilmesi üzerine kurulmuştur. Yazının ilerleyen bölümünde sürme metodumuzun ne kadar basit ve temel bir işlem olduğu anlaşılacaktır. Servonun açısının ayarlanmasında periyodun 20ms olması şart değil, önemli olan uygulanan darbenin genişliği. Servonun belirlediğimiz konumda kalması için bu bilgiyi sürekli güncelliyoruz(her 20 ms de mesela), bu işareti kestiğinizde(besleme duruyor tabi) servo son açısında kalıyor ancak ufak bir tork servonun açısını değiştirebilir. Yani siz eğer yüke bağlı servonuzu belirli bir konumda tutmak istiyorsanız 20ms belki daha da düşük periyotlu bir işaretle servoyu kontrol etmeniz gerekir.

Ancak bu darbe aralıkları her hobi servo için böyle değil (şimdiden sonra yazı boyunca hobi servo yerine servo diyeceğim). Nitekim bizim kullanacağımız servonun darbe aralığı 540 us ile 2400 us arasında. Peki biz bu darbe sürelerini nerden öğreneceğiz, yok mu bu kullanacağımız servonun teknik bilgileri? Yok ne yazık ki. Burda kullanacağımız servonun web sitesinde motorun temel özelliklerini yazmakla yetinmişler, servo işte siz sürersiniz demek istiyorlar heralde(site:http://towerprocn.sh15.host.35.com/towerprocn/english/servo/SERVO.html).
Her marka servo için durum böyle değil tabii ki, mesela futaba’nın sitesinde motorun sürülmesi için gereken tüm bilgiler verilmiş(site:http://www.gpdealera.com/cgi-bin/wgainf100p.pgm?I=FUTM0503):

Torque: 196 oz-in @ 6V
(13.8 kg-cm @ 6V)

Communication: Pulse Width Modulation (PWM)
Operation range: 180°
Pulse cycle: 14.25ms
Pulse width: 920-2120us
gibi.
Bizim motorumuzun bu bilgileri verilmemiş ama olsun, bu bilgileri kendimiz buluruz hem de daha öğretici bir çalışma yapmış oluruz. Çalışmamızda mikro olarak 16F628 PIC mikro, dil olarak CCS C dili seçilmiştir.

Bu bilgileri bulma işine girmeden önce servomuza bir hareket verelim, bakalım çalışıyor mu! Servomuza 1ms darbe genişliği uygulayarak konumlandığı açıya bakalım. Besleme gerilimi olarak servonuzun teknik bilgilerine bakabilirsiniz. Bizim servomuz için “Operating voltage 4.2-6V” denilmiş. Genel olarak 6V uygulanabilir, ben 5V uyguluyorum. Servomuzun data girişine b0 pinini bağlayacak olursak bunun için bizim yazacağımız temel kod:

while(1){
      output_high(pin_b0);
      delay_us(1000);
      output_low(pin_b0);
      delay_us(19000);
}

olacaktır.
Evet ben servoları sürerken timer kullanmıyorum, bu yöntemle yaptığım denemelerden gayet memnunum. Dolayısıyla temel kodumuz bu basitlikte. Şimdi eğer:

long b0=600;
while(1){
      output_high(pin_b0);
      delay_us(b0);
      output_low(pin_b0);
      delay_us(20000-b0);
}

yazarsak servomuzun pozisyonunu b0 değişkeniyle kontrol edebiliriz. Hobi servo sürmek bu kadar basit:)
Şimdi gelin servomuzun hangi darbe aralıklarında çalıştığını öğrenelim. Ben bunu şöyle yaptım: devremde iki adet düğme var, düğmelerden biri b0 değişkenini 50us arttırıyor, diğeri 50us azaltıyor. Düğmelere basarak ilerlerken b0 değişkenini her değişmede bilgisayara gönderiyorum, yani şu anki b0 değerini takip diyorum.
Ne zaman ki servo artık değişime tepki vermiyor(daha fazla dönemiyor) o b0 değeri benim sınır değerim oluyor. Tabi bu teste başlamadan servomuzun ilk konumunun ortada bir yerde olması için b0 ın ilk değerini 1000us civarı seçmeliyiz. Bu işi yapan kod:

long b0=1000;
while(1){
if(!input(pin_b3)){ //dugmeye basildi
      b0+=50;
      delay_ms(200);
      deger=b0/10;
      putc(deger); //8 bitlik sayıyı bilgisayara gönder
}
if(!input(pin_b4)){ //dugmeye basildi
      b0-=50;
      delay_ms(200);
      deger=b0/10;
      putc(deger);
}
      output_high(pin_b0); //surmeye devam
      delay_us(b0);
      output_low(pin_b0);
      delay_us(20000-b0);
 
}//while

Bilgisayara göndermek şart değil b0 ın ilk değerini programınızda 1000us gibi sabit bir sayıya eşitleyin sonra düğmeye kaç defa bastıysanız o kadar 50 us ekleyerek(veya çıkararak) servonuzun sınır darbe genişliklerini tespit edebilirsiniz. Her düğmeye bastığınızda “toggle” eden bir led olursa adım kaçırmazsınız.

Sınır değerleri de bulduysak artık servomuzu istediğimiz açıya getirebiliriz. Peki ne kadar bir hassasiyetle? Devre düzeneğinizi bozmadan düğmelerle değiştirdiğiniz b0 değerini 50 us değil de daha az yapın, bakalım tepki veriyor mu? Bizim servomuz için bu hassasiyet “Dead band width =10 us” olarak verilmiş. Bu da yaklaşık 1 dereceye tekabül ediyor.

Peki bu yöntemle aynı anda kaç servoyu sürebiliriz?
Benim şu anda elimde 2 servo var, 2 sini rahatlıkla sürebiliyorum. ISIS simülasyonda 5 servoyu sürüyorum. Yazılan kod yine aynı mantıkta, 3 servo sürmek istersek:

long s1=650,s2=650,s3=650;
while(1){
      output_high(pin_b0);
      delay_us(s1);
      output_low(pin_b0);
 
      output_high(pin_b3);
      delay_us(s2);
      output_low(pin_b3);
 
      output_high(pin_b4);
      delay_us(s3);
      output_low(pin_b4);
 
      delay_us(20000-s1-s2-s3);
 
}//while

Gelelim bu bilgilerimizi güzel bir uygulamada kullanma kısmına:
Servolarımızı s1, s2, s3 değişkenileriyle kontrol edebileceğimizi gördük, peki bu değişkenleri nasıl değiştireceğiz? İlk uygulamamızdaki gibi düğmelerle mi? Bu değerleri bilgisayarımızdan göndersek nasıl olur?
…
Bence de güzel olur. Ancak bunun için küçük bir program yazmalıyız ve bir de arayüz hazırlamalıyız. Bence bu iş için en uygun yol visual studio.net ortamında C# kullanmak. Serialport nesnesi, hazır form elemanları ve kontrol kolaylığı tam bize göre. Yani bilgisayar kısmında işimiz kolay. Peki gelen verileri PIC le nasıl alacağız? UART kesmesiyle.
Kodumuz gayet basit:

while(1){
 
      output_high(pin_b0);
      delay_us(s1);
      output_low(pin_b0);
 
      output_high(pin_b3);
      delay_us(s2);
      output_low(pin_b3);
 
      output_high(pin_b4);
      delay_us(s3);
      output_low(pin_b4);
 
      delay_us(20000-s1-s2-s3);
 
}//while
}//main
 
#INT_RDA
void seri_data_geldi(){
bx=getc(); // bx de long türünden
 
if(bx==200){ //sira ilk motorun
   sira=1;
}
if(bx==220){//sira ikinci motorun
   sira=2;
}
if(bx==240){//sira ucuncu motorun
   sira=3;
}
 
if(bx<200){ //gelen veri motorlara
if(sira==1){
   s1=10*bx+540;
}
if(sira==2){
   s2=10*bx+540;
}
if(sira==3){
   s3=10*bx+540;
}
}
output_toggle(pin_a1); //kesme geldi belirteci
}

Peki elimizde servo yoksa bu uygulamayı Proteusta simüle edebilir miyiz? Evet. Bunun için öncelikle “eltima virtual serial port” programı gibi bilgisayarımızda virtual serial port oluşturabilecek bir programa ihtiyacımız var. Çünkü “virtual port” oluşturamazsak visual studio.net ile açtığımız porta proteus bağlanamayacak, proteusla açtığımız porta vs.net bağlanamayacak. Bahsettiğim virtual serial port programı bilgisayarımızda birbirine bağlanmış sanal port çifti oluşturuyor, örn com1 ve com2 olarak. Proteustan com1 e bağlanıp başka programlardan com2 ye bağlanarak iki program arasında iletişimi sağlayabiliyoruz.

Dikkat etmemiz gereken bir diğer nokta proteusta kullandığımız servonun sağ tık menüsüyle açılan özelliklerinin kendi servomuzla uyuşuyor olmasıdır.

Çalışmamızdan bazı resimler:

—
EK NOTLAR:
14 Mayıs, 2010
Büyük servo sürerken servo harekete geçerken devrenin kaynağına bir anda yüklendiğinden mikro devresi(bizde PICli devre) reset atabiliyor. Buna karşı alacağımız ilk önlem PIC in besleme uçlarına büyükçe bir kapasite bağlamak. Bu da her zaman çözüm olmayabiliyor, servo sürücü ile PIC kaynağı nın izole edilmesi konusu zamanında denemediğim bir çalışma. Duruma göre farklı önlemler almak gerekebilir.
—
Çalışmayla ilgili tüm dosyalar:
Proteus(7.1 SP4) Simülasyon, servo3.c, servo3.hex
C# Proje Klasörü

Solda udea, sağda keymark çifti.
Geçtiğimiz günlerde bu iki modül için de minimum test devresi ve minimum test yazılımı oluşturmaya karar verdim ve iki modül için de denedim, denemeler başarılı. Modülleri test etme aşamasına gelmeden önce donanım ile alakalı problemleri aşmış olmamız gerekiyor, devrenizi kurup son haline getirdiğinize kanaat getirdikten sonra tüm gerilimleri voltmetrenizle kontrol ettiniz mi? Keymark modüller için verici besleme geriliminin 3V olduğuna emin misiniz? Her iki(alıcı-verici) devre için de besleme gerilimlerinin iyi regüle edilmiş olduğuna emin misiniz? Nitekim ben deneme yaparken kullandığım şarjlı pilin pic i çalıştırdığını ama çok kararlı olmadığını fark edip pili şarj ettikten sonra kullandım.

Bir de bu modülleri kullanmak isteyen arkadaşların ilk aklına gelen test devresi verici tarafın data girişine DC uygulayıp alıcı tarafın data çıkışında led yakmak oluyor. Bu benim zamanında hiç düşünmediğim bir olaydı. Belki de DC bir işaretin modüle edildiğine hiç rastlamadığımdandır. Bahsettiğim test devresinde(çalıştığını görüp emin olduğum) bu olayı denedim, verici girişine DC(5V) verdim ve alıcı çıkışına bir led bağladım, led yanıyordu ama girişi toprağa çektiğimde de yanıyordu. Yanma dediğim de kararlı bir yanma değil, seğirme şeklinde(her iki durumda da). UDEA teknik döküman sayfasında modüller için UHF bandında ASK(amplitude shift keying) kullanıldığı söylenmiş. Şimdi bu(ASK) ON-OFF keying şeklinde de olabilir yani modüllerimiz lojik 1 için 433 MHz lik bir işaret gönderirken lojik 0 için hiç bir şey göndermiyor veya farklı genlik seviyeleri kullanılmış olup lojik 1 için A genliğinde 433 MHz lik bir işaret gönderirken lojik 0 için B genliğinde 433 MHz lik bir işaret gönderiyor olabilir. Eğer ilki gibiyse verici girişini toprağa çektiğimizde hiçbir şey göndermiyoruz demektir, alıcımız ortamdan ne gürültü alıyorsa ona göre ledi yakacak demektir. Alıcı modülün data pininin led sürme kabiliyeti ise ayrı mesele… Yani bana sorulursa bu modüllerle DC gönderme işi uygun değil. Eğer uzaktan kontrol etmek istediğiniz elemanlar led, röle gibi bir bitle kontrol edilecek elemanlar ise PIC kullanmaksızın PT2262-PT2272 çiftini kullanarak rf modüller üzerinden güvenli bir şekilde veri gönderebilirsiniz.

Gelelim kendi test devremize, öncelikle biz test verisi olarak kullandığımız mikro(PIC)lar tarafından desteklenen RS232 protokolüne göre ‘A’ veya ‘B’ verilerini göndereceğiz ve alacağız(DC değil). Dolayısıyla her iki tarafta da PIC olacak, kutumda 16F628(verici) ve 16F628A(alıcı) vardı ben onları kullandım. Kodları diğer pic lere uyarlayabilirsiniz.

Testimiz şöyle:
alici.hex ve verici.hex dosyaları uygun PIC lere yüklendiyse şemadan da takip edebileceğiniz gibi:
Alıcı tarafta A0 ve A1 pinlerine bağlı iki ledimiz var, bu ledler şuna göre yanıyor: Eğer son gelen veri ‘A’ ise A1 pinine bağlı led yanacak, eğer son gelen veri ‘B’ ise A0 pinine bağlı led yanacak. Verici tarafta ise B4 ve B5 pinlerinden en fazla bir tanesini toprağa çekeceğiz. Eğer B4 pini toprakta B5 pini VDDde ise ‘A’ gönderiyoruz, B4 pini VDDde B5 pini toprakta ise ‘B’ gönderiyoruz. Bu işlem için “buton” kullanmayalım, boşta bıraktığımız kablolarla istediğimiz pini toprağa çekme işlemi yapalım. Yapılacak nihai işlem bir pini toprakta diğer pini VDDde bırakmak ve test için toprak-VDD sırasını değiştirmek. Böylece herhangi bir durumda (‘A’ gönderirken veya ‘B’ gönderirken) verimizi kısa bir sürelik değil sürekli gönderiyor olacağız, tabiri caizse alıcımızı veri yağmuruna tutacağız. Bu durumda alıcı modülün uyanmama, geç kalma gibi bir sorunu olmuyor. Alıcı için verimizi alabileceği en kesin durumu sağlıyoruz.
Her testin bir geçme-kalma şartı vardır, bizim testimizin şartı ledlerin yanıyor olması değildir, gönderdiğiniz veriyi değiştirdiğinizde alıcıda yanan ledin değişmesidir. Yani devrenizin doğru değişikliğe doğru cevabı vermesidir. Nitekim alıcıdaki ledlerin yanması çok olası bir durum, şöyle ki: verici kısmı çalıştırmadan önce alıcı kısmı çalıştırın, ne görüyorsunuz? Bir süre sonra ‘A’ verisine ait led yandı veya ‘B’ verisine ait led yandı… Bu verileri bizim göndermediğimiz kesin(verici devrenin beslemesi bağlanmadı) peki kim gönderiyor? Nasıl olur da biz veri göndermeden alıcımız sanki doğru verileri almış gibi ledleri yakıyor!
Bu bir şekilde oluyor arkadaşlar, çevreden gelen bazı etkiler modülleri yanlış yorumlatabiliyor. Bu gözlem modüllerin ne gibi yanlış anlaşılmalara yol açabileceği açısından faydalı bir gözlem(verici devreyi çalıştırmadan alıcı devreyi çalıştırıp olup biteni gözleme).
Bu yüzden modülleri test ederken doğru değişikliğe doğru tepkiyi vermelerinin gerektiğini söyledim.
Öncü veri kullanarak bu yanlış anlaşılma durumunun çok büyük ölçüde önüne geçebiliyoruz, dileyen arkadaşlar ekteki dosyalarda pre_alici.c ve pre_verici.c ye bakabilirler. Ancak bizim şu anki konumuz modülleri en basit şekilde çalıştırmak, doğru değişikliğe doğru tepki verdiğini görmek. Devreyi proteusta çizip simüle ettim(kablolu haliyle), kurduğum devre simülasyon ortamındakinden farksız sadece kablo yerine modülleri bağladım:

Bu arada bu test devresi ve vereceğim test yazılımında iki modül de gayet başarılı bir şekilde çalışıyor ancak keymark biraz nazlandı, bir kaç defa reset attım sonra düzgün çalışmaya başladı. Bir de yazarken aklıma geldi keymark modülleri birbirinden 1m kadar uzaklaştırıp denemekte fayda olabilir. Son olarak modüllerimizi yakın mesafede test ettiğimiz için anten bağlamaksızın çalıştırabiliyoruz. Aynı test devresini daha uzak mesafelerde denemek için 50 ohm empedanslı 17 cm uzunluğunda anten kullanabilirsiniz. 50ohm luk anteniniz yoksa 17cm lik metal bir tel kullanabilirsiniz(50 ohm luk antene göre daha düşük verimle çalışacağını kabullenerek)

verici.c

//UDEA ve Keymark RF atx arx alıcı-verici modüller için test programı, 6 Mayıs 2008
//verici.c
//fatiherdem.net
#include <16f628.H>
#fuses INTRC_IO, NOMCLR, NOPROTECT, NOWDT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=PIN_B2, rcv=PIN_B1)
 
void main(){
output_high(pin_b3); //calisma gostergesi
while(1){
if(!input(pin_b4) && input(pin_b5)){
putc('A');
}
if(!input(pin_b5) && input(pin_b4)){
putc('B');
}
 
}
}

alici.c

//UDEA ve Keymark RF atx arx alıcı-verici modüller için test programı, 6 Mayıs 2008
//alici.c
//fatiherdem.net
#include <16f628A.H>
#fuses INTRC_IO, NOMCLR, NOPROTECT, NOWDT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=PIN_B2, rcv=PIN_B1)
 
void main(){
char a=0;
output_low(pin_a0); //cikislari temizle
output_low(pin_a1);
output_high(pin_b3); //calisma gostergesi
 
while(1){
a=getc();
if(a=='A'){
output_high(pin_a1);
output_low(pin_a0);
}
if(a=='B'){
output_high(pin_a0);
output_low(pin_a1);
}
 
}
}

Bir resim:

İlgili tüm dosyalar:
Simülasyon(proteus) + kod(verici.c, alici.c, pre_verici.c, pre_alici.c, *.hex)

Modüllerin Katalogları (UDEA ve Keymark için)

Çalışmayla ilgili resim-video (60 Mb) (Öğretici içerik notu: %15)

Öncelikle modülleri deneyebileceğimiz hem de basit bir uygulama sayılabilecek bir devre kuralım. Alıcı tarafta bir LCD ekran olsun ve vericiden gelen veriyi ekranda göstersin. Bu sistemi alıcı verici olacak şekilde hazırlayalım ve RF modüllerden önce sistemi kablolu iletişimle deneyelim. Kablolu iletişimde sorun oluyorsa RF modüllerden veri iletimini gerçekleştirmesini beklemek olmaz! RF modüllerle iletişim denemesine geçmeden önce kablolu iletişimin sorunsuz çalıştığına emin olmamız lazım. Ben veri olarak RS232 protokolü kullanarak “A”, “B”, “C” gibi harfler -daha doğrusu ASCII karşılığındaki sayıları- gönderdim. Kablolu düzgün çalışıyorsa RF modüller denenmeye hazırdır(baudrate uygunsa tabi). Kablolu sisteminiz çalıştıysa iki sistem arasındaki haberleşme kablolarını(toprak,data) çıkarın. Verici ve alıcı modüle besleme gerilimlerini ve topraklarını bağlayın, anten bağlamanıza şimdilik gerek yok (yakın mesafelerde-2m- gerek olmuyor). Data pinlerini de bağlayıp modülleri birbirinden en az 1 m olacak şekilde uzaklaştırın ve çalıştırın. Veri alışverişi gerçekleştiyse ne ala! Güle güle kullanın! Ama çalışmadıysa…..!

İlk olarak alıcı verici modüllerin ve sisteminizdeki diğer elemanların besleme gerilimlerine bakın-mikrodenetleyicilerinizin bir pinini çalışma işareti olan bir ledi yakması için ayırmakta fayda var-. Özellikle keymark ın verici modülüne 3V besleme gerilimi vermek isterken potla -gerilim bölücü- ayarladığımız 3V, yüke bindikten sonra 2 lere düşecektir. Bu yüzden sistemi çalıştırdıktan sonra gerilimi yeniden ayarlamamız gerekecektir. Besleme gerilimlerinde sorun yok tüm değerler olması gerektiği gibiyse eğer kullanma imkanınız olan bir osiloskop ve sinyal üreticisi varsa modüllerinizi deneyebilirsiniz. Verici modülünüze kare dalga uygulayıp(data pininden tabiki) alıcı modülün data pininden verdiğiniz işareti gözleyerek modüllerin sağlamlığını test edebilirsiniz. Test ettiniz ve sağlamlar! O zaman yazdığımız kodu yeniden düzenlemek durumundayız. Nasıl? Nasılına gelmeden önce: Lab imkanınız yok ve modülleri test edemediniz, modülleri sağlam varsayarak kod denemeleri yapmaya devam etmeliyiz.

Baudrate ve alıcı verici pinleri yeniden gözden geçirin!

Kablolu iletişim sorunsuz ise alıcı verici pinlerde sorun yok demektir ancak baudrate dediğimiz saniyede aktarılan bit sayısını bildiren değişkenimizin de doğru değerde olması gerekiyor. RF modüllerinizin kataloğunda(datasheet) vericinin gönderebileceği azami veri hızı ve alıcının alabileceği azami veri hızına dikkat edin. Benim kullandığım modüllerde verici için asgari 300 bit/saniye (yani baud 300) azami 1kbit/saniye diyordu. Bu durumda 9600 baudlu bir iletişimi bu modüllerden bekleyemeyiz. Ve tabi ki baudrateleri düzenlerken her iki tarafta da aynı olmasına dikkat etmek gerekiyor. Herhangi bir baud da iletişimi sağladıktan sonra denemeler yaparak en iyi hangi baud da çalıştığını tespit edebilirsiniz.

Yine çalışmadı sorun başka ne olabilir?

Osiloskop-sinyal üreticisiyle testiniz gayet başarılı, tüm bağlantılar ve gerilimler doğru, yazılım olarak da kablolu sistemde çalışan kodlar var ancak yine de çalışmıyorsa RF modüllerde halledilmesi gereken daha ince bir problem var demektir. Benim problemim şuydu: alıcı modüldeki clock çok kısa bir süre geç çalışıyordu. Yani kendisine gelen verinin ilk kısmını geç çalıştığı için kaybediyor geri kalan kısmını alıyordu haliyle alıcı taraf bu kırpılmış işaretten hiç bir şey anlamıyordu. Bu kanıya varmamdaki sebep (http://www.ottawarobotics.org/articles/rf/rf.html) bağlantısındaki yazıda yazarın benzer bir sorun yaşamış ve sorunun sebebini clock gecikmesi olabileceğini söylemesidir. Nitekim biz de osiloskop ekranında bir takım çok kısa zamanlı gecikmeler gözlüyorduk ancak o gecikmelerin clock un geç çalışmasıyla alakalı olup olmadığını bilemiyorum. Şu anki gözlemlerim clock un sadece başlangıçta biraz gecikme ve veri kaybına sebep olabileceği şeklinde. O yazıda yine arkadaşın şöyle mantıklı bir tesbiti var: “Çoğu RF alıcısı gelen veriyi hemen almak için hazır değildir”, bu yüzden önden bir uyandırma işareti gönderdip alıcıyı şöyle bir sarsıyoruz. Dalgın bir arkadaşımıza bir şey söylemeden önce kendsine bağırmak gibi -biraz kaba bir benzetme oldu ama-

Bu sorunu nasıl çözdük?

Madem clock bir süre geç çalışıyor biz de bir süre anlamsız işaret göndererek-herhangi bir işaret- clock un düzgün çalışmasını bekler ve hiç bekletmeden verimizi göndeririz. Nitekim böyle yaptığımızda verileri başarıyla gönderebildik. Okuduğum yazıların birinde bu işaret için uyandırma işareti ifadesi kullanılmış, bence isim çok güzel uymuş. CCS C kodu olarak bu işlemi aynen şöyle yapmış oluyoruz:

putc(0b01010101); //uyandır

putc(veri); //veri gönder

Alıcı taraf bu uyandırıcı sinyali zaten algılamayacaktır, tesadüfen algıladığında veya bir şekilde başka bir veri olarak yorumladığında(yanlış bir veri göndermiş olduğumuzda) ne olacak? Cevabı aşağıda geliyor(öncü veri başlığı altında).

Uyandırma işaretini neden 0b01010101 olarak seçtik ve Manchester Code

Bu sorunun cevabı da Manchester Code olarak adlandırılan kodlama sistemin mantığıyla ilgili. Kendim bizzat deneyip görmemekle birlikte şunları söyleyebilirim: RF vericiye veri gönderilmeden önce bu verideki 0 lar 01, 1 ler ise 10 olarak kodlanıp (Manchester Encoding) veriliyor(8 bitlik veri 16 bite çıkmış oluyor) böylece arka arkaya gelene 0 lar veya 1 ler ortadan kaldırılmış oluyor.

Örnek: 0b 0 1 0 0 0 1 0 0 verisi 0b 01 10 01 01 01 10 01 01 haline geliyor. Bu veri sonra tekrar alıcı tarafta 8 bitlik ilk haline geri döndürülecek(Manchester Decoding).

Arka arkaya gelen 0 lar veya 1 lerin RF modülün veri iletimi için sağlıksız olduğu söyleniyor. Arka arkaya gelen aynı bitler bir sonraki gelen farklı ilk bit için değişimi zorlaştırdığından bu şekilde bir kodlamanın daha uygun olduğu söyleniyor, ben denemedim-görmedim. Bu mantığa göre 01 lerin uyandırma için daha uygun olduğunu düşündük-ama şart değil, başka işaretler de bu işi görüyor-.

Not: Manchester encoding ile alakalı şu pdf ye bakabilirsiniz(ing).

Öncü Veri (“Preamble”) Nedir?

Benim elimdeki RF modül çiftlerinin birinin alıcısı diğerinin vericisiyle çalışabiliyor. Bu durumda aynı ortamda iki farklı modülü haberleştirmek mümkün olmayacaktır çünkü veriler her iki modülde de anlam bulacağından karışıklık olacaktır. Bunu çok basit bir mantıkla hallediyoruz: Verimizi göndermeden önce kimliğimizi bildiren başka bir veri gönderiyoruz. Örnekten kolayca anlaşılacaktır:

Örnek:

Verici tarafa:

putc(0b01010101); // uyandırma

putc(‘x’); // ben x ten geliyorum

putc (veri); // verimizi gönderiyoruz

Böylece alıcı tarafa nerden geldiğimizi bildirebiliyoruz. Alıcı tarafta ise:

if (getc()==’x'){ //eğer veri x vericisinden geliyorsa

gelen_veri=getc(); //veriyi al

}

şeklinde yazarız. Öncü veriyle iki modül çiftinin karışmamasını sağladığımız gibi ortamdaki gürültülerden de %100 olmasa da sıyrılmış oluyoruz. Bu açıdan da öncü verinin önemi vardır. Yani bir ortamda sadece bir modülün çalıştığına emin olsak da, öncü veri kullanarak ortamda bulunabilecek anlamsız işaretlerden azami düzeyde sıyrılabiliriz.

Umarım RF modüllerle çalışan arkadaşlara yardımcı olmuştur, iyi çalışmalar dilerim.

Step motorlar ve servolar… işlev olarak çok yakınlar ve çoğu uygulamada birbirleri yerine kullanılabiliyorlar. Bu iki motora da açı(veya pozisyon) kontrollü hareket yaptırabiliyoruz. Ancak step motorlar yapı itibariyle servolardan çok daha basit, step motorlar kalıcı mıknatıs(permanent magnet) ve sarımlardan oluşurken servoların içinde bir kontrol devresi bulunmaktadır. Bu iki motorun da çok geniş bir kullanım alanı var ancak ben step motorları en çok CNC makinelerinin eksen hareketlerinde görüyorum, servoları ise açılı hareketin çok önemli olduğu robot kolu uygulamalarında çokça görüyorum.

Bizim sürdüğümüz step motor ise hepsinden basit Torku ancak yazıcıya kağıt alabilecek büyüklükte olan mütevazı bir motor. Step motorlarda rotor(ortada dönen parça) kalıcı mıknatıslardan oluşuyor stator(rotoru çepeçevre saran hareketsiz bölüm) da ise sarımlar var. Rotordaki kalıcı mıknatıs sayısı ve statordaki sarım sayısı tamamen motorun özellikleriyle ilgili. Sarımlar rotor etrafını sarmış sıralı bir şekilde duruyor(resmi aşağıda-bir resim altta-):
Kalıcı mıknatıslardan oluşan rotor:

Resim www.overclockers.com dan alınmıştır.

Statordaki sarımlar(4 tane):

Resim www.allaboutcircuits.com dan alınmıştır.

Motorun sürülmesi işlemi ise bu sarımları belirli bir sırayla mıknatıslandırmaktan ibaret, teker teker veya 2 li 1 li 2li… gibi bir sırayla mıknatıslandırarak motorumuzu sürebiliriz. Sarımı mıknatıslandırmak? Sarıma akım vererek mümkün tabi. Akım vereceğiz ancak önce motorumuzdan çıkan kabloların hangisi hangi sarıma ait bunu bilmeliyiz. Sarımlarda bazı uçlar ortak olmuş olabilir(aşağıdaki gibi) veya tüm sarımların uçları dışarı verilmiş olabilir. Tüm bunları anlamanın yolu bir ohmetre ile bakmaktan geçiyor. Her bir sarımın yaklaşık 80-100 ohm civarında bir direnci var, ohm metreyi elinize alın ve başlayın 2 şerli ölçüm almaya. Çiftlerin birinde 100 ohm okudunuz! Hah! bir sarımı buldunuz demektir. 200 ohm okuduysanız bir ortaklık var demektir, ortak ucu bulmaya çalışın Bu şekilde tüm sarımları keşfettikten sonra sürücü devre işlemine başlayabiliriz.

Herhangi bir sarımı mıknatıslandırdığımızda rotordaki en yakın mıknatıs mıknatıslandırdığımız sarımın manyetik doğrultusuna girer. Sonra bir yandaki sarımı mıknatıslandırırız ve rotordaki en yakın mıknatıs yeni mıknatıslanan sarımın manyetik doğrultusuna girer, rotordaki kalıcı mıknatısların ve statordaki sarımların yerleşim biçimi bu iki hareketle motorun bir adım ileri atmasını sağlar. Aşağıdaki resim rotorda sadece tek kalıcı mıknatıs olsaydı ne olacağını gösteriyor, bizim tarif etmeye çalıştığımızın aşağıdaki olaydan tek farkı rotorda tek mıknatıs değil birden çok mıknatıs olmasıdır(Rotorumuzun örnek resmini yukarıda vermiştik). Hangi mıknatısa göre yön belirlenecek sorusunu sorabilirsiniz, rotordaki kalıcı mıknatıslardan mıknatıslanan sarıma en yakın olan mıknatısa göre Bu motorun tasarımıyla ilgili bir durum şu anda bizi çok da ilgilendirmiyor, sürme işlemi için yapmamız gereken sarımları uygun bir şekilde mıknatıslandırmaktan ibaret. Aşağıdaki hareketli gösterimde a ve b sarımları için ortak uçlar ayrı, bunlar da ortak olabilir yani 4 sarımın da bir tek ortak ucu olabilirdi, bu durumda motorumuz 6 uçlu değil 5 uçlu olurdu.

Resim :http://www.cefetrs.tche.br/tro/alunos/motordepasso/toppage1.htm adresinden alınmıştır.

Resmi aldığım adrese bakarsanız bu resmin yanında yarım adım sürme ile ilgili resim var, 2 li 1li derken onu anlatmaya çalışmıştım, hareketli gösterimde çok güzel anlatılmış. Hazırlayanların eline sağlık.

Sarımları mıknatıslandırma işlemi için bir devre düşünelim. Şartlarımız:
1) İstediğimiz sarımı istediğimiz zaman mıknatıslandırabilmeliyiz (mikrodenetleyici kontrollü -eğer tek tip sürüş yapacaksak senkron(clock sinyali ile çalışan) bir lojik devre ile de sürebiliriz)
2) Devremiz tarafından yeterli akım sağlanmalı

Akım verdiğimiz sarımları daha hızlı değiştirirsek  motorumuzu hızlandırabiliriz. Ne de olsa akımın hangi sarımdan akacağını dijital olarak kontrol ediyoruz. Ancak bu hızı da bir yere kadar arttırabiliriz, bir sarıma akım vererek mıknatıslandırıp rotoru gelmesi gereken pozisyona gelmeden diğer sarıma geçersek motorumuz bu hıza cevap vermeyecektir. Bu süreyi nasıl ayarlayacağız? Ben hız denemesi yapmadım, aşağıda verdiğim programdan da anlaşılacağı üzere adımlar arasında 500 ms beklemişim(epey uzun bir süre), siz bu süreyi kısaltarak ne kadar kısaltabileceğinizi test edebilir, motorunuzun ne kadar hıza ulaşabileceğini görebilirsiniz.

#include <16f628.H>
#fuses INTRC_IO, NOMCLR, NOPROTECT, NOWDT, NOLVP
#use delay(clock=4000000)
main(){
//int a[8]={1,3,2,6,4,12,8,9};
//int a[4]={1,2,4,8};
//int a[2]={1,4};
int a[4]={8,4,2,1};
int i=0;
while(1){
 
output_b(a[i]);
delay_ms(500);
i+=1;
 
if(i==4){
i=0;
}
 
}

Tekrar devremize dönersek: İlk aklımıza gelen herhangi tip bir transistorü anahtar(switch) olarak kullanıp bu anahtarları mikrodenetleyici veya lojik devre ile kontrol etmek . Bu işi önceden yapan arkadaşların devrelerine baktığımız zaman ULN2003 adlı bir entegrenin sıkça kullanıldığını görüyoruz. Bu entegrenin içinde 8 tane darlington var, bahsettiğimiz ilk yöntemden farklı değil, sadece daha yüksek akım için darlington yapısı kullanılmış.
Bizim motorumuzun keşfettiğimiz 4 tane sarımı vardı. 6 uçlu(kablolu) bir motordu, 2 sarımın da ortak olduğu bir nokta vardı, bu uçları +VCC ye bağlamıştık(aşağıdaki resmi inceleyeiniz, bunu yapıp yapmamakta serbestiz, farklı kombinasyonlarla farklı sürüşler uygulanabilir) ve kalan uçlarından hangisini toprağa çekersek o sarım mıknatıslanıyordu. Yani sürme işlemi için ULN2003 ün 8 darlingtonundan 4 tanesi bizim için yeterli. Devre şemamız ise şöyle:

Çok emin olmayarak(hata olabilir) hazırladığım Proteus Simülasyon ve CCS C kaynak kodunu indirmek için buraya tıklayınız.
Videosu:

Yavaş gösterim:

Kayan yazı çalışmalarına aşağıda verdiğim bağlantıdaki yazıyı okuyarak başlamıştım. Bu yazıyı okudaman önce kayan yazılar hakkımda neredeyse hiç fikrim yoktu.
http://www.biltek.tubitak.gov.tr/gelisim/elektronik/17.htm
Ancak bu yazıdan sonra bütün kayan yazılar böyle çalışır gibi davranmayınız. Büyük panolar için daha farklı tarama mantığı(satır tarama) ve farklı devre elemanları gerekmektedir. İyi çalışmalar.