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

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

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

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

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

verici.c

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

alici.c

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

Bir resim:

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

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

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

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

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

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

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

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

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

Bu sorunu nasıl çözdük?

Madem clock bir süre geç çalışıyor biz de bir süre anlamsız işaret göndererek-herhangi bir işaret- clock un düzgün çalışmasını bekler ve hiç bekletmeden verimizi göndeririz. Nitekim böyle yaptığımızda verileri başarıyla gönderebildik. Okuduğum yazıların birinde bu işaret için uyandırma işareti

ifadesi kullanılmış, bence isim çok güzel uymuş. CCS C kodu olarak bu işlemi aynen şöyle yapmış oluyoruz:

putc(0b01010101); //uyandır

putc(veri); //veri gönder

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

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

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

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

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

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

Öncü Veri (”Preamble”) Nedir?

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

Örnek:

Verici tarafa:

putc(0b01010101); // uyandırma

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

putc (veri); // verimizi gönderiyoruz

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

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

gelen_veri=getc(); //veriyi al

}

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

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

Uzun zamandır yazmak istememe rağmen yazamadım, sitenin kapandığı sırada bir kaç gelişme oldu, onları kağıda yazdım şimdi ordan bakarak da bazı şeyleri aktaracağım. Biraz havadis biraz teknik uzun bir yazı olacak, gittiği yere kadar…

Staj vesilesiyle Anakara’ya geldim, çalışma kutumu da toparlayıp biraz da “zip”leyip getirdim, birkaç malzeme gerekti geçen hafta ilk defa meşhur Konya Sokak’a gittim. Vitrinlerin önünde gezerken heyecanım depreşiyordu, ne zaman malzeme almaya gitsem zamanım da varsa vitrin vitrin gezinirim. O esnada bir yerleden “128 byte gönderdim hepsi gitti” gibisinden sesler duydum, bir süre kulak kesildim(!) birileri bir şeyler konuşuyordu… Muhabbete girmemek için kendimi zor tuttum, sonra bir dükkana girdim, az önce konuşan zat-ı muhterem de bir süre sonra aynı dükkana girince dedim Allah gönderdi, ordan bir muhabbet… picproje.org dan da tanıdık çıktık, laf lafı açtı-malum elektronik dünyası- konuşmaktan yorulduk, kendisiyle tanıştığıma çok memnun oldum sonra iletişim adreslerimizi alıp ayrıldık. Mühendis misiniz diye girmiştim konuya, arkadaşı biraz şaşırttım ama bazen böyle deli cesareti geliyor işte… okursa kendisine burdan saygılar:)

İlk girdiğim dükkanda UDEA nın modüllerini bulabilmem güzel bir şeydi, Karaköy’de UDEA modül nerde satılıyor hala bilmiyorum. Datalogger çalışması için büyük RAM li bir PIC almam gerekiyordu 18F4520 buldum, 1536 Byte rami var, başka 18F serisi o dükkanda yoktu biz de yeter dedik aldık. 628A dan vazgeçtim çünkü tüm rami kullanmak istesem de yetersiz kaldığını farkettim. Bu arada geç de olsa bu benim ilk 18F PIC im oluyor. k128 programlayıcım güncel olmadığı için 18F4520 yi programlayabilmek için güncellemem gerekti. Güncelleme işini şöyle yaptım:diypack26.rar lincocin içindeki .msi dosyasını çalıştırdıktan sonra oluşan C:\diypgmrt dizinine gidip k128.HEX i 16F628A model bir PIC e yüklüyorsunuz, sonra bu yeni programlanmış PIC i k128 in 16F628A sıyla değiştiriyorsunuz, yani k128 in içindeki PIC e yeni program yüklemiş olduk. Yazılım olarak da artık eskisi değil C:\diypgmrt dizinindeki MicroPro.exe yi kullanıyorsunuz. Bu kadar! Programlarken “silinme” ile  alakalı bir uyarı veriyor ancak devam deyip geçerseniz programlıyor. En azından 18F4520 yi doğru programladı ve eski bazı PIC leri de test ettim. Deneme amaçlı PT2262 ve 2272-M4 encoder decoder aldım. Denemelerin ardından sonuçları burdan yazarım inş. Bu encoder-decoderin “full datasheet” lerini de firmasından rica minnet istedim, “kimsin, ne projesi napıyorsun” gibi sorulardan sonra firma yetkilileri katalogları gönderdi. Katalogları detaylı, güzel

Datalogger için uğraşıyordum da hangi kumanda sistemi basit, saf data gönderiyor ki! Biz bile preamble dı senkron du datayı epeyce kalabalık gönderiyoruz. Encoder-decoder lı sistemlerde dataya farklı işlemler uygulanıyor vs . Dolayısıyla loglama işlemine girişmeden önce sistemleri iyi tanımak lazım. Öncelikle benim loglamak istediğim data ASK modülasyonlu olması gerekiyor, çünkü elimde UDEA ve keymark olmak üzere ASK receiver var. Geçtiğimiz günlerde şu deneyleri yaptım:
Keymark alıcı modülü PC ye bağladım ve hiçbir data göndermezken çeşitli baud seçeneklerinde ne geliyor diye baktım, aynısını udea alıcı modül ile de yaptım, sonuçlar hemen hemen aynı, tamamen rastgele olduğunu düşündüğüm datalar geliyor (herhangi bir istatiksel benzerlik bulunabilir mi bilmiyorum) ya da alıcı modül öyle yorumluyor:

mavi halka içine aldıklarım A ve E dataları, bu datalar haberleşmede kullanabileceğimiz bilindik datalar. Hatırlarsanız “Rf modüllerinizi test edin” yazısında ilgili durumdan bahsetmiştim.  Bir süre sonra kendi vericimi çalıştırdım(udea veya keymark farketmiyor) ve sonuç:
yani ben rf vericiden data gönderdiğimde anlamsız veriler yerine çok yüksek bir doğruluk oranında kendi gönderdiğim ABCDE bilgisi iletildi.

Eğer alıcıyı çalıştırıp vericiyi de TX pinine bağlarsam ve TX ten hiç veri göndermezsem ekran temiz kalıyor, yani modüller “idle state” i aktarıyor (bunu sadece udea modüllerle denedim).

Önceki yazılarda UDEA ve keymark modüllerin kendi içlerinde alıcı-verici modüllerin haberleştiğinden bahsetmiştim. Yani bir keymark verici başka bir keymark çiftinin alıcısıyla çalışabilir, aynı şekilde UDEA da. Zaten satın alırken bir verici kutusundan bir de alıcı kutusundan rastgele bir çift veriliyor. Rf modüllerinizi test edin yazsını hazırlamaya çalışırken devreleri kurmuştum ama gelin görün ki UDEA nın verici-alıcısıyla keymark ın alıcı-vericini karıştırıp deneme yapmamıştım. Yani keymark verici> UDEA alıcı gibi… farklı kombinasyonları neden denemediysem! İki modülün katalogunda da ASK kullanıldığı söylenmiş. Keymark ON-OFF Keying yani ASK nın en basit formunu kullandığını söylemiş. Dolayısıyla bu modüller kendi içlerinde özel bir encoding-decoding yapmıyorsa-ki görünmüyor-  birbirleri arasında haberleşebilmeliydi. Sonuçları söylemeden ASK yi hatırlayalım:

Eğer lojik 0 durumunda düşük genlikli bir işaret yerine hiç bir şey gönderilmeseydi yine ASK ama OOK olacaktı.
UDEA verici Keymark alıcı çifti pek iyi çalışmıyor, bugün tekrar denedim verilerin ancak çok küçük bir oranını doğru alabildim. Ancak Keymark verici UDEA alıcı ile gayet güzel çalışıyor.

3310 lcd ekranı okuma işleri ise…
Nokia LCD sürücüsü pcd8544 nü inceledim, okuma konusunda iki büyük sıkıntı var. Birincisi “instruction set” te read komutu yok, evet içerde bir RAM var ama sürücü devre okuma izni vermiyor. İkincisi karakter tablosu yok, her karakter piksel piksel oluşturuluyor, kayan yazıları hatırlattı. Temel işlemler D/C (data/command), SCL(serial clock), SDIN (serial data in) pinleri üzerinden yapılıyor. SCL nin yükselen kenarında SDIN örnekleniyor. Bitler MSB önce olmak üzere gönderiliyor, 8 bit gönderildikten sonra işlem yapılıyor(komut veya data her neyse). Bu durumda okumak yine mümkün, ama biraz zor yoldan… SCL nin her yükselmesinde RB0 kesmesiyle girilen seri data kayıt edilip PIC le çözülebilir ama tahmin edeceğiniz gibi gelen data 1010101.. yumağı halinde ve işlenmesi uzun sürebilir. Yapmaya değer duruyor, işlerin gidişatına göre uğraşabilirim de uğraşamayabilirim de… Eğer siz uğraşmak isterseniz Proteus 3310 library dosyasını(hazırlayana teşekkürler), CCS C librarisini ve lcd sürücü katalogunu burdan indirebilirsiniz.

Son olarak kayan yazı panosu Farkettim ki kullandığım 74HC154 decoder in pin başına akım kapasitesi çok düşük, 20 mA, dolayısıyla parlaklık sorunları vs eksik olmuyor. Texas Ins. in power logic ismini verdiği takımda tpic6b595 adında bir “shift registeri” var, pin başına max akım 500mA nominal akım 150mA civarı gayet iyi yani ama biraz pahallı-1.75 YTL-. Ancak bu “shift register” bildiğimiz 74595 ler gibi değil, çıkışlar “open drain”. Şöyle: tpic6b595 de lojik 1 çıkışı diye bir çıkış yok, eğer siz çıkışa lojik 1 datası gönderirseniz çıkış toprağa çekiliyor ve toprağa çekilen pin 150mA sink akım çekebilme kabiliyetine sahip oluyor. Eğer çıkışa lojik 0 gönderirseniz katalog çıkış “off” olur demiş, yani mosfet kesime girip çıkış yüksek empedans gösteriyor. Yani çıkış için iki seçenek var ya toprak ya yüksek empedans. Gerekirse pull-up direnç yardımıyla lojik1 çıkış elde edilebileceğimizi unutmayalım.

Uzun bir yazı oldu, herkese iyi çalışmalar dilerim.