Register kodlaması

[sessiz_roman]

Arkadaşlar hepinize selamlar.
Geçenlerde nucleo kartimla proje yazmaya çalışırken hal kutuphanesinin kodlarinin işlemcinin flashini cok fazla doldurduğunu farkettim.
Örneğin bir led yakma projesinde ledin bulundugu bacağı hal kutuphanesi kodu ile(hal_gpio_write_pin) yakarsak flash bellekte bu kod %2 lik yer kapliyor diyelim. Ayni kodu kaldirip yerine ayni bacagi aktif etmek icin (gpiox->odr) register kodlamasi ile ilgili biti aktif edersek bu kod flash bellekte %0.5 lik bir yer kapliyor.

Bu noktada egitimime register kodlamasi uzerinden devam etmek istiyorum ancak iki gundur arastirmalarim somucu adam akilli bir kaynak bulamadim. Sizce kaynak ve strateji yokslugunu nasil asabilirim.
Not.:ingilizce duzeyim yetersiz turkce kaynak onerirseniz daha iyi olur.

[MB_77]

Register demek işlemcinin vs. ayarmekanizması demektir. Üretici işlemcinin birçok özelliğini ilgili register ile ayarlamaya olanak tanır. Ve bunu kullanım kılavuzu diyebileceğimiz datasheetlerde anlatır. Hangi registerin hangi bitini ne yaparsan ne olur belirtilir. Dolayısıyla bu yöndeki eğitim dokümanı datasheettir.

Önecikle 3-5 defa datasheet baştan sona okumalısın. Böylece işlemcide ne özellikler var ve bunları ne ölçüde kontrol edebiliyorsun anlarsın. Hangi ayarın hangi durumda ne yapılacağını da kendi mantığınla kurgulayarak derleyici komutlarına ve kütüphanelere çok bağlı kalmadan programını yazabilirsin. Bu esnada üç beş defa daha datasheet okursun.

Programın karmaşıklaştıkca nerede neyi neden yaptığını unutur programı tekrar yazarsın 😁

Register bazında yazdığından programın büyük ölçüde seçtiğin işlemciye bağımlı olacaktır. İşlemci değiştirdiğinde epey bir revizyon gerekecektir.

Tek sebep hafıza kullanımıysa harcayacağın emek ve zamana değmez. Ama bu yöntem daha kabiliyetli programlar yazmana da imkan verir.
Tabi datasheetler de İngilizcedir. Google büyük ölçüde yardımcı olacaktır.

[sessiz_roman]

Register demek işlemcinin vs. ayarmekanizması demektir. Üretici işlemcinin birçok özelliğini ilgili register ile ayarlamaya olanak tanır. Ve bunu kullanım kılavuzu diyebileceğimiz datasheetlerde anlatır. Hangi registerin hangi bitini ne yaparsan ne olur belirtilir. Dolayısıyla bu yöndeki eğitim dokümanı datasheettir.

Önecikle 3-5 defa datasheet baştan sona okumalısın. Böylece işlemcide ne özellikler var ve bunları ne ölçüde kontrol edebiliyorsun anlarsın. Hangi ayarın hangi durumda ne yapılacağını da kendi mantığınla kurgulayarak derleyici komutlarına ve kütüphanelere çok bağlı kalmadan programını yazabilirsin. Bu esnada üç beş defa daha datasheet okursun.

Programın karmaşıklaştıkca nerede neyi neden yaptığını unutur programı tekrar yazarsın 😁

Register bazında yazdığından programın büyük ölçüde seçtiğin işlemciye bağımlı olacaktır. İşlemci değiştirdiğinde epey bir revizyon gerekecektir.

Tek sebep hafıza kullanımıysa harcayacağın emek ve zamana değmez. Ama bu yöntem daha kabiliyetli programlar yazmana da imkan verir.
Tabi datasheetler de İngilizcedir. Google büyük ölçüde yardımcı olacaktır.

Düşüncelerinizi güzel aktardiniz hocam teşekkürler peki bu low layer programlama denilen kısım daha çok hangi tarafa yakin duruyor. Register kodlamasina mi yoksa hal kutuphanelerine mi. Mantik olarak yani

[e-zeki]

Düşüncelerinizi güzel aktardiniz hocam teşekkürler peki bu low layer programlama denilen kısım daha çok hangi tarafa yakin duruyor. Register kodlamasina mi yoksa hal kutuphanelerine mi. Mantik olarak yani

Low layer programlama donanıma olabildiğince yakın olan programlamaya deniyor. yani bu durumda registerlar üzerinden kodlama yapmak HAL'dan daha low layer oluyor.
bende @MB_77 'yle aynı fikirdeyim. register üzeriden gitmek komplike programlarda çok baş ağrıtabiliyor.

[MB_77]

Low layer register kodlamasına yakın. Bir ölçüde kolaylık sağlasa da büyük ölçüde işlemciye hakim olma gerekliliği devam etmekte.

Bu durum avantaj mı dezavantaj mı tamamen görecedir. Hızlı ve sonuç odaklı, ihtiyacı karşılayacak şeyler üretmekse amaç kütüphaneler en iyi çözüm.
Uzman seviyesinde, özel ve yenilikci şeyler üretmekse amaç register seviyesine inmek gerek.

[MB_77]

Ya o ya bu diye bir tercih yapmak çok da doğru değil aslında. Kütüphaneler de o kütüphaneyi yazanın bilgisi ve kriterleri ile oluşuyor. Başta belirttiğin gibi kolayca daha iyisini yapabileceğin şeyler için de kütüphane kullanmaya gerek olmayabilir. Her durumda, nerede ne yapman gerektiğine daha iyi karar verebilmek için datasheet okuma alışkanlığı oldukca önemli

[Tagli]

Bence ST'nin HAL'ı, adının aksine pek de öyle donanım soyutlaması sağlamıyor. Datasheet ve reference manual'i iyice okumadan Cube ve HAL'ı kullanmak zaten pek mümkün değil. Bu sebeple HAL'ı sevemedim bir türlü. Reference manual'i okumaktan azad etmediği gibi, öğrenilmesi gereken bir dolu yeni şey getiriyor.

HAL bence, bir donanım modülünü ilk kez kullanacaksanız modül başına 1-2 gün kazandırabilir. Ayrıca bir projeye başlarken pinlerin ayarlanmasını da büyük ölçüde kolaylaştırıp projenin başında yarım veya bir gün kazandırır. Ama getirdiği kolaylık, ortaya çıkarabileceği sorunlara değer mi orası tartışılır.

Ben şahsen HAL kullanmıyorum. Projeye başlarken CubeMX'i açıp pinleri belirliyorum ve clock ayarlarını yapıyorum. Ancak kodu kendim register seviyesinde yazıyorum. Zaten bir süre sonra daha önce yaptığınız projelerden kod kopyalayarak ilerliyorsunuz.

ST'nin işlemcilerinin modülleri birbirinden farklı olabiliyor ve en tehlikeli şey "Ben bu modülü biliyorum zaten, diğer işlemcinin kodundan kopyalayayım" demek oluyor. Bazen donanımlar arası küçük bir fark gözünüzden kaçıyor ve sizi bir gün uğraştırıyor. Ama yine de durum çok kötü değil. Sadece STM32 için konuşursak, zaten kullanacağınız topu topu 3-4 tane aile olacak. İçlerinden de birkaç işlemci favori işlemciniz olacak. Haliyle bir süre sonra, farklılıkları ile birlikte ezberliyorsunuz. Aklınızda kalmasa bile, daha önce o işlemci için yaptığınız projeden kopyalıyorsunuz.