PIC ile LED yakma

[ULAGA]

4x4 matrix şeklinde dizilmiş 16 tane led ile yapılmış animasyon devresidir. PIC16F84 ile yapılmış olup, 9-12V ile çalışabilir. BU DEVRENIN ÇALIŞMA PRENSIBINI AÇIKLAYABILECEK BİRİ VARMI ?

İnternette delinin birisi bir şeyler karalamış ve resmini çekmiş.
Ben de o resim üzerinden anlatayım olayı.


Buton olsun, LED olsun bu gibi sistemlerde tarama yöntemi kullanılır.
Mesela yukarıdaki LED devresini, PIC16F628A'nın B portuna bağlayalım.

PORTB0 > 9
PORTB1 > 10
PORTB2 > 11
PORTB3 > 12
PORTB4 > 3
PORTB5 > 4
PORTB6 > 5
PORTB7 > 6

Eğer 9 ve 3'e lojik 1 verirsek, en sol üst köşedeki LED yanar.
Aslında uygulamalı olarak anlatsam daha iyi anlarsın.
Örnek olarak bütün en dıştaki LEDleri yakıp, bir kare çizebilmek için şu kodları arka arkaya göndermen gerekir;

PORTB = 0x1F;
PORTB = 0x29;
PORTB = 0x49;
PORTB = 0x8F;

 

[GüvTek]

4x4 matrix şeklinde dizilmiş 16 tane led ile yapılmış animasyon devresidir. PIC16F84 ile yapılmış olup, 9-12V ile çalışabilir. BU DEVRENIN ÇALIŞMA PRENSIBINI AÇIKLAYABILECEK BİRİ VARMI ?

LM7805 kullanacaksın besleme için.. PICte PORTB nin 4 bitini yatay 4 bitini dikey tarama için kullanacaksın.. Mesela yataydaki ledlerin - lerini PORTB nin son 4 bitine bağladın.. Son 4 bite sırayla 0 vereceksin.. Dikeydeki ledlerin +larını da PORTB nin ilk 4 bitine bağlayacaksın, ve son 4 bit ile seçtiğin yatay sırada yanmasını istediğin dikey ledleri çıkış olarak vereceksin..

RB0---*---*---*---*-
RB1---*---*---*---*-
RB2---*---*---*---*-
RB3---*---*---*---*-
RB4 RB5 RB6 RB7

(*)ların led olduğunu varsa.. Ve (-) lerini PORTB nin 0-3 nolu pinlerine, (+) larını da PORTB'nin 4-7 nolu pinlerine bağladın.. Sırayla önce RB0 a (-) verip, sonra RB4-RB7 arasından ilk sırada yanmasını istediğin ledleri 1 olarak çıkış vereceksin.. Bi süre bekleme koyacaksın.. Sonra RB4-RB7 pinlerini 0 yapıp, 2. sıraya geçecek, ve 2. sırada yakmak istediklerin için RB4-RB7 den 1 vereceksin.. Sonra 3. sonra 4. sonra tekrar 1..

 

[GüvTek]

PORTB = b'0001 1111';
PORTB = b'0010 1001';
PORTB = b'0100 1001';
PORTB = b'1000 1111';

Binary olarak kareyi daha rahat görür sanırım..

 

[ULAGA]

Binary olarak kareyi daha rahat görür sanırım..

Alışmışım HEX'e, idare et.

 

[GüvTek]

Uzmanlık derken ne demek istediğimi aslında sen son mesajın içinde belirtmişsin zaten.
Eğer bir geliştirici, örneğin bir I2C protokolunu inceleyip bunu, ASM'ye dökebiliyorsa prosodürsel olarak, işte o şahıs ASM'de uzmandır.
Bir yazdığın prosedürü, başka bir yazılımında kullanamıyorsan, muhakkak geliştirirken bir şeyleri eksik yapıyorsundur.
Kütüpheneleme konusunda elimden geldiği kadar yardımcı olurum sana.
Tabii, paylaşmak istersen.

Hocam şöyle söyleyeyim.. GSM modülü kontrolü için 2 yazılım yazdım.. Biri 16F biri 18F için, elbette birbiri yerine kullanamam.. Ama aynı işlemci olduğunu varsayalım..

Birinde sms geldiğinde direk okunup işlem yapılıyor.. Çoklu komut desteği de var.. Fakat okuma anında işlem yaptığından, 10-12 baytı eeproma kaydederken mesajı okuyamıyor ve kilitleniyor.. Ayrıca yanıt smsleri sabit olmak zorunda, yani şu mesajı şu şu numaralara gönder şeklinde bişey yapamazsınız.. Herşey pic programının belirlediği sırada olmalı.. Aksi halde algılamama vs gibi sorunlar olacaktı.. Haliyle sistemin esnekliği ve kararlılığı için ram üzerinden kontrol etmeliyim diye düşündüm..

Yenisinde önce mesaj okunuyor, sonra mesaj bilgileri çözülüp, yapılacaklar rame kaydediliyor.. Sistem boşta bekleme moduna girdiğinde ise bu işlemler parça parça yapılıyor, gelen tek bir baytı dahi kaçırmamak için.. Örneğin eeprom kaydı bayt bayt yapılıyor..

Özetle biri tamamen komutlar üzerinden belli bir sırada işlerken, öteki tamamen ram üzerinden işliyor.. Bunlarda bazı komutları kullanabilsem de tümünü birebir kullanamıyorum.. Mesela mesaj gönderimi, eskisinde bikaç bayt üzerindeki her bit bir mesaj anlamına geliyordu.. Fakat yenisinde her mesaj bizzat rame kaydoluyor ve oradan gönderiliyor.. Altyapı nerdeyse tamamen farklı..

 

[ULAGA]

Benim anlatmak istediğimi anlamamakta ısrar ediyorsun GüvTek.
Ben sana işlem parçacıkların, kütüphane olmasından bahsediyorum;
Sen ise tüm işlem parçacıklarının birbirine uymamasından bahsediyorsun.
Şöyle örnek vereyim;
24C serisi E2PROM'lara veri kaydetmek için aynı kütüphaneyi kullanırsın.
Yüksek hafızalı serileri için birkaç satır kod değiştirirsin sadece.
İşte bu okuma-yazma işlemi için bir kere kütüphane yazarsın ve onu sürekli kullanırsın.
Ben bunu diyorken, sen; "E2PROM'a veri kaydettim, ondan sonra şunu yapması gerekiyor. Öbür yazılımda ise başka bir şey yapması gerekiyor." diyorsun.
Senin anlattığın olay kütüphane olayına değil ana yazılımın yapacağı işlemlere giriyor.
Mesela mesaj okuma olayında okuma şeklinin farklılığında bahsetmişsin.
O zaman her ikisini de kütüphane haline getirirsin.
Ve bundan sonraki GSM devrelerinde nasıl bir şekilde mesaj okuyacaksan o prosedürü kullanırsın.
Sistemini ayrıntılı bilmediğim için daha derinlere inemiyorum.

 

[GüvTek]

Dediğiniz doğru, ufak tefek parçacıkları kullanabiliriz,, ki onları yazmak kolay zaten.. Ama alt yapıyı değiştirdiğinizde sistem değişiyor.. Mesela eeprom kaydını fonksiyon olarak kullandınız diyelim.. Normalde ne yapılır, önce baytı kontrol edersin farklıysa yazdırır bekler, sonra yine kontrol eder ve bitirirsin.. Bu döngü 5-10 ms sürer..

Ama bunu kesme ile yapmam gerekiyor ki seri port verisi kaybolmasın.. Kesmeye de bu rutini direk koyamam.. Genelde kullandığım seri port tamponu da 16 bayt.. 10-12 baytlık veri yazım süresinde yeterli gelmiyor.. Eğer kesmeli halini kütüphane rutini yaparsam, bu durumda da komutlar içine eeproma kayıt tamam mı şeklinde bir sorgu koymam gerekir, haliyle diğer yazılıma uymaz.. Kütüphaneye 2 kayıt rutinini de koymam gerekir haliyle.. Yani illaki kütüphane düzenini bozan bişeyler çıkıyor asmde..

Mesaj gönderimi, biraz yanlış bir örnekti sanırım ama sistemin alt yapısının standart komutlar kullanımına etkilerini vurgulamak istedim..

Kütüphane hiç kullanmıyor değilim, mesela TBLPTR registerlerine etiket atamalarını macrolar üzerinden yapıyorum.. Ama iş programlamaya gelince standart olmuyor hiç birşey..

 

[ULAGA]

Bence konu; tamamen neyin standardize edilip edilmemesi ile alakalı.
Kesme olayı farklı bir olay olduğu için zaten onun da kütüphanesel bir hâle dönüştürmek fikri kabul edilemez bir şeydir.
Kesmede basit değişken denetimi yaparsın, kesme ile alakalı işlemleri de, o değişken ile farklı noktalarda çözersin.
Aslında daha somut ve güzel bir örnek üzerinde gidersek daha kolay anlaşacağız gibi görünüyor...
Verilen örnekler zaten kütüphane olayına uymuyor.
Atıyorum ortada bir grafik kütüphanesi var, dikdörtgen, daire, üçgen ve kare prosedürlerini oluşturan.
Kare çizmen gereken yerlerde girdi olarak, başlangıç X,Y değerleririni bir de bitiş X,Y değerlerini girersin;
O prosedür de o girdilere göre grafiğini çizer.
Başka bir örnek; kare içine üçgen çizdirmek istiyorsun.
Bunun için yine kare ve üçgen metodlarını birleştirirsin, al sana yeni bir kütüphane.
Bu oluşturduğun prosedüre sadece başlangıç ve bitiş X,Y değerlerini verirsin, o da sana kare ve içinde üçgen çizer.
Bu kütüphanedir.
Ancak sen bunu bir programda RS232 kesmesinde kullanacağım, diğer programda da TIMER kesmesinde kullanmak isterim dersen;
Bu senin dediğin kütüphane olayına girmez.
Tamamen iş (business) mantığına dayanır.

 

[GüvTek]

Sms gönderimi örneğimde bu girişlerde birinde adres giriyorsunuz, diğerinde string değişkeni giriyorsunuz..

Eepromdan bahsedecek olursak,, bir string değişkeni eeproma kaydetmek istiyorsunuz.. Bunun için 2 yol var.. Ya eeproma harf harf sırayla yaz emri verip işlemin bitmesini bekleyeceksiniz ya da "eeprom yazımı bitti" kesmesini kullanan eeprom rutinine şu değişkenleri yaz diyeceksiniz..

İkisi de aynı kapıya çıkar aslında.. Ama ilk örnek yazılımın işlem yapmasını önler.. Diğeri ram yettiğince sorun yaratmaz..

Şimdi sorunumuz şurada.. İlk örnekte yazdır dediğinizde, bu komutlardan hemen sonrasında eeprom verisi güncellenmiş ve iş bitmiş olacaktır.. Haliyle bayt okurken eeprom yazılmış mı kontrol et, gibi birşeye gerek yok.. Ancak diğer kesme ile yazım durumunda, program diğer işlerini yaparken kayıt işlemi hala devam ediyor olacaktır.. Haliyle eepromu kullanan ana döngüdeki programlara, "eeprom kaydı varsa bu işlemi ertele" gibi bir komut koymalısınız.. Okuma fonksiyonunun içine eepromu bekleme komutu koyarız diyeceksiniz sanırım.. Bu durumda da yazım esnasında eepromu okumak istediğinde ana döngüyü tekrar tıkayacaktır.. Aynı amaçlı, farklı yöntemli 2 fonksiyonun ana döngüdeki komutlara etkisini söylemek istedim..

Aslında haklısınız, tüm sorun standardize edememekten geliyor..

 

[ULAGA]

GüvTek, zaten her şeyi kütüphane yapacaksın diye bir kaide yok.
Kütüphanelerin ortaya çıkma sebebi, kod tekrarını ortadan kaldırmaktır.
Bir yazılımda, aynı işlem birden çok yerde kullanılıyorsa, onu kütüphane ya da prosedür haline getirmek zorundasındır.
Yoksa aynı işlemi kodun başka bir yerinde değiştirdiğinde, öbür yerdeki aynı kalır ve sen sabahlara kadar hatanın nerde olduğunu arar durursun.
Bir yazılımda, bir işlem asla iki defa yazılmamalıdır, bunu aklından çıkartma yeter...