Etiket arşivi: EFM8

EFM8 ile I2C Master

Bir Cevap Yazın

Çalışma Frekansı Ayarı

Master mode’da, SCL ‘yi master ürettiği için çalışma frekansını biz belirliyoruz. EFM8SB1’de I2C modülü iki farklı zamanlama kaynağına ihtiyaç duyar: Biri zaman aşımı denetimi için diğeri clock frekansını belirlemek için (baud-rate generation gibi düşünün).
Bizim için ikincisi önemli. Bunun için, diğer modüllerde olduğundan farklı olarak birden çok seçeneğimiz var. TMR0 pek çok uygulamada genel amaçlı sistem saati ya da harici sayaç, TMR1 uart baud rate generator veya harici sayaç olarak kullanılabildiği için ben TMR2 kullanıyorum. Ayrıca, I2C çalışmasında gerekli taşma hızları çok yüksek olduğu için, 16 bitlik bir sayaca da ihtiyacımız yok. Değerli kaynakları boşa harcamamak için split mode çalışabilen bir timer kullanmak daha mantıklı.
Seçtiğimiz saat kaynağının kesmesini başka işlerde kullanmaya devam edebiliriz. I2C modülü arka planda taşma bayrağına bakarak I2C işlemlerini zamanlayabilir.
Kullanmak istediğimiz SCL frekansının 3 katı hızıyla tick üreten bir sayaç ayarlamamız gerek:

Split mode yaptığın bir sayacın alt yarısı ile üst yarısını kullanmak arasında küçük bir fark var: Sayacın açma/kapama kontrolü yalnızca üst yarıya kumanda eder. Alt yarı sürekli çalışır. Eğer üst yarıyı başka bir iş için kullanacaksak bu I2C için daha uygun bir paylaşım olur.

Program Tasarımı

Aşağıdaki zaman diyagramına bakın. Bu, bir sensörden veri okumak için yapılması gerekenleri gösteriyor:

I2C, ne yazık ki kendi başına iş görme yeteneği düşük bir haberleşme modülüdür. Yukarıdaki gibi, belli bir register’dan 2 byte veri okumasından ibaret bir işin SPI ile ne kadar kolay olacağını ve durumlar tanımlamak gerekmeden tek satırda bitebileceğini düşünün.
I2C’de işe yarar bir konuşma (transaction) yapmak için birden çok durum çalıştırmak gerekir. EFM8SB1’de bunları donanıma yaptırmak için kullandığımız kumanda bitleri tek bir register’da yer alıyor.

// I2C kumanda bitleri:
sbit SMB_SI = SMB0CN0^0;
sbit SMB_ACK = SMB0CN0^1;
sbit SMB_ARBLOST = SMB0CN0^2;
sbit SMB_STO = SMB0CN0^4;
sbit SMB_STA = SMB0CN0^5;

I2C konuşması fazla işlemci meşguliyeti yaratan bir iş olduğu için bu tür çevresel birimlere sürücü yazarken yaklaşımımız ana uygulamanın çok-görevlilik durumuna göre olmalı. Eğer I2C erişimi önceden bilinen zamanlarda yapılmayacaksa ve başka işlerle çakışması olasılığı varsa çok-görevli bir kodlama daha uygun olur. Çok görevlilik, I2C işlerini tüm durumları kapsayan bir kesme fonksiyonu içinde çalıştırmak şeklinde olabilir. Veya ayrı bir thread içinde bu işlerin kotarıldığı task’ler şeklinde bir durum makinesi yazılabilir. Birincisi için Silabs’ın örnek i2c kodlarına bakabilirsiniz. İkincisi benim genellikle tercih ettiğim yöntemdir. Daha büyük işlemcilerde genellikle i2c thread’i içinde erişimleri yazarım.

Benim bu yazıda paylaşacağım yaklaşım yukarıdakilerden biraz daha farklı. Programın asıl işinin zaten bu i2c modülüne erişim olduğu durumlarda bu yöntem daha efektif olacaktır. Burada esas olan, işlemcinin i2c erişimi yaparken başka işinin olmayacak olması. Ek olarak, i2c okuması uygulamanın zamanlamasını kesin olarak bildiği anlarda başlar ve biter. Örneğin, zamanının çoğunu uyku modunda geçiren ve uyanıp, i2c üzerinden bir sensörle haberleşen bir uygulama için bu yöntem biçilmiş kaftandır.

Genel Amaçlı Fonksiyonlar

Aşağıda paylaştığım i2c fonksiyonlarını doğru sıra ile çağırarak, herhangi bir slave aygıt için ihtiyaç duyulan sürücü fonksiyonları gerçekleştirilebilir. Bu fonksiyonlar blocking olarak çalışırlar. Yani, düz bir sıra ile verilen i2c okuma/yazma işlemini yaparlar.

// START durumu üretir ve ardından verilen slave adresini yazdırır (read ya da write)
bool I2C_Start(unsigned char slave_address)
{
  SMB0CN0 = 0x20;   // START durumu başlat!
  while (SMB_SI == 0)  ;

  if (SMB_ARBLOST) return(false);
  SMB0DAT = slave_address;
  SMB0CN0 = 0;
  return(true);
  // fonksiyon, işlemin bitmesini beklemeden hemen döner..
}

// ilk erişimde, yazma adreslemesi sonrasında erişilecek
// çip adresini (/yollanacak komutu) gönderir:
bool I2C_Register_Set(unsigned char reg_addr)
{
   while (SMB_SI == 0) ;  // yazma adreslemesinin bitmesini bekle

   if (SMB_ACK)   // yazma adreslemesine ACK aldıksa..
   {
     SMB0DAT = reg_addr;
     SMB_SI = 0;
     return(true);
   }
   else
   {
     SMB0CN0 = 0x10;   // STOP durumu üret
     return(false);
   }

}


// Start'tan farkı, devam etmek için önceki işlemin sonuçlanmasını bekler
// ve slave adres yüklemesi sonrası da slave'den ACK bekler
bool I2C_ReStart(unsigned char slave_address)
{
  while (SMB_SI == 0) ;  // önceki yazma işleminin bitmesini bekle

  if (SMB_ACK == 0)
  {
    SMB0CN0 = 0x10;  // STOP durumu üret
    return(false);
  }

  // önceki yazmaya ACK almışsak devam edelim:
  SMB_STA = 1;
  SMB_SI = 0;     // Repeated-Start üret
  while (SMB_SI == 0) ;

  if (SMB_ARBLOST)
  {
     SMB0CN0 = 0x10;   // STOP durumu üret
     return(false);
  }

  // repeated start sonrası, verilen slave adresini yolla:
  SMB0DAT = slave_address;
  SMB0CN0 = 0;
  while (SMB_SI == 0) ;

  if (SMB_ACK)  // re-start adreslemesine ACK aldık mı?
  {
      // slave'e adres yazması sonrası modülü hold durumda bırakıp dön:
     return(true);
  }
  else
  {
    SMB0CN0 = 0x10;
    return(false);
  }
}

// bu fonksiyon i2c denetimini bir önceki adımdan hold durumda devralmıştır
// (ilk okuma için read address yazması sonrası,
// sonraki okumalar için master ACK üretimi sonrası)
// ack = 1 olursa daha veri okunacak demektir.
// slave'e ACK üretilir ve i2c makinesi hold durumda iken fonksiyon döner.
// ack = 0 olursa stop durumu üretilir ve durum makinesi de boşa çıkar.
unsigned char I2C_Byte_Read(bool ack)
{
  unsigned char x;

  SMB_SI = 0;   // state machine'i sal..
  while( SMB_SI == 0)

  if (ack) SMB_ACK = 1; else SMB_ACK = 0;

  x = SMB0DAT;  // gelen veriyi al.

  if (!ack)
  {
    SMB0CN0 = 0x10;
    while (SMB_SI == 0) ;
    SMB_STO = 0;
  }

  return(x);
}


// kendisinden önceki yazma (pointer set / data yazma) devam ederken çağrılır
// geri döndüğünde de yükleme yapılan yazma sürüyordur.
bool I2C_Byte_Write(unsigned char b)
{
  while (SMB_SI == 0) ;  // önceki yazma işleminin bitmesini bekle

  if (SMB_ACK == 0)
  {
    SMB0CN0 = 0x10;  // STOP durumu üret
    return(false);
  }

  SMB0DAT = x;
  SMB_SI = 0;
  return(true);
}

void I2C_Stop(void)
{

  while (SMB_SI == 0) ;  // önceki işlemin bitmesini bekle
  SMB0CN0 = 0x10;
  SMB_SI = 0;
  while(SMB_SI == 0) ;
  SMB0CN0 = 0;
}

EFM8BB1 IDLE Mode

Bir Cevap Yazın

Küçük işlemcilerle yaptığımız uygulamaların azımsanmayacak bir kısmı şu tarife uyar: Bunlar “belli bir olay“a tepki vermek için “bekleyen” programlardır.

Örneğin bir butona basıldığında bir işlem yapan bir program düşünelim. Program, butona basılmadığı zaman sadece butona basılmasını bekliyor (aslında belli zamanlarda yaptığı başka işler olması bu hikayenin teorisini çok değiştirmiyor).

İşte bu belli olayı beklediğimiz uzun müddetler boyunca işlemciyi boşa alarak akım tüketimini azaltabiliriz. Beklediğimiz olay için bir kesme kurmamız yeterlidir. EFM8 işlemcilerdeki IDLE mode, bu senaryo için uygundur.
– Idle mode’da iken işlemciyi istediğimiz saat hızında bekletebiliriz ve istediğimiz modülleri açık tutabiliriz.
-Idle mode’dan çıkmak için mevcut kesmelerin herhangi birini ya da bir kaçını kullanabiliriz.
– Çıkış bir interrupt fonksiyonuna atlama kadar hızlı olacağı için olaya tepkimiz hızlı olabilir.
Yani, Idle mode kullanımı basit ve sağladığı tasarruf bizim tercihlerimize bağlı bir çalışma ayarıdır. Bununla beraber, işlemci aslında kapanmadığı için bu en yüksek düzeyde güç tasarrufu sağlayan mod değildir.

Bir uygulama geliştirmek çalışan bir kod elde etmekten çok fazlasıdır. Bir uygulama tasarlamak temelde, seçimler yapmak demektir. Bu seçimler gereksinimlerinize en uygun seçimler olurlarsa başarılı olursunuz.
İşte bu yazının konusu olan Idle mode, sıklıkla ve zamanlamasını tam bilemediğiniz anlarda görev başına geçmesi gereken bir programınız varsa doğru bir seçim olabilir.

Tipik bir kullanımda kod
– Beklerken gerekli olmayan birimleri kapatır,
– Makul bir çalışma frekansına yavaşlar,
– IDLE mode’dan çıkış kaynaklarını ayarlar,
– Ve işlemciyi idle mode’a sokar..


IDLE mode’a giriş:

   TMOD = 0x31;
   TH0 = 0;
   CKCON0 = 0x02;  // tmr0 prescaler SYSCLK/48 olsun
   CLKSEL = 0x40;  // sistem saatini 1,53MHz'e indir..
   TCON = 0x11;    // TMR0 çali$sin, EX0 kenarda tetiklemeli
   IE = 0x83;      // = 0x83 TMR0 ve EX0 kesmeleri devrede
   PCON0 = 0x01;   // IDLE=1
   PCON0 =  PCON0;
   _nop_();

Yukarıdaki kod parçası işlemciyi EX0 ve TMR0 kesmeleri ile normal çalışmaya geri dönmek üzere boşa çıkarır.
İşlemcinin kötü bir şans eseri IDLE=1 komutu işlenirken gelecek bir kesme yüzünden hiçbir zaman IDLE durumundan çıkamayacak olması ihtimaline karşılık, bu komutun hemen ardından bir byte’tan büyük opcode’lu bir komut işletilmelidir. PCON0=PCON0 dummy komutu bu yüzdendir.
İşlemcinin normal çalışma moduna dönünce, kendisini uyandıran kesme kodunu işledikten sonra _nop_() ile devam edeceğini de not edelim. Yani uyanma kodu, buradan sonra yer almalı (muhtemelen yapılacak ilk iş çalışma hızını arttırmak olacaktır).
Bu şekilde her şeyi tek düzeyli düz bir while(1) süper döngüsü içinde halledebiliriz.
Son bir not olarak da EFM8BB1 için IDLE mode çalışma akımı vereyim. 1,53MHz için işlemci akımı 550 uA ‘dir. ( -G sıcaklık sınıfındaki çipler için )

nRF24L01+

Bir Cevap Yazın

Nordic Semiconductor her ne kadar son zamanlarda bluetooth’a odaklanmış gözükse de uzun yıllardır sub-ghz rf çiplerini kullandığımız bir marka.
İnsanlar artık “uysa da uymasa da” bir protokol seçip, onu çalıştıran stack’in yüklü olduğu işlemciyi barındıran bir SOC alıp, ilave bir-iki özelliğini kurcalayıp proje üretiyorlar. Özellikle farklı cihazlarla beraber çalışma gibi durumlar söz konusu olduğunda bu elbette doğru bir yaklaşım. Öte yandan, eğer bir bluetooth uzaktan kumandası kullanıyorsanız, bunun kitlesel olarak üretilmiş cihazlarda bile bazen ne kadar başarısız sonuçlar verdiğini de yaşayarak görmüşsünüzdür.

Tam çalışma şeklini, iletişim protokolünü, güç yönetimini ve tüm radyo parametrelerini kendimiz ayarlayarak, tam olarak uygulamanızın ihtiyacına göre kablosuz haberleşme gerçekleyebildiğimiz çözümler de var. Bunlar genelde üreticilerin Proprietary RF (uygulamaya özel protokol) başlığı altında ele aldığı çözümlerdir. Teorik olarak herhangi bir RF SOC’unu alıp, dökümantasyonla mücadele edip bu şekilde çalıştırmak mümkün. Ancak, anlaşılır sebeplerle, 1GHz altında çalışan modüller protokolü size bırakılmış, böyle uygulamalar için oluyor genelde. Bizim bu yazıda ele alacağımız 24L01+ bu tarzın 2,4GHz’deki temsilcisi olması sebebiyle de ilginç.

Aslında bu çipin uygulama devresinde çok az harici eleman var, bu yüzden bunu board’a eklemek zor bir iş değil. Ama hazır modüller o kadar ucuza bulunabiliyor ki çipi temin etmeye çalışmaya (ki muhtemelen modülü bulmaktan daha zor) buna değmez.

nRF24L01+ modüllerle ilgili, ilk gördüğümde dikkatimi çeken şey çok ucuz olmaları olmuştu. Eğer uygar ve gelişmiş bir ülkede yaşıyor olsak, para birimimizin bir kesiri ile belirtilen bir fiyat etiketiyle bu ürüne sahip olabilirdik. Muhtemelen bir bardak çay parasından ucuza. İçinde olduğumuz duruma rağmen, bu modüller hâlâ herhangi bir uygulamaya eklemek için çok da düşünmeyeceğiniz kadar ucuzlar. Öte yandan bu ucuzluğuna rağmen pek çok kablosuz habereşme işinde kullanmaya da uygun gibi gözüküyorlar. Yani, bunlara bir bakmaya değer.

Donanım

Gerekenler;
– 3 port SPI,
– iki çıkış : CE ve CS
– bir tane de giriş (isteğe bağlı) IRQ.

Elimde nRF24L01+ modülünü doğrudan takmak için bir board var. Bunu bir ana dinleyici olarak tasarladım. Görevi, sürekli dinlemek ve kendine yollanan verileri RS485 üzerinden aktarmak. Daha otonom çalışma için board’un üzerinde röle çıkışları da var.

Alıcısı olan şeyin bir de göndericisi olmalı elbette. Bu taraf, uygulamaya göre şekillenir. Çünkü biz kablosuz haberleşmeyi data-agnostik işlerde kullanmıyoruz. Elimizde, benim eskiden kalma alışkanlıklarla “saha” dediğim, bir şey ölçmek ya da kontrol etmek istediğimiz bir uzak noktada bir modül var. Radyo haberleşmesi bize bu uzak modül ile, daha merkezi bir kontrol noktası arasında iletişim kurmak için gerekiyor. Yani bizde radyo haberleşmesi, yollanacak veriden bağımsız bir iş değil. Bu yüzden bir alıcı pek çok farklı işte kullanılabilir ancak gönderici kapasitif bir sıvı sensörü de olabilir, radar kullanan bir mesafe sensörü de olabilir, bir sıcaklık sensörü de olabilir, bir kapıya takılmış güvenlik anahtarı da olabilir. Ve işi bu modül tanımlar.
Ben, gönderici tarafın çalışma şeklini denemek için daha önce, bambaşka bir proje için hazırladığım bir prototip board’unu kullandım. Bu kartı seçmemin sebebi boyutları değil, üzerinde bir header ile bağlantısı olan SPI portu olmasıdır.

Bu arada ben gündelik konuşmadaki anlamıyla “alıcı” ve “gönderici” tabirlerini kullanıyorum. Gerçekte, modüller hangi tarafta olurlarsa olsunlar hem alma hem de yollama radyo fonksiyonlarını yürütmek zorundadırlar. Bizim alıcı ve verici derkenki kastımız “data” (veri) yönünü ima etmiyor, “information” (bilgi) yönünü ima ediyor.

Şimdi kullanacağımız pinlerden bahsedelim:
SPI = SCK, MISO, MOSI, CSN
Bu, bildiğiniz SPI faz 0. CSN de 0 iken etkin SPI slave select çıkışıdır.
Ben 1MHz SPI clock ile modüllerle sorunsuz haberleşiyorum. Gönderici tarafta salkım saçak kablolarla bağlantı olduğu için çok hızlandırmayı düşünmedim.

CE = Chip enable çıkışı. Nordic bu tabiri çiplerine dışarıdan bir işlem başlatan girişlerini tanımlarken kullanıyor. Mesela veri yollama işlemini başlatmak ya da alıcıyı etkinleştirmek gibi.

IRQ = Gönderme ya da alma işlemlerinin tamamlanışını, eğer ilgili maske bitini ayarlanmışsanız bu pinin 1->0 geçişinden anlayabiliyorsunuz. O yüzden “kesme” ismi verilmiş. Donanımda pin kıtlığı varsa bunu bağlamak için bir giriş ayırmadan da çipi çalıştırabiliriz ama o zaman periyodik olarak SPI konuşması yapmamız gerekir.

Sürücünün Tasarımı

Sürücü ile kastettiğim, bizim kartlar üzerinde çalışan firmware’in radyo modülleri üzerinden iletişim kurmasını sağlayan fonksiyonlar ve değişkenler. Bunu doğru tasarlarsak donanımımız asıl işini yaptıktan sonra (bir sensörden veri okumak gibi) ileteceği veya alacağı veriyi UART’tan yollamaktan çok da farklı olmayan bir şekilde iletip çevrimini tamamlayacaktır.

Burada konu ettiğimiz radyo çipi gibi amatörlerin beğenisini kazanmış, bilindik ürünlerle ilgili internette firmware araştırmaları yaptığımda karşıma çok fazla boş içerik çıkıyor. Bunun en basit nedeni, adamın birinin (hatta bazen çipin üreticisinin) bir arduino kütüphanesi yazması. Konuyla ilgilenen çoğu kişi bu kütüphaneyi referans gösteriyor. “Nasıl kullanılacağını açıklama” amaçlı pek çok makale gidip bir arduino kütüphanesine dair nesneyi main.c içine koyup .begin demekten öteye geçmiyor.

Bu çip için geçerli değil ama daha dehşet verici olan ise şu: Pek çok durumda, yazılmış arduino kütüphanesinin “kendisi” de ürünün pek çok özelliğini kullanmayan, dökümantasyonla tam uyuşmayan hasbel kader çalışmış bir kod oluyor. Ürünün üstünde olan ve benim tam da onu seçme sebebim olan bazı yönlere dair hiçbir ayrıntı görmüyorum. Yani, internetten çalışan bir kod arama macerası genellikle konuya ilgi duyan ama ayrıntıları çözecek motivasyonu ya da zamanı olmayan kişileri yanlış yönlendirecek ya da asıl işe yarar bilgiden yalıtacak şekilde çalışıyor. Ben bir şeyleri çalıştırmaya çabalarken de, yaptığım bir şeyle ilgili bilgiler paylaşırken de bundan uzak durmaya özen gösteriyorum. Açık dökümantasyonu olan ve geliştirme araçlarına sahip olduğumuz her şeyi nasıl çalıştığını anlayıp, kendi ihtiyacımız için en optimum ayarlarla kullanabilmeliyiz. Aksi halde başkasının gelinliğiyle/damatlığıyla düğün yapmış oluruz. En sonunda ortaya çıkan sonuç da çoğu zaman “optimal” bir çözüm olmaz.

Benim hemen hemen her yeni işte karşılaştığım bu can sıkıcı duruma dair düşüncelerimi de paylaşmamın ardından nRF24L01+ ‘e nasıl erişeceğimiz konusuna dönebiliriz:
SPI’ı , ilk byte’ı bir komut olan master paketlerine yanıt vererek haberleşiyor. Okuma, yazma, register/fifo erişimi gibi tüm olasılıklar ilk byte’ta verilen komuta göre belirleniyor:

Bu da demek oluyor ki, çipe erişme işlerimiz daima bir komutu yazarak başlamalı:

static unsigned char NRF_Command(unsigned char cmd);

Komutlar nrf24l01.h içinde tanımlı bir byte’lık sabitlerdir. Datasheet’in 51. sayfasında listesi verilmiştir. Yukarıdaki fonksiyonda CSN=0 yapıp, verilen komut byte’ını yazıp bu esnada MISO’dan da STATUS içeriğini okuyup sonraki eylemi beklemeye koyuluruz.

nRF24L01+ ‘e yaptıracağımız işler şunlar:
– Çipi konfigüre etmek;
– Çipin çalışma durumunu (MODE) değiştirmek,
– STATUS’ü okumak
– Veri buffer’larına gidecek veriyi yazmak ya da onlardan gelen veriyi okumak.

Bu görevler kısa süren eşzamanlı işlemlerle halledildikleri için generic bir sürücü, gerektiğinde çağrılacak fonksiyonlardan ibaret olabilir.

KONFİGÜRASYON:

Power-up sonrası nRF24’ün lojik kısımlarının çalışmaya başlaması için 100ms geçmesi gerekir. Bu yüzden, program başlar başlamaz çipi konfigüre edeceksek önce bir 100ms beklemek zorundayız. Sonra, çipin POWER_DOWN mode’da olduğundan emin olabiliriz.

nRF24L01+’de çalışma öncesi yapılması gereken ayarlamalar şunlar:
– Auto-Ack :
Firmware Sabiti.
Bu özelliği kullanıyorum, o yüzden hem alıcıda hem de göndericide pipe-0 için ack enable yapıyorum.
– RX Address Enable:
Firmware sabiti.
Alıcıda pipe-0 ve pipe-1 yollayıcıda ise pipe-0 (ack’i almak için) etkin yapıyorum.
– Address Width:
Firmware sabiti.
4 byte adresleme kullanıyorum.
–Auto-Retransmission:
Firmware sabiti.
Alıcıda 0 ama göndericide sıfırdan farklı değerlere ayarlanmalı.
– RF Channel:
Uygulama için parametrik.
7 bitlik radyo kanalı tanımı
–RF Setup:
Uygulama için parametrik.
250kbps veri hızı kullanıyorum. Çıkış gücü ayarlanabilir olabilir.
– Payload Width:
Firmware sabiti.
Sadece alıcı tarafta tanımlanması gerek. Yollayıcı tarafta TX payload olarak ne yüklersek radyo onu yolluyor.
–P0 için RX Adresi:
Uygulama için parametrik
Alıcıda, bu ağı tanımlayan master adresi budur. Yollayıcıda burada alıcının adresi olmalı (ACK almak için böyle yapmak gerekiyor).
–P1 için RX Adresi:
Uygulama için parametrik
Alıcıda, bu konfigürasyon çağrı adresi. Normal veri mesajlaşması dışındaki işlemler için rezerve tutuluyor. Yollayıcıda kullanılmayabilir veya konfigürasyon adresi olarak tanımlanabilr.
– TX adresi:
Uygulama için parametrik.
Yollayıcıda bu ağın tanımlayıcısı olan master RX adresi (alıcının P0 adresi). Alıcı için ise tanımlanması gerekmiyor (konfigürasyon için adres gereksin dersek kullanılır).

Çip POWER-DOWN durumundayken konfigüre edilebilir. Ben de bunu tercih ediyorum. Çip yollama veya alma yapmadan önce STAND_BY-1 durumuna geçmiş olmalıdır. Bunu yaptırmak için CONFIG register’ına yazma işlemi yapan bir fonksiyon kullanıyorum: 

void Radio_Stby(void)

CONFIG register’ında sürekli değiştirmemiz gereken bit PWR_UP biti (bit-1) olsa da burada CRC ayarlarını, TX/RX çalışmasını ve IRQ pinini sürecek kesme kaynaklarını belirleyen bitler de var. Her Stand_By’a geçişte bunları da doğru değerlere ayarlamak gerekiyor.

GÖNDERİCİ İÇİN İŞLEMLER:

Radyo STAND_BY -1 durumundayken;
– Yollanacak veriyi TX FIFO’ya yüklemek,
– CE = 1 yapmak, 15us beklemek ve CE=0 yapmak,
Yollama işlemini başlatır.

Bu işleri 

void Radio_TX(unsigned char xdata *ptx)

isimli fonksiyonumda hallediyorum. Bu fonksiyon her çağrıldığında TX FIFO’ya belirtilen konumdaki paketi yükler ve sonra CE pulse’ını üretir. Burada TX adresini yeniden yüklemiyorum. Flash’tan yüklenen radyo ayarları bellek alanında master adresi tanımlanmıştır ve konfigürasyon aşamasının ilgili adımında bu adres TX adresi olarak yüklenir. Radyo üzerinden yeniden konfigürasyon işlemi için config çağrı adresinin yeninden yüklenmesi gerekecektir.

Auto-Retransmit fonksiyonunu kullandığımız için, belirtilen süre içinde ACK almazsa radyo tanımlanmış sayı kadar tekrar yollama denemesi yapacaktır:


TX için radyoyu STAND_BY-1 durumuna getirirken config register’ına ;

#define CONFIG_TX  0x4E

sabit değerini yazıyorum. Bu durumda nRF24L01+ ‘in IRQ pini veri yollandığında veya max. retransmit count deneme sayısına ulaşıldığında 0 olacak demektir. Ana programın IRQ pininin 1 -> 0 geçişini beklemesi gerekir.

Bu olduktan sonra 

void Radio_Clear_IRQ(void)

fonksiyonu ile kesme nedeni okunup hemen sonra da flag’ler sıfırlanmış olunur. Yollayıcı program MAX_RT kesmesi gelmişse alıcının veriyi almadığı varsayımıyla uygun işlemi yapabilir. Tipik kullanımda ben her durumda veri yollaması sonrası donanımı düşük enerjili moda alıp işlemciyi de rtc kesmesi ile uyanacak şekilde kurup kapatıyorum. Gönderme işlemimiz MAX_RT kesmesi ile sonuçlanmışsa daha kısa, TX_DS kesmesi ile tamamlanmış ise de normalde düşündüğümüz uyku süremizi ayarlıyoruz.

Pil Seviyesi Ölçümü:

Kablosuz cihazlar genellikle pille çalıştıkları için, pil düzeyini ölçmek, bu programlarda çoğu zaman olmasını isteyeceğimiz bir özelliktir.
Pil düzeyini doğru ölçmenin basit bir yolu, pilden her seferinde belli bir akım geçerken onun gerilimini ölçmek olabilir. Kablosuz bir uç nokta cihazında nRF24, muhtemelen en çok akım akıtan parça olacağı için, nRF etkinken pil seviyesini ölçmek bize mantıklı bir okuma sonucu verecektir (kullandığımız işlemciler radyo modülüyle kıyaslanmayacak kadar az akımla çalışırlar).
İşte bu yüzden, radyo tam gönderme işleminin ortasındayken pil gerilimini okumak mantıklıdır.

TX işlemi sırasında radyo 7mA ile 11.3mA arasında değişen bir akım çeker (değer, çıkış gücüne bağlı olarak değişir).
Bu durumda, pil seviyesi ölçme işlemini
Radio_TX() fonksiyonu içinde,
CE pulse’ı ürettikten hemen sonra başlatabiliriz.
Yukarıda belirttiğim 710us Time on Air süresi, benim protokoldeki paket süresidir.

ALICI İÇİN İŞLEMLER

Bu tür düşük enerjili saha node’larının master-slave çalıştıkları ağlarda alıcı sürekli açık olsa daha uygun olur gibi gözüküyor. Yani, en basit başlangıçta, bize sürekli dinleme durumunda olan bir radyo gerekli. Bunun için öncelikle nRF24L01+ ‘i başlatıyorum ve ardından onu STAND_BY-1 durumuna sokuyorum. Sonra biraz bekleyip CE pinini 1 yapıyorum. Bu durumda radyo daha önce konfigürasyon aşamasında bahsettiğim üzere, pipe-0 ve pipe-1 için tanımladığımız adreslere gelecek paketleri beklemeye başlıyor. Ayrıca kesmeyi de DATA_READY flag set edildiğinde pini sürmek üzere

#define CONFIG_RX  0x3F

konfigürasyon değeriyle ayarlamış oluyorum. Bu durumda bir veri geldiğinde IRQ = 0 olacağını varsayıp bekliyoruz.

IRQ=0 algılandığında hemen çipin STATUS register’ını okuyorum. Aslında bu durumda iken tek kesme kaynağı veri alınması olsa da hangi dinleme pipe’ına veri geldiğini ayırt etmemiz için status içeriğini biliyor olmamız gerek.

void Radio_Read_RXData(unsigned char xdata *dest)

fonksiyonu RX FIFO’nun geçerli içeriğini dest ile belirtilen ram konumuna aktarır. Status ile belirlediğimiz dinleyici kanalına uygun kayıt konumunu seçeriz. Bu kısım gelen veriyi işlemeyle ilgili..

Read_RXData() fonksiyonu ile FIFO’yu okuduktan sonra radyo üstündeki gelen veri buffer’ının boş olduğundan emin olmak için bir kez daha STATUS register’ını okuyorum. Buffer boş ise işlemler bitmiştir, dolu ise bu kez hangi pipe’tan veri almışsak onunla ilgili hedef konumuna fifo içeriğini okuyorum. Bu şekilde, birbirine yakın zamanlarda gelmiş olan iki paketi de atlamadan alacağımızı ümit ediyorum.

Yeri gelmişken yazayım: Bu, birden çok dinleme “pipe” ‘ı mevzusu alıcının toplam iş çıkarma kapasitesini arttırmıyor. Çünkü, radyo belli bir anda tek bir kanalda dinleme yapıyor ve sadece bir paketi alabiliyor. Birden çok RX adresi olması otomatik ACK üretme işinde ve bir seviyeye kadar gelen paketleri sınıflandırmada işe yarar.

FIFO boş olduktan sonra kesme bayrağını TX işleminde yaptığım gibi STATUS register’ına yazarak sıfırlıyorum ve alma işlemi bitiyor.

Test programında yapılan son iş gelen veriyi seri porttan yollamak.

alpha-S

Bir Cevap Yazın
decolit alpha-s rgb led lamba modüllerinin çıplak kart halleri

Üç renkli LED elemanlar kullanarak rengarenk aydınlatmalar yapmak son zamanlarda bana da çekici gelmeye başlamıştı. Aslında bunun için hazır pek çok seçenek var ancak ben küçük bir board yapıp, üzerine kendi seçtiğim RGB LED’leri yerleştirip kendi tanımladığım kumanda şemasını yürütebilecek bir şeyler yapmak istedim. Sonrasında bu küçük kartları istediğim yerlere yerleştirip, onları değişken renklerle yakmak niyetindeyim. Noktasal olarak büyük bir ışık yoğunluğunu hedeflemiyor olsam da bir board üstüne 5 tane PLCC kılıf LED koymaktan kaçınmadım.

Kartın boyutları 58mm x 13.5mm oldu.


Deneme amacıyla ürettiğim board’ların üzerine Cree marka CLP6C-FKB model LED’ler taktım. Sonuç gayet güzel.

LED’leri doğrudan kartların besleme hattı üzerinden besliyorum ve her renk için bir pull-down transistör ile sürüyorum. Şemada 100R olarak gözüken seri dirençler besleme gerilimine göre seçilmesi gereken denge dirençleri.

Bu projeyi bir hafta sonu çalışması olarak uğraşmaya değer bulmama neden olan şey bu kartları seri haberleşme ile kumanda edilebilir ve kaskat bağlanabilir yapmam. Bu şekilde iş basit bir renk ayarından çok daha fazlası olabilir.

Aslında arka arkaya bağlanabilir renkli LED deyince akla gelen Neopixel diye bir LED çipi de var. Bunun Çin malı kopyaları ucuza bulunabiliyor. Ama bunlar adreslenebilir modüller değiller. Ben uzun clock katarları üretmek zorunda kalmak yerine doğrudan UART kullanan bir şey yapmak istedim. Bu şekilde tek bir komutla tüm lambalara aynı anda aynı şeyi yaptırabilmek mümkün. Veya istediğiniz belli bir adrese doğrudan komut verebilirsiniz. Eğer hızlı animasyonlar yapmak söz konusu ise bu daisy-chanining’e göre çok büyük bir fark yaratabilir.

Her modülün sol tarafında uart’ının RX ‘i sağ tarafında ise TX çıkışı bulunuyor.

Modülleri arka arkaya (kaskat) bağladığımızda soldan sağa birbirlerini sürmüş olacaklar.Bir modül sol tarafından bir paket aldığında bu paket onu adreslemiyorsa veya bir genel çağrı adresi taşıyorsa o komutu sağ taraftaki TX pininden aktaracaktır. 0-3V gerilim düzeyinde çalışıyor olsak bile bu şekilde alavere yaparak uzun bir lamba zincirini bir uçtan kumanda edebilmeyi umuyorum. Bu arada, 24mA kaynak akımı verebilen bir logic buffer kullanmakla sonraki modül ile aramızdaki kablonun kapasitesinden kaynaklanacak yavaşlamaları azaltmış olacağız. Şemadaki paralel kondansatöre takılmayın. Orada bir komponent yeri olsun istedim sadece.

Benim “adreslenebilir” bir lamba modülünden beklediğim kumanda işlevleri her kanal için ayrı ayrı olmak üzere;
* Açma ve kapama denetimi,
* Çıkış gücünü ayarlama,
* Rampalı açma/kapama,
* Çıkış gücünü rampalı değiştirme,
* Rampa sürelerini değiştirebilme
* Çıkış gücünü çıkışa yansıtmaksızın değiştirebilme (komut verildiğinde uygulanmak üzere)
* Tüm modüllere eşzamanlı komut verebilme

Bu fonksiyonlar basit seri komutlarla kumanda edilebildiğinde ana kontrolcünün karmaşık efektleri yürütmesi kolayca mümkündür.

Firmware Yapısı

Ana program, dört ayrı thread’den oluşur:
+ Sürekli olarak çalışan ve her aşaması belirli bir zaman aşımı denetimi ile korunan bir seri haberleşme thread’i..
+ Zaman çoğullamalı olarak çalışan ve her biri bir renk sürücüsüne çıkış veren üç özdeş paralel renk kontrol thread’i.

Her renk kontrol thread’i 4 farklı duruma dair task’ler çalıştırır. Her task’in o renk için bir “durum” olduğunu düşünün. Bunlar;
OFF
ON
RAMPUP
RAMPDOWN
task’leridir. OFF ve ON task’leri kalıcı durumlardır. Bir komut alınmadığı sürece denetim bu task’i çalıştırmayı sürdürür. RAMP task’leri ise belli bir süre boyunca çalışan geçiş durumlarıdır. Set değeri değiştirildiğinde (kademeli geçiş komutu verilmişse) veya kademeli açma kapama komutları verildiğinde yeni set değerine ulaşılıncaya dek bu adımlarda kalınır.

Çıkış kontrol task’lerinin zaman bölümlemesi 10,7ms ‘dir. Yani her 10,7ms’de bir sıradaki renk kanalının geçerli durumuna dair task çalışır. Ve bu çevrim art arda sürekli devam eder. İki rezerve zaman slotunun da eklenmesiyle, bir tam çevrim 5×10,7 = 53,5ms ‘de tamamlanır. Bu demektir ki, çıkış güncellemeleri 53,5ms çözünürlükle yapılmaktadır. Durağan adımlarda bu önemli olmamakla beraber kademeli geçiş adımlarında bu süre değişim hızını tanımlar.

PWM

İşlemcinin üzerindeki 3 PWM kanalını da kullanıyoruz. PWM çözünürlüğü 8 bittir. PWM frekansı da 7,98 kHz’dir.
Bu projenin donanımını tasarlarken EFM8BB1 işlemcisini kullanmıştım. Firmware’e de bu işlemci üzerinde çalışarak başladım. Sonra iş deneme aşamasına gelince prototip montajları için bana yardımcı olan arkadaşımın elimdeki board’lara BB1 yerine yanlışlıkla SB1 takmış olduğunu fark ettim.
Sleepy-Bee ile Busy-Bee “hemen hemen” pin uyumludur. Ancak firmware’de oldukça yaşamsal farklar vardır. Ne yazık ki buna PCA modülü de dahil, ki bu board’da PWM’i bununla üretiyorum. O yüzden, elde olan asıl olandır mantığıyla benim firmware’i SB1 üzerinde çalışacak şekilde değiştirdim. Ancak asıl üretimim BB1 ile olacak. Çünkü bunda daha çok özellik var.
Bu işlemcilerde PWM çıkışı aktif duty cycle’da 0, pasif durumda da 1 oluyor. Ben BB1’de PCA0POL register’ı ile bu evirme işlemini donanımsal olarak halledebiliyordum. Ancak SB1’de POL register’ı yok. Bu durumda çıkış gücü 0 yazarsak en büyük 255 yazarsak en küçük olmuş olur. Ayrıca, kanalı kapatmak istediğimizde önce çıkışa 255 yazmalı sonra da _ECOM bitini sıfırlamalıyız.
8 bit PWM’de set değerini PCA0CPHx register’ına yazmak gerek. Daha yüksek çözünürlüklü PWM ayarlarında kullanılabilen auto-reload register’larının kullanım seçimi bu modda kullanılmıyor.
Çalışma sırasında PCA modülü ve sayacı sürekli devrede. Bir kanalın kapalı olması gerektiğinde
PCA0CPMx = 0x02; yazarak o çıkışın toggle olmasını engelliyorum. (PCA0CPHx = 255)
PCA0CPMx = 0x42; yazdığımda da PWM çalışmaya devam ediyor.

BB1 kullanan versiyonda işler biraz daha değişik. Burada o kanalın POL bitini = 0 yapıp _ECOM=0 yapmam çıkışı kapatmaya yetiyor. Duty cycle’ı değiştirmeme gerek yok.
Ayrıca, BB1 ‘de PWM’i center-aligned kullanıyorum.

Kontrolcü, komutlar tamamlanmadan yeni komutu işleme almaz. Ancak rampa komutları icra edilirken seri haberleşmeden yeni bir komut alınırsa komut kuyruğa eklenir ve geçerli komut tamamlanınca işleme alınır. Ani açma / kapama /set değeri değiştirme komutlarında bunun olma olasılığı yoktur. Rampa işlemlerinde komutun tamamlanması rampa ayarına bağlı olarak uzun sürebileceği için bu olasılık vardır.

Üç renk kanalı birbirinden tamamen bağımsız olarak çalışabilir ve kumanda edilebilirler. Ancak tamamen eşzamanlı olarak da kumanda edilebilirler.

Bir zincirde 128 adet modül arka arkaya bağlı olabilir. Her modülün adresi sabittir. Bir ağda aynı adresli iki modül olması çalışmayı bozmaz, sadece bu modüller ayrı ayrı ayarlanamamış olurlar. 0x81 adresi tüm modüllerin ortak çağrı adresidir.

Seri portun haberleşme hızı 38400bps’dir. Yazdığım ilk versiyonda modül aldığı paketin adresi kendi adresi değil ise paketi tamamlanmasını beklemeden iletmeye başlıyordu. Ancak sonra, kesme kodunu kısa tutma takıntım yüzünden bu özellikten vazgeçtim. Bu durumda, her modül için paket aktarım gecikmesi yaklaşık 1,6ms’dir.

Haberleşme Yapısı

Paket boyu tüm komutlar için sabittir ve 6 byte’tır. Her paket sync byte’ı (0xAA) ve hedef node adresi ile başlar (0x01..0x81). 0x81 genel çağrı adresidir.
Ardından gelen cmd byte’ı paketi tanımlar. Geçerli komutlar ve kullandıkları parametrelerin anlamı şöyledir:

node: 1..128 arası, hedef adresi. 129 tüm modülleri adresler.
cmd_X : kanal komutları. anlamları şunlar:
0: Bu kanala ait komut yok.
1: forced-on : Kanal kapalıysa hemen açılmasını sağlar. Eğer açıksa out_X’te o an yazılı olan set değerini çıkışa yansıtır.
2: turn_off : Kanalı hemen kapatır.
3: ramp-up: Çıkış gücünü kademeli olarak out_X ‘te yazılmış değere yükseltir. Kanal kapalı idiyse açılır ve set değerine kademeli yükselir.
4: ramp-down: Çıkış gücünü kademeli olarak out_X’te yazılmış değere azaltır.
5: rampdown-off: Çıkış gücünü sıfır değerine kadar kademeli azaltır ve sonra kanalı kapatır.
NOT: Ramp-up ve ramp-down komutları, o anki çıkış oranı, out_X set değerinden sırasıyla yüksekse ve düşükse tek seferde yeni set değerine gelir.

Bu projede önemli bileşenin lambaların kontrolcüsü olduğunu düşünüyorum. Firmware’i tamamlayıp denemelere başladığımda işin bu yönünün geliştirilmeye oldukça açık olduğunu gördüm. Yukarıdaki komutların çalışmasını hızlı biçimde deneyebilmek için basit bir PC programı hazırladım. Aşağıda onun görüntüsünü görüyorsunuz. Üzerine tıklayarak programı indirebilir ve deneyebilirsiniz:

EFM8 DAC

Bir Cevap Yazın

EFM8 ‘in üstündeki DAC biriminden bahsetmeye başlamadan önce, digital-to-analog converter denen şeyler hakkında uzun süre devam eden bir kanaatimi not etmek isterim: DAC bana hep lüks bir şey gibi gelmiştir. ADC bir şekilde en başından beri erişilebilirliği olan bir birimdi. Ama DAC, ister bir mcu’da isterse de bir plc’de olsun, sanki hep maliyeti arttıran bir şey gibi geldi bana.

15 sene kadar önce bir iplik boyama makinesinde, boya desenleri oluşturmak için boya püskürten kafaların dönme hızlarını akan ipliğin uzunluğuna bağlı olarak değiştirilebilir yapmam istenmişti. Bulduğum çözüm küçük bir işlemciyle encoder darbeleri saymak ve 8 bitlik bir DAC’a çıkış vererek asenkron motor sürücülerinin hızlarını değiştirmekti. O zaman National’ın paralel bir DAC’ını kullanmıştım, çıkışa bir de opamp koyunca sonuç muhteşem olmuştu. DAC deyince aklıma hep bu iş gelir.

Yıllar sonra da ilginç bir proje için dalga şekli üretme işiyle uğraşmak zorunda kaldım. Artık işlemcilerin üzerinde oldukça hızlı DAC’lar var. Ayrıca çok yüksek çözünürlüklü PWM’lerin olması zaten pek çok durumda DAC ihtiyacını tamamen ortadan kaldırıyor. Ama ben yine de üzerinde DAC birimi olan mcu’lara ayrı bir gözle bakıyorum.

EFM8’de 4 kanal DAC var. Bunlar iki çift olarak kullanılıyor gibi gösterilse de tamamen bağımsız çıkışlar olarak kullanabiliyorsunuz. Bir çifti, birbirinin aynı ya da eşlenik çıkış üretmek istersek beraber kullanabiliriz. DAC çözünürlüğü 12 bit.

Anlatacağım örnek uygulamada DAC çıkışını ses üretmede kullanıyorum. Bunun için 2 DAC kanalını toplam şeklinde kullanmak için bir devre hazırladım. Bu şekilde basit dalgalardan daha çok harmonik üretmek mümkün.

DAC sinyal yolu (bazı şekiller sevgili kızım tarafından çizilmişlerdir)

Bir stereo kuvvetlendirici kullanıyor olsam da mono ses üretiyorum. Kuvvetlendiricinin yüksek giriş direncinin karşısında iki çıkışı dirençlerle birbirine bağlamak bir toplama kuvvetlendiricisi elde etmemizi sağlıyor. Benim kullandığım amplifikatörün bir bias off girişi de var. Bununla yükleme/geçiş vb. anlarda pop/click türü gürültüler olmasın diye çıkışı kapatabiliyorum.

Referans gerilimini, referans gerilim bölücüsünü (REFGN) ve çıkış sürücüsü kazancını (DRVGN) ayarlayarak çeşitli çıkış aralıkları elde edebiliriz. Ben bunlardan 4 tanesini kullanıcı konfigürasyonu ile seçilebilir yaptım:

Bir dalga üretmek iki eksende hareket etmemizi gerektirir: Y ekseni tahmin etmesi kolay olacağı üzere
V = Vref * REFGN * DRVGN * (DAC0H:DAC0L) / 4095
çarpanlarıyla belirlenir.
X ekseni ise zaman. Dalga şeklimizin çözünürlüğüne bağlı olarak, istediğimiz frekansı bir tam periyotta üretecek bir hızla DAC güncellemesi yapmamızı gerektirir.

Daha açık bir deyişle, bir dalga şeklini 12 örnekle tanımlamışsak DAC güncelleme frekansımız istenen dalga frekansının 12 katı kadar olmalı. Örneğin;

Yandaki dalga şeklini tanımlayan “normalize” sinüs dizisi;
32,48,60,64,60,48,32,16,4,0,4,16

Bu diziyi, DAC’a 208us periyotla yüklersek yaklaşık 2,5ms periyotlu bir sinüs çıkışı alırız. Bu da 400Hz kadar eder. Ses çıkışını test etmek için bunu deneyebiliriz.
Burada ilginç olan iki nokta var: Birincisi sample genlikleri unipolar. Çünkü DAC çıkışımız 0V ile seçtiğimiz pozitif Vref gerilimi arasında bir gerilim üretebilir. O yüzden, genliği simetrik bir işaret üretmek istiyorsak Vref/2 kadarlık bir offset eklememiz gerekir.
İkinci nokta, DAC sayısal değerimizle ilgili. Ben bir dalga şekli tanımlarken onu 0..64 gibi bir aralıkta normalize ederek üretiyorum. Eğer donanımsal değil, yazılımsal genlik ayarı yapmak isterseniz bu 0..64 aralığını 0dB kabul edip, sample değerlerini istediğiniz bir sabitle çarpıp, anlık bir çıkış genliği üretirsiniz.

Eğer bu bir ses işareti ise ters-logaritmik bir adım bölümlemesi volume ayarı için uygun olacaktır. 4095 verilebilecek en büyük çıkış değeridir. DAC çıkışını yüklüyorsanız ve 3V gibi bir range ayarı yaptıysanız çıkışın max. değerden önce doyuma ulaşması tehlikesi vardır.

Aşağıda, genel amaçlı kullanıma uygun bir dalga tablosu tanımı paylaşıyorum. Burada her bir dalga tanımı 24 byte’tan oluşuyor (her sample little endian yerleşmiş 12 word). Bunu denemek isterseniz dikkatinizi çekmek istediğim bir şey var: İlk 4 dalga haricindeki dalga tanımları kendisini 3 kez tekrar ediyor. Yani bunların frekansını hesaplarken x12 değil x4 hızla yükleme yapmalısınız.
code quailfier ile dizinin flash bellekte yerleşmesini sağlıyorum ancak mutlak adres veremiyorum. _at_ directive kullandığınızda değişkenleri başlatamazsınız.
Bu yüzden de, bu işleri denerken en başta yaptığım gibi, çalma kesmesi içinde doğrudan bir code pointer’ı çalıştıramıyorum. Bunun yerine waveTable dizi indeksini volatile bir değişken olarak kullanıp compiler’ın verimliliğine güveniyoruz.

unsigned char code waveTable[288] = 
{ 
	// wav-1 : sine +18dB
	0x00,0x01,0x80,0x01,0xE0,0x01,0xF8,0x01,
	0xE0,0x01,0x80,0x01,0x00,0x01,0x80,0x00,
	0x20,0x00,0x00,0x00,0x20,0x00,0x80,0x00,
       // wav-2 : sine +28dB
	0x00,0x03,0x80,0x04,0xA0,0x05,0xE8,0x05,
        0xA0,0x05,0x80,0x04,0x00,0x03,0x80,0x01,
        0x60,0x00,0x00,0x00,0x60,0x00,0x80,0x01,
	// wav-3 : sine +32dB
	0x40,0x05,0xE0,0x07,0xD8,0x09,0x56,0x0A,
        0xD8,0x09,0xE0,0x07,0x40,0x05,0xA0,0x02,
        0xA8,0x00,0x00,0x00,0xA8,0x00,0xA0,0x02,
	// wav-4: sine +36dB
	0x80,0x07,0x0B,0x40,0x10,0x0E,0xC4,0x0E,
        0x10,0x0E,0x40,0x0B,0x80,0x07,0xC0,0x03,
        0xF0,0x00,0x00,0x00,0xF0,0x00,0xC0,0x03,
	// wav-5: symm.sawtooth +12dB
	0xC0,0x00,0xFC,0x00,0x00,0x00,0x40,0x00,
        0xC0,0x00,0xFC,0x00,0x00,0x00,0x40,0x00,
	0xC0,0x00,0xFC,0x00,0x00,0x00,0x40,0x00,
	// wav-6 symm.sawtooth +24dB
	0x00,0x03,0xF0,0x03,0x00,0x00,0x00,0x01,
        0x00,0x03,0xF0,0x03,0x00,0x00,0x00,0x01,
	0x00,0x03,0xF0,0x03,0x00,0x00,0x00,0x01,
        // wav-7: symm.sawtooth +32dB
	0xE0,0x07,0x56,0x0A,0x00,0x00,0xA0,0x02,
        0xE0,0x07,0x56,0x0A,0x00,0x00,0xA0,0x02,
	0xE0,0x07,0x56,0x0A,0x00,0x00,0xA0,0x02,
	// wav-8: symm.sawtooth +36dB
	0x00,0x0C,0xC0,0x0F,0x00,0x00,0x00,0x04,
        0x00,0x0C,0xC0,0x0F,0x00,0x00,0x00,0x04,
        0x00,0x0C,0xC0,0x0F,0x00,0x00,0x00,0x04,
	// wav-9: sq.wave: +12dB
	0xFC,0x00,0xFC,0x00,0x00,0x00,0x00,0x00,
	0xFC,0x00,0xFC,0x00,0x00,0x00,0x00,0x00,
	0xFC,0x00,0xFC,0x00,0x00,0x00,0x00,0x00,
	// wav-10: sq.wave: +24dB
	0xF0,0x03,0xF0,0x03,0x00,0x00,0x00,0x00,
        0xF0,0x03,0xF0,0x03,0x00,0x00,0x00,0x00,
        0xF0,0x03,0xF0,0x03,0x00,0x00,0x00,0x00,
	// wav-11: sq.wave: +32dB
	0x56,0x0A,0x56,0x0A,0x00,0x00,0x00,0x00,
        0x56,0x0A,0x56,0x0A,0x00,0x00,0x00,0x00,
	0x56,0x0A,0x56,0x0A,0x00,0x00,0x00,0x00,
	// wav-12: sq.wave: +36dB
	0xC0,0x0F,0xC0,0x0F,0x00,0x00,0x00,0x00,
        0xC0,0x0F,0xC0,0x0F,0x00,0x00,0x00,0x00,
	0xC0,0x0F,0xC0,0x0F,0x00,0x00,0x00,0x00
};

DAC güncelleme “frekans” ayarı konusuna geri dönelim: Ben bu iş için Timer-2 kesmesini kullanıyorum. TMR2’ye vereceğimiz bir reload değeri ile DAC güncelleme hızını ayarlarız, böylece dalga üretecimizin X ekseni hassas biçimde ayarlanmış olur. 

CKCON0 |= 0x30;   // TMR2 clock source -> SYSCLK
TMR2CN0 = 0;      // 
// çalıştırmak:
TMR2CN0_TR2 = 1;  // bu register bit addressable
// çalma frekansını değiştirmek:
TMR2RLL = rld_L;
TMR2RLH = rld_H;

TDAC (DAC Erişim Periyodu) = istenen işaret periyodu / N
N : Bir periyodun örnekleme sayısı (yukarıdaki örnekte bu 12)
T2 : (TMR2 tick period) = 1/49M
Reload Değeri = 65536 – (TDAC / T2)

Bir çalma ayarında istenen frekans değerini değil, TMR2 reload değerini saklamayı tercih ediyorum.

TMR2 kesmesinde yapılacak iş “sıradaki” sample’ı DAC’a yazmak. Oynatılacak (veya çalınacak diyelim) dalga örneklerini flash bellekte saklıyorum. Bu noktada iki farklı yaklaşım geliştirdim:
Birinci yöntemde, çalma ayarları yüklenirken (mesela bir sequencer’ın belli bir adımının zamanı geldiğinde) flash’tan, sequencer’ın belirttiği dalga setini okuyorum ve yukarıda anlattığım şekilde düzey ölçeklemesi yapıp (normalize sample’ların volume ayar değeriyle çarpılması) ram’de bir çalma tablosu oluşturuyorum (hatta iki tablo oluşturup biri çalarken diğerini yükleme ve geçişleri hızlı yapma gibi bir şey denedim ama 49MHz çalışmada bu çok kritik bir hızlandırma değil).
Çalınacak sesin genliği ya da dalga şekli değişinceye dek çalma tablosu artık değişmiyor.
İkinci yaklaşım daha sade: Çalınacak sample’ları flash’ta normalize halleriyle değil, ölçeklenmiş halleriyle saklıyorum ve çalma sırasında doğrudan flash’tan okuma yapıyorum. Okunacak dalga tablosu indeksini sequencer yüklemesinde bir rom pointer’ında belirliyorum ve sonra kesme kodunda doğrudan pointer’ı çalıştırıyorum. Bu yaklaşımda TMR2 kesme kodu şöyle:

// Play Kesmesi:
void ISR_TMR2 (void) interrupt 5
{ 
   TMR2CN0_TF2H = 0;
   // playBuffer ba$a sarmasi gerekiyor mu?:
   if ( smpIndex > 11 ) 
   {
     smpIndex = 0;
     playIndex = wavIndex;	// çalma indeksini de ba$a sar.
     // durdurma istegi verilmi$ mi?
     if (STOP_REQ) 
     {
       TMR2CN0_TR2 = 0;  // artik player kesmesi tetiklenmeyecek..
       STOP_REQ = 0;
       return;
     }
  }
    
  ///// DAC Update:
  SFRPAGE = 0x30;     
  DAC0L = waveTable[playIndex];  // yukarida anlattigim mevzu!!
  ++playIndex;
  DAC0H = waveTable[playIndex];
  SFRPAGE = 0;
  ++playIndex;
  ++smpIndex;
  
}

playIndex waveTable’ın sıradaki elemanına erişmek için kullandığımız dizi indeksi. Bunu, çalma adımını yüklediğimizde (ne çalacağımızı bize söyleyen veri) öğreniyoruz ve indeksi başlatıyoruz. Bunun yerine, muhtemelen daha efektif bir kesme kodu için
unsigned char code * volatile data playPtr;
şeklinde bir işaretçi tanımı yapıp bunu çalınacak rom sample’ları boyunca da koşturabilirdik.

Burada, özellikle dikkat edilecek bir nokta var: Kesme kodu içinde SFRPAGE değiştiriliyor. Interrupt handler yedeklemeyi hallediyor mu halletmiyor mu hiç endişe etmemek için, bu kesmeyi başka bir kesmenin kesmesi ihtimalini ortadan kaldıralım. (Böyle cümleleri şık hale getirmeye çalışmak işi sulandırmak olur, sonuçta anlatım bozukluğu yok).
Daha açık konuşursam, bu işlemci bir de UART kesmesi çalıştırıyor (native priority’si daha yüksek). Çipi başlatırken UART kesmesini TMR2 kesmesinden daha düşük öncelikli olacak şekilde ayarlıyorum. Çünkü gelen bir byte biraz bekleyebilir (baudrate düşük).
DAC yazması yaparken başka bir koda atlamak SFRPAGE anahtarlaması dışında da sorunlar yaratacaktır. Çünkü DAC güncelleme hızımız SYSCLK hızında. Bu arada yeri gelmişken onu da not edeyim: DAC güncelleme hızını SYSCLK yapmamızla TMR2 kesmesi içinde DAC yazması yapmamız arasında bir bağlantı yok. DAC’ın kendi güncellemesi başka bir şey. Sanırım yazılımdan daha bağımsız DAC otomasyonları yapmak istersek kullanışlı olur. Yine de, ben merak edip DAC update source ile benim DAC yazma kesmemi aynı timer ile çalıştırdım. Sonuç değişmedi. Sonuçta SYSCLK çok hızlı olsa da biz çıkışı 200kHz hızıyla güncelleyebiliriz (bunu da denedim). Bu, tıpkı ADC’de olduğu gibi, “elektriksel” bir kısıt. Kişisel görüşüm, 200k gayet yüksek bir hız!

Son olarak, bir sequencer (kullanıcı tarafından belirlenmiş dalga şekillerini verilen ayarlara göre bir diziden okumak ve art arda üretmek) yapacaksak, çalmayı anlık olarak durdurmak ve devam ettirmek için kullanabileceğimiz makroları da vereyim:

#define Play_Sequencer()  SFRPAGE = 0x30; DAC0CF0=0x80; SFRPAGE=0; \
			  TMR2L = seqData.pt_rld_L; \
                          TMR2H = seqData.pt_rld_H; \								  
                          TMR2CN0_TR2=1; IE_ET2=1; \ 					  
                          PLAYING=1; MUTE=0; LED1=0
								  
#define Stop_Sequencer()  MUTE=1; \
	  	          TMR2CN0_TR2 = 0; IE_ET2=0; \					  
                          SFRPAGE=0x30; \
			  DAC0L=0; DAC0H=0; \
			  DAC0CF0 = 0; \
			  SFRPAGE=0; PLAYING=0; LED1=1

Sequencer’ın verilen adımındaki ayarlara bakarak DAC’ı konfigüre etmek de şöyle olabilir:

	// cfg.<pwr> bitlerine bak:
	 switch ( seqData.cfg & 0x03 )
	 {
		case 0:		// 2V çiki$
		  REF0CN = 0x80;	
		  DACGCF2 = 0x11;		  
		  DAC0CF1 = 0x00;
		break;
			
		case 1:	  // 1,2V çiki$
		  REF0CN = 0x40;
		  DACGCF2 = 0x10;
		  DAC0CF1 = 0x00;
		break;
			
		case 2:    // 1,6V çiki$
		  REF0CN = 0x80;
		  DACGCF2 = 0x12;			  
		  DAC0CF1 = 0x00;	  
		break;

		case 3:	 // 2,4V çiki$
		  REF0CN = 0x80;
		  DACGCF2 = 0x10;		  
		  DAC0CF1 = 0x00;
		break;
		
	}

	/// wav pointer'ini ba$latalim:
	wav_address = 0x3C00 + 24 * seqData.wav;	
	playPtr = (unsigned char xdata *) wav_address;
	smpIndex = 0;

        /// çalma frekansini güncelle:
        TMR2RLL = seqData.pt_rld_L;
        TMR2RLH = seqData.pt_rld_H;

Yukarıdaki örnek kodda 12 sample’lık bir wav dizisi kullanılıyor ve flash bellekteki 0x3C00 sayfası bu işe ayrılmış. Kullanıcının seçtiği wav indeksi seqData.wav parametresinden okunuyor.
smpIndex, sınır denetimi yaparken 16 bit sayılarla kendimizi yormayalım diye kullanılan yardımcı bir değişkendir. Kesme koduna bakabilirsiniz.

Sonuçta, gördüğünüz gibi, DAC kullanarak bir dalga şekli üretmek, eğer çıkışta analog bir işaret kullanma ihtiyacınız varsa PWM ile aynı sonucu elde etmeye çalışmaktan daha basit bir iştir. Yukarıda bir audio çıkışı (benim aklıma waveform generator deyince ilk bu geliyor) üzerinden örnek verdim. Ancak daha önce, programlanabilir bir sabit akım kaynağı işi için de bu DAC çıkışını kullanmıştım. Çalıştığımız alan, LED parlaklığını PWM ile ayarlamamızın mümkün olmayacağı bir uygulamaydı. Bu durumda EFM8’in bir çipte 4 adet bağımsız kullanılabilen DAC çıkışlarını bir sabit akım kaynağına referans girişi yaparak basit ama doğruluğu yüksek bir çözüm üretebildik. (Bunu da burada paylaşırım bir ara)

ADC Auto-Scan

Bir Cevap Yazın

Bir analog-dijital dönüştürücünün çalışma hızı ölçüm devresine ve ADC’nin yapısına bağlıdır. Öte yandan, çok sayıda analog kanalı örneklemek gibi bir ihtiyacımız varsa “hız”a dair kaygımız genellikle, ADC’nin kendi ölçüm hızı değil bizim kanallar arasındaki geçiş hızımızla ilgili olur. Çünkü biz bir işlemcinin üstündeki ADC’yi kullanıyoruz ve kanallar arasında geçmek ve ölçüm sonuçlarını bir yere yazmak gibi işler dönüştürme işleminden daha çok zaman alıyor.

Eğer çok sayıda analog girişi okumak gerekiyorsa ve dahası, bu kanalların aynı anda alınmış örnekleri (mesela bir besleme hattının akım ve gerilim ölçümü gibi) anlamlıysa veya kesin bir bir zaman aralığında alınmış belli sayıda örnek toplamak istiyorsak bu işleri donanımsal olarak halletmek işimizi çok kolaylaştıracaktır.

EFM8’de bu tür durumlarda kullanabileceğimiz bir tarama fonksiyonu var. Bu fonksiyon ADC modülünün ayarlarından bağımsız olarak istediğimiz zaman kullanabileceğimiz bir örnekleme otomasyonu sağlıyor.

  • ADC’yi istediğiniz referans ve örnekleme/dönüştürme hızı ayarlarıyla ayarlıyorsunuz.
  • Sonra tarama işleminin başlangıç kanalını seçiyorsunuz. Taramada en çok 4 kanal ardışık olarak örneklenebiliyor.
  • Sonra kaç kez örnekleme yapılacağını belirliyorsunuz. Burada, komutla başlatılan tek bir örneklemenin sayısı belirleniyor. Bir örnekleme kendi içinde istenen sayıda oversampling içerebilir.
  • Dönüştürme işlem sonucunun xram’de yazılacağı konumu belirliyorsunuz.
  • İşlemi başlatıyorsunuz.

Tarama ayarını bir kez yaptıktan sonra işlemleri otomatik başlatabilirsiniz. Tarama içindeki iki dönüştürme işlemi arasına sabit bir süre koyabilirsiniz veya tarama içindeki dönüştürmeleri birbirine olabildiğince yakın yaptırabilirsiniz.
Bir tarama işlemi yapılırken sonraki işlem için istenen ayarları hemen berlirleyip ADC’yi durmaksızın arka arkaya farklı ayarlarla çalıştırabilirsiniz. Bu, mesela double-buffering gereken okuma durumlarında işin buffer güncelleme kısmını çok basitleştirir.

Aşağıdaki kod örneği, AN6..AN9 kanallarının birer kez ölçülmesi ile elde edilen sonuçları xram’in 16..23 konumuna big endian olarak yazdırır:

SFRPAGE = 0x30;
ADC0MX = 6;		  // AN6 seç (ba$langiç kanali)
ADC0ASAH = 0x00;
ADC0ASAL = 0x10;	  // sonuçlari xram=16 adresinden itibaren yaz
ADC0ASCT = 3;		  // tarama 4 sample sürer (her kanal 1 kez)
ADC0ASCF = 0xC3;          // 4 kanal örneklenecek..	
ADC0ASCF = 0x43;          // _ASEN = 0
SFRPAGE = 0;
ADC0CN0_ADINT = 0;
ADC0CN0_ADBUSY = 1;

Yukarıdaki kodda en ilginç kısım, ADC0ASCF_ASEN bitini 1 yapıp işlemi başlattıktan sonra hemen sıfırlamamız.
ASEN=1 yapıldığında donanım tarama ile ilgili tüm ayarları dahili belleğe kopyalar. Yani, ASEN=1 yaptıktan sonra tüm ayarları bir sonraki tarama için değiştirebiliriz.

Yukarıdaki ayarlarla, ADINT=1 olduğunda işlemler bitmiş ve sonuçlar xram’e yazılmış olacak. Eğer durmaksızın sonraki 4 kanala geçmek isteseydik _ASEN=0 yapar yapmaz ADC0MX’i ve ADC0ASAL’i değiştirmemiz yeterliydi.

Ben bu örnekte öyle yapmadım ama ADC0ASCF_STEN bitini 0 yapıp ADC’yi bir timer ile tetiklenecek şekilde ayarlasaydık (ADC tetikleme kaynağı ayarının tarama özelliğiyle ilgisi yok) zaman aralıklı tarama çalışması elde etmiş olurduk. Belki ileride bununla ilgili bir örnek de paylaşırım.

ADC işleminin sonucunda üretilen veriyi eşzamanlı olmayan başka bir süreç kullanıyorsa bu işi otomatize etmek ve kullanıcı sürecin sadece ram’deki datayla uğraşmasını kodlamak performansı oldukça arttıracak bir iyileştirme. Donanımı kullanmasını bilmek ile donanımdan bağımsız kod yazmakta konfor aramak arasındaki farka oldukça dramatik bir örnek olarak göz önüne alınabilir.

Pulse Encoder Knob Interface

Bir Cevap Yazın

Keyes-KY040 encoder’dan gelen harekete göre değer girişi yapmak için bir arayüz hazırlamam gerekti, bununla ilgili düşüncelerimi burada paylaşmak istiyorum.

KY-040 modülünde 5 pinli bir header var. Bu pinler sırasıyla şöyle isimlendirilmişlerdir:

GND, + Besleme
SW Pushbutton NO ucu
DT Faz-B
CLK Faz-A

Modülün iç yapısını yukarıdaki gibi gösterebiliriz:

BQ’ları açık kollektör NPN çıkışlı endüktif proximity switch’ler olarak görelim. Rod Push Switch, knoba basınca kısa devre olan bir push-button. Bendeki modülde R3 olarak gözüken direnç takılı değil. Ama bu şekliyle bunu ham kontak olarak kullanamayız çünkü diğer uç (-) beslemeye gidiyor, yani her durumda bunu bir pull-down button olarak kullanacağız demektir.

İnternette yapılan bir aramada, beslemenin +5V’a bağlandığını gösteren şemalar geliyor ama sanırım bu, arduino modüllerinin bir kısmının 5V ile çalışması yüzünden böyle belirtilmiş. Ben modülü +3V ile besliyorum çünkü benim devrede, +3V’a bağlı harici pull-up dirençleri de var.
DT ve CLK uçları endüktif algılayıcıların pull-up yapılmış çıkışlarına bağlı ve aralarında dönme yönüne bağlı faz farkı olan encoder çarkı izleme sinyalleri.

Bu arada, modülün üstünde pull-up dirençleri olduğu için encoder sinyallerini işlemciye doğrudan bağlamak yeterli gibi gözükse de kenarlarda debounce olmasına tahammülü olmayacak kadar hızlı bir kod çalıştıracaksanız, pull-up kondansatörleri kullanmanız iyi olur. Ben işlemciye girmeden önce 10nF kondansatör ile pull-up yapıyorum.

ENC-A ve ENC-B olarak isimlendirdiğim encoder pulse sinyallerini P06 ve P07 portlarına giriyorum. P0’ın kullanılması şart değil, işaret fazlarını değerlendirmekte kullanacağım port-match fonksiyonu EFM8’in tüm pinlerinde var. Ancak, söylemeye gerek yok ama aynı portun pinlerini kullanmak register ayarlarını tek yazmada yapmamız açısından hızlandırıcı olabilir elbette.

Firmware

Eğer üzerinde çalıştığımız işlemcinin üstünde QEI (Quadrature Encoder Interface) modülü yoksa encoder fazlarını takip etmek için bir yol olarak port match fonksiyonunu kullanabiliriz.
Ben bu encoder’la ilk denemeleri yaparken doğrudan port değerini okuyan bir döngü ile sistemi çalıştırdım. Zaten örnek program diye bulacağınız şeylerin hepsinde de öyle yapılıyor.
Ancak pratik kullanımlarda çoğu zaman deneme programında olduğu gibi, port okumasına âmâde bomboş bir ana çevrim olmayacaktır. Bu durumda, özellikle yüksek encoder hızlarını doğru okumak için port-mismatch kesmesini kullanmak yerinde olur.

EFM8’de her bir portun MAT register’ıyla ayarlanan bir port match değeri var. Bunu portun “olmasını beklediğimiz” değeri, “boşta” değeri olarak düşünelim. Herhangi bir port bitinin durumu bu boşta değerden farklı olduğu an bir kesme tetiklenir. Elbette bu mekanizmayı sadece ilgilendiğimiz port bitleri için devreye almamız gerekir. Bunu da her portun MASK değerini ayarlayarak yaparız.
Port mismatch kesmesi EIE1<1> (_EMAT) biti ile devreye alınır ve 8 numaralı kesme vektörüne atlama yaptırır.
Kesmenin tetiklenme koşulunu şöyle yazabiliriz:
Py.x & PYMASK.x != PYMAT.X & PyMASK.x
Bu kesmenin bir flag’i yok. Kesmeye atlandığı an durum sıfırlanıyor. Microchip’teki gibi mismatch tetikleyen portu okuma zorunluluğu da yok.
Benim uygulamada, P0^6 ve P0^7 için mismatch kesmelerini devreye almak, sürekli olarak çağrılan bir kodla portların durumunu yoklama külfetinden (overhead) bizi kurtarıyor:

#define Enable_Port_Mismatch() P0MAT = 0xFF; P0MASK = 0xC0; EIE1 |= 0x02


Encoder’da bir hareket olduğunda kesme tetiklenecek. Ancak iki şeyi daha ayırt etmemiz gerekiyor: Hareketin yönü ve bitişi.
Bunun için kesme kodu içinde basit bir durum makinesi çalıştırmak gerek. Bu durum makinesinin çalışmasını şöyle özetleyebilirim:

0ENC_IDLEHangi girişin kesmeye neden olduğunu bul (önde olan faz). Bu, hareket yönünü belirlememizi sağlar. Ardından önde olan fazın kesme üretmesini iptal et. [Diyagramda 1 durumu]
1ENC_CW_LEADINGBu aşamada gelen kesme kesinlikle B girişinden geliyordur. Artık uygulamaya saat yönünde bir hareket olduğunu söyleyebiliriz. B fazının mismatch durumunu 1 yaparsak hareket fazının bitişinde kesme almış olacağız. [Diyagramda 2 durumu]
2ENC_CCW_LEADINGBu aşamada gelen kesme kesinlikle A girişinden geliyordur. Uygulamaya saat yönünün tersinde hareket olduğunu söyleyebiliriz. A fazının mismatch durumunu 1 yaparsak hareket fazının bitişinde kesme almış olacağız. [Diyagramda 2 durumu]
3ENC_PULS_TRAILINGGeride kalan fazın 0->1 gerçişi yapmasını bekle. Bu, hareketin bitişi demektir, yani durum makinesi başa dönebilir. [3] durumu. Her iki yön için de bu adım ortak.
4ENC_WAKEUPBu, sistemi uykudan uyandırmak için kullanılan adım. Bir hareket algılaması yapılmayacağı için durum makinesi çalışmaz.
void ISR_Port_Mismatch(void)  interrupt 8
{
 switch ( encoder_state )
  {
    case ENC_IDLE:
    // Encoder bo$ta iken bir mismatch kesmesi gelmi$se
    // önde olan faz =0 olmu$ demektir. Bu, cw/ccw ayrimini yapmamizi saglar
	  if ( ENC_A == 0 )
	  {
             P0MASK = 0x80;	// P0.6 (ENC_A port match fonksiyonu kapatildi)
	     encoder_state = ENC_CW_LEADING;
	  }
	  else
	  {
	     P0MASK = 0x40;	// P0.7 (ENC_B port match fonksiyonu kapatildi)
	     encoder_state = ENC_CCW_LEADING;
	  }
     break;
	
	
     case ENC_CW_LEADING:
     // bu a$amada gelen interrupt enc-b: 1->0 geçi$i sebebiyle tetiklenmi$tir..
     // $imdi, enc-b: 0->1 geçi$ini bekleyebiliriz:
	P0MAT = 0x40;
	ENC_PULS_CW = 1;
	/// todo: ENC_A = 1 durumu hata olarak algilanabilir!
	encoder_state = ENC_PULS_TRAILING;			
    break;
		
		
    case ENC_CCW_LEADING:
    // bu a$amada gelen interrupt enc-a: 1->0 geçi$i sebebiyle tetiklenmi$tir..
    // $imdi, enc-a: 0->1 geçi$ini bekleyebiliriz:		
	P0MAT = 0x80;
	ENC_PULS_CCW = 1;
    /// todo: ENC_B = 1 durumu hata olarak algilanabilir.
	encoder_state = ENC_PULS_TRAILING;
    break;
		
		
    case ENC_PULS_TRAILING: 
    // bu interrupt gelmi$se gerideki fazin: 0->1 geçi$i olmu$ demektir.
    // encoder fazi tamamlanmi$tir.
    // fiziksel olarak tamamlanmi$ olsa bile, bir fazin bitmesini 
    //bekleyen i$lem flag'inin sifirlanmasi ile mumkun kilalim:
	P0MAT = 0xC0;
	P0MASK = 0xC0;
	encoder_state = ENC_IDLE;
   break;		
		
   // CPU encoder hareketi ile IDLE durumdan çikmi$ demektir.
   // encoder okuma state mach. çali$mayacak.		
   case ENC_WAKEUP:
    // wake-up durumundan çikiliyor.
      EIE2 = 0;
   break;

   }
}

Bakınca, ana döngü içinde port poll eden “örnek” uygulamadan bile daha basit gözüküyor. Artık, pulse üreten encoder’ınızı,
ENC_PULS_CW ve ENC_PULS_CCW
adında, Port mask ve(/veya) _EMAT bitleri ile kolayca devreye alınıp çıkarılabilen mantıksal bit girişleri olarak düşünebilirsiniz.
Bu bitlerin sıfırlanması uygulama programının sorumluluğundadır. Siz ENC_PULS_XX bitini işlemeden yeni bir pulse algılanırsa bu hareket “atlanacaktır”. Ben uygulamamda bunu özellikle istiyorum çünkü ekrandaki bir değeri encoder hareketine göre değiştiriyorum. Öte yandan hız/konum algılama gibi bir iş yapacaksanız encoder kesmelerini ana programın işlemesi öncesi buffer’lamanın bir yolunu düşünmelisiniz. En basiti, hareket ile artan/azalan bir tamsayı sayaç kullanmaktır, değil mi?

LMT01 ile Sıcaklık Probu

Bir Cevap Yazın
LMT01 sıcaklık probu / temperature probe
LMT01 Temperature Probe

LMT01 TI’nin yüksek doğruluklu dijital sıcaklık algılayıcı çipidir. Benim bir sıcaklık ölçüm probu yapma işine soyunduğumda bu malzemeyi seçmiş olmamın ana sebebi, bunun doğruluğunun yüksek olması. İkinci seçim sebebim, bunun dijital çıkışının pulse-count olması. Bu sayede probu ilave bir önlem almaksızın uzatabilirim. Bir üçüncü sebep de, bu sensörün fiziksel yapısı ve malzemesi sayesinde ısıl eylemsizliğinin düşük olması, yani tepki süresinin hızlı olması. Kullanım alanına göre, bu çok önem kazanabilir (ileride anlatacağım). Belki bir seçim sebebi sayılmaz ama TO92 kılıfta geliyor olması da mekanik işleri kolaylaştırıyor.

Pulse count interface, sıcaklık ölçüm sonucunu pulse sayısı olarak çıkış vermek demek. Ayrıca, çipin kendisi de bu arayüzden besleniyor. Pulse çıkışı akım değişimi olarak oluşturuluyor. Bir ölçüm + veri yollama periyodu 104ms sürüyor. Kullanmadığımız zaman çipin enerjisini kesebiliyoruz. Enerjiyi vermeye devam ettiğimiz müddetçe çevrim 104ms’de bir tekrarlanıyor (yani örnekleme frekansı 9,6Hz olarak sabit).

LMT01 bir pulse yollamak için 125uA, boşta durum için 34uA akım çıkışı yapar. Bu akımları gerilime dönüştürmenin en basit yolu bir direnç üzerinden çıkışı toprağa bağlamaktır. Direnç uçlarındaki gerilim sensörün çıkış dalga şekli olacaktır. Bu direnci seçerken LMT01’in uçları arasında 2,15V’luk bir potansiyel farkının korunmasına dikkat etmek gerek. POWER (Vp) ucuna 3V vereceğimizi düşünürsek ölçüm direncimizin uçlarında 125uA çıkış akımı için en fazla 850mV bir gerilim düşümüne hakkımız olduğunu görürüz.

Ben bu mevkide oynatmak için E96 serisinden 6k19 değerinde bir direnç seçtim. Bu direncin uçlarında 125uA pulse’ı yollanırken 774mV gerilim oluşacaktır. Ancak, fark ettiğiniz üzere bu voltaj, bir mikroişlemci girişi tarafından doğrudan lojik olarak okunmaya uygun bir seviye değildir, özellikle de bahsettiğimiz seviyelere bir gürültü marjının da eşlik edeceğini hesaba katarsak..

Gerilim değişimi doğrudan seviye okumaya uygun olmadığında MCU ‘nun comparator modülünü kullanmak uygundur. Ancak isminden de anlaşılacağı gibi, comparator modülünün diğer ucuna da bir referans gerilim bağlamamız gerekecek. Ben bu tarafı da programlanabilir yapmak için şöyle bir yol düşündüm:

LMT01’in çıkışına koyduğumuz direncin aynısından bir tane daha kullanıyoruz ve bunun üstünden de akım çıkışlı DAC ile ayarladığımız bir referans akımı geçiriyoruz. Dirençler aynı değerde oldukları için artık seçeceğimiz eşik değerini son derece güvenilir biçimde akım cinsinden belirleyebiliriz. Sıcaklıkla değişim gibi şeyleri de dert etmek zorunda kalmayız.

Referans akımı 34uA ile 125uA arasında bir yerlerde olmalı. Tam orta noktayı (80uA) seçmek mantıklı gibi gözüküyor.

EFM8SB1’deki DAC 1uA ya da 8uA (Hi current mode) çözünürlükle çalıştırılabiliyor.

EFM8SB1 IDAC module

EFM8SB1’deki akım referansı modülünü Hi-Current mode’da çalıştırıyorum. Bu durumda modül 8uA’lik adımlarla akım çıkışı üretiyor. Modülün akım ayarı 6 bit olarak tanımlanıyor. IREF0DAT = 10 (desimal) yazmakla 80uA çıkış elde ediyorum.

Güç tasarrufu sağlamak için, akım kaynağını yalnızca ölçüm yapacağım zaman açıyorum. Ek olarak, akım kaynağının sürdüğü direncin paralelinde bir kondansatör de olduğu için komparatör çıkışını saymaya başlamadan bir süre önce akım kaynağını açmış olmam gerek. 

IREF0CN0 = 0x4A;    // 8*10=80uA akım referansı

Akım kaynağı modülünü 80uA ile çalıştırdığımda iki direncin uçlarındaki gerilim yukarıdaki gibi gözüküyor. Bu seviyenin şimdilik uygun olduğunu düşünüyorum. Şimdilik yazdım çünkü bu denemede LMT01’i 1m uzunluğunda bir kablonun ucuna taktım. Bir de, sensör çıkışındaki dirence paralel 100pF bir kondansatörüm var.

Referans seviyemizi de ayarladığımıza göre artık comparator module’e bakabiliriz:

EFM8SB1 Comparator module

Bizim uygulamada comparator’ün iki girişini de port pinlerine bağlıyorum. Çıkışın asenkron halini de aynı şekilde port pinlerinden birine alıyorum. Interrupt kullanmıyorum. Ama anlayacağınız gibi, eğer pin sayısını azaltma gibi bir gereksinim olsa idi, bu kesmelerden birini kullanarak, sayma işini interrupt handler’a yaptırabilir ve kullanılan modül sayısını azaltabilirdim.

Comparator async. output sinyalini de crossbar üzerinden portlardan birine çıkış veriyorum. Artık burada, komut cycle’ından bağımsız fazlı şekilde LMT01’in count pulse sinyalini görebilirim.

CMP0MD = 0x80;      // fastest response, edge interrupt'lar kullanilmiyor
CMP0MX = 0x44;      // P11 = CMXN, P10 = CMXP
CMP0CN0 = 0x81;		// bunu yapmak comp. modülünü açar ve 5mV negatif hystersiz verir

Comparator modülünü yalnızca sensörü okumak istediğim zaman açıyorum (enerji tasarrufu). 5mV negatif hysteresis (düşen kenar) eklemek, eşik değerini biraz daha yüksek seçsem bile darbe genişliğinin çok azalmamasını sağlıyor (aslında sayma hızım bu mertebelerin çok üstünde olsa da).

5mV’luk düşen kenar hystersis’inin dalga şeklinin duty cycle’ını neredeyse %50’ye getirdiğini görebilirsiniz. Düşen kenardaki overshoot’u benim comparator çıkış pini (CPO) üzerinden ölçüm almam yüzünden görüyorsunuz. CPO pinini T0 girişine 100 ohm gibi bir direnç üzerinden bağlamanın neden iyi olduğunu da açıklıyor (T0 yüksek giriş empedanslı bir sonlandırma ve pull down direnci de bulunmuyor). Elbette burada tüm bu bağlantılar birkaç mm içinde hallolduğu için hiçbir şeyi dert etmeniz gerekmez. Ben genel konuşuyorum, amacımız bu basit sensörü çalıştırmak değil, büyük resmi görün.

Sıcaklık sensöründen gelen pulse’ları lojik seviyeye çevirdikten sonra, şimdi onları saymamız gerekiyor. Karşılaştırıcının çıkışını bir pine alıp onu da işlemcinin sayıcı olarak ayarlayabildiğim bir girişine bağladığımda artık LMT01 pulse’larını kesme falan koşturmadan sayabilirim:

EFM8SB1 T0 Mode0/1

8051 ‘de T0 ve T1 modülleri harici sayaç ya da gated counter olarak ayarlanabiliyor. Bir pini, crossbar’da T0 counter girişine route edip T0’ın CT0 bitini 1 yapmak girişteki pulse’ları saymak için yeterli.

TMOD = 0x25;        // TMR1: mode 2, TMR0: 16 bit counter, TMR0 T0 pin counter mode
TH0 = 0;
TL0 = 0;
TCON_TF0 = 0;
TCON_TR0 = 1;

Geriye tek bir şey kalıyor: MCU’nun pinlerinden birini, LMT01’i beslemek için çıkış yapmak. Bu pini 0 yaptığımda sensör devre dışı kalmış olacak.

Bu donanım düzenlemelerini yaptıktan sonra pulse count interface ile okuma yapmam için gereken firmware işlemleri şunlar:

1) Sensörü enerjilendir.
2) Akım kaynağını aç.
3) 20ms bekle.
4) Karşılaştırıcıyı aç.
5) Sayıcıyı devreye al.
6) Sayıcının, 180ms boyunca gelen pulse’ları saymasını bekle.
7) 180ms sonunda sayıcıyı kapat. Karşılaştırıcıyı kapat. Akım kaynağını kapat.
8) Gelen pulse sayısı iki ardışık ölçüm sonucunun toplamıdır.

Bir sıcaklık sensöründen sürekli arka arkaya ölçüm almak istemeyiz. Çünkü;
1) Bu zaten gereksizdir çünkü sıcaklık denen fiziksel nitelik genellikle çok hızlı değişen bir şey değildir. (Ortam sıcaklığı gibi şeyler ölçtüğümüzü varsaydığımızda)
2) Enerji bütçemiz kısıtlıdır. 2V – 34uA besleme ile çalışan bir sensör kullanıyorsam düşük güç tüketimi gerektiren bir uygulamam var demektir. Tasarım kriterini bu yönde olabildiğince ileride karşılamaya çalışırım.
3) Dijital bir sensörü sürekli çalıştırırsam onun kendi kendini ısıtmasına neden olurum. Doğruluğu bu mertebede olan bir çipte bu belirgin bir hata yaratacaktır.

Çipi sürekli enerjili tutarsak LMT01 yukarıda göreceğiniz hızla çalışıyor. Bu, olabilecek en yüksek ölçüm hızımızdır. Bir hatta akan suyun sıcaklığını ya da kimyasal bir tepkimenin sıcaklığını ölçmeniz gerekiyorsa 120ms’de bir ölçüm yapabileceğinizi bilmeniz gerek.

Bu sensörün ölçümlerini başka bir sensörle kıyaslayan basit bir uygulama hazırladım. Aşağıdaki trend grafiğinde gördüğünüz 32 *C’lik plato, LMT01’i parmaklarımın arasına alıp birkaç saniye tutmam sonucunda oluşan sıcaklık değişimi.

Bu çalışmayı aşağıdaki sensör board’u ile yaptım:

Kablolu ve kablosuz olarak bir host aygıta sıcaklık ve nem ölçümleri gönderen bir uygulamaya dair bilgileri burada paylaşacağım.

Ayrıca LMT01 kullanan hassas el termometresi tasarımına dair notlarımı da burada paylaşacağım.