Picproje Elektronik Sitesi

MİKRODENETLEYİCİLER => ARM => Konuyu başlatan: samedkutuk - 21 Kasım 2020, 23:38:22

Başlık: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 21 Kasım 2020, 23:38:22
Arkadaşlar Merhabalar,
Öncelikle umarım herkesin sağlığı yerindedir  :)
1-) Cubeide ile STM32 programlama çalışıyorum. Basit bir Timer7 kesmesi oluşturarak counter arttırıp artan değeri debug menusunde görmek istiyorum fakat zannımca değişken timer fonksiyonundan çıkmıyor.
Timer kesmesi içerisinde yazdığım kod aşağıdaki gibidir. Ayarladığım zamana uygun olarak Pin_15 ledi Toggle oluyor onu gözlemleyebiliyorum fakat değişkenin değerini debug da göremiyorum sebebi ne olabilir ?
2-)Main sayfamda yazdığım bir fonksiyonda bu değişkeni kullanmak istediğimde de bu değiken tanımlanmadı olarak hata veriyor. Sanırım burada da sorunum uygun değişken tipini uygun yerde tanımlamıyorum.
Bu konuda fikri olan var mıdır ?

İyi çalışmalar dilerim.
void TIM7_IRQHandler(void)
{
  /* USER CODE BEGIN TIM7_IRQn 0 */
 static uint8_t counter=0;
HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_15);
if(counter >2){
HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_14);
counter=0;
}
counter++;
  /* USER CODE END TIM7_IRQn 0 */
  HAL_TIM_IRQHandler(&htim7);
  /* USER CODE BEGIN TIM7_IRQn 1 */

  /* USER CODE END TIM7_IRQn 1 */
}

Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 00:25:07
Bu konu genelde benim de kafamı karıştırıyor ve başıma bela oluyor. Anladığım kadarıyla durum şöyle: Bir değişkenin debugger'da görülebilmesi için, kod duraklatıldığında "var olması" gerekiyor. Global değişkenler işleyiş boyunca hep varlar, bunlarda bir sıkıntı yok. Local static değişkenlerde durum nasıldı hatırlamıyorum. Aslında bunlar da teknik olarak hep "varlar", ancak belki scope dışında debugger'a görünmez olabilirler, emin değilim. Fonksiyon içindeki normal değişkenler ise ancak kod o fonksiyon içinde iken debugger'a görünür oluyorlar.

Senin alttaki counter kullanımı zaten yanlış. Local static bir değişken, tanımlandığı scope dışında var olamaz, daha doğrusu erişilemez. Yani static olduğu için fonksiyona ilk girişte vücut bulur ve ondan sonra sürekli vardır, ama fonksiyon dışından görünmez.

Ya debug yapabilmek için geçici olarak değişkenini fonksiyondan çıkarıp global olarak tanımlayacaksın, ya da fonksiyon içinde breakpoint koyup kodu orada durdurup local değişkenleri inceleyeceksin. Başka bir yolu varsa da ben bilmiyorum. Ama bence static olmayan bir local değişken için zaten hiç umut yok, çünkü stack üzerinde var oldukları için yeri yurdu belli değil, fonksiyon terk edildiği anda da zaten yok olur. Böyle bir şeye debugger'ın erişmesine imkan yok. Local static için belki benim bilmediğim bir yöntem vardır.

C++'ta kod yazarken ise debugger'a değişkenleri class veya namespace scope ile göstermen gerekiyordu yanlış hatırlamıyorsam. Benim de sürekli karıştırdığım ve her seferinde deneme yanılma ile çözdüğüm bir durum.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 00:39:46
@Tagli  Hocam yanıtınız için teşekkür ederim.
Burada global değişken kullanımı ile ilgili sytax ın nasıl olduğuna dair kısa bir örnek vermeniz mümkün müdür ?
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 01:03:52
static uint8_t counter=0; satırını fonksiyonun dışına alman yeterli. Aslında bu durumda static ifadesine de gerek yok, ama duruma göre static olması daha iyi olabilir. Eğer static olursa, değişken internal linkage'a sahip olur, yani sadece o dosya içinde kullanılabilir. Bu durumda diğer .c dosyalarındaki aynı isimli global değişkenler ile çakışmaz.

static ifadesi genel olarak biraz kafa karıştırıcı. Kullanıldığı yere göre anlamı değişiyor. Fonksiyon içinde kullanılmışsa o değişkenin stack'te değil kalıcı olarak RAM'de saklandığı anlamına geliyor ve bu durumda fonksiyondan çıkılsa bile değişken silinmiyor, fonksiyona tekrar girildiğinde eski değerine sahip oluyor. Fonksiyon dışındaki bir global değişkenin başına static yazılırsa, yukarıda anlattığım gibi internal linkage anlamına geliyor. Aklımda yanlış kalmadıysa const global değişkenler (garip oldu bu, yani "değişmeyenler" diyelim) varsayılan olarak zaten internal linkage'a sahip.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: z - 22 Kasım 2020, 02:31:06
Bu konu sadece Keil'de degil Delphi'de de problem.

Global degiskenler cok guzel monitor edilirken lokal degiskenleri monitor edemiyorum.

Bu genel bir kural degilse cozumu bana da lazim.  Global degiskenleri izlemek kadar basit olmali.

Aslinda teknik olarak hic bir zorlugu yok. Nedense debugger yazanlarin islerine gelmemis gibi gorunuyor.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 10:31:30
Alıntı yapılan: z - 22 Kasım 2020, 02:31:06Aslinda teknik olarak hic bir zorlugu yok.
Hocam static local değişkenler konusunda haklısın. Ancak eğer bir local değişken static değilse, bence izlenmesi teknik olarak mümkün değil. Anladığım kadarıyla debugger aslında mutlak adresleri sorguluyor.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: z - 22 Kasım 2020, 10:47:52
Teorik olarak neden mumkun olmasin?

Degisken isimleri ve siralamasi belli. Sadece ramdaki  (stak) ofseti belli degil.

Breakpoint yendigi anda stack adresi belli. Yani o statik degiskenler nerede belli artik.

Birazcik hafiyelik gerekiyor.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 12:29:54
Hocam yanıtınız için teşekkür ederim,
Evet fonksiyonun dışına çıkarıp static i kaldırınca debug menüsünde görebildim Fakat main dosyasında halen değişkeni kullanamıyorum tanımlı değil diyor.
Yapmaya çalıştığım şua aslında;
stm32f4xx_it.c dosyasında
Alıntı Yapvoid TIM7_IRQHandler(void){}
kesmesinin içinde bir değişkeni arttırıp bu değişkeni main.c dosyamda kullanmak istiyorum

Alıntı yapılan: Tagli - 22 Kasım 2020, 01:03:52static uint8_t counter=0; satırını fonksiyonun dışına alman yeterli. Aslında bu durumda static ifadesine de gerek yok, ama duruma göre static olması daha iyi olabilir. Eğer static olursa, değişken internal linkage'a sahip olur, yani sadece o dosya içinde kullanılabilir. Bu durumda diğer .c dosyalarındaki aynı isimli global değişkenler ile çakışmaz.

static ifadesi genel olarak biraz kafa karıştırıcı. Kullanıldığı yere göre anlamı değişiyor. Fonksiyon içinde kullanılmışsa o değişkenin stack'te değil kalıcı olarak RAM'de saklandığı anlamına geliyor ve bu durumda fonksiyondan çıkılsa bile değişken silinmiyor, fonksiyona tekrar girildiğinde eski değerine sahip oluyor. Fonksiyon dışındaki bir global değişkenin başına static yazılırsa, yukarıda anlattığım gibi internal linkage anlamına geliyor. Aklımda yanlış kalmadıysa const global değişkenler (garip oldu bu, yani "değişmeyenler" diyelim) varsayılan olarak zaten internal linkage'a sahip.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: muhittin_kaplan - 22 Kasım 2020, 14:00:45
Bir değişkenin yaşam alanının dışında  debug da "görülebildiğini" hiçbir dilde ve IDE de görmedim.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 14:10:38
cevap veren tüm hocalarıma teşekkür ederim,
Ben önce debugda local değişkeni göremediğimi @Tagli hocamdan öğrendim ve değişkenimi fonksiyon dışına çıkararak ilk sorunumuçözmüş oldum.

ikinci sorunum ise kesme fonksiyonunun olduğu .c dosyasında bir değişken arttırarak o değişkeni main.c dosyasında kullanmak idi ve onu da extern tanımlama biçimi ile main.h dosyasına tanımlayıp daha sonda main.c dosyasında uint8_t olarak çekerek kullanabildim.
İlgili fotoğrafları aşağıda birilerinin işine yaraması dileği ile paylaşıyorum.

Bunlara ek olarak ynalışım var ise uyarmanızı eksiğim var ise önerilerinizi rica ederim :)
 
Herkese iyi çalışmalar dilerim :)




(https://i.ibb.co/X25KCzD/Ekran-Al-nt-s-1.png) (https://ibb.co/X25KCzD)

(https://i.ibb.co/VVxPLbb/Ekran-Al-nt-s-2.png) (https://ibb.co/VVxPLbb)

(https://i.ibb.co/nzn9H4G/Ekran-Al-nt-s-3.png) (https://ibb.co/nzn9H4G)

(https://i.ibb.co/GQhY863/Ekran-Al-nt-s-4.png) (https://ibb.co/GQhY863)
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 16:05:40
Alıntı yapılan: z - 22 Kasım 2020, 10:47:52Teorik olarak neden mumkun olmasin?
@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.

Yine de bir dipnot olarak yazayım: Bazı kısıtlı cihazlarda derleyici fonksiyonların reentrant olmadığını varsayarak local değişkenlerin hepsini static olarak bellekte bir yere yerleştirebilir. Böyle derleyicilerde fonksiyonlar stack kullanmazlar. Tabi ki bu durumda aynı fonksiyonu mesela hem kesmede hem de normal kodda çağıramazsınız (ama bunun da çaresi var). Benzer şekilde recursion da yapamazsınız. Microchip'in bir dokümanında bununla ilgili bir şeyler okuduğumu hatırlıyorum. Belki XC8 böyle idi, emin değilim. Ayrıca bu özelliği açıp kapama için bir derleyici opsiyonu da olmalı. Ama XC8 bir kolaylık da sağlıyor: Aynı fonksiyon hem normal kodda hem de kesmede çağrılırsa, o fonksiyonun bir kopyası oluşturuluyor otomatik olarak. C++'taki template'ler gibi bir mantığı var yani. Neyse, lafı çok uzattım. Böyle bir derleyicide local değişkenler gerçekte static olurlar ve bunlara erişmek teorik olarak mümkündür. MPLAB X'te debug yaparken bunu yapabiliyor muyduk hatırlamıyorum.

@samedkutuk , extern ifadesi derleyiciye "Böyle bir değişken var ama burada değil dışarıda bir yerde tanımlı, linker söyleyecek sana bunu" demektir. Yani extern geçen yerde değişken için bir yer ayrılmaz. Linker bunu link aşamasında artık hangi dosyada tanımlanıp derlenmişse oradan bulup bağlar. Tabi bunun için bu değişkenin external linkage'a sahip olması gerekir. Değişkeni static ifadesi ile tanımlarsan internal linkage olur, yani linker'a görünmez olur gibi düşünebilirsin. Senin durumunda böyle olmasını istemiyorsun, çünkü o değişkene başka dosyadan erişmen gerekiyor. Ama özel bir sebep yoksa external linkage genel olarak tercih edilmeli. Yoksa farklı dosyalardaki global değişkenler eğer isimleri aynı ise birbirleri ile çakışırlar ve linker hatası alırsın. C++ kullanırken her değişkenin başına static yazmak yerine bunları topluca isimsiz bir namespace içine de atabilirsin.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 16:12:30
@Tagli  hOCAM BEN 8 BİT pic ler ile çaqlışıyordum henüz stm ile yeni başladım çalışmaya external linkage kullanımını kısaca göstermeniz mümkün müdür ?

Alıntı yapılan: Tagli - 22 Kasım 2020, 16:05:40@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.

Yine de bir dipnot olarak yazayım: Bazı kısıtlı cihazlarda derleyici fonksiyonların reentrant olmadığını varsayarak local değişkenlerin hepsini static olarak bellekte bir yere yerleştirebilir. Böyle derleyicilerde fonksiyonlar stack kullanmazlar. Tabi ki bu durumda aynı fonksiyonu mesela hem kesmede hem de normal kodda çağıramazsınız (ama bunun da çaresi var). Benzer şekilde recursion da yapamazsınız. Microchip'in bir dokümanında bununla ilgili bir şeyler okuduğumu hatırlıyorum. Belki XC8 böyle idi, emin değilim. Ayrıca bu özelliği açıp kapama için bir derleyici opsiyonu da olmalı. Ama XC8 bir kolaylık da sağlıyor: Aynı fonksiyon hem normal kodda hem de kesmede çağrılırsa, o fonksiyonun bir kopyası oluşturuluyor otomatik olarak. C++'taki template'ler gibi bir mantığı var yani. Neyse, lafı çok uzattım. Böyle bir derleyicide local değişkenler gerçekte static olurlar ve bunlara erişmek teorik olarak mümkündür. MPLAB X'te debug yaparken bunu yapabiliyor muyduk hatırlamıyorum.

@samedkutuk , extern ifadesi derleyiciye "Böyle bir değişken var ama burada değil dışarıda bir yerde tanımlı, linker söyleyecek sana bunu" demektir. Yani extern geçen yerde değişken için bir yer ayrılmaz. Linker bunu link aşamasında artık hangi dosyada tanımlanıp derlenmişse oradan bulup bağlar. Tabi bunun için bu değişkenin external linkage'a sahip olması gerekir. Değişkeni static ifadesi ile tanımlarsan internal linkage olur, yani linker'a görünmez olur gibi düşünebilirsin. Senin durumunda böyle olmasını istemiyorsun, çünkü o değişkene başka dosyadan erişmen gerekiyor. Ama özel bir sebep yoksa external linkage genel olarak tercih edilmeli. Yoksa farklı dosyalardaki global değişkenler eğer isimleri aynı ise birbirleri ile çakışırlar ve linker hatası alırsın. C++ kullanırken her değişkenin başına static yazmak yerine bunları topluca isimsiz bir namespace içine de atabilirsin.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 16:19:22
@samedkutuk sen olayı çözmüşsün zaten. Senin static demeden tanımladığın uint8_t genel_sayici external linkage'a sahip. Böyle bir değişkene başka bir .c dosyasından erişebilirsin. Ancak erişeceğin dosyada extern uint8_t genel_sayici şeklinde belirtmen lazım. Yukarıda da belirttiğim gibi bu ifade derleyiciye, o değişkenin başka bir yerde tanımlı olduğunu anlatır. Sen bunu doğru bir şekilde uygulamışsın.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 16:33:05
Anladım hocam,
Anladığım kadarıyla .h Dosyasında Extern diye tanımladığım değişkenlerine .h dosyasını içeren tüm .c dosyalarından erişebiliyorum.
Tabi .c dosyalarında veri tipi ile tanımlamak zorundayız

Alıntı yapılan: Tagli - 22 Kasım 2020, 16:19:22@samedkutuk sen olayı çözmüşsün zaten. Senin static demeden tanımladığın uint8_t genel_sayici external linkage'a sahip. Böyle bir değişkene başka bir .c dosyasından erişebilirsin. Ancak erişeceğin dosyada extern uint8_t genel_sayici şeklinde belirtmen lazım. Yukarıda da belirttiğim gibi bu ifade derleyiciye, o değişkenin başka bir yerde tanımlı olduğunu anlatır. Sen bunu doğru bir şekilde uygulamışsın.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 22 Kasım 2020, 20:03:06
Evet doğru, o şekilde.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: samedkutuk - 22 Kasım 2020, 21:50:07

teşekkür ederim hocam :)
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: z - 23 Kasım 2020, 00:10:37
Alıntı yapılan: Tagli - 22 Kasım 2020, 16:05:40@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.

Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: ecunnu - 23 Kasım 2020, 01:01:23
@samedkutuk hocam optimizasyon demişken  uint8_t genel_sayici değişkenini volatile olarak tanımlarsan, optimizasyonları açsanda sorun çıkarmaz sana.

Alıntı yapılan: z - 23 Kasım 2020, 00:10:37Benim 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.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: Tagli - 23 Kasım 2020, 01:20:50
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.
Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: z - 23 Kasım 2020, 01:30:36
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.

Başlık: Ynt: CubeIde ile Debug'dan değişken görmek için veri tipi tanımı nasıl olmalı ?
Gönderen: ecunnu - 23 Kasım 2020, 02:16:40
@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.

Alıntı yapılan: z - 23 Kasım 2020, 01:30:36Optmizasyon 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.