Sonsuz Döngü

[taydin]

Burada şöyle bir durum da var: Sen ekrana ne zaman birşey yazsan, komple ekranı temizliyorsun, sonra birşeyler yazıyorsun ve sonra da gönderiyorsun. Bu gerekli olmayabilir. Mevcut ekrana sadece bir çizgi ilave edip sonra göndermek de işe yaraması lazım.

Bir de tam olarak hangi fonksiyon en çok işlemci yiyor anlamak için clear buffer, send buffer, drawline artık neyse her birisini tek tek zaman ölçümü yapabilirsin:

void loop()
{
    digitalWrite(BOS_BIR_GPIO, HIGH);
    u8g2.clearBuffer();
    digitalWrite(BOS_BIR_GPIO, LOW);
    
    // pals fazla sivri olmasin diye koydum
    delay(100);
}

 

[Gokrtl]

Sen ekrana ne zaman birşey yazsan, komple ekranı temizliyorsun

Bu dediğini daha önce fark edip sadece gereken yerlere clearBuffer ekledim. Şuanda her defasında clearBuffer göndermek gibi bir durum yok.

Bir de tam olarak hangi fonksiyon en çok işlemci yiyor anlamak için clear buffer, send buffer, drawline artık neyse her birisini tek tek zaman ölçümü yapabilirsin:

Yaparım ama bunlardan birşey çıkacağını sanmam. Kodun toplamı zaten for döngüsü olmazsa 8ms sürüyor.
Buna dayanarak for döngüsündeki 63 ile sendBuffer'ın gönderildiği 8ms çarparsak zaten 500ms filan yapıyor. Bu durum gecikmeyi açıklıyor.
Benim derdim bu for döngüsü her yere karışıyor mu onu anlamak. Bunun içinde for döngüsünü kapatıp, sıkıntı çektiğim diğer kod bloğunu çalıştırarak zamanı takip edeceğim.

 

[taydin]

Kodun tamamı 8 ms sürüyor tamam. Ama hangi fonksiyon götürüyor bu zamanı? Eşit olarak paylaştığını sanmıyorum. Büyük ihtimalle bir tanesi yapıyor bunu.

 

[Gokrtl]

Kodun tamamı 8 ms sürüyor tamam. Ama hangi fonksiyon götürüyor bu zamanı? Eşit olarak paylaştığını sanmıyorum. Büyük ihtimalle bir tanesi yapıyor bunu.

Tamam abi. Yarın bakacağım ona. Şimdi mesaiye başladım artık.

 

[Gokrtl]

Kodun tamamı 8 ms sürüyor tamam. Ama hangi fonksiyon götürüyor bu zamanı? Eşit olarak paylaştığını sanmıyorum. Büyük ihtimalle bir tanesi yapıyor bunu.

Her ölçtüğümde farklı sonuç alıyorum yav. Dediğin gibi elemanları tek tek ölçtüm. 1-2ms hepsi. (Tabi yanlış ölçmediysem).
Ama u8g2.sendBuffer() tek başına 358ms sürüyor. Daha önce hepsinin toplamını 8ms bulup suçu for döngüsüne atmıştım.

void loop() {
 
    u8g2.clearBuffer();
   
    drawF(0, 0, 128, 64, 1, 1, 126, 62); //Ölçemedim
   
    u8g2.setFont(u8g2_font_nokiafc22_tu); // 2ms
   
    u8g2.drawStr(27, 30, "RESETLENIYOR..."); //2ms
   
    u8g2.drawFrame(29, 40, 63, 7); // 8ms
   
    u8g2.drawBox(30, 40, 6, 6); // 0ms
    digitalWrite(16, LOW);
    u8g2.sendBuffer(); // 358ms
    digitalWrite(16, HIGH);
    delay(200);
     
   
}

 

[taydin]

Tamam işte, o kütüphanede bir şekilde bir ayar var herhalde. Fazla hızlı yazıp da LCD nin sınırlarını aşmamak için muhafazakar davranıyor. O ayarı bulup azaltmak lazım.

 

[Gokrtl]

Tamam işte, o kütüphanede bir şekilde bir ayar var herhalde. Fazla hızlı yazıp da LCD nin sınırlarını aşmamak için muhafazakar davranıyor. O ayarı bulup azaltmak lazım.

Bir ara bakayım bulabilecek miyim?

 

[taydin]

Yalnız süreyi yanlılş ölçmüşsün GPIO low ile GPIO high arasını ölçmen lazım.

 

[Gokrtl]

Yalnız süreyi yanlılş ölçmüşsün GPIO low ile GPIO high arasını ölçmen lazım.

Bir tam cycle ölçtüm ya. Ozaman ikiye mi böleceğiz?

 

[taydin]

Bir tam cycle ölçtüm ya. Ozaman ikiye mi böleceğiz?

sendBuffer'ın hemen girişinde ne yaptın? pini low yaptın. sendBuffer'ın çıkışında ne yaptın? pini high yaptın. O zaman bu fonksiyon ne kadar sürmüştür?

 

[Gokrtl]

sendBuffer'ın hemen girişinde ne yaptın? pini low yaptın. sendBuffer'ın çıkışında ne yaptın? pini high yaptın. O zaman bu fonksiyon ne kadar sürmüştür?

Resimde yanlış hesaplamışım ya. 150ms olacak
Sınav sorusu olsa basit hatadan kalmıştık

 

[taydin]

Ben resime bakınca 160 ms gibi görüyorum.

 

[Gokrtl]

Ben resime bakınca 160 ms gibi görüyorum.

O kadar ince hesap yapacaksak, iki nokta arası 20ms. LOW kısımı tam 0 da desek, HIGH kısımda ancak 5ms taşmıştır.
155ms ye tatlıya bağlayalım

 

[taydin]

Neyse olayın mantığını anladın. Ve osiloskobu da daha sık kullanıyorsun artık

 

[Gokrtl]

Neyse olayın mantığını anladın. Ve osiloskobu da daha sık kullanıyorsun artık

Evet aşağı yukarı anladım. Sadece şu trigger voltajı kafamda tam oturmadı. Ne zaman elle ayarlasam yakalamıyor.
Bende önce Auto ile sinyali yakalayıp sonra triggeri aktif ediyorum. Ama daha öğrenmem gereken şeyler var. 1KHz sinyal 48MHz sinyal neye göre seçiliyor flan. Ama şimdi anlatma. İşim düşünce öğreniyorum çünkü

 

[taydin]

Evet aşağı yukarı anladım. Sadece şu trigger voltajı kafamda tam oturmadı. Ne zaman elle ayarlasam yakalamıyor.
Bende önce Auto ile sinyali yakalayıp sonra triggeri aktif ediyorum. Ama daha öğrenmem gereken şeyler var. 1KHz sinyal 48MHz sinyal neye göre seçiliyor flan. Ama şimdi anlatma. İşim düşünce öğreniyorum çünkü

Normal trigger ile ilgili bug var zaten. Boşuna tırmalamıyorsun. Adamlara söyledim bakalım düzeltecekler. Düzeldiktan sonra tam düşündüğün gibi çalışacak normal trigger.

 

[Gokrtl]

Normal trigger ile ilgili bug var zaten. Boşuna tırmalamıyorsun. Adamlara söyledim bakalım düzeltecekler. Düzeldiktan sonra tam düşündüğün gibi çalışacak normal trigger.

Yav bende diyorum ne kadar beceriksizim. Ne yapsam bir tutarsızlık oluyor.

 

[Gokrtl]

Tamam işte, o kütüphanede bir şekilde bir ayar var herhalde. Fazla hızlı yazıp da LCD nin sınırlarını aşmamak için muhafazakar davranıyor. O ayarı bulup azaltmak lazım.

Konuyla ilgili bir link buldum.
Sanırım ekran tanımlaması sırasında hızı belirleyebiliyoruz. Ama telefondan bakınca bir şey anlayamadım.

u8g2setupcpp

U8glib library for monochrome displays, version 2 - olikraus/u8g2

github.com

 

[Ahmet]

Konuyla ilgili bir link buldum.
Sanırım ekran tanımlaması sırasında hızı belirleyebiliyoruz. Ama telefondan bakınca bir şey anlayamadım.

u8g2setupcpp

U8glib library for monochrome displays, version 2 - olikraus/u8g2

github.com

16854 eklentisine bak

bizim işlemcide sorun yok abi 1024'ü seç

 

[Gokrtl]

bizim işlemcide sorun yok abi 1024'ü seç

Yarın pc den bakacağım. Birde şu reset pinini aktif etmemiz gerek. Bir sıkıntı olunca ekran donup kalıyor.