Kategori arşivi: EFM8

EFM8 DAC

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 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

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?

EFM8BB3 Sıcaklık Sensörü

Sıcaklık ölçümü ile ilgili hikayelerimizde sıra hiçbir sensör kullanmadan sıcaklık ölçmeye kadar geldi.

İşlemcilerin üzerinde bir sıcaklık sensörü olması alışıldık bir durumdur. Silabs EFM8 serisinde de analog modülde, giriş multiplexer’ını ayarlayarak ADC bağlantısını yapabildiğimiz bir sıcaklık sensörü var.

Bu sensörü ortam sıcaklığı ölçmede kullanmayı düşünüyorsanız bunun çoğu durumda pek iyi bir fikir olmayacağını baştan söylemem gerek. Daha önce anlattığım kendi kendini ısıtma etkisi, tahmin edeceğiniz gibi işlemci üstündeki sensör için ziyadesiyle geçerli olacaktır. Elbette koskoca işlemciyi yalnızca sıcaklık ölçmek için kullanmayacağınızı varsayıyorum.

İşlemci üstünde sıcaklık ölçmenin bize donanımsal bir maliyeti yok. Sıcaklık ölçmek için ADC’nin herhangi bir dış bağlantısına ihtiyaç duymuyoruz. Yazılımsal olarak da büyük bir maliyet yok. Birkaç satırlık kod ve birkaç ms içinde işimiz halloluyor. Herkes adına ve her durumu açıklamak için konuşamam ancak ben daha önce onboard sensörü iki sebeple kullandım:

Birincisi board’umun sağlıklı çalışacağı bir sıcaklıkta olup olmadığını kontrol etmek için. Zamanında tasarladığım bir DC sürücü oldukça küçük bir board üstünde çıkış katı işlemci regülatör vs. bir aradaydı. İşlemcinin sıcaklığının 60 küsur dereceyi geçmesi durumunda önce çıkış gücünü sınırlamak sonra da aleti tamamen kapatmak gibi bir iş için onboard sensörü kullanmıştım.

İkinci kullanımda da aslında başka bir şeyi ölçmek için bir donanım kurmuşuzdur ama ölçeceğimiz şey sıcaklığa bağlıdır. Bu durumda sıcaklığa göre düzeltme yapmak için eğer uygunsa board sıcaklığını referans alabiliriz.

Vereceğim örnek kod ADC’yi hali hazırda kullanıyor olup olmamamızdan bağımsızdır çünkü ADC’nin güç bağlantılarının belli bir durumda olmasını gerektirir:

ADC0CF2 = 0x70;	 // Vref= internal ref. (1,65V) gnd= GND
ADC0MX = AMUX_TSENS;
ADC0CN0_TEMPE = 1;  // onboard temp. sensor enabled
Delay(96);  // 1ms bekle
ADC0CN0_ADBUSY = 1;

Onboard sıcaklık sensörünün çalışması için TEMPE kontrol bitini 1 yapmak lazım. Fakat öncesinde, ADC referansını 1,65V dahili referansa, eksi bağlantıyı da çip GND’ına bağlıyorum.
ADC giriş multiplexer’ına 0x14 (AMUX_TSENS) yazınca girişi de bağlamış oluyoruz.
Sıcaklık sensörünün açılma süresine bakarsanız 1,8us gibi bir süre görüyorsunuz ancak buna referansın açılmasını ve SAR girişinin settle olmasını da eklemek gerek.
Ben çeşitli donanımsal sebelerle ADC’nin kendi power-up delay zamanlamasını kullanmıyorum. O yüzden sıcaklık sensörünü açtıktan sonra, alışkanlıktan, 1ms bekliyor ve ADC dönüştürme işlemini sonra başlatıyorum.

ADC sequencer’ı, çözünürlüğü, örnekleme hızı vs. mevcut ayarlarımızda olabilir. Onları burada yeniden yazmadım. Sonuçta onboard sıcaklık sensörünün parametreleri gerilim cinsinden tanımlanmışlardır:

Sensörün V / *C kazancının offset hatasına oranına bakarsanız, çipten çipe 6 *C’lik bir 0 *C noktası farkı olduğunu göreceksiniz ki bunun kullanacağınız 100 çipten 68’i için garanti edildiğini de göz önüne almalısınız. Uzun lafın kısası, eğer mutlak değer doğruluğu sizin için önemliyse her bir board için 0*C offset’ini ölçüp flash’ta saklamanız gerekir. (Bununla kim uğraşır bilemiyorum)

Bir termostat uygulaması için sıcaklık okuması yapıyorsak *C skalası çalışma esnasında bizim için gerekli değil. Ancak yaptığımız ölçümün *C karşılığını bilmek istersek, yaptığımız ADC ölçümünden, 757mV ‘a karşılık gelen ADC okuma sayısını çıkarıp sonucu da 2,85 mV’a karşılık gelen ADC sayısına bölerek bir *C sonucuna “yaklaşabiliriz.

Sıfır noktası konusundaki belirsizliğe karşılık mV / *C doğruluğu oldukça belirlidir. Bunun sizin için anlamı şu: Bir noktada, bilinen bir değere ölçekleme yapmanız doğruluk açısından yeterli olacaktır.

Onboard sensörü kullanmanın en güzel yanı, self heating’in ne kadar dramatik bir etki olduğunu gözlerinizle görmenizi sağlayacak olması. Bunu olumsuz bir şey olarak düşünmüyorum. İşlemcinin kendi sıcaklığını görmesi sistemin toplam güvenliği için her zaman çok iyi bir şeydir. Bu arada, buzlu suyla 0 noktasını ayarlarsanız bu sensörün oldukça iyi bir doğruluğu olduğunu keşfedeceksiniz. Teşekkürler Silabs..