Selamlar 🙂 Bu gün nihayetinde Merhaba PIC16 yazımı ekleme niyetindeyim. Esasen yazdığım sayfalarca yazıyı browser’ın azizliğinden dolayı kaybettim. Ancak yılmak yok 🙂 Tekrardan yazmaya devam. Sizlerle 07.03.2015 tarihinde paylaşmayı planladığım bu yazımı ne yazık ki ancak paylaşabiliyorum. Bu gecikme için affınıza sığınıyorum ve yılmadan yazmaya devam diyorum.

Bu yazı dizisinde, sevgili dostum Birol Çapa ile üniversite yıllarında birlikte oluşturduğumuz kaynaklardan da faydalanacağım. Bu vesileyle sevgili dostum Birol‘a da teşekkürlerimi iletiyorum.

Efendim bu yazı dizisinin temel amacı, devasa bir okyanus olan gömülü sistemlere, okyanusun ortasından dalmak yerine güzel bir sahilden dalmak. Yani ne demek istiyorum? Derya deniz diye özetleyebileceğimiz bu konuda, uygulama yapabileceğimiz güzel bir başlangıç noktasından balıklama konuya dalmak. Yine çok sayıda ibretlik noktaya değineceğimizi düşünüyorum. Yazılar da yine her zamanki uslüpla olacağından, sizleri de sıkmadan eğlenceli bir yazı dizisi geçireceğimize inanıyorum.

Neden PIC16 sorusunun cevabını esasen bir önceki yazımızda bir miktar vermiştik. Şimdi başka soruların peşinde koşalım!

Neden Mikrokontrolörler?

Efendim gömülü sistemler derya deniz demiştik. Gömülü sistemlerin en yaygın kullanım alanlı alt dalı, mikrokontrolör tabanlı sistemlerdir. Bu dal öyle bir daldır ki, çoğu ağaçtan çok daha okkalıdır. Burada edineceğimiz bilgileri, joker gibi diğer tüm gömülü sistem uygulamalarında uygulayabileceğimizden dolayı, mikrokontrolörleri iyi bilmek, iyi kullanmak çok çok önemlidir. Buna istinaden bu yazı dizisi vesilesiyle hızlıca mevzuya dalmanın faydalı olacağını düşünüyorum.

PIC de, gömülü sistemlerin temel mantığını çok çok güzel şekilde anlayabileceğimiz bir başlangıç noktası. Beğenirsiniz beğenmezsiniz, Arduino var olana kadar en önemli hobi elektroniği argümanlarından birisi PIC idi. Halen daha kullanımı çok yaygın. Ve dostlar bence buradan da öğrenebileceğimiz çok önemli noktalar olabilir. O sebeple hakir görmeyelim 🙂

Neden C?

C dili ile ilgili tonlarca şeyi, Gömülü C yazı dizisinde konuşmuştuk. Mikrokontrolör programlama işlerinde, C/C++’ın yanı sıra, Assembler, basic ve hatta yer yer java dilleri bile kullanılır. C dili bunların hepsinin ağzını burnunu kırar diyeceğimi lütfen düşünmeyiniz bile. C dilini bir kenara atıp diğer dillere çamur atmaya da niyetli değilim.

Yazılımda programlama dilleri amaç değil araçtır. Programcı bir nevi ninja ise, programlama dili de ninjanın silahıdır. Bazen kocaman bir kılıç karşısında, minik bir hançer ya da mınçıka galip gelebilir. Zira kılıç ile bir hareket yapıncaya kadar, bu ufaklıkları 8. hamlesini tamamlayabilir 🙂 Keza savaş uzaktan yapılıyorsa, belki ok ve yay kullanmak daha yeğdir. Neyse, Age of Empires ya da Hitman oynamıyoruz. Ağzımdaki baklayı çıkarayım; bu dillerin her birinin muhakkak ki birtakım avantajları ve dezavantajları bulunmaktadır. Bu diller içerisinden C dilini seçmemizin nedeni, bu dilin en yaygın kullanılan programlama dili olması, gömülü sistemlerin her alanında gücünden pek de bir şey kaybetmeden kullanılabilmesi gibi çok güzel sebepler yatar. Ancak göreceksiniz ki yeri gelecek birden fazla dili beraber de kullanacağız. Benim Assembly kardeşimi hakir görmek, şüphesiz ki davaya ihanet olacaktır 😛

Temel Kaynaklar

Bir mikrokontrolör programlama mevzusu varsa en birinci kaynak, şüphesiz ki o mikrokontrolörün datasheet’i (veri kağıdı) olacaktır. Gömülü sistemlerde bir şeyler yapmayı öğrenmenin büyük bir kısmı veri kağıdı okuyup anlayabilmekten geçer. Bizim PIC16’nın da çeşitlerinin güzel güzel veri kağıtları mevcut. Aslında daha gelişmiş mikrokontrolörlerin datasheet’inde genellikle donanımsal özelliklere yer veriliyor. Bu tip donanımları kullanabilmek için “user guide” olarak da bilinen kullanım kılavuzlarını okumak gerekiyor. Neyseki PIC16F serisi, görece basit bir seri olduğundan veri kağıdı ile paçayı sıyırıyor olacağız. Hemen çok kullanacağımız bazı PIC’lerin veri kağıtlarını paylaşalım.

• PIC16F84A
• PIC16F628A
• PIC16F877A

Efendim, gömülü sistemci olacaksak ne yapıp edip bu dokümanları okuyabilir hale gelmemiz gerekiyor. İngilizce bilmeyen arkadaşlarım da lütfen bu sorunun üstesinden gelmek için Google Translate gibi araçları kullansınlar. Zira bir yerden sonra hep aynı terimler geçtiği için dökümanları anlamak çok çok kolay oluyor.

Veri kağıtlarına ek olarak önemli bir kaynak da, geliştirme ortamının ya da derleyicinin dökümanasyonu oluyor. Ben derleyici dedim ama aslında demek istediğim toolchain. Yani içinde derleyici, bağlayıcı (linker dayı), assembler, türlü türlü kütüphaneler filan bulunan yazılım paketi. Bunun dökümantasyonunu da incelemekte faideler mevcut. Bizimkine, sırası gelince değineceğim.

Kullanılacak Programlar (Kurulumlar)

Yolculuğu kafamızda şöyle kısaca bir çizelim ki, ihtiyacı listeleyebilelim. Bizim öncelikle kodumuzu yazabileceğimiz bir ortama ihtiyacımız var. Bunun adı geliştirme ortamı (IDE). Ardından kodlarımızı anlayacak, derleyecek, link edecek bir yazılım setine ihtiyacımız var. Sonra diyelim ki yazılımımızı yazdık ve executable dosyamızı elde ettik. Bunu PIC’e yazacak bir programlayıcıya, ve programlayabileceğimiz bir donanıma ihtiyacımız var. Veya, programlayıcı + programlanacak donanım yerine simülatör kullanabiliriz 🙂 Özellikle hızlı uygulama ve öğrenme açısından simülatör kullanmak çok mantıklı olabiliyor. Ancak gerçekleme yapmak da şart. Biz tüm bu aşamalara değineceğiz ancak önce kurulumlarımızı tamamlayalım.

• MPLAB X IDE: PIC için  diye gayet hoş bir IDE mevcut. Ardından bir toolchain’e ihtiyacımız var. Bazı IDE’lerin içinde toolchain hazır olarak geliyor ancak MPLAB söz konusu olunca bu kadar şanslı değiliz. Gerçi MPLAB X, tüm seriler için genelgeçer bir IDE olduğundan, toolchain’in sonradan kurulması da mantıklı 🙂 Ben MPLAB X versiyonu olarak 3.0 beta kurdum. Normal şartlar altında, bir gömülü sistemci asla ama asla beta yazılım kullanmaz. Sağlamclığıa çok aykırıdır. Ancak bu, bilgi paylaşımı amaçlı bir yazılım olduğundan, siz bu yazıyı okuyuncaya kadar 3.0 stabil versiyon da çıkar diyerekten 3.0 beta kurdum. Siz de ücretsiz olarak kurulumu yapabilirsiniz.
• MPLAB XC8. Neyse bir sonraki aşama olarak 8 bit’lik PIC’ler için olan XC8 toolchain’i kuruyoruz. Efendim eğer 16 bit’lik bir PIC için yazılım geliştirecek olsaydık XC16, 32 bit’lik bir PIC için yazılım geliştirecek olsaydık XC32 kuracaktık ancak suyu bulandırmayalım ve MPLAB X’in üzerine XC8 kuralım. Son versiyon olan, MPLAB^® XC8 Compiler v1.34 kurulumunu tamamladım. Siz de en son versiyon hangisi ise, onu kurabilirsiniz. Evaluation sürümü ücretsiz! PRO versiyonu da 60 gün için yine ücretsiz 🙂 XC8’in çiçek gibi de bir dökümantasyonu var. Mutlaka feyizlenelim. Kurulumu yaparken, MPLAB X IDE’yi XC8’i kullanacak şekilde güncelleyin seçeneğini işaretlemeyi unutmayalım 🙂 Esasen ben eskiden toolchain olarak Hitech PIC C kullanırdım. Ama Microchip şurada, artık kullanmayın demiş. Zaten hiç bir şeyin fark etmeyeceğini, bunlara ihtiyacımız bile pek olmadığını anlatacağım. Ama şimdilik önerilen ile devam edip XC8’i kuralım.
• Proteus ISE:  Bu yazılım da güzel bir simülasyon ortamı. Aslında Proteus’a simülasyon ortamı demek biraz vicdansızlık olur. Zira Proteus ile, devre tasarımı, devre simülasyonu, şematik ve PCB tasarımı da yapılabiliyor. Kendisi çok çok başarılı bir yazılım. Ancak ne yazık ki ücretli. Yine de evaluation versiyonunu kullanabilirsiniz. Ya da internetten proteus kurulumu ile ilgili detaylı bilgileri bulabilirsiniz. Ben 8.10 SP1 versiyonunu kullanıyorum, çok da memnunum 😀 Proteus kurulumunu yaptıktan sonra, eğer proteus kullanmayı bilmiyorsanız google üzerinde proteus derslerine bakıp, proteus kullanımını kabaca öğrenmeniz gerekiyor.

Bunlara ek olarak, donanım bağımsız algoritmaları test etmek amacıyla bir C/C++ IDE’si  kurmakta fayda var. Orwell Dev C++ gayet ufacık tefecik ama işe yarar bir araç.

Kurulumları tamamladıktan sonra, mevzuya dalalım 🙂 Öncelikle, proteus üzerinde programlayabileceğimiz bir PIC ortamı oluşturmamız gerekiyor. İlk örneğimizi PIC16F84A ile yapalım. Proteus’ta “P” tuşuna bastığımızda, place part yani devre elemanı ekleme ekranı açılıyor. Buraya PIC16F84A yazdığınızda, ilgili sembol çıkacak ve çift tıkladığınızda soldaki listeye eklenecektir. Ardından PIC mikrokontrolörü ve diğer gerekli devre elemanlarını eklemeniz mümkün olacak. Proteus derslerini incelediğiniz için burayı kısa kesiyorum ve kurmanız gereken basit devreyi aşağıda sizlerle paylaşıyorum.

Şimdi akıllara haklı bazı sorular gelebilir. En birincisi, bu devrenin beslemeleri nerede? PIC16F84A üzerine çift tıkladığımızda bir pencere açılır. O penecede sol kısımda “hidden pins” yani gizli pinler yazar. Burada VDD ve VCC pinlerinin gizli olduğunu ve otomatik olarak PIC’in beslendiğini görürüz. Şimdilik bu konu üzerinde çok durmayacağım ancak ileride bunu da açıklayacağım. Şimdilik merak edenler buraya bakabilirler. Proteus burada bizim işimizi kolaylaştırmış ancak gerçek hayatta beslemeyi bağlamazsanız hiç bir şey çalışmayacaktır. Buna ithafen VCC ve GND bacaklarının arasında 2.0V – 5.5V arası bir gerilim olması gerekiyor. Bu bilgiyi nereden öğrendim? Tabi ki datasheet’ten 🙂

Neyse şimdi devam edelim, işlemcinin beslemeleri otomatik yapıldı. PIC16F84A’nın dahili osilatörü olmadığından dışarıdan OSC1 ve OSC2 pinlerine bir XTAL (crystal) osilatör bağlamışız. Buradaki kapasitelerin değerine kadar datasheet’te yazıyor. 22pF da bağlasak olurdu 🙂 Esasen bu pinlerin arasında bir ring osilatör var, XTAL ve kapasitörler bu devreyi tamamlıyor ve osilasyon başlıyor. Burada şimdilik çok detaya girmeyeceğim. Osilatör bir anlamda kalp atışı gibi sinyaller üretir ve mikrodenetleyicinin, bu işarete (saat işareti, clock cycle) senkronize şekilde işlem yapmasını sağlar. Bu kısma parantez değil paragraflar açmak gerekiyor. Onu da ileride açacağım. Ancak şimdi neyse diyelim ve devam edelim.

MCLR diye bir pin var üzerinde de bir çizgi var. Bu pin Reset pini ve üzerindeki çizgi bize, bu pinin “active low” yani “düşük seviyede aktif” olacak şekilde çalıştığını anlatıyor. Bu durumun Türkçe’si şu ki, o pini lojik 0 seviyesine çekerseniz mikrokontrolör reset durumunda kalacaktır. Biz de ne yapmışız, butona basılmadığında o pin lojik 1’de kalacak şekilde yapmışız. Buton’a basıldığında ise mikrokontrolör reset’e çekilecek.

Bizim PIC16F84A yerine PIC16F877A kullanmak istesek bağlantılar nasıl olacaktı? Aşağıdaki gibi, yani aynı olacaktı.

Neyse biz hemen mevzumuza yani PIC16F84A’ya geri dönelim. Proteus’ta mikrokontrolöre hiç bir şey bağlamasak da mikrokontrolör çalışıyor 😀 Bu sebeple, hızlıca bir led bağlayıp, aşağıdaki devreyi kuralım.

Hemen ilk kodumuzu da yazalım 🙂 Bunun için MPLAB X’de bir PIC16F84A projesi oluşturmak ve aşağıdaki kodu eklemek gerekiyor.

Bu kodu projemizde derlediğimizde, derleyici .hex uzantılı bir dosya oluşturacak. Şimdi proteus isis’te kurduğumuz devreye dönelim, ve PIC üzerine çıft tıklayıp “Program File” yazan kısma çift tıklayarak, üretilen .hex uzantılı dosyamızı seçelim. “OK” tuşuna basarak çıkalım ve “play” butonuna basarak simülasyonu başlatalım. Led, aşağıdaki gibi yanacak.

Değerli dostlarım, burada PIC dünyasına merhaba demiş olduk. Mutlaka ki buraya kadar olan kısımda konuşabileceğimiz çok şey var. Ancak tüm bunları diğer yazıya bırakıyorum 🙂 Zira bu yazıyı bu gün bitmeden yayınlamak niyetindeyim. Bir sonraki yazıda bu yaptıklarımızın suyunu çıkaracağız ve ibretler üzerinden gideceğiz 🙂

Buraya kadar okuduğunuz için teşekkürler. Yazıyı beğendiyseniz, faydalanabilecek tanıdıklarınız ile paylaşabilirseniz sevinirim.

Şimdi devam!

Yol haritamız, karanlıkta kılavuzumuz demiştik. Donanım altyapısının tahsisinden sonra, kaya misali bir gömülü c altyapısı oluşturmuştuk. Bu sert altyapının ardından yol haritamızda sözünü ettiğimiz ilk yazı dizisi nihayetinde başlıyor. Hobi elektroniğinde yeri çok başka olan Microchip PIC mikrodenetleyicilerini nasıl kulumuz kölemiz yaparız, ne yapar ne eder de bu mikrokontrolörün suyunu sıkarız ona değinmeye çalışacağım.

Tüm bu planlar yol haritamızda belirttiğimiz stratejik bir yolun parçası tabi ki. Gömülü sistemlere adım atan çoğu kimse aynı kırıcı mevzudan şikayetçi; nereden başlayıp nereye gideceğini bilememekten… Sırf bu bağlamda bile yol haritamızın değerli olduğunu düşünüyorum. Konuları kompleks hale getirmeden anlatmanın yollarını bulamazsak eğer, kompleks sistemleri anlamamız mümkün olamayacak. 8-bitlik popüler bir mikrodenetleyici bu sebeple başlamak için iyi bir adım olacak 🙂 Bu sayede sonraki adımlarımızı da çok sağlam atma şansına sahip olacağız.

Kulağa çok kötü gelmiyor da bilader niye böyle bir şey yapıyoruz diyenler olmuştur. Amaç, gömülü sistemler dünyasına ayakları yere basan bir giriş yapmak. Bir eve girerken, duvardan geçmeye çalışmak her zaman iyi bir fikir olmayabilir, ancak bunun farkına varmamız için kapı, pencere gibi temel alternatifleri bilmemiz gerekir. Bu amaçla basit bir mikrodenetleyici üzerinde detaylı bir bilgi seti inşa edip sonraki basamaklara tırmanıyor olacağız. Bu süreç içerisinde yine her zamanki gibi türlü türlü ibretler ve komiklikler şakalar ile karşılaşacağız.

Bu kapsamda Microchip firmasının 3 farklı ürünü üzerinden gideceğiz. PIC16F84A, PIC16F628A ve PIC16F877A. Neden bu serileri seçiyoruz? Çünkü hobi elektroniği camiasında en çok kullanılan ürünler bunlar. Ayrıca vermek istediğim mesajları düşününce, bu serilerin işimizi gayet tertemiz göreceğini düşünüyorum. Bu sebepledir ki bu üç civciv ile başlayacağız yolculuğumuza.Haydi hayırlısı artık 🙂

Bu yolculuğumuzda elle tutulur neler ile karşılaşacağız diye soracak olursanız şöyle bir liste yapmak mümkün olacaktır diye düşünüyorum.

• Temel anlamda mikrokontrolör kullanımını anlamak
• Mikrokontrolör’ün veri kağıdını (datasheet) güzelce okumayı öğrenmek
• Mikrokontrolörün çevresellerini (peripheral) modellemeyi ve kullanmayı öğrenmek (çok önemli)
• Sensör modellemeyi ve kullanmayı öğrenmek
• 8 bitlik bir mikrokontrolör üzerinde neler yapılabileceğini ve neler yapılamayacağını görmek
• Kütüphaneleri kullanıp, onlara bağımlı olmamayı öğrenmek
• Donanım bağımsız kodlama yapmayı öğrenmek
• Mikrokontrolörlerde hata ayıklama yöntemlerini öğrenmek
• Mikrokontrolörün nasıl çalıştığını öğrenmek
• Karışık sinyal devre tasarımı hakkında pratikler görmek
• Hayata dokunan, onu yumruklayan işler yapmak

Bu bağlamda standard PIC programlama yazılarından epeyce farklı şeyler göreceğinizin garantisini veriyorum. Umuyorum ülkemizde, bu konular ile ilgilenmek isteyen kimselere faydalı olacak bir yazı dizisi olur. Gerek ilgi duyan kimselerin bu alanlara yönlendirilmesi, gerek bu alanda çalışan kişilerin bilgi birikimine bir nebze olsun katkıda bulunulması hedefleriyle bu yazıyı büyük bir motivasyonla sürdürüyor olacağım 🙂

PIC deyip küçümsemeyiniz, es geçmeyiniz efem. Zira buradan da edineceğimiz bir şeyler muhakkak vardır bakış açısı, bu güne kadar kimseye zarar getirmemiştir 🙂 Ayrıca yalnızca öğrenecek şeyleri olduğunu kabul edenler, kestirmesi olmayan uzun yolların sonunu görebilirler diye düşünüyorum. Bu vesileyle ben de zamanları boşa harcamayacak şekilde yazmayı sürdüreceğim 🙂 Bu süreçten büyük keyif alacağımı hissediyorum.

Dilerim ki sizler için de eğlenceli olur.

NOT: Yazı dizisi’nin ikinci yazısı “Merhaba PIC16” 7 Mart Cumartesi yayınlanacak.

Yazıları beğendiyseniz eğer,  faydalanabilecek arkadaşlarınızla da paylaşabilirseniz sevinirim.

Şimdi devam…

İşaretçiler (pointers) başlıklı yazımda konuyla ilgili güzel bir girizgah ve temel atma merasimi tertip ettik. Şimdi, işaretçilerle ilgili daha ileri konulara değinmenin tam sırası. İşin aslı işaretçilerin kullanım alanları çok çok geniş. Tilkiler normalde yalnız dolaşır ama işaretçiler değince aklımda bin bir tilki sürü halinde dolaşıyor. Hepsini burada yazmak çok mümkün mü bilmiyorum ancak, elimden geldiğince yazmaya çalışacağım.

Efendim özellikle belleği etkin kullanma noktasında, işaretçiler ziyadesiyle önemli bir faktör oluyor. Bu sebepledir ki gömülü programlama yapacak yiğitlerin işaretçilerin suyunu sıkması gerekmektedir. Mevzunun özütü yine aynı olsa da, her bir kullanım alanından alınacak sayısız ibretler olduğundan, farklıca örnekler üzerinden işaretçileri inceleyemeye çalışacağım. Yine de eksik kalan bir kullanım alanı olduğunu düşünüyorsanız, yorum olarak ekleyebilirsiniz.

Bu yazıyı okumayı bitirdiğinizde varacağımız noktada iki yol var.

1. Bu şeyler sizler için yeni şeyler ise, bunları sindirdiğinizde o çok korkulan işaretçiler konusunda harbici bir uzman olmuş olacaksınız.
2. Bu şeylerin tamamını zaten biliyorsanız,  zaten bir uzmansınız. Lütfen siz de blog yazın, haber edin biz de takip edelim yeni şeyler öğrenelim 🙂

Neyse şimdi derin bir nefes alıp başlayalım. Zira bu konular ciddi konular. Tek nefes yetmeyecek ama her nefesi derin almakta faydalar var.

Mutlak Adres İşaretçileri (Pointers to Absolute Addresses)

İşaretçilerin genel felsefesini bir önceki yazıda konuştuk. Genelde bir tipteki bir işaretçi, genelde aynı tipteki bir değişkeni işaret ediyordu. Peki ya bir işaretçi, sabit bir adresi işaret ederse?

Hmm. İyi güzel, etsin de niye etsin? Gömülü sistemlerde göreceksiniz ki, çalıştığınız platformun (mikrokontrolör, fpga, SoC, vs) sabit bir bellek haritası var. Yani ROM,RAM, çevreseller filan hep sabit adreslerden başlar. Doğal olarak, register’lar da sabit adreslere sahiptir.

Register’lar sabit adreslere sahiptir dedik. Öyleyse biz bunlara erişirken yani buraları işaret ederken aslında sabit adresleri işaret edeceğiz. Bu vesile ile mutlak adresleri işaret eden işaretçilerin nerede kullanılacağı hususunu apaçık bir şekilde gözler önüne sermiş olduk.

Öyleyse şimdi bir örnek üzerinden gidelim. Diyelim ki bizim mikrokontrolörün üç tane versiyonu var: A,B,C. Ve elimizdeki mikrokontrolörün 0xC0FFE nolu bellek adresinde bu kıymetli bilgi yazıyor. Bu bilgiyi nasıl okuyacağız? Hemen yazalım!

Notasyon ve kod gayet temiz diye düşünüyorum. Peki diyelim aynı mikrokontrolörün 0xFACE adresinde bulunan register da mikrokontrolörü başlatmak için olsun. Bizim mikrokontrolörü başlatmak için ille de 0xFACE adresine ‘S’ yazmak gereksin. Onu nasıl yapardık?

Gördüğünüz gibi muhteremler, sabit adresleri işaret eden işaretçileri sıklıkla kullanacağız. Şu ana kadar bellekteki bilgiyi hep int8_t olarak anlamlandırdık. Gerçekçi durumlarda genelde konfigürasyonlar mikrokontrolör register’larında struct gibi saklanır. O sebeple struct’ı nasıl sabit bir adrese gösteririz onu düşünmekte faydalar var.

Benzer bir mevzu ama, registeri doğrudan işaret eden bir etiket de aşağıdaki gibi tanımlanabilir:

Fonksiyon İşaretçileri (Function Pointers)

Fonksiyon işaretçilerinin bir örneğini aslında karar yapıları yazısında vermiştim ama pek açıklamamıştım. Şimdi bu vesileyle bu önemli konuyu da bir nebze daha pekiştirme fırsatı bulmuş olacağız.

C dilinde fonksiyonlar da esasen bir nevi değişkendir. Ancak fonksiyonlar, daha önceden de detaylıca açıkladığımız üzere biraz pahalı değişkenlerdir. Bu vesileyle bedeli ödenerek tanımlanmış fonksiyonların, ikinci aşamada işaret edilmesi ihtiyacı doğmaktadır. Hemen örneğimizi hatırlayalım.

Örneğimiz aslında ballı kaymak. Neden? Çünkü fonksiyon işaretçisini tanımlamak ile yetinmemişiz, o özel işaretçi tipini bir de typedef ile tanımlamışız ki, ihtiyacı olan herkes bu yeni tipten faydalansın. Bir nevi hayrat yaklaşımı olmuş. Neyse… Fonksiyon işaretçisi aşağıdaki gibi tanımlanmış:

Bu yazım tipi sabit. “donusTipi (*isim) (argumanlar)” şeklinde bir kalıbımız var. Fonksiyon işaretçisi böyle tanımlanıyor. Peki buradaki hikmeti ne bu işaretçinin? Switch-case yerine bunu kullandık tamam, aynı şekilde de çalıştı ama bu mevzunun altında yatan felsefe ne? Nesneye dayalı programlamada polymorphism yani çok şekillilik dediğimiz mevzunın C dili ile gerçeklenmesi aslında bu. Yukarıdaki kodda her durummun bir durum fonksiyonu var. Bu fonksiyonun şekli şemali hepsi için ortak. Ve hangi durum olursa, o durumun fonksiyonu çağırılıyor. Her biri aynı şekilde şemalde bu fonksiyonların, hepsini aynı işaretçi işaret ediyor sırayla ama o anki durum ne ise, o an onun fonksiyonu işaret edildiğinden her seferinde ilgili durumun fonksiyonu çağırılmış oluyor. Bu da gerçek hayatın modellenmesi konusunda bizlere büyük avantajlar sunuyor.

Fonksiyon işaretçilerinin kullanım alanları elbette ki bununla sınırlı değil. Eğer bir SDK geliştiriyorsanız, muhtemelen Callback sözcüğü ile yatıp, Callback sözcüğü ile kalkacaksınız. Bu callback mevzusunda da fonksiyon işaretçileri kullanılıyor. Şimdi diyelim ki SDK geliştiriyorsunuz ve SDK’da özel bir olay olduğunda, kullanıcının size söylediği bir fonksiyonun çağırılmasını istiyorsunuz. Yani çağırılacak fonksiyonu aslında bilmiyorsunuz bile. Sadece o olay gerçekleştirildiğinde, sisteme kaydedilmiş bir callback var ise o çağırılsın istiyorsunuz. Bu işi nasıl yazarız?

Şimdi yukarıda, SDK’yı yazanlar olarak biz çiçek gibi event callback register mekanizmasını verdik. Artık MyEvent olayı geldiğinde, eğer olay bilgisi, sınır değerden büyükse, kullanıcının verdiği herhangi bir fonksiyon çağırılacak. Bu fonksiyon herhangi bir iş yapabilir, kullanıcı ne isterse! Ama içinde while(1); gibi terbiyesizliklerin olmaması lazım! Şimdi SDK’yı kullanmak isteyen, usturuplu, terbiyeli bir yazılımcı kendi fonksiyonunu nasıl bizim SDK’ya kaydeder onu yazalım.

Gördüğünüz gibi, bir fonksiyona parametre olarak başka bir fonksiyonu verdik. 🙂 Bu ibretlik olayı fonksiyon işaretçilerinin varlığına borçluyuz. Buradan indirilecek ibreti beyinlerimize indirdiğimizi düşünüyorum. Öyleyse bir sonraki konuya geçebiliriz.

Genel İşaretçi (Void Pointer, void*)

Hiç uzatmadan konuya gireceğim. C dilinde, bir nevi joker olarak kullanabileceğimiz, her yere yedirebileceğimiz, her şeye cast edebileceğimiz bir veri tipi bulunuyor. Bu veri tipi, çok açık söylüyorum void*’dır. Genel işaretçi olarak tarif edebileceğimiz bu işaretçi tipi ile, her şeyi işaret edebilirsiniz. Daha doğrusu, herhangi bir şeyi işaret edebilirsiniz. Bu da bize jenerik kodlama yapma şansı sağlıyor.

Diyelim iki veriyi toplayan bir fonksiyon yazacak olalım. Her bir veri tipi için ayrı ayrı topla fonksiyonu yazmadan nasıl yaparız bu işi? Tüm veri tipleri için olmasa da, 32 bite kadar olan standart veri tipleri için şöyle yaparız:

Gördüğünüz gibi büyük oranda jenerik bir fonksiyon yazmış olduk.  Ayrıca void işaretçisini diğer tipteki işaretçilere cast ettiğimize dikkatinizi çekerim. Bu mereti, her tipteki işaretçiye cast etmek (aktarmak) mümkün.

Son olarak kısa bir hatırlatma yapayım. Bir sistemin kaç bitlik olduğunu öğrenmek için:

Bence void* büyük oranda anlaşıldı. Şimdi yine her zamanki sevimli hareketlerden birini yapacağız. Bilgilerimizi harmanlayacağız. Fonksiyon işaretçileri ile genel işaretçileri birleştirdiğimizde ne kadar güçlü bir şey elde ettiğimizi düşünelim.

Yukarıdaki fonksiyon işaretçisi tipi, giriş parametresi olarak genel işaretçiyi alıyor. Yukarıdaki fonksiyon tipindeki bir fonksiyon, tip ayrımı yapmaksızın her türlü veriyi seri porttan gönderebilir. Float olsun, int olsun, char olsun, int32_t olsun, hatta ve hatta bir fonksiyonu bile seri port üzerinden gönderebilirsiniz 🙂 Ve aynı zamanda size polimorfik bir yapı sunar. Kızarmış ekmek üstünde bal kaymak gibi… Mis.. Afiyet olsun 🙂 Öyleyse devam!

Kısaltma İçin İşaretçiler

C dilinde, kompleks veri yapıları diye bir mevzu var. İlk başta şaka gibi geliyor bu ifade ama bazı veri yapıları hakikaten kompleks olabiliyor 🙂 Bir sturct içinde başka bir struct, onun içinde afedersiniz başka bir struct, onun içinde de bir işaretçi düşünelim. Bu durumda en alt seviyedeki değikene ulaşmak hakikaten bayağı zaman alacaktır. Özellikle tembel yazılımcıları, klavyede bu kadar tuşa basmaktan nefret ederler. Bu gibi durumlarda da kısaltma amaçlı olarak işaretçilerden faydalanabiliriz. Misal:

İlk bakışta komik bir kullanım alanı gibi gözükse de, işin içine girdiğimizde bu tip kullanımların yadsınamaz miktarda olduğunu görüyoruz. Belki de tembelliğin böylesi candır canandır 🙂 Tabi burada bir pointer’ı ekstradan kullanarak bellekten biraz çaldık. Değer mi değmez mi o kararı size bırakıyorum.

Diziler ve İşaretçiler

Diziler ve işaretçiler birbirlerine çok çok yakın iki kavramdır. Nihayetinde her bir dizi, aslında bir işaretçidir. Ancak bu özel işaretçiler tanımlanırken, işaret edecekleri bellek alanları önceden ayrılır.

Diziler de tıpkı diğer değişkenler gibi ilk değer ataması mevzularına tabidir. İlk değer ataması yapılmamış bir dizi tanımı aşağıdaki gibidir:

Burada yalnızca dizinin 10 elemanlı olacağı bilgisi verilmiş. yani u8TestArray değişkeninin işaret ettiği bellek adresinden başlamak üzere 10 byte bu dizinin elemanları olarak sıralanacak.

Şimdi ilk değer ataması yapılmış ancak boyut verilmemiş bir diziye bakalım.

Burada test array aslında bildiğimiz işaretçidir. Gördüğünüz üzere kendisine “Hello!” şeklindeki karakter dizisini yani  string’i atamış olduk. C dilinde string, ayrı bir tip değildir ancak karakterlerden oluşan bir dizidir. Nitekim yukarıdakinin bir benzeri şöyledir:

testArray dediğimiz şey aslında şu aşağıdaki ile aynıdır:

Çünkü dizinin ismi yani değişken adı (testArray), aslında dizinin ilk elemanının adresini taşır (&testArray[0]).

İşte bunun farkında olmakta ve bunu unutmamakta faydalar var.

Yukarıdaki örnekte verdiğimiz Hello! yazısını karakter karakter yazdırmak istesek dizinin her bir elemanını yazdırabileceğimiz gibi, pointer aritmetiği  ile de aynı işi yapabiliriz.

Struct ve İşaretçiler

Yapılar başlıklı yazımda esasen bu konuya değinmiştim ancak ufaktan tekrar etmekte fayda var diye düşünüyorum. Struct genelde kocaman bir yapıyı modellediğinden bellekte kapladığı yer ciddiye alınmalıdır. Hal-i hazırda küçücük olup ciddiye almadığınız bir struct, yazılımın bir sonraki versiyonunda büyüyebilir ve size ciddiye almak zorunda kalacağınız bazı problemler yaratabilir. O sebeple saygıyı baştan göstermekte faydalar var.

Bir struct tanımlandıktan ve onunla ilgili bilgi belleğe yazıldıktan sonra, o veriyi kullanmak için başka bir sturct yaratmak çoğu durumda anlamsız ve mantıksızdır. Onun yerine struct işaretçisi tanımlanarak, ilgili struct’ı işaret edecek şekilde değer ataması yapılmasında sayısız faideler ve feyizler vardır.

Union ve İşaretçiler

Union bildiğiniz üzere; her elemanı belleğin aynı adresini gösteren özel bir yapı. Kendisinin feyizli özelliklerini sizlerle paylaşmıştık. Ancak tanımından da anlaşılabileceği üzere kendisi aslında bir çeşit özel işaretçidir. Dolayısıyla union kullanarak yapabileceğimiz bir çok işi, çok daha çirkin şekilde doğrudan işaretçilerle de yapabiliriz. Misal:

yerine benzer işi yapan şöyle bir kod da yazabiliriz.

Ama dediğim gibi çirkin olur kem olur. Parantez manyağı olmak zorunda kalırız ve kodumuz da anlaşılmaz.

Ancak yine de olayın altında yatan felsefeyi bilmekte faideler var.

NULL İşaretçisi

Bu NULL denen nane çok meşhurdur, her yerde de kullanılır. NULL işaretçisi esasen belleğin 0 numaralı adresini gösteren bir işaretçidir. Kendisinin tipi void*’dır.

Kütüphanelerdeki (stddef.h) tanımına baktığımız zaman şunu görürürüz:

NULL dediğimiz nane işte budur. Belleğin 0 nolu bölgesini gösteren bir işaretçi. Peki neden bir işaretçinin “boş” olup olmadığını kontrol etmek için bunu kullanırız? Çünkü bir işaretçi ilk değer ataması yapılana kadar sıfır nolu bellek adresini gösterir. Dolayısıyla bu ona ilk değer ataması yapılmadığını anlamanın güzel bir yoludur.

Fonksiyonlara Argüman Olarak İşaretçiler

Fonksiyonun pahalı bir değişken olduğunu her fırsatta söylüyorum, söylemeye de devam edeceğim. Şimdi bu pahalılıkta önemli bir gider kalemi de fonksiyonların argümanlarıdır. Bir fonksiyonun argümanları belleğin özel bir bölgesine kopyalanır. Sözü uzatmadan mevzuya dalacağım. Eğer kopyalanan şey devasa bir struct ise vay halinize. Ne demiştik? Struct kopyalamak çoğu durumda mantıksızdır. Demek ki fonksiyona argüman olarak struct yerine struct işaretçisini vermekte fayda var. Bu aynı zamanda fonksiyonun kullanacağı belleğin, fonksiyonu çağıracak kişi tarafından ayrılmasına (allocate etmek) izin verdiğinden, (caller allocation prensibi) fevkalade lezzetli bir olaydır.

Bu mevzu hakkında detaylı bilgiyi ve örnek kodları BURADAN, “Struct’ların Pointer(İşaretçi) ile İmtihanı” başlıklı bölümden bulabilirsiniz.

Fonksiyonlara argüman olarak işaretçi verilmesinin bir diğer önemli kullanım alanı da, o fonksiyonun argümanını fonksiyon içinde değiştirmesine olanak vermektir. Bu özellik yadsınamaz derecede önemlidir. Her fonksiyon tek iş yapmalıdır demiştik ama bazı durumlarda bir fonksiyonun birden fazla değer döndürmesi gerekebilir. Öyleyse o değerlerin argümanlarda işaretçi olarak alınması yeterli olacaktır çünkü bir kez değişkenin adresi bilindi mi, onun içindeki veriyi manüple etmek problem olmayacaktır 🙂

Hemen kısa bir örnek vereyim:

Bu kod çalıştırıldığında çıktısı şöyle olur:

Gördüğünüz gibi Fonksiyon1, a değişkenini fonksiyonun dışında etkili olacak şekilde değiştirememiş, ancak Fonksiyon2 değiştirebilmiştir. Bunun sebebi aslında basittir, Fonksiyon1 a değişkeninin kendisini değil, adi bir kopyasını değiştirmiştir. Nitekim a’ların adresleri yazdırılsa farklı çıkacaktır. Bu merete Japonlar bunshin diyor 😀 Bilenler bilir.

Komut Satırı Girişi

Son olarak, komut satırı argümanlarından bahsedeceğim. Bu, gömülü sistemlerde çok da önemli değil ancak bilmekte faydalar var.

Yukarıdakiler hemen hemen aynı mevzular. Siz yazdığınız kodu derleyip konsoldan çağırdığınızda ona parametre verebilirsiniz. Bunun adı komut satırı argümanlarıdır ve program çağırılırken bu bilgi programa verilebilir. Gömülü sistemlerde kodu komut satırından çağırmadığınızdan bu olay bu amaçla kullanılmaz ama başka amaçlarla kullanılabilir 🙂 Önemli olan mevzu şudur; verdiğiniz argümanlar arasındaki boşluk bulunan kelimelerdir. Bu kelimelerin sayısı argc’ye, kendileri de argv’ye işletim sistemi tarafından aktarılır.

Hemen çok sık verilen şu kodu biz de örnek olarak verelim:

Bu kodu selam.c olarak kaydedip derlediğimizi, ve çıktı olan programın adının da selam olduğunu düşünüyorum. Komut satırından programı şöyle çağıralım “selam kardes kafan cok guzelmis nerden aldin?”

Bu durumda komut satırına girilen argüman sayısı argc = 7 olacaktır. argv[0]’ın gösterdiği yerde programın adı yani selam yazacakken argv[1]’in gösterdiği yerde kardes yazacaktır. Dolayısıyla bu kodun çıktısı şöyle olur:

Sık Yapılan Hatalar

Arkadaşlar işaretçilerin biliçsiz kullanıması çok sayıda hataya yol açabilir ve bunlar gerçekten zorlu hatalar olacaktır. Ancak sizler, işaretçileri buradaki bilgilerle birlikte kullandığınızda bu sorunları zaten yaşamayacaksınız 🙂

*Misal aşağıdaki gibi bir kod yazmayacağınızı umuyorum:

*Bir diğer hata da ilk değer atanmamış bir işaretçinin göstermediği belleğin içine bir şeyler yazmaya çalışmaktır. Kemdir, puan götürür, yapmayınız. Misal:

Daha ptr’nin nereyi gösterdiğini ayarlamadan, bu belleğin içine m’nin değerini yazmaya çalışıyoruz. Önce bu ptr bir yeri göstermeli. Misal:

*Diğer bir hata da, bir işaretçinin, ilk değer atanmamış bir değişkeni işaret etmeye çalışmasıdır. Bu şık bir kullanım değildir. Önce işaret edilecek değişkene ilk değer atamakta faydalar vardır.

*İki işaretçiyi karşılaştırmak da iyi bir fikir sayılmaz. İşaretçiler, bellekteki rastgele alanları göstereceğinden, işaretçileri doğrudan karşılaştırmak anlamsızdır. Anlamlı olabilecek şey, bunların gösterdiği değerleri karşılaştırmaktır.

Daha bunu sıralamakla bitmez ama siz anladınız mevzuyu.

Yazıları beğendiyseniz eğer,  faydalanabilecek arkadaşlarınızla da paylaşabilirseniz sevinirim.

Şimdi devam…

Tekrardan merhabalar. Bu gün C dilinde pointer olarak adlandırılan konu üzerine bir yazı yazmaya çalışacağım. Yine diğer yazılarda ufaktan da olsa bahsettiğim işaretçiler(pointers) hakkında fark yaratabileceğini  düşündüğüm bilgileri paylaşmaya çalışacağım.

Epeyce bir süredir, ne yazık ki yeni bir yazı yayımlayamadım. Ülkemizde yaşanan çok çok üzücü olaylar, hayatın dönem dönem hepimizi vuran yoğunluğu gibi sebeplerle sessiz bir dönem geçirdim. Ancak ne olursa olsun, başladığımız işleri bitirmekte fayda var. Bu vesileyle bu yazımın temasını “vicdan” olarak belirliyorum.

C dilinin belki de en zor konusudur işaretçiler (pointers). Nedendir hikmeti tam bilinmez, bir türlü açık seçik açıklanamamıştır. Benim yorumum şu; işaretçiler çoğu zaman basit kurgulanmış bir yapı olmadığından, anlaması da çok basit değil. Bu yorumuma katılan, katılmayan olabilir ancak sebeplerimi kendimce sıralayıp ardından olayı açık şekilde anlatmaya çalışacağım. Zira olayın aslı oldukça basit.

İşaretçiler belleğe kestirme yollardan erişmeyi sağlar diyebiliriz. İşaretçiler, türlü potansiyel sorunları beraberinde getirdiğinden bazı dillerde kullanımı yasaklanmıştır. Örneğin C#’da pointer kullanımını açmak için kodu güvenilmez (unsafe) yazdığınızı kabul etmeniz beklenmektedir. Yüksek seviyeli dillerde belleğe doğrudan erişim hakikaten güvenilmez kodlar doğurabilir ancak C gibi orta seviyeli bir dilde işaretçi kullanarak bellek erişimi yapmak, doğru tasarım kalıpları ve prensipler izlendiğinde oldukça verimli olabilir. Bizim de niyetimiz, işaretçileri doğru kullanarak C dilinin güçlü olan bu yanına hükmedebilmek bu sayede de güzel kodlar yazabilmek. Sırf işaretçiler risk unsurları yaratabilir diye, onlara kem gözlerle bakmak, onları kötü kullanmak vicdansızlık olur diye düşünüyorum.

Bellek Hakkında

Bildiğiniz üzere bellek dediğimiz esasen fiziksel bir bilgi deposu oluyor. Bu zımbırtının veriyi saklama biçimine göre iki temel çeşidi var. Birincisi Volatile Memory denilen “Geçici Hafıza”. Birisi de Non-Volatile Memory(NVM) denilen “Kalıcı Hafıza”. Efendim ne göre geçici ya da kalıcı? Elektrik gittiğinde gösterdiği davranışa göre. Elektriği kessek  (ya da cihaza hard reset atsak) dahi, geri verdiğimizde veriler saklanıyorsa NVM, saklanmıyorsa VM. Misal RAM bir VM’dir yani geçici bellektir. Hard disk veya flash memory ise NVM yani kalıcı bellektir.

Pointer (İşaretçi) Nedir?

Biz işaretçiler ile hem kalıcı bellekteki hem de geçici bellekteki verilere erişebiliyoruz. Çok önemli olduğu için tekrar edeceğim. Bir işaretçi iki operatör ile ifade edilebilir.

Arkadaşlar C dilinde her şey bir değişken gibi değerlendirilebilir demiştik. Pointer da benzer muameleye tabi olduğundan, onun da bir tipi vardır. Örneğin

yukarıdaki dataPtr’nin tipi uint8_t* olduğundan, bu işaretçi gösterdiği bellek alanındaki bilgiyi uint8_t olarak yorumlayacaktır. Benzer bir yorum farklı veri tipleri için de yapılabilir. Misal float* tipindeki bir değişken, göstereceği adres içindeki veriyi float olarak yorumlayacaktır. Bu bilgiyi daha detaylıca açıklayacağım.

İşaretçileri anlatmanın en iyi yolu örnekler üzerinden gitmektir. Öyleyse aşağıdaki örnek üzerinden başlayalım.

Bir değişken tanımlandığında, ona uygun bir bellek gözü (ya da bellek gözleri) tahsis edilir. Hangi bellek olacağı işletim sisteminin ve derleme ortamının takdirindedir. Yukarıdaki değişkenler farzı misal 0x2015 adresinden başlayarak yerleşsin.

Şimdi kodun bir yerlerinde C dilinde şunları dersek:

Bunların insan dilinde okunuşu şöyle olur: “num değişkeninin değeri 42’dir. ptr işaretçisi ise num değişkeninin adresine eşittir.”

Tanımlandığında num değişkeni 0x2014 numaralı bellek gözünde yer almaktaydı hatırlayın. Buna göre ptr=0x2014 olması gerekir çünkü num değişkeninin adresi budur. Öteyandan ptr değişkeninin adresi 0x2018 olduğundan, ptr’nin değeri bu adreste saklanır. Buna göre 0x2014 numaralı bellek gözünde 42 yazacak, 0x2018 numaralı bellek gözünde ise 0x2014 yazacaktır. Haydi azıcık zahmet edip çizelim.

Şimdi bu ibretlik bilgiyi sınayabileceğiniz tam bir kodu paylaşalım.

Efendim bu kodun benim bilgisayarımdaki çıktısı şöyle:

• Gördüğünüz gibi, num’un adresi hakikaten ptr’nin degerine eşit.
• Ptr’nin gösterdigi deger hakikaten num’un degerine eşit.
• Ve hakikaten ptr, bir degisken olarak bellekte saklaniyor ve adresi num’un adresinden farklı.

Mevzuyu açık seçik gösterdik diye düşünüyorum. Şimdi benzer bir olayı diziler üzerinde anlatalım ki başka püf noktaları görelim.

Öncelikle kodu okuyarak anlamaya çalışınız.

Şimdi bu çıktıları teker teker yorumlayalım. Ancak önce dizinin ve işaretçilerin belleğe nasıl yerleştiğini farz-ı misal bir açıkalayalım.

Bu kodun benim bilgisayarımdaki çıktısı aşağıdaki gibi oluyor.

Şimdi bu çıktıları tek tek yorumlayıp ibretleri beynimize indirelim.

“name” ile tanımlanan dizinin başlangıç adresini benim bilgisayarım 0x22fe40 olarak atamış. p8 ve p32 işaretçilerine name dizisinin başlangıç adresini atadığımdan, hakikaten bu iki isaretcinin degeri name dizisinin baslangıç adresi yani 0x22fe40 olmuş. Buraya kadar güzel, zaten konuştuğumuz şeyler.

p8’in gösterdiği değer ‘O’ karakteri yani 79 sayısı olmuş. Bu normal çünkü p8’in değeri zaten name dizisinin başlangıç adresi idi ve o adresin içindeki verinin int8 olarak anlamlandırılması hakikaten ‘O’ karakteri.

p32’nin durumu biraz daha karmaşık duruyor ama aslında olay çok basit. Big endian little endian olayını hatırlarsınız. Ascii table konusunu da konuşmuştuk onu da aklımızın bir köşesinde tutalım. Ve sihirli sayıyı analiz edelim. 0x65677a4f. 0x4F aslında ‘O’ karakteri [bkz: ASCII table]. 0x7a=’z’, 0x67=’g’, 0x65=’e’. Aaaa, aslında bu bizim name dizisindeki ismin int32_t olarak yorumlanmış hali. İşte işaretçinin tipi burada devreye giriyor. Aynı bellekteki bilgi int32_t olarak (yani 4 byte) işaret ediliyor. Her şey şimdi aydınlandı.

p8++ dediğimizde basitçe p8’in değeri kendi cinsinden artırılıyor. Peki  p8 neye eşitti? name dizisinin başlangıç adresine. int8_t tipi 1 byte olduğundan bu p8’in yeni değeri name dizisinin başlangıç adresinin 1 fazlası oldu.

p32++ dediğimizde basitçe p8’in değeri kendi cinsinden artırılıyor. Peki  p32 neye eşitti? name dizisinin başlangıç adresine. int32_t tipi 4 byte olduğundan bu p32’nin yeni değeri name dizisinin başlangıç adresinin 4 fazlası oldu.

Gerisini yorumlamayı size bırakıyorum. Eksik bir nokta olursa çekinmeden sorabilirsiniz, paylaşabilirsiniz.

Bu arada & ile * birbirlerinin tersidir farketmişsinizdir. Örneğin

dediğimiz nane aslında p8’nin kendisidir çünkü * ile & birbirini götürür. Yine

nanesi de p8’in kendisidir aynı sebepten.

Sizlere nacizane tavsiyem işaretçilerle mümkün mertebe oynamanız.  İşaretçilerin temeli budur. Bir dahaki yazıda uç noktalara değineceğiz.

Yazıları beğendiyseniz eğer,  faydalanabilecek arkadaşlarınızla da paylaşabilirseniz sevinirim.

Şimdi devam…

Merhabalar, bugünkü yazımda C dilindeki yapılardan bahsedeceğim. Ancak bu bahsediş esasen bir girizgah şeklinde olacak. Çünkü yapısal bir dil olan C dilinde, tasarımın temel yapı taşı, bir manada tuğlası, sıvası yapılar olduğundan bu yapıları tek bir yapıda anlatmak oldukça zor olacaktır. Bunu yapmaya çalışıp eksik çok sayıda nokta bırakmak yerine, önce çok derinlere inmeden sizlere yapısal tasarım elemanlarnı ve bunların temel psikolojilerini aktarıp, ardından ilerleyen konularda bunların sanatsal kullanımlarını sunmanın peşindeyim. Bunun daha faydalı olacağına inanıyorum. Dilerim sizlere azami faydayı sağlayacak formatı, bir şekilde tutturabilirim 🙂

Bence bir yazı, lap diye konuya dalmadan önce ne vadettiğini anlatmalı, amacını açıklamalıdır. Ben de struct, enum, union diye başlamadan önce sizlere bunlarla ne yapacağımızı aktarmaya çalışacağım. Haydi başlayalım…

Daha önce de söylediğim gibi, bir programın amacı, gerçek hayattaki bir problemi çözmektir. Gömülü sistemlere özgü olarak sunulan çözüm, gerçek hayatı fiziksel olarak doğrudan etkiler. Yani bir gömülü sistem, genellikle hayatla doğrudan temas halindedir. Gerçek hayattaki bu problemin çözülebilmesi için, sisteme problemin ve çözümün tanımının, çok iyi yapılması gerekir. İşte gerçek hayatın unsurlarının, bizim tasarım ortamımıza aktarılması işine modelleme denir. Modelleme, mühendisliğin en temel konularından biri olmakla birlikte, tasarımın olmazsa olmazıdır. Lafı uzatmayayım. C dilinin yapısal bir dil olarak sınıflandırılmasının sebebi, modellemenin yapılar ile yapılmasıdır. Bu vesileyle bir dile sınıfını verecek kadar önemli bir konuya geçtiğimizi belirtmek istiyorum 🙂 Yapıları hakkıyla kullanmayı bilmeden, karşılaştığımız problemlere güzel çözümler üretebilmemiz mümkün olmayacaktır. Bu sebeple lütfen, bu yazıdan ya da başka bir kaynaktan, yapıları hakkı ile öğrenmeye, hakkıyla biliyorsanız bile bu işi bir adım da olsa ileriye taşımaya gayret edininiz.

Şimdi, C dilindeki struct, enum ve union’un suyunu sıkmaya başlayalım. Bakalım neler çıkacak 🙂

STRUCT

Struct, gömülü yazılımda çok çok çok büyük öneme sahip. Bu sebeple affınıza sığınarak, uzatarak da olsa basitçe açıklamaya çalışacağım. Bunu yaparken diziler ile analoji kurarak struct’u sizlere açıklamaya çalışacağım.

Bildiğiniz üzere diziler, aynı veri tipindeki birden fazla değişkeni bellekte saklamak için kullanılırlar. Ancak bu veri güruhu ya da veri dizisi bellekte saklanırken yan yana saklanır. Yani çok sıra dışı bir durum yok ise bir dizinin tüm elemanları belleğe ardı sıra yerleşir. Dizi tanımının en önemli iki özelliğini bu bağlamda tekrar sıralarsak :

1. Dizinin tüm elemanlarının aynı veri tipinde olması
2. Dizinin elemanlarının belleğe ardışıl yerleştirilmesi.

Daha dizilere değinmedim ama, bu iki özellik diziler hakkında ayan beyan görülen ilk iki özelik. Struct veri tipi de (dizilere benzer şekilde) bir veri topluluğunu ifade eder ancak bu topluluktaki her bir veri (değişken), farklı tipte olabilir. Yine struct içindeki bir veriye ( yani struct elemanına), dizi indeksi gibi bir indeks yerine, bu verinin ismiyle erişilir.

Struct, birbiriyle ilintili birden fazla farklı kavramı birleştirerek bir context(konu) çerçevesinde toplamaya yarayan çok güçlü bir modelleme aracıdır. Güçlü olmasının sebebi ise, farklı veri tiplerini aynı yapı içinde paketleyebilmesinden gelir.

Struct’un bellek kullanımı dizilere benzerdir yani struct içindeki elemanlar belleğe ardışıl olarak yerleşir. Ancak eğer struct içindeki elemanlar, kodlamanın yapıldığı hedef platformun adres genişliğine tam oturmuyorsa, struct alignment problem denilen problem ortaya çıkar. Bu durumda, struct elemanları bellek adresinin bir veya bir kaçını tam olarak dolduramadığından, derleyici bu sorunu gidermek için arada kaydırmalar ya da boş yer bırakmalar gibi operasyonlara gider. Bu durumun bilincinde olmakta büyük faydalar var.

Struct tanımı birde farklı şekilde yapılailiyor. Dilim döndüğünce her birini anlatmaya çalışacağım.

Etiketlenmiş (tagged) struct tanımı aşağıdaki gibi yapılır:

Yukarıdaki örnek kodda, yeni tanımlanan struct’ın etiketi Part’dır. Ve bu struct’un elemanları sırasıyla number, on_hand, name ve price’dır. Bir struct içindeki elemanların tümünün farklı tipte olabileceğini ancak bunun bir zorunluluk olmadığını lütfen unutmayınız.

Bu noktada, “struct Part” tanımının, bir veri tipi olduğunu ve “struct Part” tipinden değişkenlerin yaratılabileceğini unutmayınız. Örneğin “sruct Part MonopolyGame;” dediğimizde Part tipinde bir monopoly oyunu yaratmış oluruz. Ve örneğin bu oyunun fiyatına şöyle erişebiliriz.

Etiketli struct tanınımda, struct tipini tanımlarken aynı zamanda değişkenleri de tanımlamak mümkündür.

Gördüğünüz gibi yukarıdaki kodda joe, sue ve mary isimli üç öğrenci tanımlanmış. Tabi bu tanımları yukarıdaki şekilde yapmak, sonradan yeni elemanlar tanımlanamayacağı anlamına gelmez. Pekala da sonrasında da yeni elemanlar tanımlayabiliriz.

Yukarıdaki yönteme ek olarak, struct tipi tanımlamadan, struct şeklinde değişkenler tanımlamak da mümkündür. Ancak bu durumda, aynı tipten yeni değişkenler tanımlamak mümkün olmayacaktır. Aynı zamanda bunların bir fonksiyona argüman olarak verilmesi de kolay yoldan mümkün olmayacaktır. Esasen bu da akıllıca değerlendirilip, kullanımı kısıtlama amaçlı olarak kullanılabilecek bir özelliktir. Ancak bu durum, tekrar kullanılabilirliği de öldüreceğinden dikkatlice kullanılmalıdır. Şimdi bu tarif ettiğim duruma bir örnek vereyim:

Temel anlamda struct tanımını öğrendik. Şimdi bir sonraki seviyeye geçelim 🙂

Typedef’in Struct ile Kullanılması

typedef, programlama yapan kimselerin kendi veri tiplerini tanımlayabilmelerini sağlar. Bu veri tipi, basit veri tipi (uint8_t gibi) olabileceği gibi; complex (birden fazla  veri tipini aynı anda içinde barındıran) yapıda da olabilir.

İyi de yazılımcı kendi veri tipini tanımlamaya neden ihtiyaç duysun ki? Çünkü temel veri tipleri sadece genel amaçlar içindir. Ve modellenen problemler genellikle özel problemlerdir ve bu probleme özgü bilgi setlerini barındırırlar. İşte bu bilgi setlerini modeleyebilmek ve bu modeli tekrar kullanabilmek için typedef sözcüğünden faydalanırız.

Hemen örnek verelim:

Yukarıda Integer olarak adlandırılan, aslında int tipinin aynısı olan yeni bir veri tipi tanımlanarak bu veri tipindn 3 adet değişken yaratılmıştr. Böyle bir şey ilk bakışta saçma gelebilir ancak burada büyük ibretler vardır. Misal verecek olusak:

1. Integer isimli bir veri tipi, okunabilirlik açısından int’den çok daha iyidir.
2. Gerek duyulursa typedef ileride farklı şekilde değiştirilebilir. Örneğin “typedef long Integer”. Bu sayede Integer tipinden tanımlanmış tüm değişkenler bundan etkilenir. (Bunun dezavantaj oluşturduğu durumlar da vardır)

Ayrıca bu sayede, örneğin C dilini Türkçeleştirmek bile mümkündür 🙂

Hemen misal verelim:

Epey eğlendik ama artık C üzerine kurulmuş küçük bir programlama dilimiz oldu. Hem de  TÜRKÇE!

Tüm bu eğlenceye ek olarak, typedef tanımının asıl gücü, kompleks veri tiplerinin tanımlanmasında ortaya çıkar. Bu da tam olarak struct’ı anlatmaktadır.

Diğer değişkenler için geçerli olan scope kavramı, struct için de aynen geçerlidir. Typedef olsun ya da olmasın, struct tipi tanımlandığı yerin scope’u kadarlık bir bölgede tanımlı olur. Ne demek istiyorum? Misal typedef struct ile yapılan bir veri tipi tanımı bir fonksiyonun içinde yapıldıysa, o değişken tipi ancak o fonksiyonun içinde kullanılabilecektir. Her yerde kullanılmasını istediğiniz bir veri tipi tanımlamak için, onu h dosyasında tanımlamanız yeterli olacaktır. Bu sayede o h dosyasını include ile ekleyen her c dosyası, tanımlanan bu yeni veri tipini kullanabilecektir.

Şimdi bizim öğrenci örneğini typedef ile yapalım.

Artık, Student tipi yeni bir veri tipi olarak tanımlandığından, Student tipinden yeni değişkenler yaratacağımız zaman artık bir daha struct yazmaya gerek kalmaksızın değişken tanımı yapabileceğiz. Misal şöyle:

Yukarıdaki örnekte, struct’un etiketi ile veri tipi aynı tanımlanmıştır. Bu mümkün olmakla birlikte zorunlu değildir. Aşağıdaki tanım, yukarıdaki ile aynıdır.

Ben genelde struct tanımlarını yukarıdaki gibi yapıyorum. Kullanımı daha kolay geliyor 🙂 Aynı zamanda kod bence daha anlaşılır oluyor ancak bu kısmı tartışmaya tamamen açık bir yorum.

Struct’a İlk Değer Ataması Yapmak ve Struct’ların Birbirine Atanması

Struct tipinde olan değişkenlere de farklı şekillerde ilk değer ataması yapılabilir. Süslü parantez içinde, her bir eleman sırası ile virgül ile ayrılarak ilk değer ataması yapmak mümkündür. Misal verelim:

Yukarıdaki örnekte susie adlı  öğrencinin gpa yani not değeri girlmediğinden ilk değer olarak 0.0 değerinin not olarak atanması beklenir. Ancak bu beklenti gerçekleşmeyebilir. İlk değer ataması yapılmayan değerler her zaman risk unsurudur ve mümkünse tüm verilere ilk değer ataması yapılmalıdır. Neyse 🙂

İlk değer ataması bundan farklı şekillerde de yapılabilmektedir. Örneğin Linux kaynak dosyalarında sıklıkla göreceğiniz bir değer atama şekli aşağıdaki gibidir:

Yukarıdaki yöntem C’nin C99 destekleyen derleyicileri ile mümkündür ve bu sayede struct içindeki değişkenlerin sırası önemsiz olmaktadır. Çünkü zaten “.isim” ile hangi elemana ilk değer ataması yaptığımızı belirtmiş oluyoruz. Bu yöntemin, diğer yönteme göre çiçek gibi bir güzelliği vardır. Haydi diyelim bir struct tanımladınız, sonra günlerden bir gün içiniz elvermedi ve structa bir eleman daha eklediniz. Eğer sıralı ilk değer ataması yaparsanız (ilk örnekteki gibi) başınız dertte demektir çünkü yarattığınız her bir sturct değişkeni için sırayı tek tek bulup doğru yere ilk değer atamasını yazmanız gerekir. İkinci yöntemde ise koyun noktayı yazın yeni değişkenin adını, atayın değeri ve arkanıza yaslarken build tuşuna basın 🙂 Linuxcu dayılardan alınacak çok ibret var ama, burada da bu yöntemi seçerken bir bildikleri olduğunu görüyoruz.

Struct’ların Birbirlerine Atanması

Aynı tipteki iki değişken birbirine atanabilir. Bu bağlamda aynı struct tipindeki iki değişken de doğrudan birbirlerine atanabilecektir. Yalnız struct’ların birbirlerine atanmaları çok sıkıntılı ve dikkat edilmesi gereken bir mevzudur. Hatta struct’un herhangi bir şeye atanması dikkatle yapılması gereken bir işlemdir ve bazı riskler barındırır.

Ne demek istiyorum? Diyelim ki sturct içinde bir pointer var. Bu pointer bir yer işaret ediyor. Bir struct değişkenini bir başkasına atamak, o structu kopyalamak anlamına gelmez. Sadece iki sturct’un da aynı yeri göstermesi anlamına gelir.

Bu kısım biraz uzayacak olsa da, önemli olduğundan detaylıca anlatmaya çalışacağım. Bizim Student sturct’ının tipindeki değişkenleri birbirine atamak/kopyalamak filan isteyelim. İlk anda akla gelen 3 temel yol var.

İlk yöntem, camiada amele yöntemi olarak (asla hakaret/aşağılama amaçlı değildir!) bilinir ve çok da tercih edilmez. Sonuçta Veli’nin tüm bilgilerini Ali’ye atamak istiyorsak bunun daha güzel yolları var.

İkinci yöntem atamadan çok kopyalamadır. Adı üstünde iki değişkenin işaret ettiği ya da tutulduğu bellek alanlarını verilen uzunluk (sizeof Student) kadar byte kopyalar. Bu olay hard copy olarak geçer ve bellek içeriği tamamen kopyalanır. Yani aynı bilgileri taşıyan iki farklı adres bölgesi olur. Bu yöntem çok belayı def eder. Ali’nin bilgilerini Veli’ye aktarıp sonra Veli’yi okuldan kovmak istiyorsanız bu yöntem birebirdir çünkü Veli’yi kovsanız bile, Veli’nin bilgileri Ali’nin aklında ayrı bir yerde saklanmış durumda olur.

Üçüncü yöntem kısa gözükmekle birlikte derleyiciye çok daha fazla optimizasyon şansı bırakır. Bu da beklemediğiniz bazı davranışları beraberinde getirebilir. Okunurluk açısından da iki değişkeni birbirine atamak, kopyalamaktan daha farklı bir mesaj verir ve doğal olarak = operatörü burda kopyalama değil atama işi yapar. Yani bizim Veli bildiğimiz kişi artık aynı zamanda Ali’dir. Bu durumda Veli’nin başına birşey gelirse Ali’nin de başına bir şey gelecektir. Bu da çok büyük bela demektir.

Sizlere nacizane tavsiyem, bu yöntemler üzerinde denemeler yaparak davranışı bir kez de kendiniz görünüz. Sonra bir gün başınıza gelir, öyle okuyup geçerseniz hatırlamazsınız bile 🙂 Bu konunun oturması için bu atamaları yapıp, altında printf ile struct adreslerinin ve struct elemanlarının yazdırılması şart. Belki aranızda sturct adresi nasıl yazdırılır bilmeyen olabilir, onun için de hemen şöyle ufacıktan yazıverelim:

Başınız ağrımasın istiyorsanız, yukarıdaki amaç için yöntem 2’yi öneririm. Ne yaptığınızı çok iyi biliyorsanız yöntem 3’ün de avantaj getireceği durumlar vardır. Misal daha az bellek kullanırsınız. Ama çok dikkat etmeniz gerekir. Hem de eğer kodu takım olarak geliştiriyorsanız, sizin çok dikkat etmeniz yetmez, arkadaşlarınızın da aynı dikkati göstermesi gerekir. Eğer takım arkadaşlarınızı seviyorsanız, onlara dikkat etmeleri gereken yeni şeyler vermeyin. Zorlaştırmayın, kolaylaştırın 🙂

Struct’ların Pointer(İşaretçi) ile İmtihanı

Şimdi daha işaretçileri anlatmadım ama, zaten bu yazı dizisinin doğası gereği sizin onu referans verilen kaynaklardan ya da başka yerlerden öğrenmiş olmanız ya da zaten biliyor olmanız gerekiyor. Ki burada olayın biraz daha ince detaylarını, felsefi yönlerini değerlendirelim 🙂

Pointer yani işaretçi dediğimiz nane, herhangi bir şeyin adresini tutabilir. Zaten işaret ettiği şey de o adresin içindeki veridir. Pislik yapıp farklı türde işaretçiler ile bambaşka türden verileri işaret etmek de çirkin olsa da mümkündür. Ama öyle şeyler yapmayacağız, pointer hangi tipte veriyi işaret edecekse o tipi gösterecek.

Örnek kodumuzda, sptr değikeni struct Student* (struct Student işaretçisi) tipinde bir işaretçidir ve haliyle struct Student tipinden bir veriyi işaret etmek ister. Nitekim bu işaretçi, isteğine kavuşup alice’i işaret etmiştir. Struct’ları fonksiyona argüman olarak filan verecekken tüm veriyi kopyalamak feci derecede kötü bir tercihtir. Bu gibi durumlarda struct’ın kendisini kopyalamak yerine, bellek adresini kopyalamak daha mantıklıdır. Misal bizim Student struct’ı nereden baksanız 28 Byte filan vardır. Oysa 32-bit’lik bir platformda her adres 4 Byte’dır. Bu sayede fonksiyona bu bilgiyi aktarırken 28 byte yerine 4 byte kopyalayarak, tam 24 byte kara geçmiş olduk.  Böyle güzide bir fonksiyon örneğini aşağıda hizmetinize sunuyorum.

Bu fonksiyonu çağırmak için de aşağıdaki gibi  adresi(&) operatörünü kullanabiliriz.

Dikkat ederseniz implementasyonda myStudent.name yerine myStudent->name yaptık. Bunun sebebi, myStudent bir pointer olduğundan onun gösterdiği bellek alanını struct olarak düşünüp oradaki name değerine ulaşmayı sağlayan operatörün -> operatörü olmasıdır. myStudent değişkeninin tipi struct olmadığından (çünkü struct işaretçisidir), nokta ile elemana ulaşmak doğal olarak mümkün olmaz. Ancak myStudent dediğimiz zaman artık  (myStudent) ifadesinin tipi bir struct olacaktır. Dolayısıyla onda nokta ile erişim yapmak aşağıdaki tüm şekillerde mümkündür.

Bizim yapılar (struct’lar) içlerinde temel tiplerin ya da kompleks tiplerin işaretçilerini taşıyabilir. Görürseniz garibinize gitmesi için bir sebep yoktur.

Sturct içinde işaretçi görürseniz, sturct ataması yaparken iki defa düşünün ve yöntem 2’yi aklınızda tutun lütfen 🙂

Struct Bit Erişimi

Bu kısım çok çok çok çok önemli. Dataheet modelleme ve sürücü yazma işlerinde burayı bilhassa çok kullanacağız. Eğer bu konuda öğrenebileceğiniz yeni bir şeyler var ise, lütfen dikkatle okuyunuz.(Zaten okumadan bunu kimse bilemeyecek 😀 )

C dilindeki standart veri tipleri ile, en küçük BYTE erişimi yapabilirsiniz. Oysa stuct ile belleği bit bit modellemek mümkündür. Bu hem bellekten kazanç sağlar, hem de örneğin datasheet modellemesinde, çiçek gibi modelleme yapma imkanı sunar. Datasheet modellemeyi ileride anlatacağım ancak, lütfen bu kısmın çok önemli olduğunu unutmayınız, unutturmayınız.

Hemen hızlıca örnek kodu yazalım.

is_element:1 demek, is_element değişkeni 1 bit yer kaplayacak demek. Bu durumda bu değişken gerçek bir bool oluyor. atomic_number:8 demek, atomic_number 8 byte yer kaplayacak demek. Bu durumda en fazla 255’e kadar değer alabilecek bu numara.

Her şey tamam da uint32_t ve reserved niye var. Sebebi şu; 1 bit işaret edebiliyorsunuz diye bellek içindeki her bir biti canınız istediği şekilde yönetemezsiniz. Ne demek istiyorum? 32 bit’lik bit platformda her bellek gözü 32’bit olacaktır. Ve siz bir bit’lik bir sturct tanımlasanız bile, daha önce bahsettiğim sturct alignment problemi yüzünden geriye kalan 31 bit israf olacaktır. Derleyici burayı optimize etmek isterse de vay halinize çünkü sizin 1 bitiniz ciddi olmayan bir azınlık olduğundan, çoğunluğun bekası için feda edilebilir. Bunu engellemek için struct’umuzun boyutunu 32 bite tamamladık. Nasıl yani; 1+1+1+1+4+8+16 = 32 oldu. 32 bite tamamlayacağımızı peşin peşin söylemek içinde  her elemanın tipini uint32_t: yaptık. Bu sayede hem olası yanlış optimizasyonları engelledik hem de kimyasal envanter için gerekli onca bilgiyi 32 bit’de sakladık. Peki böyle yapmasaydık da aşağıdaki gibi yapsaydık ne olurdu?

Bu durumda bizim kimyasal envanter 7 byte yani 56 bit tutacaktı çünkü bool tipi asla 1 bit tutmaz genelde 1 byte tutar. Struct memory alingment olacağından bu itina ile 64 byte’a tamamlanacaktı. Yani tam 2 katı bellek kullanmış olacaktık. 1000 envanterde kaybedine tam 4000 Byte 🙁 Hiç gerek yok 🙂

Sturct için ilk turda bu kadarı yeterli.

ENUM

Enumerasyon diye Türkçeye ittirilmeye çalışılan bu terim aslında etiketlenmiş sayı yığınından başka birşey değil.  Benim bildiğim tam bir çevirisi olmamakla birlikte, sayım etiketi olarak isimlendirmek mümkün olabilir. Ya da kısaca enum da denebilir. Enum sayı gibidir demiştik ama bazı farkları var tabi (o farknan da çok güzel oldu). Enum tipinde:

• Sadece önceden belirlenmiş sabit değerlere izin verilir.
• Tanımlanmış her bir değer isim ikilisi vardır. Bu sebeple enum ile çalışırken sayılar yerine ilgili değere karşı düşen isim kullanılır.

Burada çokca feyizler vardır. “#define ile benzer bu” diyenler olabilir. Oraya da geleceğiz.

Hemen bir kaç tanımlama örneği patlatalım yine:

Ben yine yazım olarak ve tanım olarak aşağıdaki şekli daha şık buluyorum:

Burada oyunun kuralları basit:

• Herhangi bir enum elemanına, özel bir değer atanabilir: misal E_DIRECTION_NONE sayım etiketine 0 değeri atadık.
• Değer atanmayan sayım etiketleri, bir önceki etiketten bir fazla değer alır. Buna göre E_DIRECTION_NORTH etiketinin değeri 1, E_DIRECTION_SOUTH etiketinin değeri 2 oldu vs.
• Eğer ilk etikete değer atanmadıysa, ona otomatik olarak sıfır değeri atanır.

Esasen size bir sır vereyim, aynı değeri birden fazla etikete atamak mümkündür. Ama inanın bana bu alenen çirkinleşmektir, ve çirkinleşmenin hiç ama hiç luzumu yoktur!

Enum ve Define Karşı Karşıya

Hızlıca özetlemek gerekirse; enum bir veri tipidir, define ise derleyicinin kopyala yapıştır yaptığı bir etikettir. Doğal olarak enum tipinde değişken tanımlayabiliyoruz, nitekim tanımladık. Bu değişkenler doğal olarak RAM’de tutulur (const tanımlanmadılarsa!). Define her yere aynen yapıştırılacağından, genişletilebilirlik açısından enum kullanmak çok faydalıdır. Enumerasyon yapmak için define kullanmayınız, enum kullanınız. Etiketleme (define) yapmak için enum kullanmayınız, define kullanınız.

Diyelim bir durum makinasının durumlarını saklayacaksınız. Burada enum kullanmak gerekir çünkü eğer define kullanırsanız, yarın yeni bir state eklendiğinde ve onun ara değerde olması gerektiğinde, tüm define’ları teker teker değiştirmeniz gerekir. Oysa enumda rastgele bir yere yazdığınızda su akacak ve yolunu en güzel şekilde bulacaktır.

Şimdi enum ile ilgiliverdiğimiz bu örneği kod olaraktan aktaralım:

Gördüğünüz üzere çiçek gibi oldu çiçek 🙂

UNION

Geldik üç silahşörlerin üçüncüsüne… Union yani birlik!

Bizim unionlar aynen struct gibi tanımlanır ve kullanım şekilleri (kullanım yerleri değil) çok çok benzerdir. Ancak çok önemli bir fark vardır:

Struct’lar içlerindeki verileri ardışıl olarak saklayabilecek kadar belleği kendilerine ayırırlar. Union’da ise union’un boyutu, union içindeki en büyük boyutlu elemanın boyutu kadardır çünkü union’un tüm elemanları aslında belleğin aynı gözünü (aynı adresi) gösterirler. Bu özellik başta işe yaramaz gibi gözükse de, özellikle verinin bilgiye dönüştürülmesinde yani yorumlanmasında çok işe yarar şekilde karşımıza çıkmaktadır.

Hemen ibretlik bir kod paylaşalım.

Burada union kullanılarak 4 byte’dan kar edildi. Çünkü aynı uçuş sturct’ı içinde eğer uçuş tipi kargo ise float olarak tonaj değişkeni, eğer uçuş tipi yolcu ise uint32_t olarak nPassengers (yolcu sayısı) değişkeni aynı bellek gözünü gösterir. Bu olay, inanılmaz zekice bir olaydır ve anlaşılmayı hak etmektedir.

Burada union kullanılmasa idi, haybeye 4 byte harcanacaktı. Bu durumda nPassengers ve tonnages değişkenleri belleğe ardışıl olarak yerleşecekti. Halbuki düşününce böyle bir ihtiyaç gerçekte yok çünkü bu iki değişken asla aynı anda kullanılamayacak. İşte burada union geldi ve bir Flight için 4 byte, 100 Flight için 400 byte kar etmemizi sağladı.

Kodun ne kadar karizmatik olduğuna değinmiyorum bile. Belki oradan alıp yürüyecekler de olabilir.

Hemen eski yazılarımızda açıkladığımız ibretlik bir örneği daha sizlerle paylaşıyorum:

Burada da union ile yine bit kaydırma, maskeleme işlerini hiç yapmadan 32 bitlik bir veriye hem byte byte, hem 2 byte 2 byte hem de tümden erişebiliyoruz. Bu olayı da özellikle haberleşme yazılımlarında sıkça kullanacağız. Örnek kodlarla bunları denemeyi unutmayınız 🙂

Yazıları beğendiyseniz eğer,  faydalanabilecek arkadaşlarınızla da paylaşabilirseniz sevinirim 😉

Şimdi devam…

Selamlar efendim. Bugünkü yazımızın naçizane konusu, C dilindeki döngü yapıları olacak. Kontrolsüz dönüşler mide bulandırır malumunuz. İşbu döngüleri nasıl yapar, nasıl ederiz de dönme dolap misali zevk verir hale getiririz bunu dilin döndüğünce anlatmaya çalışacağım. Nasıl anlatacağım? Örnekler ile efendim.

Bir kaç basit kural ile, olayın özünü aktarmaya çalışacağım. Meselenin aslı ortaya kondu mu, çözüm bulmak kolay olur demişler 🙂

Döngülerin Sabit Limitler İle Sınırlandırılması

Efendim malumunuz, ağzımızdan çıkan iki kelimeden biri “sınırlı” sözcüğü. Gömülü sistemler şöyle sınırlı, böyle sınırlı deyip duruyoruz. Madem her-şey böyle sınırlı, sonlu sürede bitmesini istediğimiz işler için de bir sınır koymamız şart 🙂

Bir kere döngü dediğimiz nanenin, statik olarak öngörülebilir, sabit bir üst limitinin olmasında sayısız faydalar var. Bunu sadece ben demiyorum, kodunuzu hangi statik kod analiz programına verseniz, aynısını size o da söyleyecek. Yalnızca onun benim kadar nezaketle söylemeyeceğini bildirmek isterim.

Peki her döngü ille sınırsız mı olacak? Bir sınır konulanlar evet. Ama task tanımlamalarında vs yapılan bazı döngülerin özellikle (sözde) sonsuz olması gerekir. O zaman da ben bunu bilinçli yaptım, ne yaptığımın da farkındayım diye bu döngünün tepesine ecnebice;

ya da kendi dilimizde;

gibisinden birşeyler yazmakta fayda var.

Muhteremler, tamam peki sınırlı döngü olacaksa sınır olur zaten dediğinizi duyuyorum. Önemli nokta bu sınırın, deterministik ve sabit bir sınır olması. Hemen mevzuyu yine örnekle açıklayayım.

Kötü Örnek:

Mesela bu yukarıdaki döngü ne zaman biter? Mantıken bitmez aslında ama, pratikte indexLimit değeri taşıp sıfırlanıp index değerine tur bindirince bir yerlerde belki biter. Bu durum oldukça çirkin bir durumdur ve genelde yok yere hem uygulamanın kompleksitesini doğrusal olmayan yani tahmin edilmesi güç noktalara getirebilir, hem de gereksiz yere çokça güç tüketimine sebep olur. Mazallah daha fena hadiselere de sebep olabilir ama onları söylemeye dilim varmıyor.

Peki ne yaparız? Bir önceki yazıdan kopyayı çekiyoruz.

İyi Örnek:

Yine imdadımıza define yetişti. Bizim dayının kulakları çınlasın. Artık döngünün, çiçek gibi bir limiti var. Hem ne olduğu hem ne olacağı gayet anlaşılır. Kodu makine için değil insan için yazdığımızı hatırlayacak olursak, konsepti anlatan kodlar yazmanın ehemmiyetini idrak etmemiz kaçınılmaz olur.

Erişilebilir Döngü Sınırı

Şimdi diyelim sınır, öngörülebilir bir sınır. Ama arada mayınlı bölge var ulaşmak mümkün değil. Böyle sınır, ancak hasret ve hüzün doğurur. Döngüyü kontrol eden sayacın, döngü sınırına varabilmesi gerekir. Bazen farketmeden, erişilemez döngü sınırları koyuyoruz. Bundan çekinmek ve tiksinmek lazım.

Misal üzerinden gidelim yine ki mevzu havada kalmasın, ayakta kalmasın, yerine otursun. Diyelim döngüyü kontrol eden sayaç uint8_t cinsinden ve döngünün sınırı da 2000. Bu durumda aklı başında herkes bir durur ve der ki, aga bu nedir? Niye böyle der? Çünkü uint8_t tipinde birisi asla ve asla 2000 değerine ulaşamaz. İstemsiz olarak yaratılmış bir sonsuz döngüye hoşgeldin diyebilirsiniz. Hatta hoş geldin faslından sonra çay kahve de ikram edebilirsiniz çünkü döngüden asla çıkılmayacağından her şey için yeterince zaman olacaktır. Tabi bu durumda döngünün dışını yani özgürlüğü unutmak gerek. Neyse, demek ki neymiş; erişilemeyecek döngü sınırı kötüymüş.

Kötü Örnek:

Çok söze gerek yok. Peki iyisi nasıl olur bunun? 1000’e kadar sayacaksanız ona göre bir sayaç tipi seçmekte fayda var. uint16_t olabilir mesela ama 2 byte sıkıntınız yoksa şayet, ben gelecekteki değişikliklere de pay bırakmak için uint32_t tanımlardım.

İyi Örnek: