CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?

[samedkutuk]

teşekkür ederim hocam

[z]

@z hocam, fonksiyon içindeki static değişkenlerin yerleri zaten derleme anında bile bellidir. Bunlar stack üzerine yerleştirilmezler. Ama ilk değerlerini almaları fonksiyonun ilk çağrıldığı ana denk gelir. Mesela bu static local değişken bir C++ nesnesi ise, fonksiyon ilk çağrıldığında constructor'ı çağrılır. Bunlara debugger üzerinden ulaşmanın mantıken bir yolu olması lazım, ama ben bilmiyorum.

Static olmayan local değişkenlere ulaşmanın ise bir yolu olamaz. Eğer breakpoint fonksiyon içinde ise bunlara ulaşılabilir. Bunu zaten yapabiliyoruz, muhtemelen senin bahsettiğine benzer bir yöntemle. Sonuçta debugger o sırada stack pointer'ı biliyor, değişkeni de bulabilir. Ama işleyiş fonksiyon dışına çıktığı anda o değişken artık yok. Çünkü stack geri sarılmış, muhtemelen üzerine başka bir fonksiyonun stack'i binmiş, o adreste de başka bir şeyler var artık.
....

Local degiskenlerin degerlerini ne zaman ogrenmek isteriz? O degiskeni kullanan fonksiyon calisirken degil mi?

Gelisiguzel bir zamanda o degiskenin degerini kim merak eder ki?.

Benim derdim optimizasyonlar full devrede ve mesela for dongusundeki degisken local tanimli diye fonksiyon icinde dongunun kacinci kez dondugunu saklayan local degiskeni goremiyor olmam.

[ecunnu]

@samedkutuk hocam optimizasyon demişken  uint8_t genel_sayici değişkenini volatile olarak tanımlarsan, optimizasyonları açsanda sorun çıkarmaz sana.

Benim derdim optimizasyonlar full devrede ve mesela for dongusundeki degisken local tanimli diye fonksiyon icinde dongunun kacinci kez dondugunu saklayan local degiskeni goremiyor olmam.

@z hocam bende optimizasyonlar açıkken debug yapmaktan nefret ederim desem yeridir.
Çözüm için yaptıklarım:
1- Projenin optimizasyon seviyesini düşürürüm.
2- Birinci seçeneği yapamıyorsam, incelemek istediğim .c dosyasının optimizasyon seviyesini düşürürüm.
3- İkinci seçeneğide yapamıyorsam, incelemek istediğim fonksiyonun optimizasyon seviyesini düşürürüm.

[Tagli]

Dosya ve fonksiyon bazında optimizasyon ayarını denemedim hiç. Yapılabildiğini duymuştum ama nasıl yapılacağını bilmiyorum. Elle tek tek derlerken mümkün tabi ama IDE'lerde böyle bir ayara denk gelmedim.

Ben genelde -O1 deyip geçiyorum. Çoğu zaman hem hız ve bellek açısından, hem de debug açısından tatmin edici oluyor.

[z]

Optmizasyon full aktif iken bahse konu işlerin yapılamıyor olması ve optimizasyonu düşürmek zorunda kalmamız IDE yazarların profesyonelliğine sığmaz.

Debug modundayız. Kodları adım adım işleteceğiz ve bu aşamada Debug ihtiyaçlarımız karşılanmıyor.

for (n=0;......) gibi bir döngüde n'nin aldığı değeri görmek için takla atmamam lazım.

Dip Not: CPU ile arama kimse giremediği için ASM'yi bir başka seviyorum.

[ecunnu]

@Tagli hocam bazen full optimizasyonu kapattığınızda MCU flash belleği yeterli olmuyor. Ozaman insan başka çözümler arıyor mecburen. Oldukça maliyet odaklı çalışıyoruz.O yüzden bizim başımıza sık sık geliyor.
Eclipse+gcc için konuşuyorum

#pragma GCC push_options
#pragma GCC optimize ("O1")

/*
 * Code that needs optimizing
 */

#pragma GCC pop_options

yukarıdaki kod bloğunun arasında, projenin diğer bölümlerine müdahale etmeden istediğiniz seviyede optimizasyon yapmanız mümkün. Ayrıca istediğiniz .c dosyasına sağ tık yapıp properties>>C/C++ Build>>Settings den o .c dosyasının optimizasyon ayarlarını değiştirebilirsiniz. Diğer derleyicilerdede benzer yöntemler vardır.

Optmizasyon full aktif iken bahse konu işlerin yapılamıyor olması ve optimizasyonu düşürmek zorunda kalmamız IDE yazarların profesyonelliğine sığmaz.

Debug modundayız. Kodları adım adım işleteceğiz ve bu aşamada Debug ihtiyaçlarımız karşılanmıyor.

for (n=0;......) gibi bir döngüde n'nin aldığı değeri görmek için takla atmamam lazım.

Dip Not: CPU ile arama kimse giremediği için ASM'yi bir başka seviyorum.

@z hocam dediklerinize harfiyen katılıyorum. Bende çok düşünmüşümdür neden bunu böyle yapmışlar diye. Hatta bazen sinirlenmişimdir. Ama elden birşey gelmiyor. ASM ye gelince zorunda kalmadıkça kullanmıyorum. Interrup larda ,delay fonksiyonlarında , zamanlamaların kritik olduğu yerlerde yada MCU nun özel register larına müdahale etmem gerektiğinde kullanmışlığım oldu. Fakat genel anlamda c yi tercih ediyorum. ASM nin engüzel tarafı her şeyi siz yönetiyorsunuz. Sizden habersiz kuş uçmuyor desek yeridir. Ama taşınmasının zorluğu ve mimariden mimariğe gösterdiği değişiklikler beni gerçekten işin içinden çıkılmaz bir duruma götürüyor.