Picproje Elektronik Sitesi

SERBEST BÖLGE => Programlama ve Algoritma => Konuyu başlatan: Mucit23 - 10 Ekim 2014, 10:56:41

Başlık: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 10:56:41
Arkadaşlar Selamlar,

Resimdeki iç ortam 16x32 paneller üzerinde çalışma yapmak istiyorum.
(https://farm6.staticflickr.com/5609/15490691851_4a6d50a7c0_z.jpg)

Panelin tarama yapısını anlayamadım bir türlü. Panelle ilgili açık döküman internette hiç yok. Bu yüzden kendi imkanlarımla panelin yapısını anlamam gerekiyor.

Panelin bağlantı konnektörü aşağıdaki gibi.
(https://farm4.staticflickr.com/3940/15307264257_4e7632280d_z.jpg)

Burada LATCH, CLK ve OE pinlerini biliyorum.

Anlamadıklarım A,B,C  pinleri. Bunlarla muhtemelen tarama yapılıyor. R1, R2, G1, G2, B1, B2 pinleri ise data girişi olması gerekiyor. internette bir tablo buldum.

(https://farm3.staticflickr.com/2947/15470711786_93898729fd_z.jpg)

Bu tabloya göre ekran dikey olarak 2 ye bölünmüş. ilk 16 sütün'a kadar R1, G1 ve B1 pinlerinden data gönderilirken 16-32. sütünlarda ise R2, G2 ve B2 pinleri kullanılıyor. Bunu anladım.

Satır seçiminin nasıl yapılacağını anlayamadım. 16X32 için A,B ve C pinleri bu işte kullanılması lazım. Yukarıdaki tabloyu sparfun'ın sitesinden aldım. Orada Arduino kullanılmış ve A B C pinleri Arduinonun analog girişine bağlanmış. demux input diyor. Bu kafamı epeyce bir karıştırdı.

Tarama konusunda satır seçiminin nasıl yapıldığını anlayamadım. Bu konuda fikri olan varmı? 16x32 Panelde A, B ve C pinleri kullanılarak nasıl satır tarama yapılır?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: XX_CİHAN_XX - 10 Ekim 2014, 12:17:08
Bence 1. satır ile 9. satır, 2. satır ile 10, ....., 8. satır ile 16. satır beraber taranıyor. Bu şekilde A,B,C pinlerinden 3 bitlik BCD çıkışı 16 satırı taramak için yeterli gelebiliyor. Peki üst 8li ile alt 8li nin satırları ortak ise stun ları ayrı olacaktır. Zaten onun da ayrı olduğu gözüküyor R1,G1,B1 ve R2,G2,B2 şeklinde stun dataları ayrılmış. Clock, Latch ve OE lerin ayrı olmasına gerek olmadığı için tüm Shift Regsiter larda ortak tutulmuş. Bu pin yapısından başka mantıklı bir bağlantı türetemiyorum.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: OG - 10 Ekim 2014, 13:12:18
Mucit, şu rgb panelin şemasını çıkarıp paylaşsanda bir hayır yapsan.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 10 Ekim 2014, 13:32:27
Alıntı yapılan: XX_CİHAN_XX - 10 Ekim 2014, 12:17:08
Bence 1. satır ile 9. satır, 2. satır ile 10, ....., 8. satır ile 16. satır beraber taranıyor. Bu şekilde A,B,C pinlerinden 3 bitlik BCD çıkışı 16 satırı taramak için yeterli gelebiliyor. Peki üst 8li ile alt 8li nin satırları ortak ise stun ları ayrı olacaktır. Zaten onun da ayrı olduğu gözüküyor R1,G1,B1 ve R2,G2,B2 şeklinde stun dataları ayrılmış. Clock, Latch ve OE lerin ayrı olmasına gerek olmadığı için tüm Shift Regsiter larda ortak tutulmuş. Bu pin yapısından başka mantıklı bir bağlantı türetemiyorum.
Evet Hocam bu mantık geçerli olması gerekiyor.  Şartlar öyle gösteriyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 20:13:23
@OG hocam şema çıkarmak kolay. Panelin çalışmasını anlarsak zaten şema kendiliğinden ortaya çıkacak. Kağıda dökmek lazım sadece.

Herneyse satır taramayıda anladık, Sütünlara bilgi vermeyide anladık. Peki Ya PWM nasıl olacak. Yani her bir pixele ait renk bilgisi için o pixele pwm uygulanması gerekir. Hemde Shift registerlerdan yapılması gerekir. Diğer türlü led'leri açıp kapayarak sadece 7 renk elde ederiz.

Bana 24 bit renk çözünürlüğü lazım.

Bu konuda önerisi olan varmı?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: OG - 10 Ekim 2014, 20:20:04
Şema çıkarsa panelin çalışması şak diye ortaya çıkar.
Resmine bakarak veya sayısız olasılıkları düşünerek çalışmayı anlamak daha zor sanırım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 20:29:15
hocam ben birsey sormak istiyorum. bu modullerim fiyati ne kadar?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 20:31:41
Hocam haklısınız. Fakat şuanda elimde panel yok. Panel elime ulaşınca dediğinizi yapacağım.

Dediğim gibi Renk meselesi aklımı çok karıştırıyor. Eğer yüksek çözünürlüklü görüntü isteniyorsa mutlaka led'lere pwm uygulanması gerekiyor. Bununda tek yolu orada kullanılan 16 Bitlik Shift Registerin her pininden ayrı pwm sinyalleri çıkarmak. Yanlışmı düşünüyorum sizce. Eğer öyleyse bunu yapmak gerçekten zor olmalı.

@karamel yaklaşık 25$ civarında
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 20:34:31
 :-\ aslinda genel manada kullanilan malzemeleri dusununce ucuz ama benim icin pahali imis hocam. bu kayan yazilar cok hosuma gidiyor. yazin okullar tatil olunca bende kayan yazi yapmak istiyorum. bunlarin daha ucuz versiyonlari varmi hocam?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 20:37:02
@karamel
http://arectron.com/yazilim/p10-panel-kullanimi.html (http://arectron.com/yazilim/p10-panel-kullanimi.html)
Bu tek renkli ucuz olanları. Bundan ucuzu yok. Neyse Konuyu dağıtmasak iyi olur

Renk konusunda fikir görüş ve önerilere ihtiyacım var.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 20:42:46
bu supermis iste! ::) hemmen konuya geri donuyoruz hocam.

hocam burada sizin led modulden bahsediliyor. manual pwm yapiliyormus?(bu ne demek) fpga ve hizli microcontroller lar ile kolay olurmus arduino ile %20 sini kullarak 4096 bit renk i karistirmayi basarabilmisler.

https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/overview
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 20:55:25
Arduinoda 444 renk çözünürlüğü kullanılıyor. 4 Bit R, 4 Bit G, 4 Bit B. Toplamda 12 Bit Renk çözünürlüğü yapıyor. 4096'da burdan geliyor. Yani 4096 farklı renk demek.  Hobi amaçlı buda yeterli fakat İşin Tekniğini öğrenirsem çok rahat 24 bit Renk elde ederim diye düşünüyorum.

Resimlerden anladığım kadarıyla arka tarafta Shift Register yerine Sabit Akım led sürücüsü olan FD9802C kullanılıyor. Buda TLC5926 ayarında bi enteğreymiş. Şimdi taşlar yerine oturmaya başladı. Her kanaldan ayrı PWM uygulanıyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 20:59:50
http://www.logictoyz.com/electronic-components/fd9802c-16-bit-constant-current-5ma-90ma-led-driver-fd9802.html (http://www.logictoyz.com/electronic-components/fd9802c-16-bit-constant-current-5ma-90ma-led-driver-fd9802.html)

hocam bu entegre 16 cikisli pwm yapmayi becerebiliyormus. yani siz ledlerin herbirisini istediginiz gibi yakabilirsiniz. OG hocamda bir baksin ama. yanlis birsey soyluyor olabilirim suan.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 22:01:19
Panelin çalışmasında anlaşılmayan yer kalmadı sanırım.  :)
http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm (http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm)
Yukarıdaki Link'te herşey açıklanmış.

Tek bir soru kaldı aklımda birazdan açıklayacağım.

Şimdi Panel üzerinde toplam 12 adet led driver(FD9802) var. Bunlar 4 Bölge olarak ayrılmış. 16X32 paneli aklınızda iki ye 16x16 olmak üzere iki ayrı panel olarak düşünün. İsimlendirsek eğer 32 sütündan ilk 16 sütüna A bölgesi sonraki 16 sütüna ise B bölgesi diyelim.

Şimdi Panelde toplam 12 Adet led driver vardı. Bunlardan 6 tanesi A bölgesini, diğer 6 taneside B bölgesini kontrol eder.

A ve B bölgeleride kendi içlerinde iki parçaya ayrılıyor. A bölgesini ele alırsak eğer durum şöyle;

A bölgesinde 6 Adet led driver mevcut. Bu driverden ilk 3'ü 1-8 satırlar arasındaki bölgeyi kontrol ediyor. Diğer 3'ü ise 9-16 satırlar arasını kontrol ediyor.
Bu led driverler birbirlerine kas kat bağlı ama sıralama nasıl bilemiyorum. Birtek aklıma bu takıldı. Bunuda panel ile birebir uğraşınca inceleyip anlacağım.

Eğer Sistemdeki ledleri teker teker sayarsak eğer 16x32x3=1536 led eder.(RGB olduğu için 3 ile çarpıyoruz) Yani fiziksel olarak 1 panelde bu sayıda led olduğunu söyleyebiliriz. Sistemdeki LED driverlerin sayısı ise 12, Her birinin 16 çıkışı var. Ayrıca Her bir led driver 8 satırlık bir bölgeyi kontrol ediyor. Hesaplarsak eğer 12*16*8=1536 ediyorki paneldeki led sayısına eşit.  :) Zaten her 3 led driver ancak 16 adet RGB led'i kontrol edebiliyor.

En başta renk girişleri için R1, G1 ve B1 pinleri ile birlikte R2, G2, ve B2 pinleri olduğundan bahsetmiştim.  A bölgesindeki LED driver'lerin Data girişleri R1, G1 ve B1 dir. B bölgesi ise R2, G2 ve B2. Paneldeki Yapı böyle

Tarama ise Panelin ABC girişleri ile yapılıyor. Tarama sıralaması XX_CİHAN_XX'in dediği gibi. Panelde 16 satır var fakat bu 16 satır ayrı ayrı taranmıyor, ikişerli guruplar halinde taranıyor.

Paneldeki satırları yan yana yazarsak eğer aşağıda koyu olarak gösterdiğim satırlar aynı anda devrede oluyor.

  ABC                Aktif olan satırlar
  000       12345678 910111213141516
  100       12345678 910111213141516
  010       12345678 910111213141516
     .                 .                      .
     .                 .                      .
     .                 .                      .
     .                 .                      .
     .                 .                      .
  111       12345678 910111213141516

Tarama düzenide aynı bu şekilde. Aslında bunları bir tabloya dökmem lazım. Bu şekilde anlaşılması zor oluyor.

Benim panel ile uğraşmadan önce bir tane TLC5926 alıp bir tane RGB ledi 24 bit renk çözünürlüğüyle kontrol etmem lazım. Benim için işin püf noktası budur.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 22:48:43
hocam pwm icin sanirim yanlis konustum. mbi5026 da pwm le cikis olmuyormus. sanirim FD9802 dede ayni durum soz konusu. az once sizi umutlendirdim ama sanirim yanlis birsey soyledim.  :-\

hocam bakin verdiginiz linkte diyorki

The usual way to do a 24 bpp driver is to have the driver in a 256 level loop and within each loop compare the byte value of the color to the loop# and set the output if at or above this level.  But, the Prop just isn't fast enough to get 24 bpp this way.

Instead of this, we'll do a 8 bit loop with each loop lasting a power of 2 longer.  In this way, we can precalculate the output we want in the outa register.  So, there is no comparison in the loop and it can be faster. 

24 bpp yapmanin genel yontemi 256 level loop yapmak ve her bir cevrimede byte degerine gore cikis verdirmek ama propeller microcontrollerin hizi buna yetimiyor diyor.

bunun yerine biz 8 bitlik cevrim yapacagiz ve her bir cevrim ikinin kati kadar surecek(bu nedemek anlamadim) bu yontemle biz cikis registerlarini hasaplayabiliriz. bu yuzden, hizli olabilmek icin loop icinde karsilastirma yapmayacagiz.

yani yanlis anlmadiysam hocam sizin renk elde etmeniz icin ledin normal yanik kalma suresini(atiyorum 5 msn) bir sayiya bolup (buda mesela 5 olsun) bizim renk degerimiz kadar 5 msn icersinde ledleri geregi kadar yakmalisiniz. mesela 5 cevrim icin asagida tek renge ornek vereyim.


5 msn icersinde ledi

Cevrim1 = yandi ve 1msn boyle kaldi
Cevrim2 = yandi ve 1msn boyle kaldi
Cevrim3 = yandi ve 1msn boyle kaldi
Cevrim4 = yanmadi ve 1msn boyle kaldi
Cevrim5 = yanmadi ve 1msn boyle kaldi

siz o ledten %60parlaklik alirsiniz.  2 cevrimde yansa idi %40 bir cevrimde yansa idi %20 gibi hocam. diger ledleride yakarsaniz renk bulutu elde edebilirsiniz.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 10 Ekim 2014, 23:12:10
Evet dediğin doğru. Ben donanımsal PWM var diye ümitlenmiştim. Halbuki TLC5940 serisinde varmış.

Neyse Bu kısım zurnanın zırt dediği yer anlaşılan. Ve bayağı zorlayacak gibi.
Benim anladığım kadarıyla bu FD9802 veya TLC2640'ın 16 bit olması dışında 74HC595'den farkı yok(sabit akım vs dışında). Şu Bazı FPGA'lı kartlar vardı Normal Tek renkli P10'larda her pixele pwm felan uyguluyordu. Demekki oradada benzer bir mantık yürütülüyor. Çünkü monochrome video felan oynatıyor. Bende kendi kendime madem donanımsal pwm var neden arduino 24 bit renk çıkartamıyor diye söyleniyordum. Anlaşılan renk çözünürlüğü MCU Hızı + (Programcının kod yazma yeteneği)^2 ile doğru orantılı

@Karamel açıklama için teşekkürler fakat Bu çipin çalışma sistemini anlayamadım henüz.  Biraz daha ayrıntıya ihtiyacım var. Buradaki mantığı anlayan varmı?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 10 Ekim 2014, 23:32:43
hangisini hocam?  bende hangisini anlayamadiginizi anlayamadim :)

hocam benim anladigim kadari ile bu yontem microcontroller mantigina cok aykiri. cunku islenen her satir kod ile frekans bolunuyor ve ekrani surme hizimiz cok yavasliyor. led sayisi arttikca cok ama cok daha yavasliyor.

simdi su isi en az kod satiri isleyerek yapan algoritma bu isi kivirabilir.

her renk icin 3 bit cozunurlugumuz olacak(8 level) atiyorum 1. pixel icin RGB seklinde 1,5,7 degerileri icin her bir loop ta bu degerlerden bir azaltip 0 olmusmu diye bakacagiz. eger olmussa ledi sondurecegiz. asagida ornegini veriyorum hocam. bunu butun ledlere en kisa yoldan yapmak gerekir.

RGB 1,5,7 ti

loop1: (Hepsi yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop2: (R sondu digerleri yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop3: (R sonuk digerleri yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop4: (R sonuk digerleri yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop5: (R sonuk G sondu B yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop6: (R sonuk G sonuk B yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur


loop7: (R sonuk G sonuk B yanik)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur

loop8: (R sonuk G sonuk B sondu)
R,G,B den 1 cikart.
R <= 0 R ledini sondur
G <= 0 G ledini sondur
B <= 0 B ledini sondur


bu cikartma ve if kontrolleri led sayisi fazla olunca cok zaman harcayacaktir. bunu cozebilen bir algoritma dusunebilirsek bu is tamamdir.

mesaj birleştirme:: 10 Ekim 2014, 23:42:33

bu arada hocam yazmayi unutmusum yukaridaki 8 li loop u saniyede 20-30 veya 40 kere(led parlakliginin duzgun degisip degismedigine bakmak lazim. benim suanki bilgim kesin cevabi soymeye yetmiyor) tekrar etmek lazim. saniyede 40 kere oldugunu dusunsek 25 msn icersinde butun sutunlardaki(32*3) ledleri taramamiz gerekir. buda tek satir yapar. 16 satirida taramak istiyorsak 25/16 = 1.5625 msn de butun sutunlardaki(32*3) ledi taramak gerekir. zor bir is bu gercekten.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 11 Ekim 2014, 15:11:13
Dün akşam bilgisayarım çöktü sabahtan beri onunla uğraşıyorum. Yeni yeni toparlayabildim.

Dediğinizi biraz anladım. Fakat iş bu kadar zor olmaması gerekir. Heleki işin içine sorgulamalar felan giriyorsa olmaz kesinlikle.

Bu işin farklı bir yöntemi olmalı. Ben biraz arduino ile yapılan uygulamanın kodlarını inceleyeyim. Onda 444 toplamda 12 bitlik bir çözünürlük uygulanabilmiş. Yani FD9802'nin her çıkışında 4 bitlik bir çözünürlük alınmış. Konu hakkında yeterli düzeyde araştırma yapmadım. Umarım halledebilirim.

Ayrıca TI den TLC5926 sample olarak istedim. Eğer gönderirlerse, İlk testleri bu çip üzerinde yapacağım.


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 11 Ekim 2014, 15:38:06
hocam TLC5926 bu entegre her cikisindan farkli farkli pwm ler cikartiyor. FD9802 entegresi ise 595 entegresi gibi. 1 yada 0 cikartiyor. ikisi farkli seyler. 32*16 modulu bir microcontroller surebilir ama fazlasi icin yukaridaki algotimamiz hiz bakimindan yetmez gibi duruyor.

birde hocam. su asagidaki kodlari bir microcontroller a yazip derleyip ledin davranislarini gozetleyebilirmisiniz? benim suan deney yapma sansim yok. (goz algilayacakmi diye merak ediyorum.)


char i, j;

while(1)
{
  for(i=0; i<40; i++)
  {
    for(j=0; j<5; j++)// bu kisim totalde 25 msn duruyor. 40 kez tekrarlaninca 40*25 = 1000 msn de bir tarama yapmis oluyoruz
    {
         PortB.F0 = 1; Delay_ms(1);
         PortB.F0 = 0; Delay_ms(4);
    }
  }
}




yukarida bir ledi 5 bit cozunurlukte %20 parlaklikta surduk. taramayi saniyede 40 kez yaptik. led titremiyorsa mantigimiz dogru hocam. eger titremiyorsa saniyedeki tarama hizimi 30 a hatta 25 e cekip deneyler yapmaliyiz. tarama hizimiz ne kadar yavaslarsa bizim loop taki islem yapma zamanimiz artar.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 11 Ekim 2014, 16:15:49
http://www.logictoyz.com/electronic-components/fd9802c-16-bit-constant-current-5ma-90ma-led-driver-fd9802.html (http://www.logictoyz.com/electronic-components/fd9802c-16-bit-constant-current-5ma-90ma-led-driver-fd9802.html)
Yukarıdaki linkte şöyle bir ifade var

FD9802C compatible with TI's TLC5926/7, TOSHIBA's TB62726 and Macroblock's MBI5026/4/0.

Yani TLC5926 ile uyumlu olması gerekir.

Şuanda test yapma imkanım yok. İşin teorisini yeterince öğrenmeden uygulamaya geçmeyi düşünmüyorum.

TLC5926 her kanaldan nasıl pwm çıkartıyor? İçerisinde PWM için özel bir donanım yok.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 11 Ekim 2014, 16:18:45
hocam TLC 5940 entegresi ile karistirmisim. ozur dilerim. hocam sizin entegrede 595 gibi iste. sadece 16 cikisi var??  ???

sanirim cikislarinda birde transistor gibi birsey var ki direkman led surebiliyor. mantik ayni yani. seri olarak bilgiyi gondereceksiniz ???
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kantirici - 11 Ekim 2014, 16:35:24
Piyasada RGB panel kartlarında zaten FPGA kullanılıyor. En azından gördügüm bir kaçı böyleydi.  Dolayısıyla çok paneli sürmek için zaten standart bir mcu yetmeyecek gibi.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 11 Ekim 2014, 18:44:51
Alıntı yapılan: kantirici - 11 Ekim 2014, 16:35:24
Piyasada RGB panel kartlarında zaten FPGA kullanılıyor. En azından gördügüm bir kaçı böyleydi.  Dolayısıyla çok paneli sürmek için zaten standart bir mcu yetmeyecek gibi.

Evet aslında FPGA'lı kartlar kullanıldığını biliyorum. Hakkıda odur elbet. Fakat STM32 Serisi 72Mhz'de çalışan bir mcu 1- 2 panel hatta kaskat bağlı 3-4 panelin bile altından rahatlıkla kalkabileceğini düşünüyorum.

Benim ShiftRegister'in çıkışından nasıl PWM uygulayacağımı çözmem lazım? Evet arkadaşlar fikirleri alalım mantık yürütelim.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 11 Ekim 2014, 18:59:52
Hocam nasil yapildigini Turkceye cevirdim iste. anlamadiginiz yer neresi? Normal mantiktaki bir satiri yaktiginiz sureyi becerebildiginiz kadar(sistemin hizi yettigi kadar) parcaya ayirip bu kadar pwm yapacaksiniz. klim yettigince bir algoritma yazdim. buyuklerimize danisip bunu gelistirebiliriz yada daha mantikli bir algoritma kurabiliriz
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 11 Ekim 2014, 19:21:34
74HC595 ile pwm uygulaması yapabilirsek sanirim isi çözmüş olabiliriz. Nette 74HC595 ile pwm yapilmis video var ama koda rastlamadım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: SERRO EFE - 11 Ekim 2014, 19:51:44
Arduino kütüphanesinden bişeyler çıkarırsınız belki.
https://code.google.com/p/shiftpwm/downloads/list?can=1&q= (https://code.google.com/p/shiftpwm/downloads/list?can=1&q=)
PWM with shift registers for Arduino: ShiftPWM example 1 (http://www.youtube.com/watch?v=MDmOvbga0uA#)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 11 Ekim 2014, 20:53:14
@Karamel

Senin dediklerini anladım aslında. Şimdi 16 Bit Shift Register üzerinden yola çıkalım. 8 Bitlik bir PWM için 256 defa döngü kuruyoruz. Her döngüde Shift Registerin bütün pinlerini güncellememiz gerekiyor.

Bir tane döngü olacak 0-255 arası sayacak. A döngüsü diyelim
Bu döngüde 16 bitlik shift registerin her kanalı için 0-255 pwm değerleri olacak. A döngüsü içerisinde bütün bu değerler A döngüsünün o anki değeri ile karşılaştırılacak. Şayet Shift Registerin 0. biti için gönderilen Duty değeri 127 olsun. Eğer Döngünün o anki değeri 127 den küçük ise Shift Registerin 0. biti lojik 1 yapılacak. Döngü değeri 127'ye eşit veya büyük ise Shift Registerin 0. biti lojik 0 yapılacak.

Tabi A döngüsünün her çevriminde bütün 16 bit birden bu şekilde kontrol edilmesi gerekir. Bütün bu işlem yapıldıktan sonra elde edilen 16 bitlik değer SPI' donanımına yüklenip panele yollanacak. Sonra diğer shift register için aynı işlem yapılacak. Paneldeki 12 Shift Register için bu işlemlerin yapılması gerekiyor. Hemde ard arda.

12 Shift Register birden bu datalarla yüklendikten sonra Latch işlemi yapılacak Ardından bütün bu işlem tekrarlanacak. Örneğin bu işlemlerin hepsi saniyede 1000 kez tekrarlanırsa bütün çıkışlarda 1khz PWM sinyali elde ederiz.

Birde şöyle birşey var. Yukarıdaki işlemi Tek Data girişi varmış gibi düşündüm. Donanımsal SPI kullanırım diye sevinmiştim. Pek mümkün görünmüyor. Çünkü Tek panelde 6 adet SPI Data girişi var.(R1, R2, G1, G2, B1, B2) 6 adet SPI olan bir mcu yoktur sanırım. :D

Yukarıda bi A döngüsünden bahsetmiştim. İşte FPGA'ın farkı burada ortaya çıkar. Şimdi daha iyi anlıyorum niye FPGA kullandıklarını. A döngüsünün içerisinde yapılan sorgulamalar tek clock darbesinde FPGA ile yapılır diye düşünüyorum.

Yukarıda bahsettiğim döngü harbiden kritik. ASM ile yazmak icap edebilir.  ::)

İşin genel mantığı budur sanırım. Başka fikri olan varsa söylesin.

Bende eldeki donanımla yani 74HC595 ile 8 kanal 8 bit pwm oluşturmaya çalışayım.  :D
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 11 Ekim 2014, 21:11:47
Aynen hocam. Suan benim aklimdakinlerde aynen yazdiklariniz gibi. hocam asm ile yazilsada soyle bir sorun var. 100 mhz islem gucumuz var. İki kod isledik 50 mhz islem gucumuz kaliyor. Uc kod islersek 33.333 mhz islem gucumuz kaliyor. yani o karsilastirma islemlerini ve spi sorununu en hizli beceren algoritmayi yapmak ve en hizli calisan kodlari yazmak gerekir. microcontroller ile yapinca bir sinirimiz oluyor ve bu siniri yukarida yazdigim kriterler belirliyor. hocalarimiza danismamiz gerek. benim suan ki bilgim nasil yapilabilecgini cozememize yetmiyor. spi konusunda sanirim digital mux diye birsey vardi hocam. spi kismi boyle cozulebilir diye dusunuyorum?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 11 Ekim 2014, 21:35:20
 :D :D
İşlem gücünün senin söylediğinle alakası yok. Öyle değil. Farzedelim bir mcu var tek clock dabersinde bir kod işleyebiliyor, Dolayısıyla bu mcu 100mhz de saniyede 100milyon komut işleyebilir. İşlem gücü işlenen kod ile senin dediğin şekilde düşmüyor.   ;)

Dijital mux'lar aklıma yattı aslında. Dijital bir mux kullanarak tek bir SPI'ın MOSI pinini çoğullayabilirim. Bana 8 kanal mux lazım. En az 30Mhz de çalışabilmeli. Böyle bir çip varmıdır? 

mesaj birleştirme:: 11 Ekim 2014, 21:43:49

Edit;

74HC138 oluyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 11 Ekim 2014, 22:03:50
Hocam islem guc ile ilgili yazdiklarimi sanimirim ben yanlis anlattim ki sizde yanlis anladiniz. neyse deneyler yapinca ne demek istedigimi daha iyi anlayacaksiniz. 32x16 ekranimiz var ya hani bu 16 satiri taramak icin minimum tarama frekansimiz en az ne kadar olabilir?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 11 Ekim 2014, 23:51:34
Yapacağımız işlemi 2 komut ile yapabilirsek 50MHz hızında
3 komut ile yapabilirsek 33 MHz hızında bu işlemi yapabiliriz anlamında söylemiş,
tabi her komutu 1 saykılda işleyebilen 100MHz hızında çalışabilen bir mcu örneği için.

Konuyu takip ediyorum.
Uygulanması gereken algoritma ortaya çıktıkça ve bende anlamaya başladıkça
yardımcı olmaya çalışırım.

Bakmadım ama böyle bir mux vardır, 30MHz nin sıkıntı olacağını sanmıyorum.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 12 Ekim 2014, 00:01:01
Mucit hocam bana guldu ama Ramu hocam beni anlamis :) hocam yazin bende boyle bir calisma yapmak istiyorum ama once kayan yazi yapacagim. cunki suan icin bu is beni cok asan birsey gibi duruyor. birde etrafta kayan yazilar goruyorum proje istahim kabariyor. suan yazi kaydirma algotirmalarini kafamda dusunuyorum. yaza eger boyle bir proje yapabilirsem forumda yine paylasacagim ::)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 12 Ekim 2014, 00:12:49
Gözünde büyütmene gerek yok, yazı beklemenede,
Mucit i takip et aynı anda sende yapmış olursun.

Şimdi burada kayan yazı konuşmayalım, konu baltalanmasın,
istersen konu aç oradan konuşuruz.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 12 Ekim 2014, 00:59:44
@Mucit23,

Hocam 6 ayrı SPI modülü olan bir mcu olsa bile panelin tek bir clock girişi  var. Ayrıca anladığım kadarı ile satırlar içinde veri aynı anda gönderildiğinden 7 SPI gerekecek.

Kullanılan SPI hızına göre de SPI modülleri 50-200 ns gibi bir zamanlama ile bunları senkronlamak gerekir. Gerçi çok da zor bir iş değil. Ama yazılımsal SPI da rahatlıkla kullanılabilir görünüyor.

Asıl konu paneli sürebilmekten daha çok ara renkler için PWM nasıl uygulanabilir gibi.

Farklı renk elde etme için farklı yöntemler olabilir tabii.
Benim ilk aklıma gelen RGB ledlerin hepsini aynı anda ON yapıp  farklı zamanlarda OFF yapmak. Yada farklı zamanlarda söndürme işininin bir kısmı farklı tazeleme peryodlarına da bölünebilir.

Panelin her bir satırının renklerini tek bir satır tarama peryodunda oluşturma yolunu seçersek yanlışım yoksa 8 bit PWM 'i 50 hz üzeri tazeleme  frekanslarında bile elde etmek mümkün görünüyor.

Paneldeki her bir 16 led sütunu için bir SPI gerekiyor.  Satırlar içinde tek bir tane.
Buna göre  bir çevrim için aynı anda 2 adet 16*16 panel 3 renk ten 6 kanal sütunlar, artı 1 kanal da satırdan  toplam 7 ayrı kanaldan 16bit veri gönderilmesi gerekli.

50 Hz lik tazeleme frekansı kullanılırsa,  bir tazeleme peryodunda bir satırın piksellerine yani 16 piksele 1250us zaman düşer. 1/(50hz*16satır)
En kötü durumda satırdaki 16 pikselin herbirinin farklı renk değeri olur. Her bir piksel için 3 ayrı RGB değeri olacağından, maksimum 0-255 arası 48 farklı değer olur. İlk olarak hepsi beraberce ON yapılan ledlerin 48 farklı OFF zamanı olur.

Gecikmeler vs. lerden dolayı bir satırın piksellerine 1ms kalsa, 10mhz lik spi ile 16 bit veri 1ms de en az 500 kere gönderilebilir. Ki en fazla 48 defa veri göndermek yeterli olacak.

100mhz lik MCU da bir SPI çevrimi için yani 7 farklı verinini bitleri vs hesabı için yaklaşık 150 clock gibi bir zaman kalır. Buda  iki farklı lede  PWM değeri olarak ardışık değer atanmışsa geçerli.

MCU hızı yeterli olmazsa tazeleme frekansı 30hz, SPI 2Mhz seçilirse yaklaşık 250 kere 16 bit veri SPI dan basılabilir. 16 bitlik bir gönderim içinde  800 clock işlem zaman kalır.
Algoritma nasıl olur açıkçası düşünmedim. Timer ile sayma, kesme vs kullanılabilir. İlgili satırdaki 96 ledin hangisinin ilk önce ve ne zaman off yapılacağını belirlemek konusunu çözmek gerekir.

Umarım gözden kaçırdığım bir nokta yoktur.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 12 Ekim 2014, 10:21:20
Hocam satır için SPI gerekmiyor. Onun için doğrudan GPIO lar ile 3 bit(A B C) binary sayım yapılıyor. Bu sayede 1-8  9-16 arası satırlar taranıyor. Bana 6 adet SPI yeterli

Dediğiniz gibi software pwm mantıklı olabilir. Çünkü tek clock darbesinde 6 adet SPI datası yollayabilirim. Olsa zaten mutlaka öyle yaparım. FPGA da öyle yapıyordur muhtemelen.
Fakat donanımsal tek bir SPI kullanırsam 10Mhz'in üstünde clock uygulayabilirim. Hata P10 panellerle uğraşırken 745hc595 19Mhz'e yakın bir sinyalde clock basmıştım.
Hangisi hızlı çalışır bilmiyorum. Deneyip tecrübe edip görmek lazım.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 12 Ekim 2014, 15:12:07

SPI hızı çok önemli değil hocam.

1536 ledin her biri için 8 bitlik Duty bilgisi olacak.
Tazeleme hızı 50 Hz olsun. 16 Satır var. 
Anlatmaya çalıştığım yöntemde her bir satırı 1/800 sn de 1+ 48 kez yenilemek gerekecek. Ama 8 bit duty istediğimiz için bu değeri 256 gibi düşünmek lazım.

Bir satırda 96 led var.
Çevrim başında ledleri yaktık.
Bir de duty sayacımız olmalı.
Duty sayacı her bir ledin duty değerinden büyük olduğunda ledleri söndüreceğiz. 
Tam bu noktada 96 karşılaştırma yapıp SDO için kullandığımız pine 0-1 atayacağız. Bunun da 1250 us / 256 gibi bir sürede yapılmasını hedefliyoruz.
SPI lar donanımsa olsa bile SPI ye verilecek verinin hesabı gerekli. İşlem gücü burada gerekiyor.

Bu yüzden SPI hızı yüksek olamayacak. Yüksek olmasının yararı da yok zaten.

Sürme tekniğinde dediğin gibi aynı anda iki satır taranıyorsa kontrol edilmesi gereken led puty değeri sayısı 192 olacak. 50 hz tazeleme de 100mhz lik işlemcide 96 led için 4-5 clock süre kalır..
FPGA kullanma nedeni bu..

8 bit duty okuyup, zaten registerde olan duty sayaca ile karşılatırıp, bir pine (ki aslında farklı 6 pin) 0 yada 1 yazmaktan bahsediyoruz. Bunu da 5 clock da yapacağız. Duty sayacı çevrim boyunca sabit olsa bile Atomic bit set-reset, bitbanding vs. yoksa read modify-write ile imkansız gibi. İşlemci hızı da, seçimi de bilginin bellekte nasıl organize edildiği de önemli.

Olduğu kadar deyip yine de bi denemeli  derim. Tazeleme frekansı ne çıkacak bakmak görmek lazım. Olmadı duty 7 bite düşürülür vs.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 13 Ekim 2014, 00:56:56
Şimdi düşünüyorumda donanımsal spi mux ile felan olmaz bu sistem. 6 adet spi data girişi var ve 6 sına birden aynı anda data basılması gerekir. Çünkü clock'lar ortak.

Eğer mux ile SPI data hattını gezdirseydim diğer SPI data hatları boştayken ya lojik 0, yada lojik1 alacaktı. Dolayısıyla Shift Registerlere istenmeyen değerler yüklenecekti. Clock ortak olduğu için tek bir shift registere data yollanırken diğerlerinin veri alması engellenemez. Donanımsal SPI mantığını çürütmüş olduk.

Anlaşılan aklın yolu bir. Koları sıvamak lazım.

İşin güzeli 74595 ile tek kanaldan 8 bit pwm oluşturdum. Fakat donanımsal spi ile yaptım. STM32'de şöyle bir durumla karşılaştım. SPI bufferine veri yükledikten sonra TXE flagını kontrol ederek buffer boşalmışmı boşalmamışmı kontrol edip latch sinyali yolluyordum.
SPI'da Bufferin daha yarısı boşalmamışken flag'dan buffer boşaldı sinyali alıyordum. Pek çözümleyemedim durumu.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 13 Ekim 2014, 01:47:26
Mux spi shift register istenmeyen tüyler kısmını anlayamadım,
bence olur, istediğin shift register a diğerlerini etkilemeden veri basılır gibi geliyor,
sen bağlantı şeklini söyle ben nasıl olacağını düşüneyim,
konsepti ispatlamaya yetecek basit bir örnek olsun.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 13 Ekim 2014, 10:16:18
Mux yapılsa böyle birşey olacak

(http://s2.postimg.cc/hed3q8xrp/Ekran_Al_nt_s.jpg) (http://postimg.cc/image/hed3q8xrp/)

ABC girişleri ile SPI_DATA nın hangi girişe bağanacağı seçilir. Mux'un diğer bacakları seçilmemiş iken Sürekli Lojik1 de veya lojik 0 da kalır. Shift'lere clock uygulandığında MuX'un çıkışlarındaki dataları içeri alırlar. Mux olsun olması bu engellenemez.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 14 Ekim 2014, 00:43:14
Anladım.
ZAten spi_data yı misal 6 ya çoklamak
6 tane spi miz olduğu anlamına gelmez.

Benim aklıma şöyle bir yöntem geliyor
tabi donanımsal 6 tane spi si olan bir mcu kullanmak daha mantıklı,
spi ler 8 bit data gönderiyor diye düşünelim,
o zaman 6 tane 8 pinlik mcu portunu > 6 tane 8 bitlik
paralel in serial out shift register a bağlayacağız
mcu nun 48 çıkışı pinine göndermek istediğimiz değeri yazacağız
artık 6 tane shift register a aynı anda clock verdiğimizde
mcu nun 48 pininde halihazırda yüklenen 48 bitlik veriyi 6 tane spi datasına çevirmiş olacağız.

(https://lh4.googleusercontent.com/8wsmgikOncP5WUiNwqtJPnRH0xCn8f5CswC5kyIMUaA=w743-h498-no)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 14 Ekim 2014, 08:12:02
Merhabalar;
RBG ye veri gonderim mantığı altaki gibi olabilir.
Bir ara 24x24 RGB ile calısırken aklıma gelmış ve henuz uygulama fırsatı bulamamıstım.
Bir mcu da 5/6 tane Donanımsal SPI yoktur. Olacagını da sanmam.
Bu iş coklamayla falan olmaz.
Bir tane yazılımsal SPI olusturulacak veri hattı olarak ta PORTl'ardan herhangi bir port Ornegin PORTB gibi (B0....B7 )
Anlatmak istediğimi şekil ile göstereyim. 
(http://i.hizliresim.com/Z1XBg3.jpg) (http://hizliresim.com/Z1XBg3)

Bu konudaki düşünceleriniz nedir ?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 14 Ekim 2014, 09:01:34
Alıntı yapılan: M_B - 14 Ekim 2014, 08:12:02
Bir mcu da 5/6 tane Donanımsal SPI yoktur. Olacagını da sanmam.
Bu iş coklamayla falan olmaz.

Falanla olmaz derken?

Benim dediğim senin yaptığının paralel hali
yani R G B verisi MSB den LSB ye tamamen tek seferde
mcu nun üç portuna veriliyor, shift registerlar seriye döndürüyor,
kazanç ne,
senin yaptığında 8 bit R G B verisi göndermek için
mcu ya 8 defa gönderilecek veriyi biryerden okuyup porta yazman lazım
benim dediğimde 8 bit veriyi 1 defa okuyup porta yazman 8 defa clock uygulaman yeterli
asm de daha yazsan ve hiçbir döngü kullanmasan
deli dolu bir ram in olsa (bu mümkün değil)
movf    ramreg1,w
movwf  RGB_PORT
herbir bitte en az 2 komut çevrimi kaybetmiş olursun,
ki gerçekte veriyi program hafızasından alacağın için
bu en az 6-10 komut çevrimi alır, hemde herbir bit için buna birde x 8 diyeceksin...

http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005 (http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005)
(http://i.hizliresim.com/vo62mm.png)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 14 Ekim 2014, 11:39:51
Hocam donanımsal spi ile olmuyor. Mcu da  6 adet spi olsa bile panelde tek clock girisi var. Bu yüzden soft spi şart. 

Zaten 74595 ile şuanda 100hz 8 kanal 8bit pwm çıkarıyorum.  Sıkıntı yok. Bunun sayısı artacak sadece. Oda henüz yeterince optimizasyon yapmadım. 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 14 Ekim 2014, 11:52:15
1den fazla donanımsal spi kullanmadım ama
bence 6 adet donanımsal spi aynı anda 6sından birden data yollayabiliyor olmalı,
(böyleyse tek clock u bağlarsın olur biter)
yoksa niye 6 tane donanımsal spi olsun
chip select ile hatta olmasını istediğimiz spi yi seçerdik olur biterdi,
bu konuyu kesin bilmiyorum ama umutlu olmak lazım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: hasankara - 14 Ekim 2014, 16:55:16
https://www.picproje.org/index.php/topic,40249.msg301490.html#msg301490 (https://www.picproje.org/index.php/topic,40249.msg301490.html#msg301490)

pwm çoklama konusunda basit bir algoritmadan bahsetmiştim linkte.bu konuda önceki yazılanları pek okumadım belki çözüm olabilecek algoritmadan bahsedilmiş olabilir bir de ben bahsedeyim.

ekranda görüntülenecek olan görüntü, ekran sürücüsü tarafından ekranda 8 aşamada görüntülenir. her aşamada ekran parlaklığı 2 nin katları şeklinde artarak güncellenir. buna paralel olarak, her bir pikselin bir rengi için tayin edilmiş 8 bitlik olan parlaklık bilgisinin bitlerine göre her hücre için maskeleme yapılarak 8 aşama tamamlanır.

görüntünün tümünü referans alarak anlatmaya çalışırsam; 1 adet 8 bit parlaklık derinliği olan görüntüyü elde etmek için 8 adet tek ton görüntü elde ediyorsun. 8 adet tek ton görüntüyü ekranda gösterirken, her aşamada ekranın tümünün parlaklık katsayısını 2 nin katlarında arttırıyorsun. tek ton derken kast ettiğim led ya yanıyor yada sönüyor. 8 bit kafanı karıştırmasın, bir pikselde 3 adet renk var ancak her piksel değilde her ledi kendi içinde değerlendirmiş oluyoruz. sonuç olarak piksel bazlı bakıldığında 24 bit renk derinliği elde etmiş oluyoruz.

8 bitlik data ile 24 bit renk derinliği elte etmemizi, her pikselde 3 adet led kullanmış olmamıza bağlayabiliriz. bu metod yerine, her led için 8 adet led koyarak 8 kez görüntü oluşturmaktan sa parlaklık bilgisine göre parlaklıkları 2 nin katlarına göre değişkenlik gösteren bu 8 lede tek seferde uygulayarak ta tek görüntü ile parlaklıklı görüntü elde edebiliriz. 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kimlenbu - 15 Ekim 2014, 17:15:28
işinize yararsa şöyle bir şematik buldum :

http://www.ediy.com.my/Downloads/2014%2007/Arduino%20based%20RGB%20Matrix%20LED%20tester/Schematic%20for%2016x32%20RGB%20LED%20matrix%20panel.pdf (http://www.ediy.com.my/Downloads/2014%2007/Arduino%20based%20RGB%20Matrix%20LED%20tester/Schematic%20for%2016x32%20RGB%20LED%20matrix%20panel.pdf)

Dün biraz araştırdım, endüstriyel sistemlerde  PCI-express kart tasarlamışlar, görüntüyü DVI üzerinden alıp ethernet üzerinden çıkış kartına göndermişler. Çıkış kartı da 16x32'lik modülleri sürmüş, muhtemelen FPGA var üstünde.

MCU ile istenen bit derinliğinde tek modülü sürmek bile nanosaniye bazında toleranslara sahip. Kaskat bağlantıdaki modülleri sürmek zaten ihtimal dışı.

Gördüğüm kadarıyla sadece kartın çalışmasını anlamak için bir proje geliştirebilirsiniz. Ondan sonra ya senkron çalışan birden fazla MCU içeren bir tasarım yapacaksınız ya da fpga.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 15 Ekim 2014, 23:09:51
Merhaba Arkadaşlar yazdiklarinizi  okudum ve kullanilan entegrenin katalog bilgisinde bir bitin ötelenmesi için maksimum 25 MHz de ötelenir bu da bizi seri iletimde kısıtlıyor bundan daha hizli data ötelemesi yapamayız .
Ekranin taramasi 50Hz ve PWM i de 8bit olsun ve tarama 1/8 ve sütun sayisi 32 ise buna göre minimum data öteleme hizi -> 50 * 256 * 8 * 32 =  3276800 Hz maksimum 25 MHz kadar çikilabilinir .
Buna göre yukaridaki bilgiler dogrultusunda yazilim ve donanim kismi tasarlanmalidir ..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 17 Ekim 2014, 22:25:44
Frekans konusunda sıkıntı yok. Hiçbir zaman o kadar yüksek frekanslara çıkmak gerekmiyor. Yeterki işi organize bir şekilde yapalım.

Ben 74HC595 ile 8 Kanal 100Hz 8Bit çözünürlükte PWM ürettim.

Timeri kesmesini yaklaşık 40uS'ye kurdum. Her kesme oluştuğundan aşağıdaki kodları çalıştırıyorum
void Timer1_interrupt(void){
      static int Duty_Count, Bit_Count, temp=0;

      for(Bit_Count=0;Bit_Count<8;Bit_Count++)
      {
       if(Duty_Count<=Duty[Bit_Count])
         {
          temp |= ((uint8_t)1<<Bit_Count);
       }
         else
         {
          temp &= ~((uint8_t)1<<Bit_Count);
       }
    }

    for(Bit_Count=0;Bit_Count<8;Bit_Count++)
        {
       if(temp & 0x80)
             {
          GPIOB->BSRR=GPIO_Pin_0; //DATA=1
       }
             else
             {
          GPIOB->BRR=GPIO_Pin_0;  //DATA=0
       }
             temp=(uint8_t)temp<<1;

             GPIOB->BSRR=GPIO_Pin_1;    //CLK=1
             __asm {nop}
             GPIOB->BRR=GPIO_Pin_1;     //CLK=0
    }
      GPIOB->BSRR=GPIO_Pin_2;       //LATCH=1
      __asm {nop}
      GPIOB->BRR=GPIO_Pin_2;        //LATCH=1

        Duty_Count++;if(Duty_Count>255)Duty_Count=1;


Duty adında 8 elemanlı bir dizim var ve 0. eleman 74HC595'in 0. biti için Duty değeri, 7. eleman ise 7. Bitin Duty değeri. Çalışma videosu aşağıdaki gibi.

STM32F103 & 74HC595 ile Shift PWM (http://www.youtube.com/watch?v=MOSAMNj_4wc#ws)

Yukarıdaki kodlar çok iyi çalışıyor. Keilde Optimizasyon Seviyesi 0 iken yukarıdaki kodların işlenmesi20uS sürerken Optimizasyon seviyesini 2 yaptığımda yaklaşık 6 uS süreye düşüyor. Kesme 40uS aralıklarla oluştuğu için kesme alt programı içerisinde epeyce bir vakit kalıyor.

Yukarıdaki kodda başka ne gibi optimizasyonlar yapılabilir? Bunu sormak istiyorum. Daha hızlı çalışabilirmi? Birkaç yerde bit kaydırma yapıyorum. Bunlar üzerinde optimizasyonlar yapılabilirmi?

Panel için 6 adet SPI datası yollanacağı zaman yukarıdaki kodda birkaç ekleme yapmam yeterli olacak.

Şuanda beni ençok düşündüren şey ekran için ayıracağım hafıza bölgesi. Bu çok önemli aslında. Panel için toplamda 16x32x3 =1536 byte Ram'e ihtiyacım var. Bu alanda RGB data dizilimleri nasıl yapılabilir?

Aklımda 2 yöntem var.
1-)Her pixel için gerekli olan renk bilgisini 3 ayrı 8 bitlik değişkende tutmak.
2-)Her pixel için tek bir 32 bit değişken tanımlayıp Renk bilgisini içerisinde 0x00RRGGBB şeklinde tutmak.

Birinci yöntemde kesme içerisinde veri ayıklamanın birazdaha hızlı çalışacağını düşünüyorum.
diğer ikinci yöntemde ise hafıza yapısı daha düzenli olacak gibi. Fakat kesme alt programı içerisinde verileri ayıklamak biraz uğraştırıcı olacak.

Bu konuda ne düşünürsünüz? 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 17 Ekim 2014, 22:47:19
hocam beni yanlis anlamazsaniz birsey soylemek istiyorum. ise hesap yapamadan bodozlama daliyorsunuz ve diger buyuklerimizi dinlemeyip kendi secimlerinizi(dogru yada yanlis) dogru olarak goruyorsunuz. ben yasca sizden kucugum. siz benden elbetteki daha tecrubelisinizdir ama once hesap yapmalisiniz. once matematik sonra uygulama olmasi gerekir..?

ekran modulunuzun nasil calistigini onceki mesajlardan tam olarak anlayamadim ama sonucta asagida yazdigim seylerin her halukarda yapilmasinin gerekli olmasi lazim.

ekran modulumuz 32*16 yani her satirda 96 ledimiz ve 16 satirimiz var. 96 ledimizi spidan basip(artik modulunuz nasil calisiyorsa) bunu pwm leyip(bu sekil 0x00RRGGBB anladigim kadari ile 4 level pwm uretmeniz lazim) sonrada aynilarini diger satirlarada yapmaniz gerekli.

en basta 16 adet ledi karasimsegin hizlisi ve tek tarafa dogru gideni seklinde tarayip gozun algilayamadigi minimum tarama frekansini bulmaniz lazim. bu konuda herhangi birsey okumadim. yada burada hocalarimiza danismadim ama kesin burada bu konuyu bilen hocalarimiz vardir. bir danisin derim.

minimum frekansi bulduktan sonra onuda 4 e bolmeniz gerekiyor ki her satirin pwm i uretilebilsin. bu islemin sonucunda olusan degeri sizin pwm isleyen ve spi yapan kodlarinizin asmamasi gerekiyor. yaptiginiz is bence cokta kolay bir is değil. 72 mhz lik microcontroller bir adet ekran modulunu anca surebilecek. o yuzden yukarida dedigim gibi bence once hesap kitap yapin.

mesaj birleştirme:: 17 Ekim 2014, 22:58:41

mesela hocam. yukarida ledleri 100 hz de surdum demissiniz. ekrandaki 16 satir ledleri 100 hz de tarayacaksaniz spi ve pwm ureten kodlariniz icin su kadar zamaniniz kalacak.

1/100 = 10 msn (tum ekran i bir kez tarama hizi.)

10 msn / 16 = 625 mikro sn (1 satir.)

625 / 4 = 156 mikro saniye (tek pwm.)


yani sizin spi yapan kodlariniz ve pwm icin calisan kodlariniz(32*16*3 kadar degisken icin cok zaman kaybeceklerdir) 156 mikro saniyeyi gecmemelidir. eger gecerse 100 hertz frekans duser.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 17 Ekim 2014, 23:00:12
for(Bit_Count=0;Bit_Count<8;Bit_Count++)
Gibi kısa döngüleri açıp for kullanmadan yazarak
büyük ihtimalle (derleyici asmye nasıl çeviriyor bilmediğim için)
sadece bu döngünün 1 defa kullanılmasında dahi
1 kontrol ve 1 goto komutu tasarruf edilebilir.

Böyle yazıldığında
if(Duty_Count<=Duty[Bit_Count])
Duty[Bit_Count] kısmı Duty[0,1,...,7]
şeklinde tek tek elle girileceğinden yine daha hızlı çalışacak.

if(temp & 0x80)
yerine bit test komutu varsa daha hızlı çalışır.

Kaydırma başka komutla yapılabiliyorsa,
(misal ccscde var ve farklı hızlarda çalışıyorlar)
bazı komutlarla kaydırma diğerlerinden hızlı çalışabilir.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 17 Ekim 2014, 23:13:01
@Karamel

Senin şu yazdıklarını anlamakta gerçekten zorlanıyorum. Bundan önceki mesajlarındada durum böyleydi. Mesajını 3 defa okudum... Belkide farklı şeylerden bahsediyoruz. Benim PWM üretmede sıkıntım yok. PWM'in nasıl üretildiğini hesabının kitabının nasıl yapıldığını biliyorum elbette. Hiçbirşeye bodoslama daldığım yok!

İlk önce ekranın çalışmasını iyice bir anlayın yoksa farklı şeyleri konuşmaya devam ederiz. 4 Level PWM felan bu nedir böyle birşey yok.

Alıntı Yapen basta 16 adet ledi karasimsegin hizlisi ve tek tarafa dogru gideni seklinde tarayip gozun algilayamadigi minimum tarama frekansini bulmaniz lazim. bu konuda herhangi birsey okumadim. yada burada hocalarimiza danismadim ama kesin burada bu konuyu bilen hocalarimiz vardir. bir danisin derim.

Bu cümleyi bana tecrüme edermisin. Bu konuda birşey okumadım diyorsun? Neye dayanarak bunları yazıyorsun anlamıyorum.

16 Mhz lik arduino ekranda 4096 renk oluşturuyor. Benim 72Mhz lik mikrodenetleyicim bundan dahamı kötü olacak!!

Birde şunlar var.
Alıntı Yapmesela hocam. yukarida ledleri 100 hz de surdum demissiniz. ekrandaki 16 ledi 100 hz de tarayacaksaniz spi ve pwm ureten kodlariniz icin su kadar zamaniniz kalacak.

1/100 = 10 msn (tum ekran i bir kez tarama hizi.)

10 msn / 16 = 625 mikro sn (1 satir.)

625 / 4 = 156 mikro saniye (tek pwm.)

Bana bu hesabı açıklayın. Sizin bu tarama dediğiniz şey satır taramamı? Hani şu ABC pinleri vardı. Satır taraması yapıyorduk.. Daha ben o aşamaya gelmedim... Şuanda konumuz o değil...

Alıntı Yapekran modulunuzun nasil calistigini onceki mesajlardan tam olarak anlayamadim

İşin mantığını daha doğrusu panelin çalışmasını iyice anlayın öyle gelin tartışalım.

Ben ne yaptığımı çok iyi biliyorum Şuanda konumu ekranın Ram organizasyonu..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 17 Ekim 2014, 23:26:47
1000000000000000
0100000000000000
0010000000000000
0001000000000000
0000100000000000
0000010000000000
0000001000000000
0000000100000000
0000000010000000
0000000001000000
0000000000100000
0000000000010000
0000000000001000
0000000000000100
0000000000000010
0000000000000001

hocam ledleri boyle tarayin ve gozun algilayamadigi minimum frekansi bulun. anlamadiginiz diger kisimlari hocalarimiz anlatirlar. ben 18 ime yeni girdim ve  elektronikle  hobby olarak ilgileniyorum. yazdiklarim bazen yanlis oluyor. bazende kendimi anlatmayi beceremiyorum. yani sorun bende.....
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 17 Ekim 2014, 23:41:41
@Karamel sen yapıyı dot matrix displayler ile karıştırıyorsun. Shift Register ile PWM üretmek için böyle birşey yapılmıyor. Yukarıda eklediğim videoda 8 adet led var. Orada da senin bahsettiğin şekilde bir tarama yok. 16 bit shift register olsa ondada dediğin olmayacaktı. Yani satırlardan ledlere renk bilgisi gönderilmiyor.

PWM nedir biliyormusun? Ben PWM frekansından bahsediyorum.

Yaşın veya elektronikle ne amaçla ilgilendiğin beni ilgilendirmez ama konuyu anlamadan etmeden yaptığın yorumlarla hem benim kafamı hemde okuyanların kafasını karıştırıyorsun. Yazdığın her mesajı 50 defa okuyup, acaba bu neyin hesabı? nasıl bu kadar zaman geçiyor? 156uS nasıl oluştu? gibi sorulara cevap aramaktan yaptığım işi unutuyorum.

Tekrar söylüyorum

1-Panelin yapısını, Tarama, Renk bilgisi gönderme gibi konuları iyice öğrenmeden,
2-PWM nedir? Shift Register ile PWM nasıl üretilir gibi konuların cevabını iyice öğrenmeden konu hakkında yorum yapmamanızı rica ediyorum.

El insaf yahu!!
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Karamel - 18 Ekim 2014, 01:12:43
Hocam pwm nedir shift register nedir biliyorum. size bunu isterseniz Turkcede İngilizcede anlatirim eger isterseniz. neyse aslinda mesaj yazmayacaktimda pwm nedir bilmiyorsun diyince incildim vede yazma geregi duydum.ihtiyaciniz olursa ingilizce anlamadiginiz birseyler varsa ceviri falan yaparim size hocam. zaten elektroniktende matematiktende anladigim yok!! genel soruna yardim ederim bende.

İyi geceler hocam.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 18 Ekim 2014, 08:57:34
Kırılıp darılmanı istemem ama bu konuda biraz anlayışlı olmanı istiyorum.  Panelin çalışmasını anlayıp kendi yazdığın mesajları tekrar okusan eğer bana hak vereceksin

mesaj birleştirme:: 18 Ekim 2014, 09:11:08

Alıntı yapılan: RaMu - 17 Ekim 2014, 23:00:12
for(Bit_Count=0;Bit_Count<8;Bit_Count++)
Gibi kısa döngüleri açıp for kullanmadan yazarak
büyük ihtimalle (derleyici asmye nasıl çeviriyor bilmediğim için)
sadece bu döngünün 1 defa kullanılmasında dahi
1 kontrol ve 1 goto komutu tasarruf edilebilir.

Böyle yazıldığında
if(Duty_Count<=Duty[Bit_Count])
Duty[Bit_Count] kısmı Duty[0,1,...,7]
şeklinde tek tek elle girileceğinden yine daha hızlı çalışacak.

if(temp & 0x80)
yerine bit test komutu varsa daha hızlı çalışır.

Kaydırma başka komutla yapılabiliyorsa,
(misal ccscde var ve farklı hızlarda çalışıyorlar)
bazı komutlarla kaydırma diğerlerinden hızlı çalışabilir.


hocam sizin mesaj kaynadı :)

Aslında sizin dediginiz gibi düşündüm.  Fakat program cok uzuyor. Gerçek panele geçince o döngülerin sayısı 32 felan olacak. Arm de bit test komutu yok yani öyle bir fonksiyon yok. Kendim yapmak zorundayım.  Daha iyi bir yöntemi varsa deneyebilirim. Bit kaydırma felan zaten carpma işlemi.  Bunun çok uzun süreceğini sanmam.

Aslında gerçek paneli bekliyorum. Gelsin hemen testlere başlayacağım.

Ram konusunu tekrardan üste cekmek istiyorum.  Hafıza organizasyonu nasıl yapılmalı

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 24 Ekim 2014, 09:55:07
Uzun süre cevap yazamadım buraya,
şuan son durumuda merak ettiğim için yazayım istedim,
herhalde modül gelene kadar askıya aldın bu kısmı.

Ram konusundan önce panele yükleyeceğin datalar nereden gelecek?

STM32F103 kullanacaksın herhalde,
32 bit işlemci zaten,
değişkenleri 32 bit tanımlayıp
4 ayrı byte ınada farklı birer değişkenmiş gibi erişim olanağı sağlayabildiğini düşünüyorum,
komut setine bakmalıyız,
misal dspicde 16 bitlik değişkene byte modunda erişim var
stmdede vardır bu.

Program uzaması konusunda
yani seninde dediğin gibi
işlemem ufak bir hız katmak için
aynı rutini tekrar tekrar yazmak gerekiyor
gerekirse yapılır, zaten akla gelen en basit yöntem bu.

Ben rgb panelin nasıl çalıştığını halen tam olarak anlayabilmiş değilim,
hc595 kısmında problem yok zaten yazdıklarım onun içindi,
eğer modülü tam kavrarsam bu işi en hızlı yapacak algoritmalardan birini yazarım.

Aslında shift register için yaptığın bu işlem birebir spi oluyor,
yani hc595 in girişine mcunun spi çıkışını bağlasak ve
spi den 1 byte gönderip ardına hc595 için latch versek
tabiki en hızlısı bu olacak.
Şimdi senin rgb panel için bu hc595 örneğini
aynı anda 6 kanal yapman gerekiyormuş gibi olacak doğru anladıysam.



mesaj birleştirme:: 24 Ekim 2014, 10:15:35

Birde şu var misal 3 tane hc595 ile yukarıdaki örneğini genişlettiğimizi düşünelim,
bu sefer istediğin gibi 32 bitlik ram değişkenimizi var,
adı temp değil temp32 olsun,
örneğinde yaptığımız işlem şu şekilde olacak;

    for(Bit_Count=0;Bit_Count<8;Bit_Count++)
        {
//----------------------1---------------------------
       if(temp32 & 0x00 00 00 80)
             {
          GPIOB->BSRR=GPIO_Pin_0; //DATA=1
       }
             else
             {
          GPIOB->BRR=GPIO_Pin_0;  //DATA=0
       }
//---------------------------------------------------

//-------------------------------2--------------------
if(temp32 & 0x00 00 80 00)
             {
          GPIOB->BSRR=GPIO_Pin_1; //DATA=1
       }
             else
             {
          GPIOB->BRR=GPIO_Pin_1;  //DATA=0
       }

//----------------------------------------------------

//----------------------3-----------------------------
if(temp32 & 0x00 80 00 00)
             {
          GPIOB->BSRR=GPIO_Pin_2; //DATA=1
       }
             else
             {
          GPIOB->BRR=GPIO_Pin_2;  //DATA=0
       }
//-------------------------------------------------

       ve clock
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 24 Ekim 2014, 10:17:33
Tek clock da 6 spi datası. Bu yüzden fpga kullanılıyor.  Bu yüzden donanımsal spi olmuyor.  :)

Aslında ram organizasyonu üzerinde çalışıyorum ben. Bir iki fikrim var.

Sonuç olarak hedefledigim şey PutPixel(Xpos, Ypos, Color) Şeklinde bir fonksiyon oluşturmak.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 24 Ekim 2014, 10:45:41
fpga yı çok gözünde büyütüyorsun,
ilk verdiğim örneklerden bir zaten fpganın yaptığı en önemli kısmı
mcuya kazandırıyor,
fpga da sonuçta logic entegre yapmak,
bunu dışarıdanda yapıp mcuya ekleyebilirsin,
naktın hız yetmiyor ya fpga ya geçeceksin
öyle kolay olmadığı için
fpga nın artısını alıp kendi logic entegrelerinle yapacaksın,
benim düşüncem bu.
(yapacaksın edeceksin derken emir kipi manasında değil
yanlış anlaşılmasın :)  )

PutPixel(Xpos, Ypos, Color) için,
Color diziye pointer olsun,
Xpos Ypos sadece başlangıç noktasını versin,
yoksa her pixel için tekrar tekrar fonksiyondan dönüp
Xpos Ypos girmek gerekir.
Neyse hız yetmezse böyle şeyler yapılabilir aslında.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 29 Ekim 2014, 11:42:01
Merhaba Arkadaşlar

Yatay tarama ile ilgili bir sıkıntı var. Sizin fikrinizi almak isterim.

Normalde yatay tarama ABC pinleri ile yapılıyor. Satır olarak 1-9, 2-10...8-16 şeklinde satırlar aktif oluyor. Satır tarama yaparken her bir satırı en az en fazla 2-3 ms aktif tutmak gerekiyor.  2ms aktif tutarsak yatay tarama frekansımız 500hz olur.

Örneğin 1-9. Satırları aktif ettik. Bundan sonra Shift Registerler aracılığıyla ledlere PWM uygulamak gerekiyor. İşte sorun burada başlıyor. Benim LED'lere uyguladığım PWM frekansı 100Hz. Dolayısıyla  ledlere uygulanan 1 peryotluk pwm palsinin süresi 10ms civarı olacak.

Yatay Tarama frekansı, ledlere uygulanan PWM frekansından küçük. Bu durumda örneğin 1-9 satırlar aktif iken LED lere pwm verilmeye başlanır. Daha 1. peryot tamamlanmadan diğer satıra geçilir.

Dün akşamdan beri bu konuyu düşünüyorum. FPGA lı kartlarda bu iş nasıl yapılmış olabilir?

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 29 Ekim 2014, 16:18:53
Alıntı yapılan: Mucit23 - 29 Ekim 2014, 11:42:01

2ms aktif tutarsak yatay tarama frekansımız 500hz olur.
..............
Bundan sonra Shift Registerler aracılığıyla ledlere PWM uygulamak gerekiyor. İşte sorun burada başlıyor. Benim LED'lere uyguladığım PWM frekansı 100Hz. Dolayısıyla  ledlere uygulanan 1 peryotluk pwm palsinin süresi 10ms civarı olacak.

Shift reg. ile PWM uyguluyorsanız,  PWM frekansını SR lerin sürülme peryodundan ne şekilde bağımsız düşünebiliyorsunuz anlamadım.

Amac her bir ledin parlaklığını 8 bit çözünürlükte ayarlayabilmek değilmi. 
Şu ana kadar bahsedilen iki farklı yöntem var.

Birinde ledlerin mininum sürülme zamanı 2ms/256 ve OE sürekli aktif. SR sürülme yani PWM frekansı 128KHz .  Avantajı ledler tam parlak yanabilir dezavatajı işlem gücü..

Diğer yöntem Arduino ile uygulama örneği olan.. Ledlerin sürülme zamanları 2ms/8 ve kaçıncı bitte iseniz OE ye uyguladığınız duty o ve tabii OE ye uyguladığınız PWM peryodu 2ms/8 den den en az 10 kat daha az olacak.  SR ile sürülme frekansı 4KHz.  Avantajı daha az işlem gücü. Dezavatajı ise ledlerin parlaklığı en fazla diğerin yöntemin 1/4 ü olabilir.

Kod örneklerinden birinci yöntemi uygulamaya çalıştığınızı düşünmüştüm. Paylaştığınız örnek koddaki gibi yapacaksanız bellek organizasyonu vs. çok da önemli değil. Ancak DMA li falan paralel port, FSMC gibi donanım kullanabilecek olsaydık çok önemli olurdu.
FPGA in yerini tam tutmaz ama LS682-684 gibi bir comparator a duty ve clock bilgilerini FSMC ile gönderebilseydik bayağı iş görürdü. Latch, Clock sinyalleri nasıl üretilebilir kafa yormak lazım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 29 Ekim 2014, 16:51:21
Hocam açıkçası ben hep 1. yöntem üzerinde kafa yormuştum. 74HC595 ile yaptığım kod örneğinin temelinde de aynı yöntem var. Açıkças PWM frekansı çok yüksek çıkıyor. Yani ben 100Hz lerde dolaşırken 62,5Hz yatay tarama frekansında ve 8 Bit renk çözünürlüğünde dediğiniz gibi 2ms/256dan pwm frekansı tam olarak 128 khz çıkar. Shift Register'lardan bu denli bir yüksek frekans çıkarmak harbiden zor iş olsa gerek. Bu yöntem üzerinde çalışmaya devam edersem büyük ihtimal Cortex M4 ile çalışmam gerekecek. Bu frekansta pwm alabilmek için SR lere çok yüksek frekanslarda clock uygulamam gerekir. Hesabını bile yapamadım şimdi. Tırstım valla. :-X

Bellek organizasyonu dediğiniz gibi problem değil. Şu Yatay tarama ile PWM frekansı işini birlikte yapabilirsem bellek organizasyonunuda yaparım. O işi planlandım.

Ben hiç OE pinini hesaba katmadım. Açıkçası Arduino'nun kodlarını doğru düzgün incelememiştim. Benim test ettiğim 1. yöntemle yaptıklarını düşünüyordum.

2. Yöntemi Anlayamadım. OE pini tüm SR ler için ortak. Burada OE'den PWM uygulanarak LED'lere nasıl PWM uygulanıyor? Bunu birazcık daha ayrıntılı anlatabilirmisiniz?


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 29 Ekim 2014, 17:14:07
2 yöntem dediğimiz yöntemi yanılmıyorsam  @hasankara hocam detaylıca anlatmıştı.

Burada 2ms yi 8 bit karşılığı 8 eşit zamana bölüyoruz. 7. bit için OE ye %100 duty 0.bit için 1/128 duty uyguluyoruz. 2ms yi 256 yerine 8 e böldüğümüz için işlem gücü de 32 kat azalmış oluyor.  Tabii bu 8 eşit zaman da her bir ledin duty değerini, zamana karşılık gelen bitle and leyip ledi yakıp yakmamaya karar da veriyoruz. Ledlerin duty değeri 255 olsa bile ledler yaklaşık normalin 1/4 kadar parlak yanabiliyor. 

FSMC konularına pek bakmadım.
Clock ve latch puls larını uygun şekilde üretmenin bir yolu varmı bakmak lazım.
Olabiliyorsa 1 yöntem LS682 gibi bir TTL + 595 ile uygulanabilirse adeta FPGA tadında bir şey çıkar.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 29 Ekim 2014, 17:39:50
Biraz anladım ama bana çok karışık geliyor. Sizce FPGA lı kartlar bu işi nasıl yapiyor?
Gercekten SR ler ile 128Khz pwm üretmem gerekse ne kadar bir hıza ihtiyacım olur? Clock frekansım ne olur?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 29 Ekim 2014, 18:34:53
FPGA ın avantajı paralel işlem yapabilmesi. Birkaç clock da SR lerin 6 pininde de + satır pinlerinde de pulslar hazır olabiliyordur sanırım.

SR lerin hızı 128kHz PWM üretmeye rahat rahat yeter.
Panelin sağı solu ayrı sürülüyordu. Ve aynı anda iki satır sürülecek. Yani 1/128K zamanda 32 bit aktarmak gerek. 4Mhz gibi birşey çıkar.
Sıkıntı duty yi lede atanan duty ile karşılaştırıp üstelik bunu 6 ayrı pin için 6 kere yapıp, üstüne birde satırlar için pinleri de set etmekte. 
6*4 = 24M karşılaştırma işlemi gerekir. 100Mips işlemci ile bir işleme max 4 clock kalıyor. Karşılaştırma yaptığımız için en az 2 adet dallanma komutu gerekir. Ki dallanma komutları da en az 2 clock harcıyor.

2ms ye karşılık tazeleme frekansı da 60 hz gibi çıkar. Ve Tazeleme frekansı bu kadar yüksek iken bu işi mcu ile yapmak ek donanım olmadan mümkün görünmüyor.

Mplab da döngüyü simule ettiğimde, bir ledin duty sini karşılaştırıp SR pinine atanması işi için 5 clock harcadı. Ama döngü kontrolleri,  satır pinlerinin atanması gibi ek işlerden dolayı ortalaması 11 clock civarında oldu. Gerçi asm ye biraz el atıp iyileştirilmeler yapılabilir.
Kodu 16 bit için derlemiştim. Şu anda en hızlısı 70mips çalışabildiğine göre tazeleme frekansı max 15Hz gibi olabiliyor.
Ama işlemci sadece buna uğraşırsa.. Putpixel vs. işleri vs. ye zaman kalmıyor.

Pratikte bu tip bir paneli 16M renk sürmek ile 65K sürmek arasında bir fark olacağını sanmıyorum. Eğer şu an yaptığımız algoritma tartışması olmasaydı,  üretilecek bir iş olsaydı direkt 65K sürün uğraşmayın derdim.

Benim görebildiğim en azından karşılaştırma işlerini otomatiğe bağlamak gerektiği.
74LS682 den yardım alalım derken bunu kastediyordum. Led duty değerini ve duty sayacını 8+8, 16 pinden çıkarsak SR nin girişinde puls hazır olur. 6 led için duty gönderip clock, bunu 32 kere tekrarlayıp latch pulslerini aktif edince olur gibi.
Clock pulslerini de fsmc ile gönderebilseydik işi dma ye yıkabilirdik.  Belki belleği biraz bol kullanıp, araya clock, latch için birşeyler serpiştirip işin tamamı dma + fsmc ye de yıkılabilir.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 30 Ekim 2014, 11:14:21
Bu işin hepsini  M3 ile yapmak çok zor bir iş olsa gerek. Stm32F429 ile felan yapabilirim belki ama anlamsız olur. Sanırım renk konusunda haklısınız 16M renk çıkarmak bilindik yöntemlerle mümkün değil.

65K renk üzerinde çalışma yapacağım. Buda bildiğim kadarıyla 16bit renk çözünürlüğü olur. Belki 565 formatı kullanılabilir.

Aslında 74LS682 iyi bir hız katabilir. 6 Adet kullanılsa her birinin çıkışı sırayla R1, G1, B1, R2, G2, B2 Pinlerine bağlansa olabilir. Ama 6x8 den 48 adet data pini, 8 adet de ortak sayaç çıkışı olsa sadece karşılaştırma için 56 adet I/O kullanımı söz konusu olur. Pek pratik bir yöntem değil.

Bu iki yöntemin dışındada farklı bir yöntem uygulanamaz sanırım. Biraz beyin jimlastiği yapmak lazım.



mesaj birleştirme:: 30 Ekim 2014, 10:59:09

Renk çözünürlüğü 18 Bit de olabilir her seferinde 256 döngü yerine 64 döngü kurarım
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kantirici - 30 Ekim 2014, 12:55:30
Tabi şunada bakmak lazım paneldeki LED'lerin renk skalası ne? 16M renk ürettiniz ama panledeki LED buna cevap verebilecek mi? Bence bu kadar renk derinliği sunmazlar.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Kabil ATICI - 30 Ekim 2014, 13:27:55
O kadar renk derinliği sunsa bile sıradan bir insan gözü o kadarını algılayamaz.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 30 Ekim 2014, 13:40:19
Haklısınız  ledler 24 bit renk çözünürlüğünü desteklemeyebilir. 18 bit renk çözünürlüğü bile bana cok hiz katacagini tahmin ediyorum.  Sadece aklıma takılan konu 2ms lik yatay tarama suresi içerisinde kac kez pwm palsi uygulamam gerektiği.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 30 Ekim 2014, 19:31:40
Alıntı yapılan: Mucit23 - 30 Ekim 2014, 13:40:19
Haklısınız  ledler 24 bit renk çözünürlüğünü desteklemeyebilir. 18 bit renk çözünürlüğü bile bana cok hiz katacagini tahmin ediyorum.  Sadece aklıma takılan konu 2ms lik yatay tarama suresi içerisinde kac kez pwm palsi uygulamam gerektiği.

Mucit23

Yukarıdaki daha önce yazdığım kısmı anlayabildiniz mi? Burada biraz daha açık yazayım da anlaşılsın  dedim:

Ekranı saniyede tazelenmesi 50 defa olsun 1/50 -> 20 mSn olur

Displeyin yapısı gereği 8 de 1 seklinde sürülecek şekilde tasarlanmıştır sürme şeklinden anlaşılmaktadır (1/8 tarama (1,1/2,1/4,1/16 şeklindede tasarlananbilirler))

buradan -> 20/(1/8) -> 2,5 mSn bir satır ledin (32 ledin -> 4 adet 74hc595) tazelenme süresi..

Bu arada 8bit PWM yapılacaksa 256 değişik led tonu elde ederiz bir renk için .Displey bilgisinde de görüldüğü gibi RGB aynı anda gönderilmektedir.

Yukarıda elde edilen bir satır 2,5 mSn zamanında bu satır 256 defa taranmalıdır .Yani 2,5 mSn / 256 -> 9,765625 uSn bu bir taramanın süresi .

Ama biz bir satırda 32 bit göndermemiz  9,765625 / 32 -> 0,30517578125 uSn (3,2768 MHz) minimum saat frekansı ile sürülmeli (maksimum 25MHz ile sürülebilir).

Siz displeyi yukarıdaki bilgiler doğrultusunda sürülmelidir.

Buna göre bir devre kurulmalıdır. 6 bitlik bir çıkış (R1,G1,B1,R2,G2,B2) Saat ucu ve letch ve A,B,C ucu şeklinde bir tasarım yapilmalı ve buna göre bir donanım oluşturulmalıdır..

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: hasankara - 30 Ekim 2014, 22:03:14
Alıntı Yaphttps://www.picproje.org/index.php/topic,40249.msg301490.html#msg301490

pwm çoklama konusunda basit bir algoritmadan bahsetmiştim linkte.bu konuda önceki yazılanları pek okumadım belki çözüm olabilecek algoritmadan bahsedilmiş olabilir bir de ben bahsedeyim.

ekranda görüntülenecek olan görüntü, ekran sürücüsü tarafından ekranda 8 aşamada görüntülenir. her aşamada ekran parlaklığı 2 nin katları şeklinde artarak güncellenir. buna paralel olarak, her bir pikselin bir rengi için tayin edilmiş 8 bitlik olan parlaklık bilgisinin bitlerine göre her hücre için maskeleme yapılarak 8 aşama tamamlanır.

görüntünün tümünü referans alarak anlatmaya çalışırsam; 1 adet 8 bit parlaklık derinliği olan görüntüyü elde etmek için 8 adet tek ton görüntü elde ediyorsun. 8 adet tek ton görüntüyü ekranda gösterirken, her aşamada ekranın tümünün parlaklık katsayısını 2 nin katlarında arttırıyorsun. tek ton derken kast ettiğim led ya yanıyor yada sönüyor. 8 bit kafanı karıştırmasın, bir pikselde 3 adet renk var ancak her piksel değilde her ledi kendi içinde değerlendirmiş oluyoruz. sonuç olarak piksel bazlı bakıldığında 24 bit renk derinliği elde etmiş oluyoruz.

8 bitlik data ile 24 bit renk derinliği elte etmemizi, her pikselde 3 adet led kullanmış olmamıza bağlayabiliriz. bu metod yerine, her led için 8 adet led koyarak 8 kez görüntü oluşturmaktan sa parlaklık bilgisine göre parlaklıkları 2 nin katlarına göre değişkenlik gösteren bu 8 lede tek seferde uygulayarak ta tek görüntü ile parlaklıklı görüntü elde edebiliriz.

3. sayfadaki yorumumu biraz daha açmaya çalışayım. öncelikle, ben bu yorumu yazarken panele data gönderme (haberleşme) yöntemi farketmeksizin, sadece parlaklık işinin nasıl yapılabileceğinden bahsetmiştim.

tek renk görüntü oluşturabildiğimiz panelde parlaklıklı görüntü nasıl oluşturabiliriz?

standart kayan yazıları çoğu yerde görüyoruz, tek renk ten kastım tamda bu paneller aslında. diğer deyişle ekrana baktığımızda bir piksel için led ya max parlaklıkta yanıyordur yada yanmıyor dur. kafa karıştırabilecek bir noktada burası aslında matrix tarama metodu kullanılarak da tek renk görüntü elde edilebiliyor. ama nihayetinde tarama olduğu için max parlaklığı kısıtlayan bir faktör şeklinde her led ( 1/(tarama_adım_sayısı) ) duty oranında pwm lenmiş olur. illa ki tarama metodu kullanılacak diye bir şart yok her led için bir shift register çıkışı tayin edip matrix tarama yöntemini aradan çıkarabiliriz. 8x8 matrix için tarama metoduyla 1 tane 16bit lik shift register yeterli olabilirken, tarama metotsuz her led için çıkış tayin edilerek 4 tane 16bit shift register kullanılabilinir. tarama metodu için hem tam periyodik çalışma şekline hemde daha yoğun bir işlem gücü ne ihtiyaç duyabiliyoruz. tarama metotsuz yöntemde görüntü sabit olduğu sürece panel ile ilgili herhangi bir işlem yapmaya ihtiyaç yoktur ve periyodiklik önem arz etmez.

1 adet tek renkli görüntüyü elde etmek için; tarama metodu kullanıldığında tüm satırların tarama işlemi tamamlanmış olması gerekiyor. tarama metotsuz iken shift registerlere sadece bir kez bilgi yollandığında görüntü elde ediliyor tekrar belirteyim,bu yüzdende aynı bilgiyi defalarca yollamaya gerek kalmıyor.

tek renk görüntü oluşturmak için değinebileceğim diğer bir nokta her piksel için 3 led (r g b) kullanılması. aslında sürülme yöntemi olarak bu 3 ledin diğer tüm ledlerden farksız olarak değerlendirilebileceğini ve bunun sadece yazılımda ayırt edilebileceğini belirtmem de bu noktada oluşabilen kafa karışıklığını giderilebilmesi için yeterli olabileceğini düşünüyorum. elbette diğer ledlerde yapabileceğimiz gibi bir de ledleri rgb diye gruplandırarak 3 aşamadan oluşan ayrı bir tarama katmanı oluşturulabilir ancak bu metot işin içine girerse tüm görüntüler bide rgb için 3 kez daha taranması gerekir. özel ihtiyaçlar dışında bu metodun tercih edilmeyeceğini düşünüyorum.

bu arada tek renk görüntü elde etme metotlarından bahsetmişken şunuda belirtmiş olayım, kullanılacak panel hazır ise tek renk görüntü elde etme metodunu değiştirme gibi bir esnekliğiniz olmuyor çünkü bu kısmın kuralları, panel şeması ile birlikte belirlenmiş oluyor.

buraya kadar kısım sadece panelde tek renk görüntü elde edebilmek için bilmemiz gerekenlerdi. parlaklık oluşturma kısmını, tek renkli görüntü elde etme yöntemi üzerine kurulan bir katman gibi düşünebiliriz. alıntı yaptığım yorumumda bu üst katmanın oluşmasından bahsettim aslında. diğer bir öneri de tek renk görüntü oluşturmak ile tek renk görüntülerden parlaklıklı görüntü oluşturma yı birbirinden farklı işlemler olarak görmeye çalışın.

parlaklıklı görüntü elde etmek için ihtiyacımız olan diğer bir özellik de, tek renkli görüntünün oluşmasında kullanılan bütün ledlerin parlaklığını tek bir kanal dan ayarlayabilecek bir donanıma sahip olmamız. kısaca nasıl elde edebiliriz diye değinecek olursam; shift registerlerden oluşan panelin üzerindeki tüm shift registerlerin enable uçlarını birbirine bağladığımızda bu ortak nokta, görüntünün ortak parlaklığını ayarlayabilen kanalı ifade edebiliyor. bu kısımda belirtmem gereken önemli bir nokta ise; enable ucuna pwm sinyali uygulayarak tüm panelin ortak parlaklığını, sinyalin duty oranı ile ayarlayabiliyoruz ancak, ekran taraması olsun parlaklık oluşum tarama katmanı olsun tüm hepsinden çok daha hızlı bir frekansa sahip olması gerekir bu pwm sinyalinin. bu pwm sinyalinin diğer katmanarla senkron çalışmadığını varsayarak şunu söyleyebilirim, oransal olarak tahmini diğer tarama metotlarının en hızlısından en az 4 kat daha hızlı olmazsa en neticede oluşan görüntüde titreşimlere sebebiyet verebilecektir.

parlaklıklı görüntü elde etmek için iki temel ihtiyacı karşıladıktan sonra bu özellikleri kullanarak hedefimize ulaşmamızı sağlayacak katmanı tekrar açıklamaya çalışayım. ilk başta kullanıcıya sunulacak 24bit renk derinliğini 8 bit parlaklık derinliği olarak görmeliyiz. çünkü biz panel sürmek için her görüntüyü oluştururken piksel piksel değil led led oluşturacağız.

(http://s28.postimg.cc/ah02nhezd/parlaklikli_goruntu.jpg) (http://postimg.cc/image/ah02nhezd/)

8 bit sayısal ortamda 2^8=256 durum ifade edebiliyor. yani her led 256 farklı parlaklık durumunu alabilmeli. sanal ortamda her led için 8 bit uzunluklu parlaklık değişkenleri belirlenir. 0ıncı tek renk görüntüyü oluşturmak için; her ledin kendi parlaklık değişkenlerinin 0ıncı bitleri kullanılarak elde edilir. 1inci tek renk görüntüyü oluşturmak için ise, yine her led için atanmış olan parlaklık değişkenlerinin 1inci bitleri kullanılarak elde edilir. bu şekilde 8 adet tek renk görüntü elde edilmiş olunur. 8 adet elde edilmiş olan tek renk görüntüler sırası ile panelde görüntülenir ve her tek renk görüntünün görüntülendiği sürece, tüm panelin parlaklığı ayarlanır. bu parlaklık ise 0ıncı görüntü süresinde 1 birim, 1inci görüntü süresinde 2 birim, 2inci görüntü süresinde 4 birim, 3üncü görüntü süresinde 16 birim ... 7. görüntüde 128 birim şiddetlerinde ayarlanır. böylece her led üzerinde, değişkenlerimize bağlı olarak 256 parlaklık seviyesini oluşturmuş oluruz.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 30 Ekim 2014, 23:32:28
Hocam anlatımınız için çok teşekkür ediyorum. Yöntemin anlaşılması gerçekten zor.

8 bit renk derinliği için 8 adet katman oluşturmak gerekiyor. Sırasıyla 8 adet döngü oluşturup bu katmanları ekrana veriyoruz. Panelin OE pininden Pwm uyguluyoruz. 1. Katmanı gönderdikten sonra duty oranımız 1, 8. Katmanda duty oranımız 128 oluyor. Bu sebebten dolayı max. parlaklık alamıyoruz.

Benim anlamadığım konu katman meselesi. Daha doğrusu tek renkli görüntü oluşturmak. Bunu Normal P10 larda biliyorum ama Burada RGB işin içine giriyor. Her bir led için duty değerlerimiz var.

Şimdi Panelde kaç adet led var ise okadar duty değişkenimiz olsun.Aslında bunu artık panel yöntemi nasıl olursa olsun 3 adet iki boyutlu dizi ile yapmayı düşünüyorum

RDuty[32][16]
GDuty[32][16]
BDuty[32][16]

Burada SR lere veri basırlırken 8 aşamada işlem tamalanıyor sanırım.

0. Aşamada örneğin 0,0 kordinatındaki led için düşünürsek RGB duty verilerinin 0. bitlerini 0,0 kordinatındaki ledlere gönderiyoruz.(Aslında bu işlem aynı esnada tüm ledlere yapılıyor) Ardından OE pininden 8 Bit pwm sinyalinden duty değerini 1 yapıp gönderiyoruz. Bu işlem ile 1. katman ekrana yüklenmiş oluyor. Ardından 2. katman için RGB duty değerinin 1. bitlerini 0,0 kordinatındaki ledlere gönderip Duty değerini 2 yapıyoruz.
3. katman için 2. bitleri 0,0 kordinatındaki ledlere gönderip duty oranımınız 4 yapıyoruz.
8.katmana geldiğimizde 7. biti 0,0 kordinatına gönderip duty oranını 128 yapıyoruz.

Eğer buraya kadar doğru anladıysam ne mutlu bana

Şimdi bu işlemi satır taramayla birlikte nasıl yapıyoruz onu anlamadım?

Dediğim gibi anlaşılması gerçekten zor bir yöntem hocam hakkınızı helal edin  :-[
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: hasankara - 31 Ekim 2014, 01:22:42
aslında kafa karışıklığına sebebiyet verecek bir deyim kullanmışım şimdi fark ettim. 0. tek renk görüntü değilde 0. tek parlaklıklı görüntü dersem sanırım metodu anlamana biraz daha yardımcı olabilirim. mesela bahsettiğim parlaklıklı görüntüyü elde etme metotlarını işin içine karıştırmadan da her piksel için 8 farklı renk elde edebilirsin. hiçbiri,yeşil,kırmızı,mavi,yeşil ve kırmızı, yeşil ve mavi, mavi ve kırmızı, hepsi şeklinde her led için ya yanar yada söner diyerek her piksel için 8 adet renk oluşturabilirsin. eğer verilerini piksel şeklinde tutuyorsan işe, bunları 3 e parçalayıp tüm ledleri birbirinden bağımsız sürebilmek ile başlayabilirsin.

1. aşama tek parlaklıklı görüntüyü oluşturabilmek. (her ledin parlaklığını kendi içinde değerlendiriyoruz.)
2. aşama 8 adet tek parlaklıklı görüntüleri kullanarak, 1 adet parlaklıklı görüntü oluşturabilmek.

bu iki aşamayı elinden geldiğince parçalı görmeye çalış.

biraz daha somut bir örnek vermeye çalışayım. tarama metodu kullanmadan bir  16x32 piksel li (16x32x3 led li) paneli tek parlaklıklı sürebildiğini düşünelim. 16satır 32 sütun piksel yani 16 satır 96 sütun led yada 48 satır 32 sütun gibi iki farklı boyut şeklinde düşünebilirsin. hatta illa 2 boyutlu düşünmek zorunda değilsin, 16 satır 32 sütun 3 derinlik led şeklindede düşünebilirsin. son da ki gibi gidelim.
unsigned int data_sur[16][3]; // her bir hücre 32 bit, bundan 16 tane var ve bu 16 int dende 3 tane daha var. sen shftreg_up isimli fonksiyonuna bu diziyi gösterdiğin zaman panelde tek parlaklıklı görüntü oluşuyor sanırım bu kadarını yapabiliyorsun. diğer bir deyişle sanaldaki değişkenlerinin her bir biti panel üzerinde bir led anlamını taşıyor.

unsigned char data_parl[32][16][3]; asıl parlaklık değerlerini bu değişkende saklıyorsun. bu 3 boyutlu bir dizi ama her bitinin bizim için anlam ifade etmesi dolayısı ile 4 boyutlu görelim.

örnek olarak 3üncü tek parlaklıklı görüntünün 2inci satırının 1inci sütunundaki pikselin ledlerinin yanık mı yoksa sönük mü durumunu, data_parl parlaklık matrisini kullanarak oluşturalım. bitcopy(var1,bit1,var2,bit2) diye bir makromuz var bu bir değişkenin bir bitinden başka bir değişkenin başka bir bitine değer kopyalıyor.
bitcopy(data_parl[1][2][0],3 , data_sur[2][0],1);
bitcopy(data_parl[1][2][1],3 , data_sur[2][1],1);
bitcopy(data_parl[1][2][2],3 , data_sur[2][2],1);

örnek olarak 3üncü tek parlaklıklı görüntünün 2inci satırının 30uncu sütunundaki pikselin ledlerinin yanık mı yoksa sönük mü durumunu, data_parl parlaklık matrisini kullanarak oluşturalım.
bitcopy(data_parl[30][2][0],3 , data_sur[2][0],30);
bitcopy(data_parl[30][2][1],3 , data_sur[2][1],30);
bitcopy(data_parl[30][2][2],3 , data_sur[2][2],30);

for döngüleriyle yazacak olursak;

seviye[8]={1,2,4,8,16,32,64,128};

for(s=0;s<7;s++){// parlaklıklı görüntü oluşur

   for(k=0;k<31;k++){// sütunlar yüklenir
      for(j=0;j<15;i++){// satırlar yüklenir
         for(i=0;i<2;i++){bitcopy(data_parl[k][j],s , data_sur[j],k);}// pikseller yüklenir
      }
   }

shftreg_up(data_sur); // s inci tek parlaklıklı görüntü shift registerlere yüklendi
panel_pwm(seviye); // panele s inci pwm seviyesi uygulandı.

delay();// eğer panele uygulanan pwm sinyali tekrar sonraki uygulanıncaya kadar en az 4 periyot tamamlayamaz ise biraz gecikme uygulanabilir.

}
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 31 Ekim 2014, 11:54:03
Hocam teşekkürler. Şimdi biraz daha oturdu. Ben ilk yöntem üzerinde ufak bir deneme yapacağım. Çözünürlük zaten 6 bit olacak. Sonuç alamazsam eğer bahsettiğiniz yöntem üzerinde çalışma yapacağım. Tezgahı kurup lojik analyser ile bakayım hangi işlem ne kadar sürede tamamlanıyor. Ona göre kafamda hız hesabı yapabilirim.

Merak ediyorum. Acaba FPGA lı kartlardamı böyle bir yöntem kullanıyor acaba. Nasıl öğrenebiliriz bunu?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 31 Ekim 2014, 11:56:44
Alıntı yapılan: hasankara - 31 Ekim 2014, 01:22:42

1. aşama tek parlaklıklı görüntüyü oluşturabilmek. (her ledin parlaklığını kendi içinde değerlendiriyoruz.)
2. aşama 8 adet tek parlaklıklı görüntüleri kullanarak, 1 adet parlaklıklı görüntü oluşturabilmek.


seviye[8]={1,2,4,8,16,32,64,128};


Seviye belirlemede 8 adet deger kullanıyorsunuz burada 8 bit (256) renk tonu nasıl elde ediyorsunuz ?

Bence her renk için 8 bit yani 1byte renk derinliği olacak ise bir piksel için 3 byte data tutulmalı ve buradan panel için 3 * 16 * 32 = 1536 byte bir ram bolgesine bilgi ram da saklanacak ise veya Rom (Eprom) da saklanacak ise 1526 byte ihtiyaç vardır .
Artık buradan yararlanarak bir algoritma ile bir pikseldeki 3 rengin verilerinden yararlanarak PWM dataları elde edilir her renk için ve sürülir.
Yukarıda bahsettiğim minimum sürme frekansını yukarıda hesaplamıştım ekranın tazelenme süreleri satırların PWM e bağlı olarak tazelenme zamanları.
Yukarıdaki konuşmalarda PWM işlemini OE ucu ile yapılma olayından bahsedilmiç . Bu işlem bu uçla yapılamaz çünkü bu uç ortak uç .
Ancak yapılabilmesi için her rengin OE ucu ayrı olması gerekir ..

Bir pikselin bir rengin PWM degeri elde etmek için ya lojik komparator ile çıkışın 1 veya 0 durumunu kontrol ederek donanımsal olarak yaparsın .
Yada bir dongü içinde bir sayıcı degeri 1 arttırılarak piksel değerinin datası ile karşılaştırma yapılarak büyük küçük durumuna göre 1 veya 0 durumu elde edilir.
bu bilgi ile PWM durumu elde edilmiş olur o pikselin rengi için..



mesaj birleştirme:: 31 Ekim 2014, 12:00:41

Alıntı yapılan: Mucit23 - 31 Ekim 2014, 11:54:03

Merak ediyorum. Acaba FPGA lı kartlardamı böyle bir yöntem kullanıyor acaba. Nasıl öğrenebiliriz bunu?

Yukarıda anlatılanlar donanımsal olarak bit bazında işlem yapılıyor (lojik komparator gibi) donanımsal işlemler çok hızlı olduğu için bu işlemler kısa sürede bitiyor..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: hasankara - 31 Ekim 2014, 16:09:48
bu arada sayfada yazım şekli için kötü görünmüş bir kısım tekrar yazayım.

seviye[8]={1,2,4,8,16,32,64,128};

for(s=0;s<7;s++){// parlaklıklı görüntü oluşur

   for(k=0;k<31;k++){// sütunlar yüklenir
      for(j=0;j<15;i++){// satırlar yüklenir
         for(i=0;i<2;i++){bitcopy(data_parl[k][j][i],s , data_sur[j][i],k);}// pikseller yüklenir
      }
   }

shftreg_up(data_sur); // s inci tek parlaklıklı görüntü shift registerlere yüklendi
panel_pwm(seviye[s]); // panele s inci pwm seviyesi uygulandı.

delay();// eğer panele uygulanan pwm sinyali tekrar sonraki uygulanıncaya kadar en az 4 periyot tamamlayamaz ise biraz gecikme uygulanabilir.

}


bmutlu 8 bit renk tonu değil parlaklık tonu elde ediliyor. buda 3 renk led olduğunda 24 bit renk derinliği anlamına geliyor. parlaklık bilgileriyle zamana yayılarak farklı kombinasyonlarda her ledin parlama sürelerinin toplanması ile 256 farklı parlaklık kademesi elde ediliyor demek.

bu arada vermiş olduğum örnekte kullanabileceğimiz panelin sürülme metodunu da belirttim buna göre bir kod örneği oluşturdum. Ancak panel, tarama metodu ile sürülüyorsa benim yazdığım gibi tek solukta tek parlaklıklı görüntü oluşturulamayabilinir. shftreg_up(data_sur); bu satırda ki fonksiyon tüm tarama işlemlerini yapabilecek şekilde düzenlenebilir ancak diğer for döngüleri çok zaman alırsa tam periyodik bir tarama elde edilemeyebilir buda panelde oluşan görüntüde ilk taraması yapılan parçalar ile son taraması yapılan parçaların kendi aralarında genel bir parlaklık farkı oluşmasına sebep verir. bu, hesapta olmayan bir durum diğer deyişle problem dir. Bu problemi,  shftreg_up(data_sur); fonksiyonunu tam periyodik olarak işleme ile elde edebilirsin. aynı zamanda for(s=0;s<7;s++) döngüsünü de tam periyodik işleyebilmek gerekiyor. fpga olunca periyodiklik konusunda bir kuşku kalmıyor bu yüzden bu iş için fpga biçilmiş kaftan olarak görülebilinir. piksel yükleme for döngülerini tek cycle da bile halledebilmek gibi avantajları, ek arayışlardan kurtarabiliyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 31 Ekim 2014, 22:14:31
Ufak bir test yaptım ve anladığım kadarıyla bu iş ekstra donanım olmadan normal yöntemlerle yapılamıyor.
Şöyle bir kod yazdım ne kadar sürede işlendiğini ölçtüm.
for(Bit_Count=0;Bit_Count<32;Bit_Count++)
{
       if(R1_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_8;}else{GPIOB->BRR=GPIO_Pin_8;}
       if(G1_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_9;}else{GPIOB->BRR=GPIO_Pin_9;}
       if(B1_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_10;}else{GPIOB->BRR=GPIO_Pin_10;}
       if(R2_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_11;}else{GPIOB->BRR=GPIO_Pin_11;}
       if(G2_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_12;}else{GPIOB->BRR=GPIO_Pin_12;}
       if(B2_Data & 0x80000000){GPIOB->BSRR=GPIO_Pin_13;}else{GPIOB->BRR=GPIO_Pin_13;}
       R1_Data=(uint32_t)R1_Data<<1;
       G1_Data=(uint32_t)G1_Data<<1;
       B1_Data=(uint32_t)B1_Data<<1;
       R2_Data=(uint32_t)R2_Data<<1;
       G2_Data=(uint32_t)G2_Data<<1;
       B2_Data=(uint32_t)B2_Data<<1; 

GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
GPIOB->BRR=GPIO_Pin_14;     //CLK=0
    }

Bu kod 72Mhz çalışma frekansında yaklaşık 40uS de işleniyor. Bundan daha hızlı nasıl yaparım açıkçası bir yöntem aklıma gelmedi.

Benim en çok elimi ayağımı bağlayan

1-) Yukarıdaki Seri data gönderme işlemi
2-) Duty değerlerini karşılaştırma işlemi

Bu işlemlerin donanımsal olarak yapılması lazım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 31 Ekim 2014, 23:23:46
Yukarıdaki kod parçası 40usec tutuyorsa 1 sn. de 25K çalışabilir.

Yanlışım yoksa 16M  renk için bir tazeleme döngüsünde bu koddan 2048 kere çalışması gerektiğine göre 12Hz gibi tazeleme frekansı olur. 256K renk içinse 48 Hz gibi.
256K ve 48Hz tazeleme frekansı bence makul.
Üstelik renk döngülerinden dolayı frekans aslında çok daha yüksek, kırpışma vs. gözlenmez fikrimce. Tabii bunlar 256 veya 64 kere yenileme yapılan 1 yönteme göre..
Eğer 2.yönteme göre 8 eşit zamanda   OE ye uygulanan PWM ile  renk oluşturulacaksa neredeyse 400Hz tazeleme frekansı demek. Yani zaten olmuş.

Koda bakınca iyileştirilebilecek yerler de var üstelik. R1_Data G1..... dataları kaydırmak yerine duty sayıcısını döngü dışında kaydırmak gibi.

Tek avatajı ledleri daha parlak yakmak olsa da bir üçüncü yöntem olarak da üstünde konuşulan iki yöntemin ortak kullanılması olabilir.
İkinci yöntemdeki gibi tazeleme peryodunu 8 (veya 256k için 6) ayrı zamana bölmek. Ama eşit zamanlara değil.
Faydası 256 kere tarama yapmak yerine 8 kere yapmak olacak ve aynı sonucu verecek.
Bunun için de tazeleme peryodu 8 eşit zamana değil, 128/256, 64/256 ... 1/256 gibi 8 farklı zamana bölünecek.
Burada perfomansla ilgili sorun sadece 0 ncı biti işlemek olabilir. Bu durumda 256K renk için minimum süreyi 1/256 değil 1/64 seçmek perfomans konusu rahatlatır. 
256 kere yerine 8 kere de renkleri set etmek de putpixel vs. diğer işler için bayağı  zaman bırakır.
Yukarıdaki kodu bir timer kesmesinde çalıştırmak ve kesme için timer a sıradaki değeri yüklemek gibi. Artı global satır vs. değişkenleri..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 01 Kasım 2014, 00:08:56
Hocam benim hesaplara göre bu iş 1. yöntemle SM32F10x de olmaz. Olsa bile rutin işlere hiçbir vakit kalmıyor. Şöyleki yukarıda yaptığım işlem dediğim gibi yaklaşık 40us sürüyor. Eğer 6 bit renk derinliği olacaksa her bir seferinde 64 defa bu işlemi yapmam gerekirki bunun sonucunda tüm SR lerden sadece 1 puls'luk PWM sinyali elde ediliyor. 64x40us'den  2560us yapıyor. Şimdiden 2ms lik değer aşılıyor. Normalde 8 satır var ve her satır 2ms civarı aktif kalması gerekiyor. Yani benim 2ms içerisinde SR lerden olabildiğince çok PWM puls'i çıkarmam gerekiyor. Benim aklımda böyle bir düşünce vardı.

Ama sizin dediklerinizle bir türlü uyuşturamadım. Siz tazeleme frekansını nasıl hesaplıyorsunuz?

Neyse bu arada yukarıdaki işlemler STM32F407 & 168Mhz de 15uS civarı sürüyor.

Alıntı YapKoda bakınca iyileştirilebilecek yerler de var üstelik. R1_Data G1..... dataları kaydırmak yerine duty sayıcısını döngü dışında kaydırmak gibi.
Birde hocam burayı anlayamadım. R1_Data, G1_Data....B2_Data değişkenlerim benim 32 bitlik değişkenlerim olacaktı. Bu değişkenlerher bir döngüde  doğrudan SRlere gönderilecekti. Ben duty değerlerine göre bu değişkenlerin ilgili bitlerini 0 veya 1 yapacaktım. Aklımda böyle bir tasarı vardı.

Galiba en mantıklı çıkar yol hasan hocamızın anlattığı yöntem. Onuda şimdilik panel bir yana 74HC595'de uygulamam gerekir. Henüz mantık tam olarak oturmuş değil. Mantığını bi çözsem gerisi çorap söküğü gibi gelecek.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 01 Kasım 2014, 01:54:26
Alıntı yapılan: Mucit23 - 01 Kasım 2014, 00:08:56
Şöyleki yukarıda yaptığım işlem dediğim gibi yaklaşık 40us sürüyor. Eğer 6 bit renk derinliği olacaksa her bir seferinde 64 defa bu işlemi yapmam gerekirki bunun sonucunda tüm SR lerden sadece 1 puls'luk PWM sinyali elde ediliyor. 64x40us'den  2560us yapıyor. Şimdiden 2ms lik değer aşılıyor.

Ama sizin dediklerinizle bir türlü uyuşturamadım. Siz tazeleme frekansını nasıl hesaplıyorsunuz?
2ms karşılığı 62.5 Hz di. 2560us karşılığı 48Hz.. İllede 62.5 Hz tazeleme gerekiyormu?.

Hesap,

1/(256renk döngüsü* 8 satır * 40usec) = 12.21 Hz
1/(64renk döngüsü * 8 satır * 40usec) = 48.83 Hz şeklinde..


Alıntı yapılan: Mucit23 - 01 Kasım 2014, 00:08:56
Birde hocam burayı anlayamadım. R1_Data, G1_Data....B2_Data değişkenlerim benim 32 bitlik değişkenlerim olacaktı. Bu değişkenlerher bir döngüde  doğrudan SRlere gönderilecekti. Ben duty değerlerine göre bu değişkenlerin ilgili bitlerini 0 veya 1 yapacaktım. Aklımda böyle bir tasarı vardı.

Galiba en mantıklı çıkar yol hasan hocamızın anlattığı yöntem. Onuda şimdilik panel bir yana 74HC595'de uygulamam gerekir. Henüz mantık tam olarak oturmuş değil. Mantığını bi çözsem gerisi çorap söküğü gibi gelecek.


Konu karışıyor çünkü tam olarak hangi yönteme göre gidildiği belli değil.
Eğer 256 kere veya 64 kere tarama yapılan yöntemi uygulayacaksak, mantık aşağıdaki koda benzer olur.

                    //satır = 8, 2 satır şeklinde sutun = 2*16=32, sağ ve sol taraf için 3 renkten den 6 led
    uint8_t ledduty [8][32][6];
    uint8_t dutyCounter;
    uint8_t rowNum, colNum;

    dutyCounter = 0;

    rowNum = 0;
    colNum = 0;
   
    while (1)
    {
       
        for (rowNum = 0;    rowNum <8;rowNum ++)
        {
            //satır seçimi ile ilgili A,B,C pin setleri
       
            for (dutyCounter = 0;    dutyCounter<255; dutyCounter++)
            {
                //alltaki  döngü satırların sürülme sırasına ve duty bilgilerinin bellekteki yerleşimine göre 2 ayrı 16 lık döngü olabilir.
                for (colNum = 0;    colNum <32; colNum++) //
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sağ taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (dutyCounter >= ledduty [rowNum][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (dutyCounter >= ledduty [rowNum][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};
                    //sol taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][3]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (dutyCounter >= ledduty [rowNum][colNum][4]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (dutyCounter >= ledduty [rowNum][colNum][5]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};

                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }
               
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=1
                __Nop();
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=0
            }   
        }
    }   



Yok Eşit zaman aralıklarında OE pinine 2 nin katları şeklinde PWM uygulayacaksak da aşağıdaki koddaki mantıkta birşey çıkar.

    uint8_t ledduty [8][32][6];
    uint8_t dutyCounter, duty;
    uint8_t rowNum, colNum;
   

    while (1)
    {
       
        for (rowNum = 0;    rowNum <8;rowNum ++)
        {

            //satır seçimi ile ilgili A,B,C pin setleri

            //işlem gücü fazlasıyla yeteceğinden alt kısmın devamı için timer dan bir işaret beklemek gibi bir şey olabilir.
            //veya alt kısım kesme içerisinde de çalışabilir.
            while(timerFlag ==0); //timer 2ms de bir kesme oluşturmalı.. 2ms de bir çalışacak olan kısım aşağısı..
            timerFlag = 0;

            for (dutyCounter = 1;    dutyCounter<8; dutyCounter++)
            {
                duty = 1 << dutyCounter;
               
                //OE çıkışı low PWM disable
               
                //alltaki  döngü satırların sürülme sırasına ve duty bilgilerinin bellekteki yerleşimine göre 2 ayrı 16 lık döngü olabilir.
                for (colNum = 0;    colNum <32; colNum++) //
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sağ taraf diyelim
                    if (duty & ledduty [rowNum][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (duty & ledduty [rowNum][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (duty & ledduty [rowNum][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};
                    //sol taraf diyelim
                    if (duty & ledduty [rowNum][colNum][3]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (duty & ledduty [rowNum][colNum][4]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (duty & ledduty [rowNum][colNum][5]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};

                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }
               
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=1
                __Nop();
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=0
            }
            //OE çıkışına donanımdan PWM basılacak..
            PWM duty = base_duty_ON_peryod * duty
            //2ms lik zamanlarda farklı parlaklıklarda yanan veya sönen ledler renk oluşturacak..
        }
    }



Son örnek için konuşursak,
32 lik döngü 40us idi. Oda döngü içerisindeki kod fazlalıkları ile.
Dışında 8 lik duty, ve 8 lik satır döngüleri var. 40*8*8 = 2560 usec de panelin tamamı bir kez taranmış olur. 62,5 Hz lik  :) tazeleme frekansı vardı. Tüm işlem 160 ms de biter. Geriye kalan 840ms diğer işlere sanırım yeterli olur.

Bu ikinci örnekteki koddan pwm'i  çıkarıp OE pinini sürekli aktif edersek ve timer'ı toplamı 2ms edecek şekilde 8 bit için 8 ayrı değerde ikinin katları şeklinde kurarsak 1 ve 2 yöntemi birleştirmiş ve ledleri tam parlak yakmış oluruz. Karşılığında duty için 256 veya 64 yerine  8 lik bir döngüye girdiğimiz için (256K renk için 6 lık) diğer işlere yine zaman kalır. Belki 0 bit için işlem zamanında bitmeyebilir. 8 bit yerine 7 veya 6 bit kullanımı ile bu sorun da aşılabilir.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 01 Kasım 2014, 11:20:16
Hocam karışıklık olmasın. Ben çalışmalarımı 2. Yöntem üzerinden devam ettireceğim. Kasmaya gerek yok. :)


Hocam dün akşam oturdum ekranın veri yapısı için bir tablo oluşturdum. Tabloyu aşağıdaki linkten indirip inceleyebilirsiniz.
https://docs.google.com/spreadsheets/d/1gA3L6CRhEZvIhVJTa0HUKi5sRIYGjjGNbhoRD920g1M/edit#gid=496249709


R1_Data, G1_Data değişkenleride buradan geliyor aslında


Ben yukarıda bir kod örneğin vermiştim. 32 bitlik R1_Data, G1_Data gibi değişkenleri shift registerden gönderiyordum.


Panelde 6 adet Data girişi var. Her girişte toplam 2 adet SR kaskat bağlı.
R1 Girişi ilk 16 sütün içindi(1.Bölge) Dolayısıyla ABC satır seçme girişi "000" iken R1 girişindeki ilk SR 1. Satır 0-16 sütün arasına veri gönderirken diğer SR 9. satırdaki 0-16 sütün arasına veri gönderiyor. Satır tarama ile bu değişiyor. R1 girişindeki aynı SR' ler ABC girişi "001" olduğu zaman bu sefer de 2-10. satırlara veri göndermiş oluyor.


Bu yüzden ben R1_Data, G1_Data gibi 32 bitlik değişkenleri SR lere gönderiyordum. Tabi her gönderme işleminden önce butün duty değerlerini 1-64 arası sayan duty sayacıyla karşılaştırıp R1_Data, G1_Data değişkenlerinin ilgili bitlerini 1 yada 0 yapacaktım. Bu işlemi 64 defa yaparsam 6 bit çözünürlükte bir adet pwm puls'ı çıkıyor. Dolayısıyla 2ms içerisinde olabildiğince fazla bir şekilde yapmam gerekiyordu bunu çünkü sadece bir pwm puls'i yetmeyebilir diye düşünüyordum.


Fakat sizin bu döngüyü anlayamadım
   for (colNum = 0;    colNum <32; colNum++) //
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sağ taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (dutyCounter >= ledduty [rowNum][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (dutyCounter >= ledduty [rowNum][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};
                    //sol taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][3]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (dutyCounter >= ledduty [rowNum][colNum][4]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (dutyCounter >= ledduty [rowNum][colNum][5]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};


                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }

Siz doğrudan Duty değerlerini counter ile karşılaştırıp doğrudan çıkışa 1 yada 0 vermişsiniz. Acaba ben R1_Data gibi değişkenler kullanarak işimi uzatıyordum  ???


Hem 1. yöntem hemde 2. yöntem için SR lere veri göndermede yukarıdaki kodu kullanmışsınız. Nasıl çalıştığını, Daha doğrusu bit bazlı nasıl pwm oluştuğunu anlayamadım. Müsait bir vaktinizde bu konuda kısa bir açıklama yapabilirmisiniz?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 02 Kasım 2014, 00:45:16
Alıntı yapılan: Mucit23 - 01 Kasım 2014, 11:20:16
Hocam dün akşam oturdum ekranın veri yapısı için bir tablo oluşturdum. Tabloyu aşağıdaki linkten indirip inceleyebilirsiniz.
https://docs.google.com/spreadsheets/d/1gA3L6CRhEZvIhVJTa0HUKi5sRIYGjjGNbhoRD920g1M/edit#gid=496249709 (https://docs.google.com/spreadsheets/d/1gA3L6CRhEZvIhVJTa0HUKi5sRIYGjjGNbhoRD920g1M/edit#gid=496249709)


R1_Data, G1_Data değişkenleride buradan geliyor aslında


Ben yukarıda bir kod örneğin vermiştim. 32 bitlik R1_Data, G1_Data gibi değişkenleri shift registerden gönderiyordum.


Panelde 6 adet Data girişi var. Her girişte toplam 2 adet SR kaskat bağlı.
R1 Girişi ilk 16 sütün içindi(1.Bölge) Dolayısıyla ABC satır seçme girişi "000" iken R1 girişindeki ilk SR 1. Satır 0-16 sütün arasına veri gönderirken diğer SR 9. satırdaki 0-16 sütün arasına veri gönderiyor. Satır tarama ile bu değişiyor. R1 girişindeki aynı SR' ler ABC girişi "001" olduğu zaman bu sefer de 2-10. satırlara veri göndermiş oluyor.


Bu yüzden ben R1_Data, G1_Data gibi 32 bitlik değişkenleri SR lere gönderiyordum. Tabi her gönderme işleminden önce butün duty değerlerini 1-64 arası sayan duty sayacıyla karşılaştırıp R1_Data, G1_Data değişkenlerinin ilgili bitlerini 1 yada 0 yapacaktım. Bu işlemi 64 defa yaparsam 6 bit çözünürlükte bir adet pwm puls'ı çıkıyor. Dolayısıyla 2ms içerisinde olabildiğince fazla bir şekilde yapmam gerekiyordu bunu çünkü sadece bir pwm puls'i yetmeyebilir diye düşünüyordum.

Tam olarak anlayabildiğimi söyleyemem.
R1_Data...  bu değişkenleri 16+16 bit tasarlamış olmanız 2. yöntemin 8 eşit zaman aralığından birine karşılık gelen bit değerlerini yani 1 pikselin R sinin 1 biti + 2 pikselin R sinin 1 biti gibi birleştirip 16bit bir değer elde edilmiş gibi.   Böyle ise olabilir tabii, sonuçta Roma ya tek yol da gitmez, herkesin yoğurt yemesi de farklı.

Doğru anlayabildiysem bu değişkenlerin bu şekilde tasarlanması sanki donanımsal SPI dan basılacakmış gibi düşünülmesinden kaynaklı.  6 adet senkronize çalışabilen SPI modülümüz olsaydı bu şekilde güzel olurdu.
Ancak birde putpixel işlerimiz vardı. Bu tip fonksiyonları da düşününce belleğin RGB değerlerine göre lineer kullanımı da önemli olmalı. Öte yandan yazılımsal SPI kullanımından dolayı herhangi bir avantaj da sağlamıyor.
Verdiğiniz örnekteki 0x8000000 değeri ni bir kere kaydırmak yerine 6 kere değişkenleri kaydırma gibi perfomansa olumsuz etkileri gözardı da etsek benim verdiğim 2. örnekteki koddan dan perfomans açısından bir farkı olmayacak. Üstüne belleği de dağıtmış olacağız.

Alıntı yapılan: Mucit23 - 01 Kasım 2014, 11:20:16


Fakat sizin bu döngüyü anlayamadım
   for (colNum = 0;    colNum <32; colNum++) //
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sağ taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (dutyCounter >= ledduty [rowNum][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (dutyCounter >= ledduty [rowNum][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};
                    //sol taraf diyelim
                    if (dutyCounter >= ledduty [rowNum][colNum][3]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (dutyCounter >= ledduty [rowNum][colNum][4]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (dutyCounter >= ledduty [rowNum][colNum][5]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};


                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }

Siz doğrudan Duty değerlerini counter ile karşılaştırıp doğrudan çıkışa 1 yada 0 vermişsiniz. Acaba ben R1_Data gibi değişkenler kullanarak işimi uzatıyordum  ???


Hem 1. yöntem hemde 2. yöntem için SR lere veri göndermede yukarıdaki kodu kullanmışsınız. Nasıl çalıştığını, Daha doğrusu bit bazlı nasıl pwm oluştuğunu anlayamadım. Müsait bir vaktinizde bu konuda kısa bir açıklama yapabilirmisiniz?

Alıntı yaptığınız örnek 1 yöntem içindi. Gerçi alıntı yaptığınız kısım olarak bakarsak  2. yöntemde ki fark direkt karşılaştırma yerine and lemek.

Dediğim gibi sizin mantığınızı tam olarak anlayabildiğimi söyleyemem. Bu nedenle anlatmaya çalıştığım kendi mantığımı açmaya  çalışayım.

1 ve 2 yöntem arasında kod olarak ufak olsada algoritma olarak ciddi fark var. 1 sinde ledleri yakıp 256 farklı zamanda söndürme işini yapıyoruz. Led duty değeri kadar yandı ise söndürülme zamanı geldimi yi kontrol ediyoruz. Bunun için de duty sayacı ile led duty sini direkt olarak karşılaştırmak yetiyor. Burada 2ms lik zaman 256 veya 64 gibi bir değere bölünüyor.

Aslında 2 yöntemde bellek düzeni dışında sizinle aynı şeyleri yapıyoruz gibi.  Aşağıdaki açıklamalarda ki değerler 2ms yi 8 e böldüğümüz ve 16Mrenk elde ettiğimiz durum için.
2ms lik zamanı 8 eşit parçaya bölüyoruz. 
dutyCounter bu 8 eşit zaman parçasının hangisinde olduğumuzu belirtiyor.
duty ise sizin koddaki 0x80000000 'e benzer şekilde 2^dutyCounter değeri ile iş görüyor. Fark olarak ben 6 ayrı değişkeni kaydırmak yerine döngü dışında bu değişkenin içeriğini hazırlıyorum.
Döngü içerisinde de kaydırma vs. yapmadan ledlerin duty değerlerinin, bitlerinin değerine göre de 2 ms yi böldüğümüz 8 eşit zamanın her birinde o ledin yanıp yanmayacağına karar veriyoruz.
Bu noktada ledlerin bazıları yanık, bazıları sönük durumda. 2ms/8 süre boyunca  OE pinine duty değeri ile oranlı şekilde donanımsal PWM basıyoruz. Bu noktada bahsettiğimiz PWM 'in ledleri yakıp söndürme ile yani 1 yöntemdeki PWM ile ilgisi yok. Gerçek,  donanımsal,  TIMER, OC modülü ile üretilen PWM den bahsediyoruz.
Donanımsal PWM frekansını belirleyen PWM peryodu ise en fazla 2ms/8 veya katları şeklinde daha az olmalı.
Ve PWM duty = base_duty_ON_peryod * duty  dediğim yerdeki base_duty_ON_peryod değeride 2ms/8/128 veya pwm peryoduna uygun şekilde katları kadar az değer alacak.

Bu durumda 2ms/8 süreli  8 eşit zamanın herbirinde ledler kendileri için set edilen duty değerinin bitlerine göre ya yanacak yada yanmayacaklar. Yanan lar ise OE pinine ilgili bitin değerine göre uygulanan PWM nedeniyle farklı parlaklıklarda yanacaklar. 2ms/8 sürede 2 nin katları şeklindeki 8 farklı zamandaki toplam 256 PWM değeri ve parlaklık nedeni ile  16M rengimiz olacak. Veya 2ms/6 süre kullanıp 256K renk elde edilecek.
Ledleri farklı parlaklıklarda yaktığımız 2ms/8 süreli eşit zamandaki toplam duty ON değeri ancak 2ms/4 olabileceğinden ledler maks. normalin 1/4 ü kadar parlak yanabilecek.

Kısa olmadı ama umarım anlatabilmişimdir.

Buraya kadar anlaştı isek,
Bana göre çok ciddi bir avantaj sağlamayacaksa bellek düzeninin lineerliğini bozacak bir algoritma putpixel vs işlerinden dolayı uygun değil.
Ama en iç döngü içerisinde ki gerekli işlem nasıl en az olabilir diye düşünürken sizinki gibi bir bellek düzeninin perfomans sağlayıp sağlamayacağı konusuna takıldım. Sanırım bir şekilde olabilir. O da 6 ayrı biti tek tek yerine tek bir seferde paralel olarak basmak olabilir. GPIOX->ODR = xxx gibi.
Sağ ve sol panellerin aynı satır ve sütünlarındaki 3 renk den 6 ledin 1 bitleri, bir sonraki sütunun 1 bitleri, ... şeklinde 6 data pinine karşılık 6 bitlik 32 byte'lık bir diziyi 2. ve diğer bitler  için tekrarlayıp satırı arttırıp 8 kere daha takrarlayıp şeklinde elde edilmiş bir dizimiz olduğunda 1 byte tı direk pine basmak tek seferde 6 bitinde set edilmesini sağlar. Paralel veri aktarımı ve clock işleri FSMC ile sağlanırsa 32 byte da bir yani 4Khz lik kesme ile row ve latch set edilebilir. Tabii lineer belleğimizi bu düzende bir bellek alanına kopyalayacak bir fonksiyon da gerekiyor.

Artı olarak led parlaklığının az olması konusu  için bir önceki mesajda anlatmaya çalıştığım yöntem için yapılması gereken OE pinini sürekli aktif yapıp 32 lik döngüyü çalıştıracağımız zamanı bir timer kesmesi ile belirlemek, 32 lik döngüyü start edecek timer kesmesinin taşma değerini 2 nin katları şeklinde hazırlanmış 6-8 elemanlı bir diziden okumak..

İster direkt ledlerin az yandığı 2 yöntem, ister en son anlatmaya çalıştığım yöntem için Timerde FSMC tetiklemek, FSMC kesmesinde satır ve latch set etmek sanırım ideal yöntem olur. Açıkçası aklıma donanımdan da yardım alınabilecek minimum işlem zamanı gerektiren  başka bir yöntem gelmiyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 02 Kasım 2014, 15:36:53
Hocam cevap için teşekkürler.

Benim bu konuyu anlamam için mutlaka 74HC595 üzerinde test yapmam lazım. Diğer Türlü mantığını birtürlü oturtturamıyorum. 74HC595'in mantığını çözersem eğer aynı mantığı panel üzerinde uygulamam çok kolay olur. Şuan ne yapacağımı bilmiyorum.  :-[

Şuanda paneli boşverelim. 74HC595'den 8 Kanal 8 bit PWM almaya çalışalım.

OE'ye pwm uygulama işini anladım.
Alıntı YapDonanımsal PWM frekansını belirleyen PWM peryodu ise en fazla 2ms/8 veya katları şeklinde daha az olmalı.
Ben hemen Bu heseba göre 2000/8=250uS eder. Oda yaklaşık 4Khz civarı bir PWM Frekansı demek oluyor.
Ben PWM frekansını 8Khz yaptım. PWM de sıkıntı yok.

yine 8 adet duty değişkenim olsun.

uint8_t Duty[8];

Bundan sonra anladığım kadarıyla yukarıda tanımamış olduğum bütün duty değişkenlerinin 0. bitlerini sırayla SR nin çıkış bitlerine yazıyoruz.

Duty[0] değişkeninin 0. bitini SR 'a gönderilecek olan 8 bitlik değişkenin 0. bitine eşitiyoruz.
.
.
.
Duty[7] değişkeninin 0. bitini SR 'a gönderilecek olan 8 bitlik değişkenin 7. bitine eşitiyoruz.

Sonra Bu değeri SR ye gönderip OE'den 8 bitlik pwm için duty değerini 1 yapıp yolluyoruz.

Sonra yukarıdaki işlemlerin hepsini Duty değişkenlerinin 1. bitleri için tekrarlıyoruz. PWM duty oranını 2 katına çıkarıyoruz.

En son Duty değişkenlerinin 7. Bitlerini SR'ye gönderip  Duty değerini 128 yapıyoruz. Dolayısıyla %50 PWM uygulanmış oluyor.  (MaxDuty değeri 255)

Hocam anladığım yöntem doğrumu. Hatam varmıdır?


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 02 Kasım 2014, 19:03:10
Alıntı yapılan: Mucit23 - 02 Kasım 2014, 15:36:53
yine 8 adet duty değişkenim olsun.

uint8_t Duty[8];

Bundan sonra anladığım kadarıyla yukarıda tanımamış olduğum bütün duty değişkenlerinin 0. bitlerini sırayla SR nin çıkış bitlerine yazıyoruz.

Duty[0] değişkeninin 0. bitini SR 'a gönderilecek olan 8 bitlik değişkenin 0. bitine eşitiyoruz.
.
.
.
Duty[7] değişkeninin 0. bitini SR 'a gönderilecek olan 8 bitlik değişkenin 7. bitine eşitiyoruz.

Sonra Bu değeri SR ye gönderip OE'den 8 bitlik pwm için duty değerini 1 yapıp yolluyoruz.

Sonra yukarıdaki işlemlerin hepsini Duty değişkenlerinin 1. bitleri için tekrarlıyoruz. PWM duty oranını 2 katına çıkarıyoruz.

En son Duty değişkenlerinin 7. Bitlerini SR'ye gönderip  Duty değerini 128 yapıyoruz. Dolayısıyla %50 PWM uygulanmış oluyor.  (MaxDuty değeri 255)

Hocam anladığım yöntem doğrumu. Hatam varmıdır?

Eğer Paneli unutup sadece 8 ledi farklı parlaklıklarda yakmak için konuşuyorsak  yöntem olarak doğru. Anlattığınız şekilde olurdu. 

Sadece önceki mesajlarda da dikkatimi çeken nokta SR ye basacak bir değişken oluşturma konusu. Donanım SPI kullanmadığımız için SPI modülüne aktarmamız gereken bir değişkenimiz olmak zorunda değil. O değişkeni-değeri oluşturmak için uğraşacağımız zamanda zaten SR data pinini bit bit set edebiliyoruz. Yani direkt led duty değerlerini 2^dutycounter değeri ile AND leyip SR pinini anında set edebiliyoruz.  Bu söylediğim sadece performans için.  Yoksa yöntemin doğruluğu ile ilgili değil.

Panele dönersek duty[8] dediğiniz değişken 16 satır, 32 sütun ve 3 renk için bellek de lineer düzende olsun amacı ile duty[16][32][3] şeklinde tanımlayalım.
Panelin sağ ve sol kısımlarının ayrı SR ile sürüldüğünü ve aynı anda row ve row + 8 şeklinde iki satırın sürüldüğünü de gözönüne alırsak  belleği de lineer kullanacak şekilde düzenlersek daha önce verdiğim  örneği tam olarak yazmaya çalışırsak aşağıdakine benzer bir kod çıkacak. Kod içerisine de olabildiğince açıklamalar eklemeye çalıştım. Özellikle indislere dikkat edin..

    uint8_t ledduty [16][32][3]; // 16 satır 32 sütun, 3 renk
    uint8_t dutyCounter, duty;
    uint8_t rowNum, colNum;

   
   
    while (1)
    {
        for (rowNum = 0; rowNum <8; rowNum++ )
        {

            //satır seçimi ile ilgili A,B,C pin setleri

            //işlem gücü fazlasıyla yeteceğinden alt kısmın devamı için timer dan bir işaret beklemek gibi bir şey olabilir.
            //veya alt kısım kesme içerisinde de çalışabilir.
            while(timerFlag ==0); //timer 2ms de bir kesme oluşturmalı.. 2ms de bir çalışacak olan kısım aşağısı..
            timerFlag = 0;

            base_duty_ON_peryod = TIM_X->ARR/128     //base_duty_ON_peryod Donanımsal PWM frekansı için timer a yüklediğimiz değer /128 olacak..
           
           
            for (dutyCounter = 1; dutyCounter<8; dutyCounter++) //16M renk için dutyCounter<8, 256K renk için  dutyCounter<6
                                                                //buna göre timer kesmesi de 2ms/8 veya 2ms/6
            {
                duty = 1 << dutyCounter;
           
                //OE çıkışı low PWM disable
               
                //alltaki  döngü ile daha altındaki colNum döngülerinden hangisinin önce çalışacağı, satırları süren SR nin ne şekilde kaskat bağlandığına göre değişebilir
                //ayrıca sütunları süren SR lerin kaskat bağlanış şekline göre döngü artan yerine azalan yapıda da olabilir. 4 ayrı 0-8 arası rownum döngüsü de gerekebilir.
                //SR lerin ne şekilde kaskatlandığına ve bizim pikselleri adresleme şeklimiz ile SR çıkışlarının uyumluluğuna göre..

                //0-7 arasındaki satırlara ait sütunlar
                for (colNum = 0; colNum <16; colNum++)
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sol taraf, diyelim ki bellekte 1.satır 1 sütün üst sol köşe olsun..
                    if (duty & ledduty [rowNum][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (duty & ledduty [rowNum][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (duty & ledduty [rowNum][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};

                    //sqğ taraf diyelim
                    if (duty & ledduty [rowNum][colNum+16][0]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (duty & ledduty [rowNum][colNum+16][1]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (duty & ledduty [rowNum][colNum+16][2]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};

                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }
                //8-15 arasındaki satırlara ait sütunlar
                for (colNum = 0;    colNum <16; colNum++) //
                {
                    GPIOB->BRR=GPIO_Pin_14;     //CLK=0
                    //sol taraf, diyelim ki bellekte 1.satır 1 sütün üst sol köşe olsun..
                    if (duty & ledduty [rowNum+8][colNum][0]) {GPIOB->BSRR=GPIO_Pin_8;}     else{GPIOB->BRR=GPIO_Pin_8;};
                    if (duty & ledduty [rowNum+8][colNum][1]) {GPIOB->BSRR=GPIO_Pin_9;}     else{GPIOB->BRR=GPIO_Pin_9;};
                    if (duty & ledduty [rowNum+8][colNum][2]) {GPIOB->BSRR=GPIO_Pin_10;}    else{GPIOB->BRR=GPIO_Pin_10;};

                    //sqğ taraf diyelim
                    if (duty & ledduty [rowNum+8][colNum+16][0]) {GPIOB->BSRR=GPIO_Pin_11;}    else{GPIOB->BRR=GPIO_Pin_11;};
                    if (duty & ledduty [rowNum+8][colNum+16][1]) {GPIOB->BSRR=GPIO_Pin_12;}    else{GPIOB->BRR=GPIO_Pin_12;};
                    if (duty & ledduty [rowNum+8][colNum+16][2]) {GPIOB->BSRR=GPIO_Pin_13;}    else{GPIOB->BRR=GPIO_Pin_13;};

                    GPIOB->BSRR=GPIO_Pin_14;    //CLK=1
                }
               
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=1
                __Nop();
                GPIOB->BSRR=GPIO_Pin_15;    //LATCH=0
            }
            //OE çıkışına donanımdan PWM basılacak..
            //PWM duty = base_duty_ON_peryod * duty
            TIM_X->CCR_X    = base_duty_ON_peryod * duty ;
            //2ms lik süreler boyunca farklı parlaklıklarda yanan yada tamamen sönen ledler renk oluşturacak..
        }
    }


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 04 Kasım 2014, 00:52:28
Hocam selamlar,

Mesajınıza ve verdiğiniz koda bakarak 74HC595'içi bir kod yazmaya çalıştım.
int main(void)
{
  Hardware_Configuration();    //Sistem ve Donanim Ayarlarini yap..
  LCD_Clear(Green);
  LCD_SetBackColor(Green);
  LCD_ShowString(0,0,"74HC595 Shift PWM");
  setOutMode(portD,0x0F00);

  LED_Duty[7]=255;
  LED_Duty[0]=1;

  while(1)
  {
 
  for(Duty_Count=0;Duty_Count<8;Duty_Count++)
  {
TIM3->CCR3=0;//PWM Disable..
PWM_Duty = 1 << Duty_Count;
for(Bit_Count=0;Bit_Count<8;Bit_Count++)//Seri Olarak data gönderiliyor.
         {
GPIOB->BRR=GPIO_Pin_9;//CLK=0;
if(PWM_Duty&LED_Duty[Bit_Count]){GPIOB->BSRR=GPIO_Pin_8;}else{GPIOB->BRR=GPIO_Pin_8;}
GPIOB->BSRR=GPIO_Pin_9;//CLK=1;
}
GPIOB->BSRR=GPIO_Pin_10;//Latch=1;
GPIOB->BRR=GPIO_Pin_10;//Latch=0;
TIM3->CCR3=PWM_Duty;//PWM Enable
delay_ms(2);
}
     
  }
     
}



Açıkçası düzgün çalışmadı. Şuanda Lojik analyser'im yanımda olmadığı için sebebini anlayamadım.
Görsel olarak incelersek
  LED_Duty[7]=255;   
  LED_Duty[0]=1;
7. kanalın Duty değerini 255, 0. kanalın Duty değerini 1 yaptım. Gerçekte çıkışlar Çıkışların parlakları arasında çok az ama çok çok az bir fark var. Normalde böyle olmaması gerektiğini düşünüyorum. Ama dün PWM'in çalıştığını doğrulamıştım. Frekans Yaklaşık 8Khz ve 8 bit çözünürlükte. Max duty 255 olarak ayarladım. Bunu gerekli olduğu taktirde yükseltebilirimde.

Probleme geri dönersek sizce neden kaynaklanabilir. Yukarıdaki kodlarda gözünüze çarpan bir terslik varmıdır?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 04 Kasım 2014, 14:01:27
Alıntı yapılan: Mucit23 - 14 Ekim 2014, 11:39:51
Hocam donanımsal spi ile olmuyor. Mcu da  6 adet spi olsa bile panelde tek clock girisi var. Bu yüzden soft spi şart. 

Zaten 74595 ile şuanda 100hz 8 kanal 8bit pwm çıkarıyorum.  Sıkıntı yok. Bunun sayısı artacak sadece. Oda henüz yeterince optimizasyon yapmadım. 


Siz bu pic leri araştırdınız mı spi çıkışlardan biri master olacak diğer spi çıkışları slave olacak böylece tek CLK ucu ile kontrol edilebilecek .Donanımsal gönderme işlemleri işi kolaylaştıracaktır . Bu bilgiyi de dikkate alın.
Bu yazınızı gözden kaçırmışım ..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 04 Kasım 2014, 14:06:31
Alıntı yapılan: bmutlu - 04 Kasım 2014, 14:01:27
Siz bu pic leri araştırdınız mı spi çıkışlardan biri master olacak diğer spi çıkışları slave olacak böylece tek CLK ucu ile kontrol edilebilecek .Donanımsal gönderme işlemleri işi kolaylaştıracaktır . Bu bilgiyi de dikkate alın.
Bu yazınızı gözden kaçırmışım ..

@bmutlu, O meseleyi biliyorum aslında Daha önce konuşulmuştu. Problem donanımsal spi ile olup olmayacağı değil! Elimizde hali hazırda olan mikrodenetleyicler var.

Farzedin RGB panel için bir kütüphane yazıyoruz. Bu kütüphane sadece harware spi ile çalışıyorsa ne kadar esnek olur? 6 adet donanımsal spi bulunduran mcu'ları bulup getirip öğrenmek zaten başı başına bir iş. Gerek yok...
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 04 Kasım 2014, 14:30:55
Aslında PWM işlemini direkt pin üzerinde değil RAM üzerinde işlem yapıp burada gönderilecek datayı hazırlamak gönderme işlemini Donanımsal veya DMA yöntemi ile göndermek onun için zaman ayırmamanız gerekir . Oraya da bir zaman harcanmaması düşüncesindeyim .
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bocek - 04 Kasım 2014, 15:46:08
@mucit, nette dolanırken bir şeylere rastladım belki işine yarar (ucu cevhere çıkıyor).

http://www.mikrocontroller.net/topic/346057#new (http://www.mikrocontroller.net/topic/346057#new)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 04 Kasım 2014, 18:44:45
Alıntı yapılan: Mucit23 - 04 Kasım 2014, 00:52:28
Probleme geri dönersek sizce neden kaynaklanabilir. Yukarıdaki kodlarda gözünüze çarpan bir terslik varmıdır?

Bir sürü nedeni olabilir hocam. Mesela Timer doğru kurulmamış olabilir. Yaptığınız 2ms lik bekleme ile timer-PWM senkron gitmiyordur vs.
Genel olarak mantık doğru ama.

Daha önceki örneklere göre timer bekleme veya delay kısmı bir dış döngüde olmuş. Burada hata vardı. Ama sizin örneğinizde satır döngüsü olmadığından bu sorun yok.


Yazmışken tam olarak yazıp test edeyim dedim.
Timer için prescaler seçerken min duty 1 birim, frekans için timer taşması 128 birim seçildi. Böylece duty değişkeni direk PWM duy si olarak yüklenebilir ve tam senkronize oldu.  Veri gönderilip latch için timer bekleniyor. Veri gönderme zamanı PWM frekansını bozmuyor. Logic analizör ile bakarsanız pwm bir önce gönderilen veriye ait diye hatırlatayım.
Elimde SR yokmuş. Eski kart vs. bir yerlerden  bulursam fiziksel sonucuna da bir bakmak lazım.
Sanırım 32F4disco kitiniz vardır. 

#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"
#include "stm32f4xx_exti.h"
#include "stm32f4xx_syscfg.h"
#include "stm32f4xx_tim.h"
#include "misc.h"
#include "stm32f4xx_sdio.h"


#include "stdio.h"


volatile uint8_t timerFlag;
uint8_t ledduty [16][32][3]; // 16 satir 32 sütun, 3 renk

   

uint8_t dutyCounter, duty, COMPARE;
uint8_t rowNum, colNum;



//  CPU frekansi 168Mhz
//  AHB frekansi 84 Mhz
//  APB frekansi 42 Mhz
// *********************************************************************************/

void InitBoard()
{
    volatile int i;
   
   
    NVIC_InitTypeDef NVIC_InitStructure;
    GPIO_InitTypeDef GPIO_Init_Struct;
//    EXTI_InitTypeDef EXTI_InitStructure;

    //CLOCK
    RCC->APB1ENR |= 0x0006002F;        //TIM2 TIM3 TIM4 TIM5 TIM7 USART2 USART 3 CLOCK
    RCC->APB2ENR |= 0x00004000;        //SYSCFG CLOCK

    RCC->AHB1ENR |= 0x0000001F;        //GPIO A- C-D CLOCK

//GPIO D OUTPUT 13-14-15
    GPIO_Init_Struct.GPIO_Pin = GPIO_Pin_13 | GPIO_Pin_14 | GPIO_Pin_15;
    GPIO_Init_Struct.GPIO_Mode = GPIO_Mode_OUT;   
    GPIO_Init_Struct.GPIO_OType= GPIO_OType_PP;
    GPIO_Init_Struct.GPIO_Speed= GPIO_Speed_100MHz;
    GPIO_Init_Struct.GPIO_PuPd=GPIO_PuPd_NOPULL;
    GPIO_Init(GPIOD,&GPIO_Init_Struct);   


//GPIO D AF 12
    GPIO_Init_Struct.GPIO_Pin = GPIO_Pin_12;
    GPIO_Init_Struct.GPIO_Mode = GPIO_Mode_AF;   
    GPIO_Init_Struct.GPIO_OType= GPIO_OType_PP;
    GPIO_Init_Struct.GPIO_Speed= GPIO_Speed_100MHz;
    GPIO_Init_Struct.GPIO_PuPd=GPIO_PuPd_NOPULL;
    GPIO_Init(GPIOD,&GPIO_Init_Struct);   


    GPIOD->AFR[1] = 0x00020000; //TIM4 CH1


//TIM4 4000KHZ
    TIM4->PSC             = 163;//84E6/164
    TIM4->ARR             = 128;//84E6/164/128 -> 4000khz   ARR 128 seçildi. Min duty 1 olacak.
    TIM4->DIER         = 0x00000001;

    TIM4->CCMR1         = 0x0060;;    //CH1 PWM  ENABLE
    TIM4->CCER         = 0x1111;


    TIM4->CCR1         = 0;
    TIM4->CR1             = 0x0001;   
   
    NVIC_InitStructure.NVIC_IRQChannel = TIM4_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_Init(&NVIC_InitStructure);

   
}

int main(void)
{

   
    volatile uint32_t i;

   

//        uint16_t base_duty_ON_peryod;
//        base_duty_ON_peryod  = 1;


    ledduty [0][0][0] = 32;
    ledduty [0][1][0] = 64;
    ledduty [0][2][0] = 96;
    ledduty [0][3][0] = 128;
    ledduty [0][4][0] = 160;
    ledduty [0][5][0] = 192;
    ledduty [0][6][0] = 224;
    ledduty [0][7][0] = 255;

    ledduty [0][0][0] = 1;
    ledduty [0][1][0] = 2;
    ledduty [0][2][0] = 4;
    ledduty [0][3][0] = 8;
    ledduty [0][4][0] = 16;
    ledduty [0][5][0] = 32;
    ledduty [0][6][0] = 64;
    ledduty [0][7][0] = 128;

    ledduty [0][0][0] = 1;
    ledduty [0][1][0] = 3;
    ledduty [0][2][0] = 7;
    ledduty [0][3][0] = 15;
    ledduty [0][4][0] = 31;
    ledduty [0][5][0] = 63;
    ledduty [0][6][0] = 127;
    ledduty [0][7][0] = 255;


    InitBoard();

    GPIOD->BSRRL |= 1<<13;
    GPIOD->BSRRL |= 1<<14;
    GPIOD->BSRRL |= 1<<15;

    TIM4->CCR1    = 64;
   
    for (i=0;i<20000000;i++);
   
    GPIOD->BSRRH |= 1<<13;
    GPIOD->BSRRH |= 1<<14;
    GPIOD->BSRRH |= 1<<15;


    TIM4->CCR1 = 0;

    for (i=0;i<20000000;i++);

        TIM4->CCR1    = 1;


    while (1)
    {
        for (rowNum = 0; rowNum <1; rowNum++ )
        {

                        GPIOD->BSRRH = GPIO_Pin_14;

                   
            for (dutyCounter = 0; dutyCounter<8; dutyCounter++)
            {
                            duty = 1 << dutyCounter;

                            for (colNum = 0; colNum <8; colNum++)
                            {
                                   
                                COMPARE = (duty & ledduty [rowNum][colNum][0]);
                               
                                if (COMPARE)
                                {
                                    GPIOD->BSRRL = GPIO_Pin_13;
                                }
                                else
                                {
                                    GPIOD->BSRRH = GPIO_Pin_13;
                                }                                   
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();
                                   

                                GPIOD->BSRRL = GPIO_Pin_14;
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();

                                GPIOD->BSRRH = GPIO_Pin_14;
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();

                                GPIOD->BSRRH = GPIO_Pin_13;
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();

                            }

                            while(timerFlag == 0);
                            timerFlag = 0;

                           
                            GPIOD->BSRRL = GPIO_Pin_15;
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();

                            GPIOD->BSRRH = GPIO_Pin_15;
                                __nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();

                            TIM4->CCR1    = duty;

            }
        }
    }
}
void TIM4_IRQHandler(void)
{

    timerFlag = 1;
    TIM4->SR     = 0x00000000;   

}


Alıntı yapılan: bmutlu - 04 Kasım 2014, 14:30:55
Aslında PWM işlemini direkt pin üzerinde değil RAM üzerinde işlem yapıp burada gönderilecek datayı hazırlamak gönderme işlemini Donanımsal veya DMA yöntemi ile göndermek onun için zaman ayırmamanız gerekir . Oraya da bir zaman harcanmaması düşüncesindeyim .
Burada ki sıkıntı 6 ayrı veri yi tek clock ile SPI a benzer şekilde aktarmak.  Tek tek pinler set edilecek olsa bile zaten performans yetmemesi gibi bir sıkıntı olmuyor. Ama donanıma yüklenmek konusunda aynı fikirdeyim. 6 pini paralel set edip tek seferde gönderilen 2 satıra ait 32 byte lık veriyi  dma ile göndermek paneli sürme ile ilgili max  işlemci yükünü  %1-2 lere indirir.

Alıntı yapılan: iyildirim - 02 Kasım 2014, 00:45:16
Sağ ve sol panellerin aynı satır ve sütünlarındaki 3 renk den 6 ledin 1 bitleri, bir sonraki sütunun 1 bitleri, ... şeklinde 6 data pinine karşılık 6 bitlik 32 byte'lık bir diziyi 2. ve diğer bitler  için tekrarlayıp satırı arttırıp 8 kere daha takrarlayıp şeklinde elde edilmiş bir dizimiz olduğunda 1 byte tı direk pine basmak tek seferde 6 bitinde set edilmesini sağlar. Paralel veri aktarımı ve clock işleri FSMC ile sağlanırsa 32 byte da bir yani 4Khz lik kesme ile row ve latch set edilebilir. Tabii lineer belleğimizi bu düzende bir bellek alanına kopyalayacak bir fonksiyon da gerekiyor.

Artı olarak led parlaklığının az olması konusu  için bir önceki mesajda anlatmaya çalıştığım yöntem için yapılması gereken OE pinini sürekli aktif yapıp 32 lik döngüyü çalıştıracağımız zamanı bir timer kesmesi ile belirlemek, 32 lik döngüyü start edecek timer kesmesinin taşma değerini 2 nin katları şeklinde hazırlanmış 6-8 elemanlı bir diziden okumak..

İster direkt ledlerin az yandığı 2 yöntem, ister en son anlatmaya çalıştığım yöntem için Timerde FSMC tetiklemek, FSMC kesmesinde satır ve latch set etmek sanırım ideal yöntem olur. Açıkçası aklıma donanımdan da yardım alınabilecek minimum işlem zamanı gerektiren  başka bir yöntem gelmiyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 04 Kasım 2014, 19:33:57
Hocam eger benim 74hc595 icin yazdığım kodda mantık doğru ise mesleyi anladığımı söyleyebilirim. Fakat sorunu çözemedim. 

Aslında yukarıda verdiğim kodda timer kullanmadım.  Main döngüsü içerisinde çalıştırıyordum. Kesme yerine döngü içerisinde 2ms lik gecikme yaptırdım. Belki sorun latch isleminden sonra pwm i acmamdan kaynaklaniyordur. Akşam lojik analyser ile ayrıntılı bir inceleme yapacağım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 05 Kasım 2014, 01:11:48
Hocam yok mantıktada bir terslik var. Lojik analyser ile inceledim öyle görünüyor.

İlk başta 2ms lik süre içerisinde pwm sinyalinin az uygulandığını gördüm. PWM sinyalini 16Khz ye çıkardım.

hocam bilgisayarınızda saleae logic analyserin yazılımı kurulu ise çıktıyı incelemeniz çok rahat olur. Sağ üst kısımda options menüsü altında open sessions diye bir seçenek var. Ona tıklayıp verdiğim dosyayı seçince doğrudan çıktılar ekranda olacak.
Aşağıdaki linkte yükledim dosyayı. İncelerseniz sevinirim.
https://yadi.sk/d/YPIBpBqOcVYMK

Benim gözlemlerimle şöyle bir durum var. HC595'in DATA girişli lojik 1 de bekliyorken OE den uyguladığımız PWM çıkışa yansımıyor her nedense. Bizim döngümüzdede gönderilen son bit lojik 1 ise data girişi bir sonraki döngüye kadar hep lojik 1 de kalıyor. Çalışmada ciddi anlamda terslik var.
Ben HC595'in datasheetini biraz inceleyeyim.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 05 Kasım 2014, 03:01:21
Logic analizör çıktısına baktım.
Bu çıktı en son verdiğiniz koda mı ait.?
Öyleyse analizör çıktısına ve son bitin high da kalması durumuna göre  led_duty dizisinin 0. elemanı  255 7 elemanı da 128 sanırım. En son verdiğiniz koda göre tabii.

Son bitten sonra data pininin High da kalması durumu için latch dan önce data pinini low a çekebilirsiniz. son verdiğim örnek te olduğu gibi.

Dediğiniz gibi 0 kanala basılan veri ya  dediğiniz gibi çıkışa yansımıyor yada bağlantılarda bir hata var yada HC595CH0 diye isimlendirdiğiniz kanalda 7 bite bastığınız veri görüldüğüne göre isimlendirmede hata var. Sizin örneğe göre Bit_Count döngüsünü 7 den 0 a azalan şekilde   kurarsanız düzelir sanırım.

HC595CH7 diye isimlendirilen kanal da direkt PWM i görebildiğime göre ve döngü yapısı bu şekilde iken 7 kanalda aslında 0 kanala  bastığınız veri görüneceğine göre burada sorun yok.

Latch pinini on-off dan önce data pinini resetleyip,  Bit_count döngüsünü de 7den 0 a  azalan yapıda yaparsanız  istediğiniz şekilde  çalışacak diyorum.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 05 Kasım 2014, 10:31:44
Hocam gerekli duzenlemeler akşam yapacağım.  Ben dikkat etmedim ama görünüşe göre sadece veri ters gidiyor. Döngüyü tersine çalıştırmak gerekiyor. Bunu hallederim. Benim aklıma min parlaklık konusu takılıyor.  Akşam olmadı bi resimde ekleyeyim.  Parlaklık konusunda logic çıktıya bakarak yorum yapabiliyormusunuz?

Birde şöyle bir durum var. OE girişi 0 iken çıkışlar aktif oluyor. Dolayısıyla verdiğimiz PWM sinyalinin tam tersi çıkışta görünüyor. Bunuda dikkate almak lazım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 05 Kasım 2014, 13:32:18
Arkadaşlar yok, bu dediğiniz algoritmada ciddi anlamda sıkıntılar var. Az önce birkaç test daha yaptım. Ama sonuç alamıyorum.

Yaptığım işlemi uzun uzadıya anlatayım. Mantık hatası var ise belli olur.

8 adet Duty değişkenimiz var. Bu değişkenleri LED_Duty[8] diye tanımlamışım.

Yaptığımız işlem sırasıyla aşağıdaki gibi.

İlk önce 8 adet LED_Duty değişkenimizin 0 bitinlerini Shift registere gönderiyoruz. Bu işlem sonucunda LED_Duty[0] değişkeninin 0. biti, SR nin 0. bitinde olurken, LED_Duty[7] değişkenimizin 0. biti, SR nin 7. bitine gönderilmiş oluyor.
Burada sıkıntı yok. Bundan sonra PWM değerini yüklememiz gerekiyor. En düşük değerli bitler için 1, en yüksek değerli bitler için pwm değerini 128 yapmak gerekiyor. 0. Bitleri gönderdiğimiz için PWM değerini 1 yapıyoruz.

Daha sonra yine LED_Duty değişkenlerinin her birinin 1. bitlerini SR lere gönderiyoruz. Yaptığımız işlem sonucunda LED_Duty[0] değişkeninin 0. biti, SR nin 0. bitinde olurken, LED_Duty[7] değişkenimizin 0. biti, SR nin 7. bitine gönderilmiş oluyor. Ardından Duty değerini 2 yapıyoruz.

Bu şekilde bütün bitleri sırayla gönderiyoruz. En son LED_Duty değişkenlerinin sırayla 7. bitlerini gönderiyoruz ve latch işleminden sonra Duty değerini 128 yapıyoruz.Bu durumda PWM duty değeri max. oluyor.

kurduğum algoritma yaklaşık olarak böyle çalışıyor.
En son verdiğim kodlarda ufak tefek değişiklikler yaptım. LED_Duty[7] nin SR tarafında 0. bitte görülmesi olayını döngüyü tersine çevirerek düzelttim.
Kodun en son hali aşağıdaki gibidir. İnterrupt felan kullanmıyorum. Herşey main döngüsü içerisinde çalışıyor.


  while(1)
  {
 
  for(Duty_Count=0;Duty_Count<8;Duty_Count++)
{
TIM3->CCR3=0;//PWM Disable..
         PWM_Duty = 1 << Duty_Count;
for(Bit_Count=7;Bit_Count>=0;Bit_Count--)//Seri Olarak data gönderiliyor.
             {
  GPIOB->BRR=GPIO_Pin_9;//CLK=0;
      if(PWM_Duty&LED_Duty[Bit_Count]){GPIOB->BSRR=GPIO_Pin_8;}else{GPIOB->BRR=GPIO_Pin_8;}
      GPIOB->BSRR=GPIO_Pin_9;//CLK=1;
}
GPIOB->BRR=GPIO_Pin_8;GPIOB->BRR=GPIO_Pin_9; //Karisiklik olmamasi için DATA ve CLK pinlerini 0 yap1yoruz.
GPIOB->BSRR=GPIO_Pin_10;//Latch=1;
__nop();__nop();__nop();__nop();__nop();__nop(); //LATCH islemi çok hizli oldugu için lojik analyser yakalayamiyordu. Araya delay koydum.
         GPIOB->BRR=GPIO_Pin_10;//Latch=0;
             TIM3->CCR3=PWM_Duty;//PWM Enable
delay_ms(2);
}
     
  }


Kodlar yukarıdaki gibi.

Bu durumdayken duty değerlerini aşağıdaki gibi yaptım. Sonucu gözlemledim.
  LED_Duty[7]=1;   
  LED_Duty[0]=128;

Şimdi Yukarıdaki kodlarda en dıştaki döngü yani Duty_Count 0 iken olan olaylar şöyle, Bu değer 0 iken Bütün LED_Duty değişkenlerini 0. bitleri SR ye gönderiliyordu.

Daha önce PWM çıkışı tersleniyor diye bahsetmiştim. Çünkü OE girişi lojik 0 dayken çıkışlar aktif. Dolayısıyla biz bütün LED_Duty değişkenlerinin 0. bitlerini gönderiyoruz ve PWM değerini 1 yapıyorduk ya işte tam o sırada bizim OE ye uyguladığımız PWM değeri 1 olmasına rağmen çıkışta max. PWM görülüyor. Dolayısıyla LED_Duty[7] nin 0. biti 1 olduğu için SR nin 7. biti max. parlaklıkta yanıyor.

Ardından Duty_Count değeri 7 olduğunda ise LED_Duty değişkenlerinin 7. bitleri SR ye gönderiliyor.

LED_Duty[0] değişkeninin değerini 128 yaptım. Bu durumdayken bütün LED_Duty değişkenlerinin 7 bitleri SR ye gönderilir. Ardından PWM duty değeri max değer olan 128 değerini alır. Fakat OE girişi PWM sinyalini terslediği için SR nin 0. biti min. parlaklıkta yanar. Öylede oluyor. SR nin 0. bitindeki led  o kadar düşük yanıyor ki LEDin merkezine baktığın zaman ancak görebiliyorsun. Sönecek olan bir mum gibi titreye titreye yanıyor.  :)

Herşey iyi güzel terste olsa min.ve max. parlaklığı alıyoruz. Fakat bu algoritmanın bana göre ters bir tarafı var. Örneğin LED_Duty[0] değerini 127 yapalım. Bu durumdayken LED_Duty[0] değişkeninin içeriği binary olarak 01111111 olur. Bu durumdayken ilk 7 bit lojik 1 olduğu için sürekli SR ye gönderilir ve PWM değerlerinden 1-2-4-8-16-32-ve 64 değerlerini çıkışa yansıtır.

Gerçekte bu kodu deniyorum LED_Duty[0] değeri 127 iken SR nin 0. bitindeki led bayağı parlak yanıyor. LED_Duty[0] değerinin 128 yapıyorum. Yanabilecek en düşük parlaklıkta yanıyor.

Böyle tezatlıklar var işin içinde. Dolayısıyla sistemi henüz tam manasıyla çözebilmiş değilim. Açıkçası LED_Duty[0] değişkenini 0-255 arası aldığı değerleri nasıl 8 kademede yani LEDlere 8 farklı parlaklık uygulayarak yansıtabileceğiz anlamış değilim.

En son yaptığım uygulamada yani   LED_Duty[7]=1, LED_Duty[0]=128 iken Lojik analyser'dan aldığım çıktılar aşağıdaki linkte
https://yadi.sk/d/tR5d-8k8cW9kG
Saleae'nin Programı bilgisayarında kurulu olan herkes açıp bakabilir.

Hasan hocam, iyildirim hocam , Yanlış yaptığım veya yanlış düşündüğüm nokta neresi. Dediğim gibi Bu 74HC595'de bu işi düzgün yapamazsam panelde hiçbir şey yapamam.

İlgilenenlere Teşekkürler.






Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 05 Kasım 2014, 14:37:36
Alıntı yapılan: Mucit23 - 05 Kasım 2014, 13:32:18
Arkadaşlar yok, bu dediğiniz algoritmada ciddi anlamda sıkıntılar var. Az önce birkaç test daha yaptım. Ama sonuç alamıyorum.

......................

Gerçekte bu kodu deniyorum LED_Duty[0] değeri 127 iken SR nin 0. bitindeki led bayağı parlak yanıyor. LED_Duty[0] değerinin 128 yapıyorum. Yanabilecek en düşük parlaklıkta yanıyor.

Böyle tezatlıklar var işin içinde. Dolayısıyla sistemi henüz tam manasıyla çözebilmiş değilim. Açıkçası LED_Duty[0] değişkenini 0-255 arası aldığı değerleri nasıl 8 kademede yani LEDlere 8 farklı parlaklık uygulayarak yansıtabileceğiz anlamış değilim.

Hocam PWM polaritesini terlememişsiniz.
Duty 128 iken PWM çıkısı buna uygun ama SR çıkışına bakarsanız ancak PWM in off zamanı kadar yanabiliyor ledler.. 127 de parlak yanmasının nedeni de aynı. 

TIM3->CCR3=PWM_Duty;//PWM Enable       
satırını
TIM3->CCR3=129-PWM_Duty;//PWM Enable
şeklinde değiştirip denermisiniz.  Yada timer-OC modülüne PWM i ters polarite de istediğinizi de söyleyebilirsiniz.
32F103 mü kullanıyorsunuz?.
Bu hatanın dışında, verdiğiniz bu duty değerleri ile bakılınca çıktıda herşey algoritma ile uyumlu görünüyor. Led parlaklıklarının farklılaşmasını sizde gözlemişsiniz. Algoritmada, mantıkta bir sorun yok hocam.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 05 Kasım 2014, 15:02:23
Alıntı yapılan: bocek - 04 Kasım 2014, 15:46:08
@mucit, nette dolanırken bir şeylere rastladım belki işine yarar (ucu cevhere çıkıyor).

http://www.mikrocontroller.net/topic/346057#new (http://www.mikrocontroller.net/topic/346057#new)


Bence bu mesajdaki link arada kaynamasın,
detaylı bakmadım ama hazır örnek var stm32 ile ve 24bit rgb.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 05 Kasım 2014, 16:00:59
Hocam şimdi okuldayım, Akşam deneyeceğim. Parlaklıkta lineer bir artış sağlayabilirsem zaten iş bitmiş olur. :D

@Ramu o linkide inceledim. Adam M4 ile yapmış. OE den pwm uyguladığına göre Mantık olarakda şuanda uğraştığımız yöntem ile yapmış. Aslında F4 serisiyle uğraşsam 1. yöntem bile iş görebilirdi. Ama F4 kullanamam. Bu işi STM32F103 ile yapmam lazım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 05 Kasım 2014, 23:16:53
iyildirim hocam, Gerekli düzenlemeyi yaptım. Şuanda PWM tersleme sorunu yok. Kanallarda ters değil. Birkaç problem kaldı onlarıda halledersem ilerlemeye devam edebilirim herhalde.

Şuanda en büyük sorun Duty seviyesini aşağı çektikçe titreme yapması. LED çok sönük bir şekilde yanıyor. Bu sırada titreme yapıyor. PWM frekansını arttırıp bir deneyeyim dedim çözüm olmadı. Bu neden kaynaklanır?

Diğer bir sorun ise Duty değeri 128'den büyük olsa bile parlaklık artmıyor. Daha önce max. %50 parlaklık alınır gibi bir ifade geçmişti. Ozaman bu durummu kastedilmişti? Bunun sebebi nedir?

Ben internetteki videoları izliyorum ve hala bu işi adam akıllı beceremediğimi düşünüyorum.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 06 Kasım 2014, 00:29:06
Titremenin nedeni şu andaki sürme frekansının düşüklüğü olabilir.
Kodun bu haliyle 2ms-8 bit için 16 ms toplam zamandan 62.5 hz tazeleme frekansı oluyor.
Panel için konuşursak 2ms de  aslında 8 satır için 8 kere güncelleme yapıyoruz. Yani 1 bit için 250 us kalıyor. Delay kısmını 250usec yapıp denerseniz belki faydası olur. Gerçi tek bir ledin yanma frekansı değişmeyecek panel için konuşursak. Ama titreme için fikir verir. Yani panel de daha da kötü olabilir, özellikle parlaklık konusunda.

Parlaklık konusunda ise PWM olmaksınız elde edilecek parlaklığın 1/4 elde edilebilir ancak. 8 bitlik çevrimde toplam süre 16ms,  Duty ON  süresi ise max 4 ms.
Bi bakın olmazsa her bir bit için 2ms değil, bit değerine uygun şekilde 2 nin katları şeklinde süreleri tanımlamak gibi birşeyler yapma yoluna gidilebilir.
 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 06 Kasım 2014, 04:24:45
@Mucit23 hocam, delay(2ms) yerine delay(16us * duty)  yapıp OE pinini sürekli aktif ederseniz parlaklıkta ve titremede bir fark oluyor mu? Bi denermisiniz. ?

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 06 Kasım 2014, 11:14:44
Hocam denedim, ama sadece işler biraz hızlandı. Değişen hiç bir şey olmadı. Yaptığım tespitlere göre genellikle Duty %10'dan sonra titreme olmuyor.

Parlaklık konusu aklıma takıldı, Şöyle bir ifadeniz var.
Alıntı YapParlaklık konusunda ise PWM olmaksınız elde edilecek parlaklığın 1/4 elde edilebilir ancak.
Bu OE'ye hiç PWM uygulamıyorken(Lojik 0 iken) Led'in verebileceği max. Parlaklığın 1/4'ü alınır şeklinde algıladım. Dolayısıyla Duty Değerleri %128'den büyük olsa bile parlaklık açısından birşey ifade etmeyecek.

Ben birde ilk yöntemde çözünürlüğü 5 bit yapmayı deneyeceğim. Hatta 4 bit bile olur. O yöntemin çalışması nedense bana daha mantıklı geliyor. Daha problemsiz çalışıyor.

Herneyse, Şu işlemleri Döngüden kurtarıp timer üzerine çalışacak şekilde ayarlayayım. Sonra döngüden bağımsız olarak parlaklıklar ile oynayıp ledlerdeki değişimin videosunu çekeceğim. Sonra sonuca göre tekrar yorum yapalım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 06 Kasım 2014, 12:09:12
Beklemeyi duty ile orantılı yapıp OE yi sürekli aktif yapmak birinci yöntem zaten. Ledlerin yanma zamanlarını ilgili bitin değerine göre ayarlamış oluyoruz.
4096 + 32f4 ile denediğimde parlaklıkta ciddi artış oldu. Satır lar için 8 lik döngüyü de eklediğimde parlaklık azalsa bile tek satır varmış gibi OE ye PWM uygulamaktan daha parlak.
Bekleme yerine timer kullandım. Tek yaptığım duty değerini timx->CCR1 yerine timx->ARR registerine yüklemek. Ki bu durumda 8 bitlik döngünün toplam süresi 500us oluyor. 62,5 yerine 4 katı tazeleme olmuş oluyor yani. Bu yüzden hiç titreme yok. Yine de büyük ihtimalle 8 bit için düşük değerleri bitleri zamanında basamıyordur mcu.
OE ye pwm uyguladığımız yöntemde de 2ms beklemeyi düşürünce titreme olmaması gerekli. Ama parlaklık için yapılacak bir şey yok.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 06 Kasım 2014, 12:45:46
Alıntı YapBekleme yerine timer kullandım. Tek yaptığım duty değerini timx->CCR1 yerine timx->ARR registerine yüklemek. Ki bu durumda 8 bitlik döngünün toplam süresi 500us oluyor. 62,5 yerine 4 katı tazeleme olmuş oluyor yani. Bu yüzden hiç titreme yok. Yine de büyük ihtimalle 8 bit için düşük değerleri bitleri zamanında basamıyordur mcu.
OE ye pwm uyguladığımız yöntemde de 2ms beklemeyi düşürünce titreme olmaması gerekli. Ama parlaklık için yapılacak bir şey yok.

Hocam peki Burada PWM kullanmadınızmı, Yani OE'den PWM uygulamadınızmı?

Birde ben OE'den PWM uygulanarak PWM çoğullama örneği bulamadım hiç. Bu yöntemin internette yapılmış bir örneği varmı? 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bocek - 06 Kasım 2014, 16:30:38
@mucit Binary Coded Modulation-BCM (diğer adıyla Bit Angle Modulation-BAM) diye bir şey varmış. Şurayı bir incele istersen.

http://www.batsocks.co.uk/readme/art_bcm_1.htm (http://www.batsocks.co.uk/readme/art_bcm_1.htm)


mesaj birleştirme:: 06 Kasım 2014, 16:55:13

bir de bu var:
https://www.pjrc.com/teensy/td_libs_ShiftPWM.html (https://www.pjrc.com/teensy/td_libs_ShiftPWM.html)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 06 Kasım 2014, 23:55:22
Alıntı yapılan: Mucit23 - 06 Kasım 2014, 12:45:46
Hocam peki Burada PWM kullanmadınızmı, Yani OE'den PWM uygulamadınızmı?

Birde ben OE'den PWM uygulanarak PWM çoğullama örneği bulamadım hiç. Bu yöntemin internette yapılmış bir örneği varmı? 

Duty peryoduna PWM peryodundan daha büyük değer verdiğim için PWM uygulanmadı. Ama uygulanabilirde. Master parlaklık kontolü gibi.

Örnek de, yöntemin adı da varmış zaten. Herşey keşfedildi Truman! durumu..
@bocek hocamın verdiği ilk linkte 3. sayfa  konuştuğumuz en son durumu iyi anlatıyor.

Deneme yaparken kutudan birde ortak anod RGB led çıktı. Gerekli düzenleme leri yapıp test edince, özellikle yeşil renk çok baskın göründü. @bocek hocamın verdiği linklerde de bundan da bahsedilmiş. Kendi adıma her bir rengin dirençleri ile oynamak yeterli olur diye düşünüyorum, ama panel de bu olanak olmayabilir.

Bir diğer konu ben testleri 32f4 ile yaptım. 32f4 bu işe yetsede F103, 24 bit için yeterli gelmeyebilir. F103 de 24 bit olsun durumunda karşılaştırma işlerine hiç girmeden veriyi paralel basılabilecek şekile getirmek aklıma gelen tek yok. 6 bit-pin test edilmeden tek clockda basılabilirse F103, 24 bit için fazla fazla yeter.  Bir de donanıma yüklenilirse tadından yenmez. Zaten hazırı olan bir şey için bu kadar konuştuktan sonra yapılmışı uygulamakla yetinmemeli derim.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 07 Kasım 2014, 01:51:02
Galiba Arduino kütüphanelerindede Bit Angle Modulation denen yöntem kullanılmış. Çünkü oradaki kodlarıda incelediğimde her seferinde Tim preload değerini hesaplıyordu. Bu gözüme çarpmıştı açıkçası.

O linkte 3. sayfada bayağı ayrıntılı bir şekilde anlatılmış. Mantığı az çok aklıma yattı. Fakat çoklu kanallarda nasıl uygulanacağını ve anlayamadım.

Birde şunu merak ettim.Aşağıdaki linkteki mesajımda bir örnek yapmıştım. Çalışması çok iyiydi.
https://www.picproje.org/index.php/topic,55627.msg428099.html#msg428099 (https://www.picproje.org/index.php/topic,55627.msg428099.html#msg428099)
Yaptığım işi kısaca açıklamak gerekirse 8Bit PWM sinyali üretmek için 0-255 arası sayan bir döngü kuruyoruz. Sonra döngü değeri ile duty değerini karşılaştırıp döngü değeri duty değerinden küçük olduğu sürece ilgili pine 1, döngü>=duty olduktan sonra ilgili pine 0 yolluyorduk. 8Bit için bu işlemi 255 kere, 6 bit içinde 64 kere tekrarlamak gerekiyor. Bu şekilde Shift registerden pwm üretmiştim.

Şimdi bu yöntemin çalışması ile @böcek in verdiği linkteki anlatılan yöntemde performans açısından bir fark varmı. Oradada yapılan işlem doğrudan gönderilecek olan duty değerlerinin bit yada basamak değerinde tick kadar 0 yada 1 göndermek değilmi?

STM32F4 kullanmak istemiyorum ama performanstan dolayı sürekli elim kayıyor. PWM uygulama işinde ne yaptıysam titremeyi önleyemedim. Pek aklıma yatmadı o iş.

Aklımda STM32F4 ile 1. yöntem yani yukarıda anlattığım yöntem üzerinde çalışma yapmak var şuanda. 8 bit beklentim zaten yok olursa 6 bit yapabilirsem mükemmel olur. Optimizasyonlar üzerinde çalışmalıyım. 

Alıntı YapZaten hazırı olan bir şey için bu kadar konuştuktan sonra yapılmışı uygulamakla yetinmemeli derim.
Beni kamçılayanda bu zaten :)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 07 Kasım 2014, 02:32:38
İki yöntem arasında fark var,
ETE bundan bahsetmiş,
Alıntı yapılan: ete link=http://etepic.com/index.php/topic,723.msg7535.html#msg7535
.
.
.
Frekansı 100 Hz olan bir sinyalde peryot başına 256 kesme (0-255) gerekmektedir. Bu durumda 1 sn de 256*100=25.600 kesme ile bu iş helledilebilmektedir. Gerçekten kesme sayısı çok fazla. Bu kadar kesme ile sistemde göz kırpışmaların olmaması imkansız hale gelmektedir.
.
.
.
Bu sistemin asıl avantajı bir peryotta 8 kesme ile halledilebilmesidir. Dolayısıyla 100 hzlik sinyal için toplm 800 kesme gerekmektedir. 25600'e karşılık 800 kesme epeyce büyük bir fark ve avantaj.
Sonuç olarak çoklu PWM çıkışlı sistemlerde kesin olarak BAM sisteminin kullanılması büyük avantaj sağlamaktadır.
Ete


Led pwm işinde diğer mesajlardaki linkdede bahsedildiği gibi bazı sıkıntılar var,
misal eğer pwm frekansı belli bir frekansın üzerine çıkarsa
duty oranı değiştirilse dahi ledin parlaklığında bir değişim gözlenmez;
yani atıyorum
1MHz %10 duty veya
2MHz %90 duty
uygulanan iki ledde aynı parlaklıkta görülür.

Diğer problem duty oranı ile insan gözünün parlaklık algısı lineer değil,
yani %25 duty %25 parlaklıkda görünen led
%50 duty %50 parlaklıkda görünen led
anlamına gelmiyor,
linkde gama düzeltmesi diye bahsetmiş bundan.

BAM ile ilgili güzel Türkçe bilgi ve örnek
ETE hocanın hazırladığı var;
şu konuda ilgili linkleri vermiş ETE hoca;
https://www.picproje.org/index.php/topic,51040.msg385114.html#msg385114 (https://www.picproje.org/index.php/topic,51040.msg385114.html#msg385114)

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 07 Kasım 2014, 11:01:42
Mibam denen yöntemi öğrenmem lazım 8 bit pwm de 1 periyot için 256 yerine 8 kesme yetiyormuş.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 07 Kasım 2014, 21:16:11

(http://s8.postimg.cc/n704j3wtt/bcm_2.jpg) (http://postimg.cc/image/n704j3wtt/)

(http://s8.postimg.cc/55gzlb2sx/images.jpg) (http://postimg.cc/image/55gzlb2sx/)


Olay resimlerde gayet iyi anlatılmış .Bit in kuveti şeklinde zaman ile oynanacak ama 8 bitin toplam süresi sabit kalıyor.
Ekranin taramasi 50Hz ve PWM i de 8bit olsun ve tarama 1/8 ve sütun sayisi 32 ise buna göre minimum data öteleme hizi -> 50 * 256 * 8 * 32 =  3276800 Hz
daga önce verdiğim deger;
Ekranin taramasi 50Hz ve PWM i de 8bit olsun ve tarama 1/8 ve sütun sayisi 32 ise buna göre minimum data öteleme hizi -> 50 * 8 * 8 * 32 =  102400 Hz sürme haline dönüşür.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 08 Kasım 2014, 00:06:29
Bit Angle Modulation meselesini anladım ama burada süre ayarlama işini anlayamadım.

Beni sıkıntıya sokan şey 2ms içerisinde bu işlemlerin halledilmiş olması gerekmesi. Bunun yüzünden kesmeyi nasıl kullanacağımı bir türlü hesaplayamıyorum. Bu konuda ufakta olsa bir fikri olan varmı? 

mesaj birleştirme:: 08 Kasım 2014, 00:58:25

Main Döngüsü içerisinde Bit Angle modulation ile ilgili ilk denememi yaptım. Sonuç gayet iyi.
Yazdığım kodlar aşağıdaki gibi
int main(void)
{
Hardware_Configuration();    //Sistem ve Donanim Ayarlarini yap..
    LCD_Clear(Green);
LCD_SetBackColor(Green);
LCD_ShowString(0,0,"74HC595 Shift PWM");
setOutMode(portD,0x0F00);
Duty[0]=1;
Duty[1]=5;
Duty[2]=10;
Duty[3]=50;
Duty[4]=100;
Duty[5]=150;
Duty[6]=200;
Duty[7]=255;

while(1)
    {
for(Duty_Count=0;Duty_Count<8;Duty_Count++)
{
for(Bit_Count=0;Bit_Count<8;Bit_Count++)
{
  if(Duty[Bit_Count] & (1<<Duty_Count))
                {
  temp|= (1<<Bit_Count);
}
else
{
  temp&= ~(1 << Bit_Count);
}
}


  for(Bit_Count=0;Bit_Count<8;Bit_Count++)
  {
    GPIOB->BRR=GPIO_Pin_9;//CLK=0;
    if(temp&(128>>Bit_Count)){GPIOB->BSRR=GPIO_Pin_8;}else{GPIOB->BRR=GPIO_Pin_8;}
    GPIOB->BSRR=GPIO_Pin_9;//CLK=1;
  }
GPIOB->BSRR=GPIO_Pin_10;//Latch=1;
__nop();__nop();__nop();__nop();__nop();__nop();
       GPIOB->BRR=GPIO_Pin_10;//Latch=0;
  delay_us(1<<Duty_Count);
  }
  }
}


Kesmeninde periyodu sürekli değişken olması gerekiyor. Yani kesme eşit aralıklarla oluşmayacak. delay_us(1<<Duty_Count);

Yukarıdaki kodlarda en dış döngünün bitiş süresi yani 1 peryodun oluşma süresi yaklaşık 315uS civarı.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 08 Kasım 2014, 01:51:23
Alıntı yapılan: Mucit23 - 08 Kasım 2014, 00:06:29
Bit Angle Modulation meselesini anladım ama burada süre ayarlama işini anlayamadım.

Beni sıkıntıya sokan şey 2ms içerisinde bu işlemlerin halledilmiş olması gerekmesi. Bunun yüzünden kesmeyi nasıl kullanacağımı bir türlü hesaplayamıyorum. Bu konuda ufakta olsa bir fikri olan varmı? 
Hocam 2ms içerisinde bu işlemler halledilemiyor da olabilir. Süre hesaplaması vs. konusu üzerinde yeterince yazıldı.  Açıkçası nereye takıldığınızı  anlayabildiğimi söyleyemem.

bam-mibam denen örneklerde 100 hz de 16-32-64 led vs sürülmüş. Örneklerde Mhz başına 1 led gibi performansla ilgili söylemler de var. Burada 8 bitlik and shift vs. işlemler ile uğraştığınız için kullandığınız mcu nun daha yetenekli olması vs. farketmeyecek. Soru 1536 ledin titremeden, parlaklıktan ödün vermeden nasıl sürüleceği. 

Benim görüşüm 6 ayrı data hattını tek tek sürerek 24 bitlik çözünürlüğe 72Mhz F103 ile ulaşılamayacağı şeklinde.
Nedeni süre ile ilgili..
Tazeleme oranı ve aynı anda 8 satır sürüldüğünden 2ms süreye ulaşmıştık.
OE ye PWM uygulanan ve 2ms nin 8 eşit süreye bölündüğü yöntemde yöntemde eşit süreler boyunca 2 nin kuvvetleri şeklinde farklı duty oranlı donanımsal PWM i OE üzerinden uyguladığımız için 24 bit renk elde edebiliyoruz.
Eşit sürelerimiz 2ms/8 den 250 us. Ve 250 us içerisinde 6x32 bit aktarılabiliyor. Burada sıkıntı yok. Ama parlaklık konusunda sorunlu ve  titreme olabiliyor..

En son konuştuğumuz Bam denen yöntem de ise 2ms yi 256 ya bölüyoruz. 2048 us dersek min süre 8 us oluyor. En düşük değerli bite karşılık ledler 8 usec yanabilecek.
Ama 8 us içerisinde 32 kere ayrı ayrı 6 data hattına ne basılacağının hesabında sıkıntı var.
8 us / 32 / 6 dan yaklaşık 42nano sec çıkar. Buda 72 Mhz lik işlemcinizde sadece 3 clock eder. Sıkıntı burada. Veriyi önden aktartarayım, latch de bekleteyim vs. gibi yöntemler de 24 bit için bunu kurtarmaz. Bir sonraki bitin süresinden çalmış olursunuz. Süreyi çaldığınız bit 7. bit olursa belki 7.bit bunu sorun etmez ama 2. bitin bozuk çalacağından eminim.   :)   Belki de düşük değerli bite ait veriyi zamanında gönderememeyi çok dert etmemek gerek..
24 bitten vazgeçip, 18 bite razı olsanız bile read-modify-write + clock işlemi için 12 clockluk zamanınız olacak. Yani F103 ile bu yöntemle max 18 bit ancak basılabilir.
Bu sıkıntı sadece en düşük değerli 1 bite ait veriyi gönderirken sözkonusu. Daha yüksek değerli bitlerde süre de daha uzun olduğundan veri basmaya süre yetmemesi gibi bir şey olmaz.

Mibam denen yöntemde ise iki kat daha fazla veri göndermeniz gerekir. 32 sütün için 6 bitlik verileri bit değerine göre bir ters bir düz basıyorsunuz. Önce bitcount artan şekilde hemen ardından azalan şekilde. Adına uygun,  aynalanmış şekilde 7. biti ortaya almış ve parlama şiddetini de peryod içerisinde ortalamış, eşit dağıtmış oluyorsunuz.
1536 led için uygulanabilir mi bilmem.  :)   Tazeleme frekansı ikiye katlanacağından 18 bit de 15 bite indirmek gerekebilir.

Veriyi paralel olarak basmaya olanak verecek bir bellek düzeni kurmak ve hatta donanımsal paralel port kullanılabilir demiştim.
Yazılımsal olarak da yapsak 8 us de sadece 32 kere 6 bitlik veri paralel  basılacağından 8us/32 den 250ns çıkar. Bu da 18 clock demektir ki bir portun 6 bitini read -modify-write + clock için yeterlidir.

Ekteki kod bahsettiğim şekilde veriyi paralel basmanıza olanak sağlayacak duty değerlerini ayrı bir diziye atıyor. Dizilerin ne şekilde tanımlandığı kod içerisinde var.
Kodu PMP modülü olan bir pic  için simüle ettim. Sadece 4 khz lik timer kesmesinde DMA tetiklemek yeterli olacak gibi görünüyor. Ama F103 de sanırım FSMC yok ama veri direkt GPIO-> ODR portuna basılabilir.
Kodun F103 de yaklaşık olarak 1.5-2 ms gibi çalışma süresi olur diye tahmin ediyorum. Ekran verisini güncelleme hızına negatif bir etkisi olmaz.
Ekran verisinde güncellendikten sonra 1 kez çalışması yeterli.


//                 16 satır, 32 sütun, 3 renk,   toplam 1536 byte
unsigned char ledduty [16][32][3];

//                8 satır, 8 bit level, 6 bitlik  32 sütun,  toplam 2048 byte
unsigned char panelBuf[8][8][32];

//volatile
unsigned char dutyCounter;
unsigned char rowNum, colNum;


void convert32x6bit ()
{

    rowNum = 0;
    colNum = 0;
       
    dutyCounter = 0;
   
    rowNum = 0;
    colNum = 0;

    //test verisi
    ledduty [0][0][0] = 1;
    ledduty [0][0][1] = 2;
    ledduty [0][0][2] = 4;

    ledduty [0][1][0] = 8;
    ledduty [0][1][1] = 16;
    ledduty [0][1][2] = 32;

    ledduty [0][2][0] = 64;
    ledduty [0][2][1] = 128;
    ledduty [0][2][2] = 255;


    ledduty [0][16][0] = 1;
    ledduty [0][16][1] = 2;
    ledduty [0][16][2] = 4;

    ledduty [0][17][0] = 8;
    ledduty [0][17][1] = 16;
    ledduty [0][17][2] = 32;

    ledduty [0][18][0] = 64;
    ledduty [0][18][1] = 128;
    ledduty [0][18][2] = 255;



    ledduty [8][0][0] = 1;
    ledduty [8][0][1] = 2;
    ledduty [8][0][2] = 4;
   
    ledduty [8][1][0] = 8;
    ledduty [8][1][1] = 16;
    ledduty [8][1][2] = 32;

    ledduty [8][2][0] = 64;
    ledduty [8][2][1] = 128;
    ledduty [8][2][2] = 255;
   

    ledduty [8][16][0] = 1;
    ledduty [8][16][1] = 2;
    ledduty [8][16][2] = 4;
   
    ledduty [8][17][0] = 8;
    ledduty [8][17][1] = 16;
    ledduty [8][17][2] = 32;

    ledduty [8][18][0] = 64;
    ledduty [8][18][1] = 128;
    ledduty [8][18][2] = 255;

unsigned char rowNdx, bufDuty, duty;

//                 16 satır 3 renk 32 sütun
//unsigned char ledduty [16][32][3];

//            8 satır,    8 bit level , satırda  32 byte , 6 bit
//unsigned char panelBuf[8][8][32];

    for (rowNum = 0; rowNum <8; rowNum ++)
    {
        for (dutyCounter = 0;    dutyCounter<8; dutyCounter++)
        {
            rowNdx = rowNum;
            duty = 1 << dutyCounter;
            for (colNum = 0;    colNum <16; colNum++)
            {

                bufDuty = 0;
                if (duty & ledduty [rowNdx][colNum][0])
                    bufDuty = 1;
                if (duty & ledduty [rowNdx][colNum][1])
                    bufDuty |= 2;
                if (duty & ledduty [rowNdx][colNum][2])
                    bufDuty |= 4;

                if (duty & ledduty [rowNdx][colNum+16][0])
                    bufDuty |= 8;
                if (duty & ledduty [rowNdx][colNum+16][1])
                    bufDuty |= 16;
                if (duty & ledduty [rowNdx][colNum+16][2])
                    bufDuty |= 32;

                panelBuf[rowNum][dutyCounter][colNum] = bufDuty;
            }       

            rowNdx = rowNum+8;
            for (colNum = 0;    colNum <16; colNum++)
            {

                bufDuty = 0;
                if (duty & ledduty [rowNdx][colNum][0])
                    bufDuty = 1;
                if (duty & ledduty [rowNdx][colNum][1])
                    bufDuty |= 2;
                if (duty & ledduty [rowNdx][colNum][2])
                    bufDuty |= 4;

                if (duty & ledduty [rowNdx][colNum+16][0])
                    bufDuty |= 8;
                if (duty & ledduty [rowNdx][colNum+16][1])
                    bufDuty |= 16;
                if (duty & ledduty [rowNdx][colNum+16][2])
                    bufDuty |= 32;

                panelBuf[rowNum][dutyCounter][colNum+16] = bufDuty;
            }       
        }
    }   
    Nop();
}



Hata varsa da en fazla  ilk 8 satır ile ikinci 8 satır yer değiştirir. sanırım.
Kolay gelsin...
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 08 Kasım 2014, 11:02:47
Hocam 24 Bit olmaz zaten o konuyu bir kenera koyalım :) Benim  hedefim 18Bit renk çözünürlüğü. BAM yönteminde 6 adet kesme eder.

Ben yukarıdaki yöntemde en düşük bit için 1uS, en yüksek bit için 128uS bekliyordum. Fakat en düşük bit için 1Us beklesem bile bu 1uS lik beklemeye birde  Seri veri gönderme işlemlerinde harcanan süre ekleniyor. bu süreye t dersek en düşük bit için 1uS+t kadar beklenirken 7. bit için 128uS+t kadar bekleme yapılır. Bu durumda t süresi sabit olduğu için ledlerdeki yanmada bir sıkıntı oluşmayacağını düşünüyorum.

Hatırlarsanız daha önceki sayfalarda 6 adet 32 bitlik veriyi seri 6 ayrı data hattından panele göndermenin yaklaşık 40uS sürdüğünü ölçmüştüm.
Şimdi en düşük bit için 8uS beklenecek şekilde işlem yapalım. Bu durumda veri gönderme süresi bekleme süresinden büyük olacağı için sistem çalışamayacak. Yani düşünün kesmeyi 8uS aralıklarla oluşacak şekilde kurdum. Kesme oluşacak biz panele veri göndermekle uğraşıyoruz ve yaklaşık 40uS sürüyor. Bu işlem bitmeden bir daha kesme gelecek program donacak. Buna benzer durumlar yaşadım.

Bu yüzden en düşük bitin bekleme süresi mutlaka panele veri gönderme süresinden büyük olmalı. Temel şartlardan biri bu.

Alıntı YapVeriyi paralel olarak basmaya olanak verecek bir bellek düzeni kurmak ve hatta donanımsal paralel port kullanılabilir demiştim.
Yazılımsal olarak da yapsak 8 us de sadece 32 kere 6 bitlik veri paralel  basılacağından 8us/32 den 250ns çıkar. Bu da 18 clock demektir ki bir portun 6 bitini read -modify-write + clock için yeterlidir.

Hocam bu konu üzerinde biraz tartışalım. Her halükarda seri olarak veri basma işlemini hızlandırmamız gerekiyor. Kullandığım işlemci STM32F103VET6
FSMC gibi arabirimler üzerinde var.

FSMC yi kullanabiliriz fakat sistem nasıl çalışacak? Bu kısmı anayamadım. Yani DMA+FSMC kullansak, DMA hangi veriyi alacak FSMC'den paralel olarak basacak. FSMC ile clock ve uygulayabilecekmiyiz? FSMC nin nasıl çalıştığını pek bilmiyorum. Müsait bir vaktinizde bu konuya biraz değinirseniz sevinirim. Hatta delikli board'a plakete 6 Adet 74HC595 bile dizebilirim FSMC yi test etmek için.

Seri veri basma işini biraz hızlandırırsak bu iş olur gibi.

mesaj birleştirme:: 08 Kasım 2014, 11:08:09

Ekleme:

Birde şunu merak ediyorum. diyelim 1.satır seçildi. Tüm işlerimizi yapmak için 2ms var. Bu süre içerisinde Ledlerin parlaklıklarını 1 kere güncellemek sizce yeterli olurmu? Yani PWM uyguladığımızı düşünürsek tüm ledlere sadece 1 peryotluk sinyal uygulayıp ledlerin yanık kalma sürelerini güncellemiş oluyoruz.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 08 Kasım 2014, 15:53:50
Alıntı yapılan: Mucit23 - 08 Kasım 2014, 11:02:47
Hocam 24 Bit olmaz zaten o konuyu bir kenera koyalım :) Benim  hedefim 18Bit renk çözünürlüğü. BAM yönteminde 6 adet kesme eder.

Ben yukarıdaki yöntemde en düşük bit için 1uS, en yüksek bit için 128uS bekliyordum. Fakat en düşük bit için 1Us beklesem bile bu 1uS lik beklemeye birde  Seri veri gönderme işlemlerinde harcanan süre ekleniyor. bu süreye t dersek en düşük bit için 1uS+t kadar beklenirken 7. bit için 128uS+t kadar bekleme yapılır. Bu durumda t süresi sabit olduğu için ledlerdeki yanmada bir sıkıntı oluşmayacağını düşünüyorum.


Birde şunu merak ediyorum. diyelim 1.satır seçildi. Tüm işlerimizi yapmak için 2ms var. Bu süre içerisinde Ledlerin parlaklıklarını 1 kere güncellemek sizce yeterli olurmu? Yani PWM uyguladığımızı düşünürsek tüm ledlere sadece 1 peryotluk sinyal uygulayıp ledlerin yanık kalma sürelerini güncellemiş oluyoruz.

Bu işlemleri bir RAM bolgesi üzerinde işlem yaparsan ve burayi dairesel buffer olarak tanımlarsan yazma ve okumayi da denetlersen bu süre içinde herşeyi
yaparsın .Bir timer altında gönderme rutini yap diğer zamanda da renk parlaklıklarını oluşturan programda çalışırsın.

Renk parlaklığını oluştur ve gönder mantığından vazgeç çünkü en kısa zamanlarda sana zaman yetmemeye başlayacak ama uzun bekleme zamanında ise boşta beklemiş oluyorsun .Bu durumu değştirip bu zamanı kullanacak bir algoritma geliştirmelisin .

O zaman herşey yeterli olmuş olacak yukarıdaki yontem ile bu devreyi 8051 e dışarıdan RAM bağlayarak bu devre ile bile sürersin .
Bu devre bile yeterli olur..
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 09 Kasım 2014, 19:13:37
Alıntı YapBu işlemleri bir RAM bolgesi üzerinde işlem yaparsan ve burayi dairesel buffer olarak tanımlarsan yazma ve okumayi da denetlersen bu süre içinde herşeyi
yaparsın .Bir timer altında gönderme rutini yap diğer zamanda da renk parlaklıklarını oluşturan programda çalışırsın.

Hocam bu söylediğinizi açıkçası pek anlayamadım. Mazur görün.  :-X

Eğer Ekrana veri basma işlemlerini hızlı bir şekilde halledebilirsem zaten dairesel bir döngü içerisinde ekran için ayırdığım ram alanını sürekli ekrana yansıtacağım. Benim şuandaki sıkıntım, RAM bölgesindeki veriyi  hızlı bir şekilde ekrana göndermekte. Bu işlemleri FSMC ve DMA kullanarak nasıl yapabilirim onu araştırırıyorum. Temel  bir iki problem var. Onları çözersem proje sonuçlanacak.

Aslında malum vize zamanı geldi, Bu yüzden çalışmaları biraz yavaşlattım. 

@iyildirim hocam, Uygun bir vaktinizde FSMC'yi nasıl kullanabileceğim hakkında ufak bir açıklama yapabilirmisiniz?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: bmutlu - 09 Kasım 2014, 23:27:02
Alıntı yapılan: bmutlu - 07 Kasım 2014, 21:16:11
Ekranin taramasi 50Hz ve PWM i de 8bit olsun ve tarama 1/8 ve sütun sayisi 32 ise buna göre minimum data öteleme hizi -> 50 * 8 * 8 * 32 =  102400 Hz sürme haline dönüşür.

Burada yukarıdaki sürmeye göre yanlış hesap yapmışım doğrusu aşağıdaki gibi olacak.

Ekranin taramasi 50Hz ve PWM i de 8bit olsun ve tarama 1/8 ve sütun sayisi 32 ise buna göre minimum data öteleme hizi -> 1 / (50 * 8 * 255) ~   9,8 uSn  süre içinde

4 Byte (32 bit) gönderme ve satır seçimi yapılmalıdır.

@Mucit23
Yukarıda yaptığım hesapta ve gönderdiğim şekilde 0.bit 9,8 uSn de gönderilmesi gerekir .İşte buranın bit ayar kısımları (ledlerin yanık mı sönük mü tespit işlemi) ise diğer bitlerin sürülmesinden sonra kalan sürelerde bit ayar işlemleri yapılacak .
İşte bu işler aynı anda yapılamadığı zaman RAM kısmına kaydetmemiz gerekir daha az RAM bölgesi kullanmak için dairesel buffer yapmamız gerekir.Dairesel buffer yapmaz isek işlemler için daha çok RAM kullanmamız gerekir ..

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 29 Ocak 2015, 00:36:36
Arkadaşlar selamlar,

Konuya derslerimden dolayı bayağı bi ara vermiştim. Yarı yıl tatilinde devam ederim diye düşünüyordum bi aksilik olmazsa eğer öyle olacak.

Ben bu ara bir tane 16x32 P6 RGB indoor panel temin ettim. Duruyordu öylece. Şimdiye kadar edindiğim temel seviyedeki bilgilerle paneli çalıştırayım dedim. Paneli çalıştırdım ufakda bir video çektim.

Öncelikle dikkat çekmem gereken bir nokta var. Bu panellerde her bir Renk(RGB) için iki adet data girişi mevcut. (R!,R2,G1,G2,B1,B2)
Ben ilk başta panelin dikeylemesine ikiye bölündüğünü tahmin ediyordum. Yani R1 girişinin ilk 1. ile 16. sütünlara  veri gönderdiğini, R2 girişinin ise 17. ile 32. sütünlara veri gönderdiğini düşünüyordum. Fakat paneldeki bu bölünme öyle değilmiş. Yani dikey bölme yerine yatay bölme yapılıyor. Açıklamak gerekirse R1 girişi 1. ile 8. satırlara veri gönderirken, R2 girişi ise 9. ile 16 satırlar arasına veri gönderiyor.

Panel 8x32 olmak üzere iki ayrı bölüme ayrılmış. Bu benim işimi kolaylaştırırmı zorlaştırırmı henüz tam kestiremiyorum.

Diğer bir tespit ettiğim nokta ise Shift Registerlar ile ilgili.
Normal P10 larda Yanmasını istediğimiz led için Shift registerin o bitine 0 göndermek gerekiyordu. Yani Ledlerin katotları Shift register'lara bağlıydı. Bunda ise tam tersi bir durum var. Ledlerin Anotları Shift Register'lara bağlı durumda.

Bunun dışında gözüme çarpan bir farklılık yok. Tarama işlemi tam tahmin ettiğimiz gibi.

Test videosu aşağıdaki gibidir.
https://www.youtube.com/watch?v=51CerlYvKVY (https://www.youtube.com/watch?v=51CerlYvKVY)

Şuanda herhangi bir PWM uygulama durumu yok sadece bütün SR lerin çıkışlarını aktif edip aynı zamanda displayi tarıyorum. 


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 04 Mart 2015, 00:21:15
16x32 RGB Panellerin şemasını buldum.

http://www.ediy.com.my/Downloads/2014%2007/Arduino%20based%20RGB%20Matrix%20LED%20tester/Schematic%20for%2016x32%20RGB%20LED%20matrix%20panel.pdf (http://www.ediy.com.my/Downloads/2014%2007/Arduino%20based%20RGB%20Matrix%20LED%20tester/Schematic%20for%2016x32%20RGB%20LED%20matrix%20panel.pdf)

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 04 Mart 2015, 19:55:18
Bende nasıl gidiyor diye merak ediyordum bu sıralar.
Bu datasheet e benzer birşey görmüştüm sanki,
güzel oldu datasheet in bulunması,
hub75 yazan kısımla ilgili bir durum olabilir,
yanlış hatırlamıyorsam sanki üzerinde hub75 kısmı olmayan Pxx paneller var,
bunu netleştirip dikkat etmek lazım.

Birde bu modüllerin 16x16 olanlarını kullanıp
4x3 metre çift taraflı led ekran yaptık,
bu sırada kullanılan hazır kartlar ve programlar hakkında biraz bilgi edinme fırsatı yakaladım.
Epey zorlu bir iş oldu, birçok problemle boğuştum.
Ekranla ilgili 2-3 tane foto var aşağıdaki linkde;
https://plus.google.com/115602230047090229563/posts/CZyKztDLUgQ

Elimde şuan birkaç tane 16x16 olan rgb P10 lardan var
ama zaman bulup hiç inceleme fırsatım olmadı.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 04 Mart 2015, 22:38:01
Şuanda durum en son videodaki gibi. Paneli  çalıştırdım çalışmasında sıkıntı yok. Anladım herşeyi. Fakat PWM üretme konusunda hala sıkıntım var.

Şurada Panelin Arduino kütüphanesi var
https://github.com/adafruit/RGB-matrix-Panel (https://github.com/adafruit/RGB-matrix-Panel)

/*
RGBmatrixPanel Arduino library for Adafruit 16x32 and 32x32 RGB LED
matrix panels.  Pick one up at:
  http://www.adafruit.com/products/420
  http://www.adafruit.com/products/607
This version uses a few tricks to achieve better performance and/or
lower CPU utilization:
- To control LED brightness, traditional PWM is eschewed in favor of
  Binary Code Modulation, which operates through a succession of periods
  each twice the length of the preceeding one (rather than a direct
  linear count a la PWM).  It's explained well here:
    http://www.batsocks.co.uk/readme/art_bcm_1.htm
  I was initially skeptical, but it works exceedingly well in practice!
  And this uses considerably fewer CPU cycles than software PWM.
- Although many control pins are software-configurable in the user's
  code, a couple things are tied to specific PORT registers.  It's just
  a lot faster this way -- port lookups take time.  Please see the notes
  later regarding wiring on "alternative" Arduino boards.
- A tiny bit of inline assembly language is used in the most speed-
  critical section.  The C++ compiler wasn't making optimal use of the
  instruction set in what seemed like an obvious chunk of code.  Since
  it's only a few short instructions, this loop is also "unrolled" --
  each iteration is stated explicitly, not through a control loop.
Written by Limor Fried/Ladyada & Phil Burgess/PaintYourDragon for
Adafruit Industries.
BSD license, all text above must be included in any redistribution.
*/

#include "RGBmatrixPanel.h"
#include "gamma.h"

// A full PORT register is required for the data lines, though only the
// top 6 output bits are used.  For performance reasons, the port # cannot
// be changed via library calls, only by changing constants in the library.
// For similar reasons, the clock pin is only semi-configurable...it can
// be specified as any pin within a specific PORT register stated below.

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
// Arduino Mega is now tested and confirmed, with the following caveats:
// Because digital pins 2-7 don't map to a contiguous port register,
// the Mega requires connecting the matrix data lines to different pins.
// Digital pins 24-29 are used for the data interface, and 22 & 23 are
// unavailable for other outputs because the software needs to write to
// the full PORTA register for speed.  Clock may be any pin on PORTB --
// on the Mega, this CAN'T be pins 8 or 9 (these are on PORTH), thus the
// wiring will need to be slightly different than the tutorial's
// explanation on the Uno, etc.  Pins 10-13 are all fair game for the
// clock, as are pins 50-53.
#define DATAPORT PORTA
#define DATADIR  DDRA
#define SCLKPORT PORTB
#elif defined(__AVR_ATmega32U4__)
// Arduino Leonardo: this is vestigial code an unlikely to ever be
// finished -- DO NOT USE!!!  Unlike the Uno, digital pins 2-7 do NOT
// map to a contiguous port register, dashing our hopes for compatible
// wiring.  Making this work would require significant changes both to
// the bit-shifting code in the library, and how this board is wired to
// the LED matrix.  Bummer.
#define DATAPORT PORTD
#define DATADIR  DDRD
#define SCLKPORT PORTB
#else
// Ports for "standard" boards (Arduino Uno, Duemilanove, etc.)
#define DATAPORT PORTD
#define DATADIR  DDRD
#define SCLKPORT PORTB
#endif

#define nPlanes 4

// The fact that the display driver interrupt stuff is tied to the
// singular Timer1 doesn't really take well to object orientation with
// multiple RGBmatrixPanel instances.  The solution at present is to
// allow instances, but only one is active at any given time, via its
// begin() method.  The implementation is still incomplete in parts;
// the prior active panel really should be gracefully disabled, and a
// stop() method should perhaps be added...assuming multiple instances
// are even an actual need.
static RGBmatrixPanel *activePanel = NULL;

// Code common to both the 16x32 and 32x32 constructors:
void RGBmatrixPanel::init(uint8_t rows, uint8_t a, uint8_t b, uint8_t c,
  uint8_t sclk, uint8_t latch, uint8_t oe, boolean dbuf, uint8_t width) {

  nRows = rows; // Number of multiplexed rows; actual height is 2X this

  // Allocate and initialize matrix buffer:
  int buffsize  = width * nRows * 3, // x3 = 3 bytes holds 4 planes "packed"
      allocsize = (dbuf == true) ? (buffsize * 2) : buffsize;
  if(NULL == (matrixbuff[0] = (uint8_t *)malloc(allocsize))) return;
  memset(matrixbuff[0], 0, allocsize);
  // If not double-buffered, both buffers then point to the same address:
  matrixbuff[1] = (dbuf == true) ? &matrixbuff[0][buffsize] : matrixbuff[0];

  // Save pin numbers for use by begin() method later.
  _a     = a;
  _b     = b;
  _c     = c;
  _sclk  = sclk;
  _latch = latch;
  _oe    = oe;

  // Look up port registers and pin masks ahead of time,
  // avoids many slow digitalWrite() calls later.
  sclkpin   = digitalPinToBitMask(sclk);
  latport   = portOutputRegister(digitalPinToPort(latch));
  latpin    = digitalPinToBitMask(latch);
  oeport    = portOutputRegister(digitalPinToPort(oe));
  oepin     = digitalPinToBitMask(oe);
  addraport = portOutputRegister(digitalPinToPort(a));
  addrapin  = digitalPinToBitMask(a);
  addrbport = portOutputRegister(digitalPinToPort(b));
  addrbpin  = digitalPinToBitMask(b);
  addrcport = portOutputRegister(digitalPinToPort(c));
  addrcpin  = digitalPinToBitMask(c);
  plane     = nPlanes - 1;
  row       = nRows   - 1;
  swapflag  = false;
  backindex = 0;     // Array index of back buffer
}

// Constructor for 16x32 panel:
RGBmatrixPanel::RGBmatrixPanel(
  uint8_t a, uint8_t b, uint8_t c,
  uint8_t sclk, uint8_t latch, uint8_t oe, boolean dbuf) :
  Adafruit_GFX(32, 16) {

  init(8, a, b, c, sclk, latch, oe, dbuf, 32);
}

// Constructor for 32x32 or 32x64 panel:
RGBmatrixPanel::RGBmatrixPanel(
  uint8_t a, uint8_t b, uint8_t c, uint8_t d,
  uint8_t sclk, uint8_t latch, uint8_t oe, boolean dbuf, uint8_t width) :
  Adafruit_GFX(width, 32) {

  init(16, a, b, c, sclk, latch, oe, dbuf, width);

  // Init a few extra 32x32-specific elements:
  _d        = d;
  addrdport = portOutputRegister(digitalPinToPort(d));
  addrdpin  = digitalPinToBitMask(d);
}

void RGBmatrixPanel::begin(void) {

  backindex   = 0;                         // Back buffer
  buffptr     = matrixbuff[1 - backindex]; // -> front buffer
  activePanel = this;                      // For interrupt hander

  // Enable all comm & address pins as outputs, set default states:
  pinMode(_sclk , OUTPUT); SCLKPORT   &= ~sclkpin;  // Low
  pinMode(_latch, OUTPUT); *latport   &= ~latpin;   // Low
  pinMode(_oe   , OUTPUT); *oeport    |= oepin;     // High (disable output)
  pinMode(_a    , OUTPUT); *addraport &= ~addrapin; // Low
  pinMode(_b    , OUTPUT); *addrbport &= ~addrbpin; // Low
  pinMode(_c    , OUTPUT); *addrcport &= ~addrcpin; // Low
  if(nRows > 8) {
    pinMode(_d  , OUTPUT); *addrdport &= ~addrdpin; // Low
  }

  // The high six bits of the data port are set as outputs;
  // Might make this configurable in the future, but not yet.
  DATADIR  = B11111100;
  DATAPORT = 0;

  // Set up Timer1 for interrupt:
  TCCR1A  = _BV(WGM11); // Mode 14 (fast PWM), OC1A off
  TCCR1B  = _BV(WGM13) | _BV(WGM12) | _BV(CS10); // Mode 14, no prescale
  ICR1    = 100;
  TIMSK1 |= _BV(TOIE1); // Enable Timer1 interrupt
  sei();                // Enable global interrupts
}

// Original RGBmatrixPanel library used 3/3/3 color.  Later version used
// 4/4/4.  Then Adafruit_GFX (core library used across all Adafruit
// display devices now) standardized on 5/6/5.  The matrix still operates
// internally on 4/4/4 color, but all the graphics functions are written
// to expect 5/6/5...the matrix lib will truncate the color components as
// needed when drawing.  These next functions are mostly here for the
// benefit of older code using one of the original color formats.

// Promote 3/3/3 RGB to Adafruit_GFX 5/6/5
uint16_t RGBmatrixPanel::Color333(uint8_t r, uint8_t g, uint8_t b) {
  // RRRrrGGGgggBBBbb
  return ((r & 0x7) << 13) | ((r & 0x6) << 10) |
         ((g & 0x7) <<  8) | ((g & 0x7) <<  5) |
         ((b & 0x7) <<  2) | ((b & 0x6) >>  1);
}

// Promote 4/4/4 RGB to Adafruit_GFX 5/6/5
uint16_t RGBmatrixPanel::Color444(uint8_t r, uint8_t g, uint8_t b) {
  // RRRRrGGGGggBBBBb
  return ((r & 0xF) << 12) | ((r & 0x8) << 8) |
         ((g & 0xF) <<  7) | ((g & 0xC) << 3) |
         ((b & 0xF) <<  1) | ((b & 0x8) >> 3);
}

// Demote 8/8/8 to Adafruit_GFX 5/6/5
// If no gamma flag passed, assume linear color
uint16_t RGBmatrixPanel::Color888(uint8_t r, uint8_t g, uint8_t b) {
  return ((r & 0xF8) << 11) | ((g & 0xFC) << 5) | (b >> 3);
}

// 8/8/8 -> gamma -> 5/6/5
uint16_t RGBmatrixPanel::Color888(
  uint8_t r, uint8_t g, uint8_t b, boolean gflag) {
  if(gflag) { // Gamma-corrected color?
    r = pgm_read_byte(&gamma[r]); // Gamma correction table maps
    g = pgm_read_byte(&gamma[g]); // 8-bit input to 4-bit output
    b = pgm_read_byte(&gamma[b]);
    return (r << 12) | ((r & 0x8) << 8) | // 4/4/4 -> 5/6/5
           (g <<  7) | ((g & 0xC) << 3) |
           (b <<  1) | ( b        >> 3);
  } // else linear (uncorrected) color
  return ((r & 0xF8) << 11) | ((g & 0xFC) << 5) | (b >> 3);
}

uint16_t RGBmatrixPanel::ColorHSV(
  long hue, uint8_t sat, uint8_t val, boolean gflag) {

  uint8_t  r, g, b, lo;
  uint16_t s1, v1;

  // Hue
  hue %= 1536;             // -1535 to +1535
  if(hue < 0) hue += 1536; //     0 to +1535
  lo = hue & 255;          // Low byte  = primary/secondary color mix
  switch(hue >> 8) {       // High byte = sextant of colorwheel
    case 0 : r = 255     ; g =  lo     ; b =   0     ; break; // R to Y
    case 1 : r = 255 - lo; g = 255     ; b =   0     ; break; // Y to G
    case 2 : r =   0     ; g = 255     ; b =  lo     ; break; // G to C
    case 3 : r =   0     ; g = 255 - lo; b = 255     ; break; // C to B
    case 4 : r =  lo     ; g =   0     ; b = 255     ; break; // B to M
    default: r = 255     ; g =   0     ; b = 255 - lo; break; // M to R
  }

  // Saturation: add 1 so range is 1 to 256, allowig a quick shift operation
  // on the result rather than a costly divide, while the type upgrade to int
  // avoids repeated type conversions in both directions.
  s1 = sat + 1;
  r  = 255 - (((255 - r) * s1) >> 8);
  g  = 255 - (((255 - g) * s1) >> 8);
  b  = 255 - (((255 - b) * s1) >> 8);

  // Value (brightness) & 16-bit color reduction: similar to above, add 1
  // to allow shifts, and upgrade to int makes other conversions implicit.
  v1 = val + 1;
  if(gflag) { // Gamma-corrected color?
    r = pgm_read_byte(&gamma[(r * v1) >> 8]); // Gamma correction table maps
    g = pgm_read_byte(&gamma[(g * v1) >> 8]); // 8-bit input to 4-bit output
    b = pgm_read_byte(&gamma[(b * v1) >> 8]);
  } else { // linear (uncorrected) color
    r = (r * v1) >> 12; // 4-bit results
    g = (g * v1) >> 12;
    b = (b * v1) >> 12;
  }
  return (r << 12) | ((r & 0x8) << 8) | // 4/4/4 -> 5/6/5
         (g <<  7) | ((g & 0xC) << 3) |
         (b <<  1) | ( b        >> 3);
}

void RGBmatrixPanel::drawPixel(int16_t x, int16_t y, uint16_t c) {
  uint8_t r, g, b, bit, limit, *ptr;

  if((x < 0) || (x >= _width) || (y < 0) || (y >= _height)) return;

  switch(rotation) {
   case 1:
    swap(x, y);
    x = WIDTH  - 1 - x;
    break;
   case 2:
    x = WIDTH  - 1 - x;
    y = HEIGHT - 1 - y;
    break;
   case 3:
    swap(x, y);
    y = HEIGHT - 1 - y;
    break;
  }

  // Adafruit_GFX uses 16-bit color in 5/6/5 format, while matrix needs
  // 4/4/4.  Pluck out relevant bits while separating into R,G,B:
  r =  c >> 12;        // RRRRrggggggbbbbb
  g = (c >>  7) & 0xF; // rrrrrGGGGggbbbbb
  b = (c >>  1) & 0xF; // rrrrrggggggBBBBb

  // Loop counter stuff
  bit   = 2;
  limit = 1 << nPlanes;

  if(y < nRows) {
    // Data for the upper half of the display is stored in the lower
    // bits of each byte.
    ptr = &matrixbuff[backindex][y * WIDTH * (nPlanes - 1) + x]; // Base addr
    // Plane 0 is a tricky case -- its data is spread about,
    // stored in least two bits not used by the other planes.
    ptr[_width*2] &= ~B00000011;            // Plane 0 R,G mask out in one op
    if(r & 1) ptr[_width*2] |=  B00000001;  // Plane 0 R: 64 bytes ahead, bit 0
    if(g & 1) ptr[_width*2] |=  B00000010;  // Plane 0 G: 64 bytes ahead, bit 1
    if(b & 1) ptr[_width] |=  B00000001;  // Plane 0 B: 32 bytes ahead, bit 0
    else      ptr[_width] &= ~B00000001;  // Plane 0 B unset; mask out
    // The remaining three image planes are more normal-ish.
    // Data is stored in the high 6 bits so it can be quickly
    // copied to the DATAPORT register w/6 output lines.
    for(; bit < limit; bit <<= 1) {
      *ptr &= ~B00011100;             // Mask out R,G,B in one op
      if(r & bit) *ptr |= B00000100;  // Plane N R: bit 2
      if(g & bit) *ptr |= B00001000;  // Plane N G: bit 3
      if(b & bit) *ptr |= B00010000;  // Plane N B: bit 4
      ptr  += WIDTH;                  // Advance to next bit plane
    }
  } else {
    // Data for the lower half of the display is stored in the upper
    // bits, except for the plane 0 stuff, using 2 least bits.
    ptr = &matrixbuff[backindex][(y - nRows) * WIDTH * (nPlanes - 1) + x];
    *ptr &= ~B00000011;               // Plane 0 G,B mask out in one op
    if(r & 1)  ptr[_width] |=  B00000010; // Plane 0 R: 32 bytes ahead, bit 1
    else       ptr[_width] &= ~B00000010; // Plane 0 R unset; mask out
    if(g & 1) *ptr     |=  B00000001; // Plane 0 G: bit 0
    if(b & 1) *ptr     |=  B00000010; // Plane 0 B: bit 0
    for(; bit < limit; bit <<= 1) {
      *ptr &= ~B11100000;             // Mask out R,G,B in one op
      if(r & bit) *ptr |= B00100000;  // Plane N R: bit 5
      if(g & bit) *ptr |= B01000000;  // Plane N G: bit 6
      if(b & bit) *ptr |= B10000000;  // Plane N B: bit 7
      ptr  += WIDTH;                  // Advance to next bit plane
    }
  }
}

void RGBmatrixPanel::fillScreen(uint16_t c) {
  if((c == 0x0000) || (c == 0xffff)) {
    // For black or white, all bits in frame buffer will be identically
    // set or unset (regardless of weird bit packing), so it's OK to just
    // quickly memset the whole thing:
    memset(matrixbuff[backindex], c, _width * nRows * 3);
  } else {
    // Otherwise, need to handle it the long way:
    Adafruit_GFX::fillScreen(c);
  }
}

// Return address of back buffer -- can then load/store data directly
uint8_t *RGBmatrixPanel::backBuffer() {
  return matrixbuff[backindex];
}

// For smooth animation -- drawing always takes place in the "back" buffer;
// this method pushes it to the "front" for display.  Passing "true", the
// updated display contents are then copied to the new back buffer and can
// be incrementally modified.  If "false", the back buffer then contains
// the old front buffer contents -- your code can either clear this or
// draw over every pixel.  (No effect if double-buffering is not enabled.)
void RGBmatrixPanel::swapBuffers(boolean copy) {
  if(matrixbuff[0] != matrixbuff[1]) {
    // To avoid 'tearing' display, actual swap takes place in the interrupt
    // handler, at the end of a complete screen refresh cycle.
    swapflag = true;                  // Set flag here, then...
    while(swapflag == true) delay(1); // wait for interrupt to clear it
    if(copy == true)
      memcpy(matrixbuff[backindex], matrixbuff[1-backindex], _width * nRows * 3);
  }
}

// Dump display contents to the Serial Monitor, adding some formatting to
// simplify copy-and-paste of data as a PROGMEM-embedded image for another
// sketch.  If using multiple dumps this way, you'll need to edit the
// output to change the 'img' name for each.  Data can then be loaded
// back into the display using a pgm_read_byte() loop.
void RGBmatrixPanel::dumpMatrix(void) {

  int i, buffsize = _width * nRows * 3;

  Serial.print("\n\n"
    "#include <avr/pgmspace.h>\n\n"
    "static const uint8_t PROGMEM img[] = {\n  ");

  for(i=0; i<buffsize; i++) {
    Serial.print("0x");
    if(matrixbuff[backindex][i] < 0x10) Serial.print('0');
    Serial.print(matrixbuff[backindex][i],HEX);
    if(i < (buffsize - 1)) {
      if((i & 7) == 7) Serial.print(",\n  ");
      else             Serial.print(',');
    }
  }
  Serial.println("\n};");
}

// -------------------- Interrupt handler stuff --------------------

ISR(TIMER1_OVF_vect, ISR_BLOCK) { // ISR_BLOCK important -- see notes later
  activePanel->updateDisplay();   // Call refresh func for active display
  TIFR1 |= TOV1;                  // Clear Timer1 interrupt flag
}

// Two constants are used in timing each successive BCM interval.
// These were found empirically, by checking the value of TCNT1 at
// certain positions in the interrupt code.
// CALLOVERHEAD is the number of CPU 'ticks' from the timer overflow
// condition (triggering the interrupt) to the first line in the
// updateDisplay() method.  It's then assumed (maybe not entirely 100%
// accurately, but close enough) that a similar amount of time will be
// needed at the opposite end, restoring regular program flow.
// LOOPTIME is the number of 'ticks' spent inside the shortest data-
// issuing loop (not actually a 'loop' because it's unrolled, but eh).
// Both numbers are rounded up slightly to allow a little wiggle room
// should different compilers produce slightly different results.
#define CALLOVERHEAD 60   // Actual value measured = 56
#define LOOPTIME     200  // Actual value measured = 188
// The "on" time for bitplane 0 (with the shortest BCM interval) can
// then be estimated as LOOPTIME + CALLOVERHEAD * 2.  Each successive
// bitplane then doubles the prior amount of time.  We can then
// estimate refresh rates from this:
// 4 bitplanes = 320 + 640 + 1280 + 2560 = 4800 ticks per row.
// 4800 ticks * 16 rows (for 32x32 matrix) = 76800 ticks/frame.
// 16M CPU ticks/sec / 76800 ticks/frame = 208.33 Hz.
// Actual frame rate will be slightly less due to work being done
// during the brief "LEDs off" interval...it's reasonable to say
// "about 200 Hz."  The 16x32 matrix only has to scan half as many
// rows...so we could either double the refresh rate (keeping the CPU
// load the same), or keep the same refresh rate but halve the CPU
// load.  We opted for the latter.
// Can also estimate CPU use: bitplanes 1-3 all use 320 ticks to
// issue data (the increasing gaps in the timing invervals are then
// available to other code), and bitplane 0 takes 920 ticks out of
// the 2560 tick interval.
// 320 * 3 + 920 = 1880 ticks spent in interrupt code, per row.
// From prior calculations, about 4800 ticks happen per row.
// CPU use = 1880 / 4800 = ~39% (actual use will be very slightly
// higher, again due to code used in the LEDs off interval).
// 16x32 matrix uses about half that CPU load.  CPU time could be
// further adjusted by padding the LOOPTIME value, but refresh rates
// will decrease proportionally, and 200 Hz is a decent target.

// The flow of the interrupt can be awkward to grasp, because data is
// being issued to the LED matrix for the *next* bitplane and/or row
// while the *current* plane/row is being shown.  As a result, the
// counter variables change between past/present/future tense in mid-
// function...hopefully tenses are sufficiently commented.

void RGBmatrixPanel::updateDisplay(void) {
  uint8_t  i, tick, tock, *ptr;
  uint16_t t, duration;

  *oeport  |= oepin;  // Disable LED output during row/plane switchover
  *latport |= latpin; // Latch data loaded during *prior* interrupt

  // Calculate time to next interrupt BEFORE incrementing plane #.
  // This is because duration is the display time for the data loaded
  // on the PRIOR interrupt.  CALLOVERHEAD is subtracted from the
  // result because that time is implicit between the timer overflow
  // (interrupt triggered) and the initial LEDs-off line at the start
  // of this method.
  t = (nRows > 8) ? LOOPTIME : (LOOPTIME * 2);
  duration = ((t + CALLOVERHEAD * 2) << plane) - CALLOVERHEAD;

  // Borrowing a technique here from Ray's Logic:
  // [url=http://www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm]www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm[/url]
  // This code cycles through all four planes for each scanline before
  // advancing to the next line.  While it might seem beneficial to
  // advance lines every time and interleave the planes to reduce
  // vertical scanning artifacts, in practice with this panel it causes
  // a green 'ghosting' effect on black pixels, a much worse artifact.

  if(++plane >= nPlanes) {      // Advance plane counter.  Maxed out?
    plane = 0;                  // Yes, reset to plane 0, and
    if(++row >= nRows) {        // advance row counter.  Maxed out?
      row     = 0;              // Yes, reset row counter, then...
      if(swapflag == true) {    // Swap front/back buffers if requested
        backindex = 1 - backindex;
        swapflag  = false;
      }
      buffptr = matrixbuff[1-backindex]; // Reset into front buffer
    }
  } else if(plane == 1) {
    // Plane 0 was loaded on prior interrupt invocation and is about to
    // latch now, so update the row address lines before we do that:
    if(row & 0x1)   *addraport |=  addrapin;
    else            *addraport &= ~addrapin;
    if(row & 0x2)   *addrbport |=  addrbpin;
    else            *addrbport &= ~addrbpin;
    if(row & 0x4)   *addrcport |=  addrcpin;
    else            *addrcport &= ~addrcpin;
    if(nRows > 8) {
      if(row & 0x8) *addrdport |=  addrdpin;
      else          *addrdport &= ~addrdpin;
    }
  }

  // buffptr, being 'volatile' type, doesn't take well to optimization.
  // A local register copy can speed some things up:
  ptr = (uint8_t *)buffptr;

  ICR1      = duration; // Set interval for next interrupt
  TCNT1     = 0;        // Restart interrupt timer
  *oeport  &= ~oepin;   // Re-enable output
  *latport &= ~latpin;  // Latch down

  // Record current state of SCLKPORT register, as well as a second
  // copy with the clock bit set.  This makes the innnermost data-
  // pushing loops faster, as they can just set the PORT state and
  // not have to load/modify/store bits every single time.  It's a
  // somewhat rude trick that ONLY works because the interrupt
  // handler is set ISR_BLOCK, halting any other interrupts that
  // might otherwise also be twiddling the port at the same time
  // (else this would clobber them).
  tock = SCLKPORT;
  tick = tock | sclkpin;

  if(plane > 0) { // 188 ticks from TCNT1=0 (above) to end of function

    // Planes 1-3 copy bytes directly from RAM to PORT without unpacking.
    // The least 2 bits (used for plane 0 data) are presumed masked out
    // by the port direction bits.

    // A tiny bit of inline assembly is used; compiler doesn't pick
    // up on opportunity for post-increment addressing mode.
    // 5 instruction ticks per 'pew' = 160 ticks total
    #define pew asm volatile(                 \
      "ld  __tmp_reg__, %a[ptr]+"    "\n\t"   \
      "out %[data]    , __tmp_reg__" "\n\t"   \
      "out %[clk]     , %[tick]"     "\n\t"   \
      "out %[clk]     , %[tock]"     "\n"     \
      :: [ptr]  "e" (ptr),                    \
         [data] "I" (_SFR_IO_ADDR(DATAPORT)), \
         [clk]  "I" (_SFR_IO_ADDR(SCLKPORT)), \
         [tick] "r" (tick),                   \
         [tock] "r" (tock));

    // Loop is unrolled for speed:
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew

      if (_width == 64) {
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew
    pew pew pew pew pew pew pew pew
      }

    buffptr = ptr; //+= 32;

  } else { // 920 ticks from TCNT1=0 (above) to end of function

    // Planes 1-3 (handled above) formatted their data "in place,"
    // their layout matching that out the output PORT register (where
    // 6 bits correspond to output data lines), maximizing throughput
    // as no conversion or unpacking is needed.  Plane 0 then takes up
    // the slack, with all its data packed into the 2 least bits not
    // used by the other planes.  This works because the unpacking and
    // output for plane 0 is handled while plane 3 is being displayed...
    // because binary coded modulation is used (not PWM), that plane
    // has the longest display interval, so the extra work fits.
    for(i=0; i<_width; i++) {
      DATAPORT =
        ( ptr[i]    << 6)         |
        ((ptr[i+_width] << 4) & 0x30) |
        ((ptr[i+_width*2] << 2) & 0x0C);
      SCLKPORT = tick; // Clock lo
      SCLKPORT = tock; // Clock hi
    }
  }
}


Arduino bu işi nasıl yapıyor. Bunu öğrenmeye çalışıyorum fakat anlamakta gerçekten sıkıntı çekiyorum.

Mantık olarak Bit Angle Modulation kullanıyor galiba. Fakat nasıl çalışıyor çözemedim.
Bit Angle Modulation işini en son yaptığım testlerde anlamıştım. Bunda sıkıntı yok. Benim anlamadığım nokta şu, BAM yönteminde en düşük değerlikli bit için süreyi ne kadar yapmam gerekir? Çünkü 6 bitlik çözünürlükte beklemeler şu şekilde olması gerekir

t+t*2+t*4+t*8+t*16+t*32 şeklinde bekleme yapmak gerekir. Buradaki t süresi ne kadar küçük olursa işlemci okadar sık kesmeye girecek demektir. Buda işlem yoğunluğunu çok fazla arttıracaktır.
Nasıl yapmam gerekiyor? Arduinodaki kodların bana bayağı fikir vereceğini düşünüyorum. Arduino kodunu yorumlayabilecek olan varmı?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 05 Mart 2015, 08:15:36
Alıntı Yapt+t*2+t*4+t*8+t*16+t*32 şeklinde bekleme yapmak gerekir. Buradaki t süresi ne kadar küçük olursa işlemci okadar sık kesmeye girecek demektir. Buda işlem yoğunluğunu çok fazla arttıracaktır.

"t" bence mümkün olduğunca küçük olacak,
büyük olduğunda tarama esnasında ekranda (flickering) kırpışma olur.

Kodda şu linki vermiş BCM (Binary Code Modulation) ile parlaklık kısmını halletmiş
http://www.batsocks.co.uk/readme/art_bcm_3.htm (http://www.batsocks.co.uk/readme/art_bcm_3.htm)
Kodda modülasyon için 6 bit kullanmış
ama hız için bütün porta değer yazmış yani
hangi port kullanılıyorsa 6 pini kullanılsa dahi
tüm portu işgal ettiğinden bahsetmiş,
bir port bu işe ayrılacak.

Linki biraz inceledim,
inceledikçe yine yazarım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 02 Haziran 2015, 11:08:44
@Mucit23 hocam;
uygulamanızda bir gelişme var mı?  Şu an bende bu uygulama ile ilgileniyorum. P6 panel ve TF-C3U kartından temin ettim.
TF-C3U kartını test ve deneme yapmak icin kullanıyorum. P6 paneli STM ile çalıştırmak istiyorum.
Test aşamasında arduino mega ile adafruit.com sitesindeki uygulamaları çalıştırdım.  Kodlarını inceledim ama tam manasıyla anlayamadım.
Nerden ve nasıl başlamalıyım.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 02 Haziran 2015, 14:57:30
Durum en son gönderdiğim videodaki gibi. Hocam iş okul derken kafamı kaşıyacak vakit bulamıyorum :'( :'( Tam final haftasindayım okul beni gercekten yoruyor.

Vakit bulupta uğraşırım diye deney düzeneğini bile bozmamışım. Beni bekliyor.

Teknik olarak geldigim noktada ise durum şöyle.

Çözemedim daha dogrusu nasıl yapacağımı bilmediğim birkaç nokta var. Onceki mesajlarımda yazmıştım. Bunları çözersem devam edecegim.

Ama arduino kodundan mutlaka fikir almam lazım.  O kodu yazanlar bu işi cok iyi bir şekilde cozduklerini düşünüyorum.  Kodu gerçekten cok inceledim ama tam olarak hangi işlemler yapıldığını anlayamadım.  Aslinda arduino mega bendede var ama arduinoyu pek iyi bilmiyorum. Bi ara kodlari denemeyi düşündüm ama Arduino icin yazılmış kütüphaneyi derleyemedim. Bi sürü hata verdi. Pek uğraşmadan tekrar STM ye döndüm. En son zaten orada kaldi. Aslında ramazanda ugrasabilirim.  Yalnız arduino kodunun nasil çalıştığını anlamam lazım.  Siz bu konuda ilerleme kaydedebildinizmi?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 06 Haziran 2015, 16:18:10
@Mucit23 Hocam;
Arduino kodunu  inceliyorum.


// -------------------- Interrupt handler stuff --------------------

ISR(TIMER1_OVF_vect, ISR_BLOCK) { // ISR_BLOCK important -- see notes later
  activePanel->updateDisplay();   // Call refresh func for active display
  TIFR1 |= TOV1;                  // Clear Timer1 interrupt flag
}

Tarama ve renk geçişleri icin  timer interrup kullanmış.
updateDisplay() fonksiyonunda ilgi ceken kısımlar ise


#define CALLOVERHEAD 60   // Actual value measured = 56
#define LOOPTIME     200  // Actual value measured = 188

t = (nRows > 8) ? LOOPTIME : (LOOPTIME * 2);
  duration = ((t + CALLOVERHEAD * 2) << plane) - CALLOVERHEAD;


Her bu fonksiyona geldikce Timer degeri değişiyor.

ptr = (uint8_t *)buffptr;

  ICR1      = duration; // Set interval for next interrupt
  TCNT1     = 0;        // Restart interrupt timer
  *oeport  &= ~oepin;   // Re-enable output
  *latport &= ~latpin;  // Latch down

Fonksiyonun devamında ise her clock palsinde verileri  PORTA ya gönderiyor.   PORTA da R1-R2, B1-B2 ve G1-G2 renk ucları var.
Renk olusumu icin  daha oncede verilen link iyice incelenmeli ve anlaşılmalı ordaki mantık kullanılmış
http://www.batsocks.co.uk/readme/art_bcm_3.htm (http://www.batsocks.co.uk/readme/art_bcm_3.htm)

Eger Paneli standart bir kayan (8x32 Tek modul alt sutun harıc )yazı mantığı ile süreceksek kolay ilk uygulamayı arduino ile yaptım. ( Tek harf icin )
Üzerinde calışmalarım sürüyor.



Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 07 Haziran 2015, 00:13:56
Bende ilk fırsatta konsantre olup tekrardan konuya odaklanmayi düşünüyorum.  STM32 aynısını daha hızlı bir şekilde yapabilmem lazım. 

Acaba arduino kodunda veri yapısı nasıl? Yani veri paketlerini 6 ayrı data olarak nasıl panele gönderiyor.  Benim için en önemli kısım burası. Veri paketlerini hızlı bir şekilde göndermede problem yaşıyordum. Yani okadar hizli olmasi lazimki ornegin t sürede bütün verilerin 1. Biti panele yuklenirken t×8 sürede 8. Bit panele yüklenmesi gerekir.

Panelde 8 satır var her bir satır 2ms aktif olsa toplamda 16ms eder. Yani tazeleme frekansı 62.5hz olur.

işte seri olarak veri gonderirken toplamda  t×8 + tx7 + tx6 + t×5 + tx4 + tx3 + tx2 + tx1  süreleri 2ms yi aşaması gerekiyor.  İşte burada olay kopuyor.  Bunu hızlı bir şekilde yapabilecek bir algoritma henüz geliştirmedim. Arduinoda bu işleri nasıl halletmisler hala anlamadım.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 07 Haziran 2015, 01:49:16
Alıntı yapılan: Mucit23 - 07 Haziran 2015, 00:13:56
Acaba arduino kodunda veri yapısı nasıl? Yani veri paketlerini 6 ayrı data olarak nasıl panele gönderiyor.  Benim için en önemli kısım burası. Veri paketlerini hızlı bir şekilde göndermede problem yaşıyordum. Yani okadar hizli olmasi lazimki ornegin t sürede bütün verilerin 1. Biti panele yuklenirken t×8 sürede 8. Bit panele yüklenmesi gerekir.

Panelde 8 satır var her bir satır 2ms aktif olsa toplamda 16ms eder. Yani tazeleme frekansı 62.5hz olur.

işte seri olarak veri gonderirken toplamda  t×8 + tx7 + tx6 + t×5 + tx4 + tx3 + tx2 + tx1  süreleri 2ms yi aşaması gerekiyor.  İşte burada olay kopuyor.  Bunu hızlı bir şekilde yapabilecek bir algoritma henüz geliştirmedim. Arduinoda bu işleri nasıl halletmisler hala anlamadım.

Hocam olay veriyi paralel olarak gönderme de biter bence.

6 kata yakın hız artışı sağlar.
6 byte (6 kere 8bit) 48 bit seri göndermek yerine 8 byte(8 kere 6bit paralel) 8 bit seri göndermek.

Paralel gönderebilmek içinde verinin bellekte buna uygun olarak gönderilmeye hazır şekilde durması gerekir.

Bir önceki mesajımda bir kod örneği vardı. Bellekte,  yanlış hatırlamıyorsam satır öncelikli sıralı duran RGB verisini 6 kanal paralel olarak gönderilmeye hazır hale getiriyordu.
Bellekte 2 ayrı ledin(2 ayrı 16x16 paneller üzerindeki aynı ledler) 6 byte lık RGB verisi, bitleri karıştırılıp 6 bitlik 8 byte haline dönüştükten sonra geriye sadece 6 bitlik sıralı bir porttan veriyi seri gönderir gibi göndermek kalır.

Bi üst aşaması  parallel port, FSMC gibi donanımları kullanmak.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 08 Haziran 2015, 15:49:07
Alıntı yapılan: iyildirim - 07 Haziran 2015, 01:49:16
Hocam olay veriyi paralel olarak gönderme de biter bence.

6 kata yakın hız artışı sağlar.
6 byte (6 kere 8bit) 48 bit seri göndermek yerine 8 byte(8 kere 6bit paralel) 8 bit seri göndermek.

Paralel gönderebilmek içinde verinin bellekte buna uygun olarak gönderilmeye hazır şekilde durması gerekir.

Bir önceki mesajımda bir kod örneği vardı. Bellekte,  yanlış hatırlamıyorsam satır öncelikli sıralı duran RGB verisini 6 kanal paralel olarak gönderilmeye hazır hale getiriyordu.
Bellekte 2 ayrı ledin(2 ayrı 16x16 paneller üzerindeki aynı ledler) 6 byte lık RGB verisi, bitleri karıştırılıp 6 bitlik 8 byte haline dönüştükten sonra geriye sadece 6 bitlik sıralı bir porttan veriyi seri gönderir gibi göndermek kalır.

Bi üst aşaması  parallel port, FSMC gibi donanımları kullanmak.

@iyildirim cevap icin Teşekkürler.  Paralel veri gönderme aklıma gelmemişti.  Gerçekten işleri hizlandiracagina eminim. Tam olarak emin olmamakla birlikte arduinonunda paralel bir şekilde veri gönderdiğini düşünüyorum.  Çünkü veri gondermede doğrudan porta veri yazmışlar.

Fakat bu sistemde veri yapısını çok karmaşık bir hale sokuyor. Burada gercekten iyi bir organizasyon yapmak gerekiyor diye düşünüyorum 
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: iyildirim - 09 Haziran 2015, 00:11:28
@Mucit23,
Arduino kodunu incelemedim ama Port'a direk veri basılıyorsa veri paralel gönderiliyordur.

Veri yapısının karışıklığı gibi gibi bir şey çok da  önemli değil ki.
Siz verinizi aynı TFT ram'i gibi sıralı bir şekilde tutacaksınız. Veri değiştiğinde de bir kere konvert işlemi yapılacak o kadar. Ki işlem süresi bir kaç ms bile sürmez.
Geri kalan paralel basılmaya hazır hale getirilmiş veriyi-buffer ı 2 nin katları olarak ayarlanmış bir timer kesmesinde göndermek. Gereken  fazladan 2048 byte ram. 

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 22 Haziran 2015, 11:42:13
PIC18F4550 ile ilgili ilk test yazım
(http://i.hizliresim.com/j5b7Lm.jpg) (http://hizliresim.com/j5b7Lm)


#include "hardware.h"
#include "define.h"
#include "font.c"

#define DATAPORT PORTB

char  i;
char yy,aa,bb,cc,aaa,bbb,ccc;


char satir=0;
char Line=0;




void main()
{

  ADCON1 |= 0x0F;         // AN pinleri dijital giriş/çıkış
  CMCON  |= 7;            // komparatörler disable edildi
  TRISA=0x00;
  TRISB=0x00;
  TRISC=0x00;
  TRISD=0x00;

Latch_Pin_Direction  =0;
OE_Pin_Direction     =0;
Clk_Pin_Direction    =0;






  while(1)
             {

                Display();

              }
} // main end.


void Display(void)
{
/***************************************/
     satir=0;
     PORTA=0x00;
     Write_data(satir);     // Satir -1
/***************************************/
      satir=satir+12;
      PORTA=0x01;
      Write_data(satir);     // Satir -2
/***************************************/
      satir=satir+12;
      PORTA=0x02;
      Write_data(satir);     // Satir -3
/***************************************/
      satir=satir+12;
      PORTA=0x03;
      Write_data(satir);     // Satir -4
/***************************************/
       satir=satir+12;
       PORTA=0x04;
       Write_data(satir);     // Satir -5
/***************************************/
      satir=satir+12;
      PORTA=0x05;
       Write_data(satir);     // Satir -6
/***************************************/
      satir=satir+12;
      PORTA=0x06;
      Write_data(satir);     // Satir -7
/***************************************/
      satir=satir+12;
      PORTA=0x07;
      Write_data(satir);     // Satir -8
/***************************************/

}


/*****************************************************************/
char Write_data(char Line)
{
char i=0;
char ii;
ii=Line+4;

      Latch_Pin = 0;
      OE_Pin = 0;

       for(Line;Line<ii;Line++)
                {


                     for(i=0;i<8;i++)
                         {
                          aa = (matrixbuff[Line]>>i)&(0x01);
                          bb = (matrixbuff[Line+4]>>i)&(0x01);
                          bb=bb<<1;
                          cc = (matrixbuff[Line+8]>>i)&(0x01);
                          cc=cc<<2;

                          aaa = (matrixbuff[Line+96]>>i)&(0x01);
                          aaa=aaa<<3;
                          bbb = (matrixbuff[Line+100]>>i)&(0x01);
                          bbb=bbb<<4;
                          ccc = (matrixbuff[Line+104]>>i)&(0x01);
                          ccc=ccc<<5;
                     
                          DATAPORT = aa|bb|cc|aaa|bbb|ccc;
                          Clk_Pin = 0;   // Clock Low
                          asm nop
                          Clk_Pin = 1;   // Clock high

                         }
                  }
                   Latch_Pin = 1;
                   OE_Pin = 1;
}
/*****************************************************************/

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 22 Haziran 2015, 12:50:41
Hocam ellerinize sağlık.  Devam edip geliştirmek lazım.  Kodlara biraz baktımda text fonksiyonlarini göremedim.  Acaba resimmi bastınız? Birde PWM işini nasıl yaptınız.

mesaj birleştirme:: 22 Haziran 2015, 12:50:41

Hocam ellerinize sağlık.  Devam edip geliştirmek lazım.  Kodlara biraz baktımda text fonksiyonlarini göremedim.  Acaba resimmi bastınız? Birde PWM işini nasıl yaptınız.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: M_B - 22 Haziran 2015, 15:28:17
Hocam Henuz font falan tanımlamadım. Sadece Panelin calısmasını kavramak ıcın matrixbuff dizisinin icine cıkmasını istediğim goruntuyu kaydettim.
PWM  kullanmadım. Fırsat buldukca bir şeyler yapıyorum.   
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: oguztkn - 22 Haziran 2015, 18:38:58
Arkadaşlar belki konu dışı olabilir ama elimde resimlerde gözüken panel var gerilim verip data uçlarına rastgele elimle dokundum rgb olduğunu gördüm. Ama uçları hiçbir yerde bulamadım bu panelin uçlarını nasıl bulabilirim birde kendim sürebilirmiyim ?
Hayırlı Ramazanlar,İyi Çalışmalar...
(http://s28.postimg.cc/bcwsivop5/P_20150622_182953.jpg) (http://postimg.cc/image/bcwsivop5/)

(http://s24.postimg.cc/kmntih97l/P_20150622_183043.jpg) (http://postimg.cc/image/kmntih97l/)

(http://s24.postimg.cc/xglvbtmn5/P_20150622_183051.jpg) (http://postimg.cc/image/xglvbtmn5/)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 25 Nisan 2017, 14:29:25
Selamlar. Aradan baya vakit geçmiş. Daha önce hobi amaçlı bu panellerle uğraşıyordum ama daha farklı bir iş için uğraşıyorum.

Bu paneller hakkında biraz fikir alışverişi yapmak istiyorum.

Panellere PWM uygulamadan 7 farklı renk çıkarmak kolay bir işlem. Bunu standart bir mikroişlemci ile rahatlıkla yapılabiliyor. Biraz yüksek hızlı bir mikroişlemci ile Her Renk için 4 bit olmak üzere 12 bit pwm uyguladım ve 4096 farklı renk elde ettim tek bir panel için. Şöyle bir sıkıntım var. Bu PWM işlemlerini C de yaptığım zaman tek panel için sıkıntı olmasada panel sayısı arttıkça kod gecikmeleri bana engel olmaya başlıyor.

İnternette bazı videolar var aklım duruyor. İkiside STM32F4 ile yaptığını idda ediyor.
https://www.youtube.com/watch?v=Xtj6mlpqDPY
https://www.youtube.com/watch?v=4_Fv_DULgeM
İkinci video gerçekten çok iyi. Kodlar vs verilmiş inceliyorum ama panel kontrolü ile ilgili bir kısım pek göremedim? Nasıl bir yöntem izlemiş olabilirler sizce?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: engineer - 27 Nisan 2017, 11:14:16
Merhaba, tarama konusunda aklıma takılan bir nokta var. 16x32 1/4 taramalı rgb bir panel üzerinden gidecek olursak, hatta işi biraz basitleştirelim, sadece R1,G1,B1 data hatlarını kullanarak üst 8 satıra birşeyler basmak istiyoruz diyelim. Göndereceğimiz her veri paketi 64bit uzunluğunda olacak (tek data hattı üzerinden R1, G1 yada B1) ve 4 kez tarama yaparak bu üst 8 satırı full basmış olacağız. Ancak bu şekilde dediğiniz gibi 7 renk elde edebiliyoruz, malum r,g, ve b nin karışımından. Burada OE'ye pwm uygulasak sadece parlaklık azalıp artmış olacak yine aynı 7 renk elde edeceğiz. Bu durumda satırdaki her pixel için tarama yapmak gerekecek. Yani ilk başta 1.satır 1. piksel R değeri için bir 64bit'lik paket gönderip oe'ye pwm uygulamak gerekecek, ardından G ve B içinde aynı adımlar gerçekleştirilecek. Daha sonra 2. pixel, 3. pixel ... 32. pixel için tek tek bu adımlar takip edilecek. Yani bir satır için totalde 3 x 32 =  96 kere tarama yapılacak. Siz her renk için 4bit kullanarak 12bit pwm uyguladım diyorsunuz aynı anda sanki tüm r,g,b ledler farklı değerlerde anahtarlanabilirmiş gibi. Bunu tam anlıyamadım? Benim yukarda kurduğum tarama senaryosu mu hatalı, siz tam olarak hangi adımları takip ediyorsunuz?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 27 Nisan 2017, 12:38:24
Hocam Bu konuda fikir alışverişi bulunabileceğim birilerini arıyorum. Farklı fikirler farklı çözümler demek.

ikinci videoda STM32F4 Discovery Kartı kullanılmış. Böyle bir performans gerçekten taktir edilecek bir durum. Ama nasıl yapmış anlamıyorum.
https://hackaday.com/tag/hub75/ (https://hackaday.com/tag/hub75/)

Arkadaş Github'da kodlarını paylaşmış https://github.com/Frans-Willem/LEDMatrixHUB75 (https://github.com/Frans-Willem/LEDMatrixHUB75)

Buda Arkadaşın blog sayfası. http://fw.hardijzer.nl/?p=223 (http://fw.hardijzer.nl/?p=223)

Hocam ben yaptığım uygulamada Her renk için 4 bit pwm uygulayabildim. PWM dediğim ise aslında temelinde "Bit Angle Modulation" tekniği. 4 bit PWM için 4 adet kesme oluşması yeterli oluyor.

Yaptığım işlemler sırası ile şöyle.
ABC 000 iken seçili satırlar 1 ve 9
Bu durumda R1, G1, B1 ve R2, G2, B2 girişlerinden bütün Pixeller için Renk bilgisinin 0. bitini gönderip T kadar bekliyorum.
T süre sonra Bütün pixeller için 1. biti gönderip 2T kadar bekliyorum.
2T süre sonunda 2. biti gönderip 4T kadar bekliyorum.
4T süre sonunda 3. biti gönderip 8T kadar bekliyorum. Bu şekilde 1 ve 9. satırdaki bütün ledlere 1 periyot boyunda PWM uygulamış oldum.

Sonra ABC 001 yapıp 2. ve 10 Satırları seçiyorum.
PWM işlemleri aynı şekilde devam ediyor.

Genel mantığım bu şekilde hocam. Birazdan tek panel için Test videosu ekleyeceği. Yüklenmesini bekliyorum.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 27 Nisan 2017, 12:54:56
Benim yaptığım bu şekilde. Bazı yerlerde rastgele pixeller yanıyor. Onun çözümü basit ona uğraşmadım. Asıl sorun yazdığım programın kod gecikmelerinden çok etkilenmesi.
https://www.youtube.com/watch?v=L_1k1tvHRRk

Sadece iyi kod yazmak yeterli gelmiyor. Donanımda kullanmak gerekiyor. STM32F4 ile arkadaş DMA felan kullandım diyor ama nasıl kullanmış hafıza organizasyonunu nasıl yapmış Bit angle modulation işlemlerini nasıl yapmış. Koddan anlamak baya zor. 

Ekleme Gerçekte Titreme olmuyor Ekran Güncelleme hızı 83Hz
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kantirici - 27 Nisan 2017, 17:56:05
Şu elemanın koduna biraz göz attım. Anladığım kadarıyla yapılan iş dataları uarttan alıp panele basmak. Yani pixel işlemleri, hesaplamaları yapılmıyor. 5.000.000 bps baudda uart kurulu ve direk DMA ile veriler alınıyor. Yine anlınan verileri porta DMA ile basılıyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 27 Nisan 2017, 21:05:39
O halde bilgisayar olmadan çalışmaz. Ben diyorum birseyler olmalı. Kendi kendimi yiyordum.


Gerçekten bitleri analiz edip teker teker dışarı çıkarıp ayni anda paneli tarayıp pwm uygulamak mikrosilemcilere göre zor bir iş.


Arduino bu işi iyi yapıyor. Adafruit in kütüphanesi fena değil. Orada da hafıza organizasyonu nasıl dizayn etmişler onu anlamadım. O kodu çözebilen oldumu?


Pwm uygulama yöntemi benimkiyle aynı gibi ama hafıza organizasyonunu anlamadım.


Bu konuyu biraz geliştirsem iyi olacak.. Çünkü hafıza organizasyonu benim bitlerle ne kadar ugrasacağımı belirliyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kantirici - 28 Nisan 2017, 08:36:54
bence tam ihtiyacın olan şey. eğer panel tarama işlemini sende bu şekilde yaparsan alt tarafta sana çok zaman kalır. o esnada da ilgili işlemleri yaparsın.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: gokhangokcen - 28 Nisan 2017, 08:58:26
belki biraz konu dışı olacak ama 2 bacak ile RGB led yapmışlar. Pek detaylı açıklaması yok. Ürün dedikleri gibi enerji sarfiyatı düşük. Bir kaç uygulamada kullandım. ama acil işler olduğu için inceleme fırsatım olmadı. Sizce nasıl çalışıyordur?

http://makroled.com/smart-led-nedir (http://makroled.com/smart-led-nedir)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 28 Nisan 2017, 10:34:21
Alıntı yapılan: kantirici - 28 Nisan 2017, 08:36:54
bence tam ihtiyacın olan şey. eğer panel tarama işlemini sende bu şekilde yaparsan alt tarafta sana çok zaman kalır. o esnada da ilgili işlemleri yaparsın.

Koda biraz daha baktım ama sanırım tam olarak öyle çalışmıyor. Yani Veriler doğrudan uart'dan gelip ekrana gönderilmiyor. Dediğin gibi uart 5000000 bps ye ayarlı Yüksek hızda veri akışı olup DMA yardımıyla bu veriler uart'a ait bir buffer'a yazılıyor.

Program uart loop içerisinde gelen verileri ayrıştırıp frame buffere yazıyor. Fakat frame buffere yazılırken bir takım karışık işlemler yapılıyor. Muhtemelen benim Bit angle modulation için yaptığım bit ayrıştırma işlemleridir.

Donanımın ayrı bir kısmı ise Timer ile DMA'yı tetikleyip Timer+DMA+GPIO üçü birlikte çalışıp frame bufferin ilgili kısımlarını alıp ekrana gönderiyor.
Sanırım bitlerle ilgili işlemleri frame buffere yazarken yaptığı için ekranla ilgilenirken daha çok vakti oluyor.

Anlamadığım birkaç nokta var. GPIO'dan DMA ile veri gönderirken eş zamanlı olarak panele nasıl clock uyguluyor? Bu kısmı anlayamadım..

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 28 Nisan 2017, 12:08:10
Aklıma yeni bir yöntem geldi. Biraz ram fazla gidecek ama kafamdaki seneryo canlanırsa oldukça hızlı çalışır
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 02 Mayıs 2017, 16:32:55
Bu panelleri kullanmak için güzel bir yöntem geliştirdim. Önceden RGB datalarını tek panel için 16x32 boyutunda ram'de 0x0RGB şeklinde 16 bit olarak tutup Daha sonra ekrana gönderirken bu RGB datalarını ayrıştırıp panele gönderiyordum. Bit Angle Modulation için gerekli olan Maskeleme ve bit manipülasyonları çok fazla vaktimi alıyordu.

Şuanki yöntemimde Göndereceğim RGB dataları için 4 farklı katman kullandım. 4 bit renk çözünürlüğü içi 4 katman.
1. katman ekrandaki tüm pixellere ait renk datalarının sadece 0. bitlerinin bilgisini tutuyor.
2. katman ekrandaki tüm pixellere ait renk datalarının 1. bitlerinin bilgisini tutuyor
3. katman aynı şekilde 2. bitleri
4. katman ise RGB renk datalarının 3. bitleri saklanıyor.

Bu katmanlarda saklanan renk dataları doğrudan panelin anlayacağı şekilde dizili olduğu için hangi katmanı göndereceksem eğer gönderirken hiçbir işlem yapmandan doğrudan hafızadan okuyup panele gönderiyorum. Bu şekilde çok fazla zaman kazandım.

RGB datalarını katmanlara yerleştirme işlemlerini ise Panele veri gönderirken değil diğer boş zamanlarda yaptığım için zaman sorunum olmuyor. Yani her bir Pixele ait RGB datalarını katmanlara yazarken bitlerine ayırıp o şekilde katmanlara yazıyorum. Bu şekilde pixel dataları panelin anlayacağı formata dönüşmüş oluyor.

Önceden Hafızadan pixel datası okuyup bunları ayrıştırıp panelin anlayacağı formata dönüştürmem yaklaşık 82uS sürerken şuanda 30uS sürüyor.
Üstelik DMA kulanmadım. DMA kullanırsam veri aktarımı dahada kısa sürecektir.

Şuanda Tek panel yani 16x32'de 12 bit Renk çözünürlüğü hiçbir sıkıntı olmadan çalışıyor. Hatta renk çözünürlüğünü 15bite'de çıkarabilirim.

Bundan sonra 16x32, 16x64 ve 16x96 deneyeceğim.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 23 Mayıs 2017, 23:37:37
Son yaptığım uygulama
https://www.youtube.com/watch?v=EQt0-ViSo8I

3 Adet 16x32 RGB Panel Bağladım. Çözünürlüğüm 16x96, Renk Derinliği ise 12bit yani 4K, Bu haliyle ekran güncelleme hızı yaklaşık 83Hz, Standart bir M3 işlemci videodaki sonucu rahatlıklar verir diye düşünüyorum

Çözünürlük olarak Daha Fazlasına İşlemci hızım yetmiyor. Fakat renk çözünürlüğü düşerse örneğin RGB 333 olsa panel sayımı iki katına çıkarabilirim sanırım. Eğer hiç PWM uygulamadan bana 7 renk yeter diyorsanız o halde kullanılacak olan işlemcinin RAM'ine bağlı olarak Ekran boyutunu baya arttırabiliriz. PWM uygulanmadan 7 renk olarak kullanılırsa 16x32 panel için 256 Byte alan gerekiyor. Renk çözünürlüğü arttıkça kullanılan ram alanı artıyor. Renk çözünürlüğü 4 bit olursa tek panel için 4x256=1Kbyte alan kullanılıyor.

Beni En çok sıkıntıya sokan kısım ekran için ayırdığım belirli bir ram alanını otomatik olarak çok çok hızlı bir şekilde clock sinyali ile birlikte panele yükleyecek bir donanım olmaması. Bazı paralel LCD interface donanımlarını inceledim ama yavaş çalışıyorlar. Bu sorunu mikroişlemcilerde çözersem Bu panellerde video bile oynatırım. Bu tür işleri yapan kartlarda bu yüzden FPGA kullanıyorlar.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: HexfeT - 24 Mayıs 2017, 02:15:49
SPI donanımında her veri transferinde otomatik çıkış verecek bir GPIO tanımlanabiliyor olması lazım. 42Mbit hız yeterli olursa SPI+DMA+seri paralel çevirici kullanılabilir.
Raspberry Pi için yapılmış bazı TFT ekranlar benzer şekilde çalışıyor. İki adet 74HC4094 Panelin 16 bit paralel arayüzüne bağlanmış ve SPI ile sürülüyor. Şu an kurcaladığım 3.5" LCD bu şekilde.

(https://s4.postimg.cc/6nqslurn1/IMG_20170524_022132.jpg)
(https://s4.postimg.cc/g9kd25ist/IMG_20170524_022225.jpg)
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 24 Mayıs 2017, 09:34:35
Hexfet hocam hız yetermi emin değilim. SPI donanımı çok hızlı burada sıkıntı yok. Ufak bir hesap yapalım. Bana 8 bitlik bir Shift register yeterli oluyor. Çünkü Paralel 6 adet data çıkışım var. 6 Adet Data 1 adette clock sinyaline ihtiyacım var.

Tek panel için düşünürsek eğer Her satır için tek seferde 32Byte veri göndermem gerekiyor. Panel sayısı arttıkça tek seferde göndermem gereken veri boyutu artıyor.

Şuanda veri göndermek için basitçe bir for döngüsü kullanıyorum.

   for(i=0;i<32;i++)
   {
      Display_Write(frame_buffer[layeraddress+i]);
      CLK_Write(1);CLK_Write(0);
   }

Bu işlem yaklaşık 30uS sürüyor. Bunu SPI ile yaparsam bu süreden daha kısa sürmesi mümkünmüdür?

Birde Clock üretme işlemini anlamadım. O nasıl olacak?
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: kantirici - 29 Mayıs 2017, 13:22:39
Burada benzer bir çalışma var. Yardımcı olur belki.

https://esdblog.org/how-to-drive-4096-rgb-leds-each-24bit-rgb-brightness-with-one-stm32-microcontroller-without-much-cpu-load/

https://esdblog.org/update-how-to-drive-8192-rgb-leds-each-24bit-rgb-brightness-with-one-stm32-microcontroller-without-much-cpu-load/
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 29 Mayıs 2017, 17:33:29
@kantirici

İnceledim ama açıkçası işin içinden çıkamadım. iki adet DMA kullanmış, Biri LED datasını Panellere taşıyor diğeri ise Timer Counter Değerini prescaller isimli bir değişkene taşıyor. Fakat mantık ne çözemedim dediğim gibi. Gerçi PWM uygulanıyorsa pek fazla seçenek yok. Yöntem aynıdır. Önemli olan donanımı nasıl kullandığı.

Şuan gerçi PWM ile uğraşmıyorum. O konuda donanımım müsade ettiği kadar ilerledim. Şuan PWM'siz yani 7 renk üzerinde çalışıyorum. Büyük boyutlu ekranlarda süper sonuçlar elde ettim. Yakın zamanda yine bir video paylaşıcam
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 07 Haziran 2017, 17:04:34
Bu projede geldiğim son nokta. FFT alıp spektrum felan çizdirdim. Basit birkaç animasyon felan yaptırdım. Bu haliyle fazla bir iş yüküde yok.

https://www.youtube.com/watch?v=OiFWJM_rMwE&t=2s (https://www.youtube.com/watch?v=OiFWJM_rMwE&t=2s)
7 Renk olduğu zaman standart 48Mhz üstü her mikroişlemci panelde hatırı sayılır bir hakimiyete sahip olabilir. Ama bu boyutlarda LED lere pwm uygulamak düşük hızlı mikroişlemcilerle çok zor. Ciddi anlamda donanım desteğine ihtiyaç oluyor çünkü bazı işlemleri koddan bağımsız olarak çok hızlı bir şekilde yapmak gerekiyor. Ama 7 renk olduğu zaman ekran dışında diğer işlerle uğraşmaya baya vakit kalıyor.


Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: E-x8 - 07 Haziran 2017, 17:26:19
@Mucit23 harika gözüküyor.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: miyago - 07 Haziran 2017, 17:57:58
Sayın HexFEt

Kullandığınız LCD ekranı Türkiye'den temin edebileceğimiz bir yer var mı?

iyi günler
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: HexfeT - 07 Haziran 2017, 21:15:45
@miyago

Yurt içinde bulunacağını sanmıyorum. Olsa bile bu tip ürünler biraz pahalı oluyor burada. Aliexpress'de 11.15 Dolar, ücretsiz kargo.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 19 Haziran 2017, 18:28:06
Saçma sapan bir sorunla uğraşıyorum.

RGB paneli STM32F103 ile kontrol ediyorum. Panel ile STM32F103 arasındaki kablonun uzunluğu değişince modül saçma sapan çalışmaya başlıyor. Normal diyebilirsiniz ama modül ile mcu arasındaki 16 pin flat kabloyu kısaltınca düzgün çalışmamaya başlıyor. Ekranda kırpışmalar pixellerde kaymalar felan. Ama aradaki kablo 1mt civarındayken hiç bir problem olmadan çalışıyor. Birkaç farklı kablo ile denedim hep aynı sorun.

Üstelik uzun kablo ile kısa kablonun ucundaki Sinyalleri lojik analyser ile incelediğimde birebir aynısını görüyorum.  ??? Kabloyu uzatınca ne oluyor anlamıyorumki  ??? ???
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 23 Haziran 2017, 18:39:01
Kablo konusunda bir gelişme var mı,
denediğin bir şeyler,
ne bileyim kısa kabloya seri direnç ekleyip deneme,
pull up, pull down ekleme vs. gibi belkide anlamsız denemeler :)


Mesajını okuyunca baya merak ettim neden olduğunu, nasıl çözüleceğini.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: Mucit23 - 23 Haziran 2017, 19:45:05
Aslında sorunu anladim ama ne alaka??

Gnd ile ilgili sorun var. Kısa kablo olunca stm32f103 kartıma tek noktadan gnd bağlantısı yapınca çalışmıyor. Hub75 uzerinde birkaç tane gnd baglanti noktası var. Bunların hepsi rgb panel uzerinde kısadevre edilmiş durumda. Eğerli tek bir noktadan gnd bağlantısı yaparsam çalışmıyor veriler bozuluyor. Ama stm32f103 kartıma iki noktadan gnd bağlantısı yaparsam çalışıyor. Gerçi kart üzerinde gnd bağlantısı yaptığım yere göre bile değişiyor. Iki adet gnd bağlantısı yapsam dahi farklı noktalarda çalışmayabiliyor. Tam olarak çözebilmiş değilim   :o sonuç olarak gnd önemli bir konu.

Uzun kabloda hiçbir sorun olmuyor. Daha önceleri benzer sorunları stm32f4 ilede yasamıştım. Onda hiç çalıştıramadım Çözmeyince daha yavaş ciplerle deneyeyim dedim. Stm32f103dede bu sorunu yaşadım.

Muhtemelen hub75 için uzerine dogrudan stm32f103 monte edebileceğim bir kart yapman gerekecek. Board üzerinde çalışmakda problem yaratıyor olabailir.

Bu arada geçen gün 96x96 panel ile deneme yaptım. Bu boyuttada sıkıntı olmadan çalıştırdım.

Projeyi sonuçlandırdım sayılır ama aklım hala full color rgb işinde.

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 24 Haziran 2017, 11:46:39

Alıntı yapılan: Mucit23 - 23 Haziran 2017, 19:45:05
...
Board üzerinde çalışmakda problem yaratıyor olabailir.
...

Breadboard damı kurulu stm li devre?

Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: RaMu - 24 Haziran 2017, 11:52:34

STMli kart, hub75, rgb panel GND, üçünden tek tek
en az 0.75 kablo ile
Güç kaynağı GND ye bağlamak uygun olur gibi.

Birde güç kaynağıda probleme sebep oluyor olabilir,
lab tipi masaüstü ayarlı güç kaynağı bazı işlerde problem çıkarmıştı bana.
Başlık: Ynt: 16X32 RGB Panel hakkında
Gönderen: gokhangokcen - 25 Ağustos 2021, 13:18:17
Konu üzerinden epey vakit geçmiş, @Mucit23 üstad geliştirdiğin bir kart var mıdır? ya da konu en son o şekilde kaldı mı? Benzer bir kart geliştirmeyi bende düşünüyorum. Çeşitli haberleşme alt yapıları ile istediğim noktaya istediğim yazı-fontta değişken yazmak. Bu olay için uğraşıyorum.