Gömülü C – 4 : Sabitler ve Yorum Satırları

27 November 2014 by ozenozkaya

Önceki yazıda veri tipleri, değişkenler ve isimlendirmeden bahsetmiştim. Bu yazıda yorum satırlarından ve sabitlerden kısaca bahsedeceğim.

NŞA’da sabitler ve yorumlarla ilgili bahsedilebilecek şeyleri zaten okuduğunuzu / bildiğinizi varsayıyorum. Nitekim herhangi bir C kitabında ya da tutorial’inde mutlaka bir takım temel şeyler yer alıyor. Bu kısımda yine birazcık daha fazlasına değinmeye çalışacağım 🙂

YORUMLAR

C dilinde yorum satırları iki şekilde yazılır. Her iki duruma da örnek olarak aşağıdaki kod parçası örnek gösterilebilir:

#include <stdio.h>
#include <stdint.h>
#include <string.h>

/*
Asagidaki fonksiyon main fonksiyonudur.
Genelde C dilinde yazilimis bir kod, 
main fonksiyonundan baslanarak isletilir.
Bu da bir yorum satiridir.
*/
int main()
{
//haydi bir degisken yaratalim
uint32_t workOfThisProgram=0;

return workOfThisProgram;
}

#include <stdio.h>

#include <stdint.h>

#include <string.h>

Asagidaki fonksiyon main fonksiyonudur.

Genelde C dilinde yazilimis bir kod,

main fonksiyonundan baslanarak isletilir.

Bu da bir yorum satiridir.

int main()

{

//haydi bir degisken yaratalim

uint32_t workOfThisProgram=0;

return workOfThisProgram;

}

Gördüğünüz gibi tek satırlık bir yorum yazmak için “//yorum”, çok satırlı yorum yazmak için ise “/* yorum */” kullanılır. Yıldızlı olan blok yorum esasen C++’da olan bir özellik olup sonradan faideleri görülüp C’ye de aktarılmıştır. Yorumun program için açıklayıcı olmasına dikkat edilmelidir.

SABİTLER

C dilinde yaratılan değişkenler, bellekte bir adreste saklanırlar. Bu değişkenlerin saklanış şekillerini bir önceki yazıda incelemiştik. Bu değişkenleri yaratırken, değişkenlerin bir işe yaramasını istiyorsak, değişkenlerin değer alması mecburi olacaktır. İşte bu değer atamasında, bir değişkeni başka bir değişkene atayabileceğimiz gibi, bir değişkene sabit bir değer de atayabiliriz. Misal,

uint8_t abcProtokolununBesmelesi=0x18;
uint8_t ehliyetAlmaYasi = 18;
uint8_t ismininBasHarfi = 'Ö';
uint16_t birYildakiGunSayisi = 365;
float birYildakiGercekGunSayisi=365.25;
float piSayisi= 3.14;
int8_t izinVerilenMinSicaklikCelciusCinsinden=-40;

uint8_t abcProtokolununBesmelesi=0x18;

uint8_t ehliyetAlmaYasi = 18;

uint8_t ismininBasHarfi = 'Ö';

uint16_t birYildakiGunSayisi = 365;

float birYildakiGercekGunSayisi=365.25;

float piSayisi= 3.14;

int8_t izinVerilenMinSicaklikCelciusCinsinden=-40;

Değişkene sabit değer ataması yapılırken, sabitin boyutunun değişkenin boyutu ile uyumlu olmasına dikkat etmek gerekir. Misal 8 bitlik bir değişkenin alabileceği azami değer 255 iken ona gidip 65372 gibi bir değeri atamaya çalışmamak gerekir. Ama oldu ki atadık, ne olacağını da bilmemiz gerekir. Bu durumda değişkene 65372’nin 255 modundaki değeri atanır. Bu da değerin bellekteki yerleşiminin düşük öncelikli byte’ı demektir. Tabi bu derleyiciden derleyiciye değişir.

AĞZIMDAKİ BAKLA

Şimdi gelelim asıl mevzuya… Esasen yorum satırları yazılım dünyasında büyük tartışmalara sebep olmuştur. Hatta benim de bir mensubu olduğum “birileri” yorum satırlarının mecburi durumlar dışında kullanılmaması gerektiği, gerektiği yerde de kullanılmamasının hata olduğu yönünde görüş bildirmiştir. Okulda ders aldığım hocamın da mensubu olduğu “birileri” ise, yorumsuz kodu koddan saymamış, reddetmiş, sıfır vermiş, onu hakir görmüştür.

Şimdi mevzu aslında yorum olup olmaması değil bence. Her ne kadar bu konuda bir taraf olsam da, görüşümü detaylıca açıklayacağım. Sonrasında yolunuzu seçmek üzere karar size ait 🙂 Ben derim ki, bir yazılım, baştan iyi tasarlanmış olmalıdır, iyi implemente edilmiş olmalıdır, iyi yazılmış olmalıdır. Yani kod öyle yazılmalıdır ki, ne iş yaptığını zaten anlatmalıdır. Bunu sadece ben de söylemiyorum “self-descriptive” yani kendini ifade eden kodlama, bir yazılım kalitesi unsuru olarak literatürde bakidir. Sonuçta C,C++,Java ne olursa olsun söz konusu araç bir dildir ve dilin kuralları herkes için ortaktır. int i=5 derken, dili bilen herkes i diye bir değişkenin, int cinsinden yaratıldığını ve ona 5 değerinin atandığını bilir. Sorun, bu 5 değerinin ne olduğudur ve i’ye niye atandığıdır. i’nin neden int olduğu ve neden 5’in ona atandığı da diğer sorular tabi ki. Şimdi kimisi der ki ben pis pis kodumu yazarım, üstünü de yorumla sıvarım. Nasıl mı? Misal:

int i = 255;// dizinin son indeksi

1	int i = 255;// dizinin son indeksi

Şimdi bu kodu yazan adamın arkasından nasıl konuşulur? Şöyle… Kardeş, kafan çok güzelmiş kodu da öyle yazmışsın, zahmet edip yorum da yapmışsın ama bu dizi kim? 255 dizinin neden son indeksi? Madem bu değişken bir dizinin son indeksi, değişkenin adını felancaDizininSonIndeksi filan diye koysan ne olurdu? Madem bu dizinin son indeksi 255, sen o bilgiyi başka bir yerde de kullanacaksın ve yine ne olduğunu kimse bilmeyecek. O bilgiyi etiketlesen canın mı çıkardı?

Ve nihayetinde o bildiğiniz acı son ile kodu yazan kişinin arkasından bir güzel dualar edilirdi.Bir de aşağıdaki satırı yazan kodcu var tabi…

#define COMMUNICATION_RX_BUFFER_SIZE 255
#define COMMUNICATION_RX_BUFFER_LAST_INDEX (COMMUNICATION_RX_BUFFER_SIZE - 1)

/* We are starting from the last index because, the last value is the most recent one. By the way, we are inceasing the possibility to find the searched character */
uint8_t commRxBufferCurrentIndex = COMMUNICATION_RX_BUFFER_LAST_INDEX;

#define COMMUNICATION_RX_BUFFER_SIZE 255

#define COMMUNICATION_RX_BUFFER_LAST_INDEX (COMMUNICATION_RX_BUFFER_SIZE - 1)

/* We are starting from the last index because, the last value is the most recent one. By the way, we are inceasing the possibility to find the searched character */

uint8_t commRxBufferCurrentIndex = COMMUNICATION_RX_BUFFER_LAST_INDEX;

Önce hiç bir şey denmez, çünkü herşeyi anlamış olmanın verdiği aydınlanma hissi bedeni kaplar. Yani neticede bir kodda bir sürü yerde 255 değerinde bir şeyler olabilir ama hangisinin ne anlama geldiğini anlatmak etiketler olmadan çok zordur. Etiket dediğim de #define ile yazdığım şey. Bu sayede kodda 25 geçtiği zaman o 25’in oda sıcaklığı mı yoksa, amerikanın bir eyaletindeki ehliyet alma yaşı mı olduğunu anlayabiliriz. Bu olaya “MAGIC NUMBER CODING” deniyor. Kodda nereden peydah olduğunu bilmediğimiz sabit değerler olmamalı 🙂 Yazılımda zaten mevzuyu anlamak zor, bir de yorumlarla sabitler doğru kullanılmadı mı olay epey işgenceye dönüyor doğrusu.

Şimdi bir diğer önemli konu da veri ve bilgi kavramlarının farklılığı.Programlamada birbirine en çok karıştırılan kavramlardan biri de bilgi ve veri kavramlarıdır. Eee haliyle çok sayıda yanlışlık da yapılıyor. Örneğin bir 3. sınıf öğrencisininn ‘A’ sınıfında olması bir bilgidir. O bilgi, sayısal karşılığı 0x41 yani 65 olan veri ile ifade edilebilir. Buradaki 65 sayısı, konu içeriği bilinmeyen bir veridir. Keza ülkemizde erkekler için emeklilik yaşı da 65’tir. Yani bu bilgi de ‘A’ ile aynı şekilde bellekte saklanmaktadır. Aaaaaa?

i=’A’, i=65, i=0x41;

Bunların hepsi aynı değerde olan atamalar. Demek ki biz söz konusu içeriği farklı şekilde sunsak, anlamlandırsak da (bilgi), bu anlamlandırmanın bellekteki yerleşimi aynı olabiliyormuş. Biz sadece okuyan adam daha iyi anlasın diye sınıfı gösteren değişkene ‘A’ verisini(değerini) atadık, emeklilik yaşına da 65’i atadık. Bu yaklaşımın değişkenin adını düzgün koymaktan bir adım öteye gittiğini lütfen kaçırmayalım. Sonuçta her iki durumda da derleyici bu ifadeleri 65 sayısına çevirecek ve bu veriyi bellek gözüne yazacak. Demek ki neymiş? Sabit’i atarken bile o bilgiyi ifade etme şeklimiz, iyi kod yazmak için, anlaşılabilir olmak için çok çok önemliymiş. Buradan çıkarılacak sayısız ibretler var. Parçaları birleştirecek olursak aslında ‘A’,65 gibi sayıları kodun çeşitli yerlerinde tekrar tekrar yazacağımıza, #define ile etiket oluşturup o etiketi kullanmakta büyük feyizler var.

Bu konunun bir örneği de printf ile verilebilir. Gömülü sistem yazılımcıları, çok pahalı bir fonksiyon olabildiği için printf’e karşı çok mesafeli olsa da, konsepti anlatabilmek adına örneğimizi onun üzerinden vermemiz mümkün.

#include <stdio.h> //printf için lazım
#include <stdint.h> //int8_t için lazım

int main()
{
int8_t anlamsizDegisken = 65;
printf("Verinin karakter olarak [ismin bas harfi] yorumlanması: %crn", anlamsizDegisken );

printf("Verinin onluk tabanda sayi olarak [emeklilik yası] yorumlanması: %drn", anlamsizDegisken );

printf("Verinin on altılık tabanda sayi olarak [protokol basligi] yorumlanması: %xrn", anlamsizDegisken );

while(1); /ille elle kapat
return 0;
}

#include <stdio.h> //printf için lazım

#include <stdint.h> //int8_t için lazım

int main()

{

int8_t anlamsizDegisken = 65;

printf("Verinin karakter olarak [ismin bas harfi] yorumlanması: %crn", anlamsizDegisken );

printf("Verinin onluk tabanda sayi olarak [emeklilik yası] yorumlanması: %drn", anlamsizDegisken );

printf("Verinin on altılık tabanda sayi olarak [protokol basligi] yorumlanması: %xrn", anlamsizDegisken );

while(1); /ille elle kapat

return 0;

}

Bu kodu çalıştırdığınızda her seferinde aynı veriyi yazdırmanıza rağmen, sırayla ‘A’, 65 ve 41 görürsünüz. Bu bellekteki verinin bilgiye dönüşümüdür. Üzerinde düşünüldüğünde burada da sayısız ibretler vardır.

Neticede ağzımdaki baklayı çıkardım. Yorum satırlarının kullanımı ile ilgili felsefemi aktardım. Karar sizin. Kararınıza sadık kalınız.Ardından sabitlerle ilgili çok önemli olduğunu düşündüğüm kavramları aktarmaya çalıştım. Umuyorum bir şeyler katmıştır, şimdi devam 🙂

Önceki Sayfa Sonraki Sayfa

Gömülü C – 3 : Veri Tipleri, Değişkenler ve İsimlendirme

15 November 2014 by ozenozkaya

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.Martin Fowler

Gömülü sistemler yazı dizisinin güzide yazılarından bir olan “Merhaba Dünya” yazısından sonra geldik artık veri tipleri ve değişkenlere. Tekrara düşmek manasız olduğundan sürekli söylemek istemesem de, bu yazı da bilinenlere referans vererek önemli başka konuları içerecek. Yani herhangi bir tutorial‘deki gibi bir bilgi seti beklemeyiniz 🙂

Şimdi malumunuz genelde bir program, bir problemi çözmek için yazılır. Problem demişken mevzu ille de negatif olacak diye bir şey yok tabi. Sadizmi de bir kenara koyuyorum. Anlatmak istediğim şu ki her programın bir amacı var. Bu amaç belli nedenlerle tetiklenir ki buna da problem diyelim. Her program, problemi farklı bakış açılarıyla modeller. C bunu yapısal bakış açısıyla modellemeye uygundur, C++ nesne yönelimli modellemeye uygundur, SequenceL misal fonksiyonel modellemeye uygundur falan filan.

Bu demek değil ki, C ile nesne yönelimli modelleme yapamayız, C++ ile yapısal modelleme yapamayız. Yaparız de bazen lezzetli olmaz. Bazen de çiçek gibi olur; evine, iş yerine koy seyret.

Neyse konuya dönecek olursak her program mantıken bir problemi ama öyle ama böyle modeller. İş o ki, programlama yapan adam bu modellemeyi kaliteli yapsın. Gel gelelim bu iş, hakikaten zor iş. Niye? Çünkü çok fazla parametreyi düşünmek gerekiyor ve bu parametrelerden bazıları birbirleriyle çatışıyor. Misal kodu daha efektif yapmak çoğu zaman anlaşılırlığı azaltır. Taşınabilirliği artırmak için kodun boyutu artar falan fişman. Madem bu kadar çok parametre var, nasıl state of art yazılım yapacağız? Hem de gömülü yazılım? Cevabı kısaca şu: güzel pratikleri takip ederek ve trade-off’ların (bir şeyi kazanmak için bir şeylerden fedakarlık etmeyi gerektiren durumların) FARKINDA olarak.

Sözün kısası yazının bu kısmında, güzel pratiklerin bir nevi besmelesi anlatılacak. Hemen her problemin modellenmesinde değişkenler kullanılır. Değişkenleri doğru kullanmak ve doğru isimlendirmek, anlaşılırlığa çok büyük katkı sağlıyor. Pek bir şeye de zarar vermiyor. Yani değişkenleri doğru kullanıp, doğru adlandırdığımızda hiç bir şey kaybetmeden bayağı bir kâra geçiyoruz. Bolca sevap kazanıyoruz 🙂

C dili için genelde şöyle bir tablo yapılır:

Tip	Boyut(inş cnm yha)	Değer aralığı(inş cnm yha)
char	1 byte	-128 to 127 or 0 to 255
unsigned char	1 byte	0 to 255
signed char	1 byte	-128 to 127
int	2 ya da 4 byte	-32,768 to 32,767 or -2,147,483,648 to 2,147,483,647
unsigned int	2 ya da 4 byte	0 to 65,535 or 0 to 4,294,967,295
short	2 byte	-32,768 to 32,767
unsigned short	2 byte	0 to 65,535
long	4 byte	-2,147,483,648 to 2,147,483,647
unsigned long	4 byte	0 to 4,294,967,295

Yukarıdaki tablo şerdir, güvenilmezdir, kemdir. Zaten boyut kısmında inş cnm yazmaktadır.

Bu görmüş olduğunuz tipler C dilinin temel tipleri malumunuz. Şimdi size bir önerim olacak. Bu veri tiplerini gömülü sistemlerde ASLA KULLANMAYIN. Aklınızdan iki soru geçti hemen… Birincisi “niye?”, ikincisi “ne kullancaz o zaman?”. İkisine de nedenleriyle cevap vermeye çalışacağım.

Niye?

Çünkü standard veri tiplerinin boyutu platform bağımlıdır. Ne demek istiyorum? Örneğin X mikrokontrolöründe int veri tipi 2 byte iken, Y mikrokontrolöründe int veri tipi 4 byte olabilir. Yine Z mikrokontrolöründe int veri tipi 8 byte olabilir ve eşşeğin kulağına su kaçırabilir. Örneğin sizin bilgisayarlarınızda muhtemelen int 8 byte olacaktır. Bunun sebebi işlemcinin adres yolunun genişliğinin platformdan platforma farklı olabilmesidir. Bu kavram “void*” veri tipinde daha detaylı anlatılacaktır. Ancak şu söylenebilir ki 32-bit’lik platformlarda int veri tipi 32 bit yer kaplar ki bu da malumunuz 4 byte’a tekabül eder. Benzer şekilde 64 bitlik sistemlerde int 8 byte yer kaplar. Tabi bunlar, normalde olması gereken durumdur, derleyici; Ali Cengiz oyunları ile burada başka işler yapabilir. Sözün kısası ölçmeden veri tiplerinin boyutunu bilemezsniz. Bu sebeple int, long, short gibi değişkenler “platform safe (platform-ül emin)” değildir. Peki efendim nasıl ölçücez?

Ahanda böyle:

#include <stdio.h>

int main()
{
   printf("int degiskeninin boyu: %d n", sizeof(int));
/* program işini bitirince çıkar gider. çıkmasın dursun istersen aşağıdaki satırı uncomment yap*/
//while(1); 
   return 0;
}

#include <stdio.h>

int main()

{

printf("int degiskeninin boyu: %d n", sizeof(int));

/* program işini bitirince çıkar gider. çıkmasın dursun istersen aşağıdaki satırı uncomment yap*/

//while(1);

return 0;

}

İsterseniz kodu BURADAN da derleyip çalıştırabilirsiniz.

Neyse derdimizi anlattık. Bu arada bir değişkenin limitlerini bilmiyorsanız yardımcı kütüpanelerle onlara da ulaşabilirsiniz. Misal float için şöyle işler de yapılabilir:

#include <stdio.h>
#include <float.h>

int main()
{
   printf("float'in boyu : %d n", sizeof(float));
   printf("Minimum degeri: %En", FLT_MIN );
   printf("Maximum degeri: %En", FLT_MAX );
   printf("Cozunurlugu: %dn", FLT_DIG );
   
   return 0;
}

#include <stdio.h>

#include <float.h>

int main()

{

printf("float'in boyu : %d n", sizeof(float));

printf("Minimum degeri: %En", FLT_MIN );

printf("Maximum degeri: %En", FLT_MAX );

printf("Cozunurlugu: %dn", FLT_DIG );

return 0;

}

Gömülü sistemlerde, belleğin bilinçli şekilde kullanılabilmesi çok önemlidir. Programın bellek kullanımının platformdan platforma değişmemesi ise, bir çok hatanın önüne geçmemizi sağlar. Örneğin iki adet gömülü sistemin haberleştiğini düşünün. Birinde(X) int 32 bit olsun diğerinde(Y) ise 64 bit olsun. X’den Y’ye olan haberleşmede aynı kodları kullanmak istediğimizde Y’de daha az değer okumaya başlarız. Aynı sayıda değer okumaya kalkarsak da yanlış değer okuruz. Keza X’de bir struct’ı olduğu gibi sd carda yazarsak, ve Y’de o sd cardı aynı struct ile okumaya kalkarsak, eğer struct; int, float gibi platform safe olmayan değişkenler içerirse verileri yanlış okuruz. Misal aşağıdaki struct’ın kaç byte yer kaplayacağını soralım:

typedef struct _ts_BulBakalimBoyumu
{
short sBirGaripDegisken;
int iDegiskeninKrali;
float fDegiskeninDikAlasi;
double dDegiskeninSonNoktasi;
long lUzunBirDegisken;
}ts_BulBakalimBoyumu;

typedef struct _ts_BulBakalimBoyumu

{

short sBirGaripDegisken;

int iDegiskeninKrali;

float fDegiskeninDikAlasi;

double dDegiskeninSonNoktasi;

long lUzunBirDegisken;

}ts_BulBakalimBoyumu;

Kaç byte kaplar? Cevap aşağıda…

ÖNEMLİ BİLGİ

Platformdan platforma kaç byte kaplayacağı değişir. Ama misal 2+4+4+8+8 = 26 Byte kaplaması şaşırtmazdı. Yine de platform bilinmiyorsa net bit şey söylenemez.

Bu gibi bir çok sebeple, öntanımlı veri tiplerini gömülü sistemlerde kullanmamaya gayret etmekte fayda var. Ama tabi yeri gelir, ne yaptığımızı bilerek, bedelini göze alarak ve sisteme zarar vermesini önleyerek kullanabiliriz.

Neyse… Niye sorusunun cevabını verdik gibi. Şimdi diğer soruya geçelim 🙂

Nasıl?

Ne kullanacağız öyleyse? Bu sorunun cevabını iç dünyamızda aramayacağız. Cevap C’nin standard kütüphanelerinden birinde gizli. Anlı şanlı “stdint.h” !!! Evet bu mübarek kütüphane, bir çok problemi tarihin tozlu sayfalarına gömüyor.

Cengaver gibi stdint tablosuna hemen bir göz atalım.

Degisken	İşareti	Bits	Bytes	Minimum Değer	Maksimum Değer
int8_t	Signed	8	1	−2⁷ = −128	2⁷ − 1 = 127
uint8_t	Unsigned	8	1	0	2⁸ − 1 = 255
int16_t	Signed	16	2	−2¹⁵ = −32,768	2¹⁵ − 1 = 32,767
uint16_t	Unsigned	16	2	0	2¹⁶ − 1 = 65,535
int32_t	Signed	32	4	−2³¹ = −2,147,483,648	2³¹ − 1 = 2,147,483,647
uint32_t	Unsigned	32	4	0	2³² − 1 = 4,294,967,295
int64_t	Signed	64	8	−2⁶³ = −9,223,372,036,854,775,808	2⁶³ − 1 = 9,223,372,036,854,775,807
uint64_t	Unsigned	64	8	0	2⁶⁴ − 1 = 18,446,744,073,709,551,615

Önceki tabloda, yani int,char gibi öntanımlı tiplerin yer aldığı tabloda, boyut kısmında “inş cnm” vardı. Sıkıyorsa burada da olsun… Olmaz çünkü bu değişkenlerin hepsinin boyutu SABİT. Hangi platforma giderseniz gidin, uint32_t, işaretsiz olan 32 bitlik bir değişkendir. İşte bu! Yani biz bu değişkenleri kullanarak bir yazılım ortaya koyduğumuzda, yarın öbür gün o kodu başka platforma taşısak da yazılımımızın bellek kullanımı aynı olacak. Buna ne denir? Çiçek çiçek…

ÖNEMLİ BİLGİ

Gömülü yazılımlarda, yalnızca stdint kütüphanesinden değişkenleri kullanmak bir nevi sevaptır.

O çok sevilen char bile, platformdan platforma işaret değiştirebilmekte. Velhasılkelam bunların hiç birine güven olmaz. İyisi mi stdint kullanın. Hiç zararı yok desem yeridir, ama sayısız faideleri mevcuttur.

Bununla birlikte, ikinci sorumuzu da yanıtladık. Şimdi geldik değişkenlere.

DEĞİŞKENLER

Şimdi değişken dediğimiz nane, bellek adreslerinin güzelce etiketlenmesinden başka bir şey değildir. Misal int i=32 diye bir değişken yarat…. Şeytana uymayın int filan yok 🙂 Baştan alalım. Misal şöyle bir değişken yaratalım.

uint32_t u32MaxConnectionCnt=1988;

1	uint32_t u32MaxConnectionCnt=1988;

Derleyici biz bu değişkeni yarattığımızda ne yapar? Gider ram’e şunu der: “Abi müsaitse ben bi 4 byte yer alayım içine de arkadaşlar bi zahmet 1988=0x000007c4 yazsınlar.” Bunu duyan ram cevap verir “Abi bakalım varsa itin olsun.” Bunu aslında ram’im kendisi değil de yöneticisi (işletim sistemi, vs) söyler. Ve neticesinde atıyorum 0x10208032 adresine sizin 1988 sayısı 4 byte olarak yerleşir. Big endian veya little endian olmasına göre verinin belleğe yerleşim sırası değişebilir. değişken uint32_t yerine int32_t olsa yine aynı muhabbet olacaktı 🙂 Ama int16_t olsa idi veri 0x07C4 olarak belleğe yerleşecekti. Neyse.

Bu değişkenin değişmeyen çeşidi de var ilginçtir. Misal aşağıdaki değişken, değişmeyen bir değişkendir ve değeri derleme aşamasında bir kez belirlenir ve o değişkenin değeri bir daha asla değişmez.

const uint32_t cu32MaxConnectionCnt=1988;

1	const uint32_t cu32MaxConnectionCnt=1988;

Değişkenin başına const koyduğumuz zaman derleyiciye deriz ki, bak bilader bu değişkenin değeri asla değişmeyecek. Dolayısıyla sen bunu zırt pırt değişmeyecek bir bellekte saklayabilirsin. Derleyici de gider o değişkeni ram’e değil flash’a ya da hard diske ya da genel adıyla NVM’ye(non-volatile memory) koyar. Hmm demek ki değişken demekle aslında bellekteki bir veri gurubunu etiketlemekten söz ediyoruz. Nitekim belleğin adresinden ziyade değişkenin ismini akılda tutmak daha kolay 🙂

Peki kardeşim bu değişkenin değeri değişeni var değişmeyeni var. Yeri değişmeyeni istersek ne yapacağız biz? O zaman da değişkene durduğun yerde dur diyeceğiz. Nasıl mı? Böyle:

static uint32_t cu32MaxConnectionCnt=1988;

1	static uint32_t cu32MaxConnectionCnt=1988;

Şimdi gelelim başka bir mevzuya. Peki ya bizim değişkenimiz öyle ansızın değişebilmeliyse? Ram’e erişmek görece çok hızlı olsa da sonuçta işlemcinin dışındaki bir bellekten söz ediyoruz ve haberleşme için bir miktar zamanı paşa paşa kaybediyoruz. Öyle bir imkan olsa ki çok acil durumlar için daha hızlı bir çözüm olsa. Var efendim, işlemcinin register’ları var. Biz derleyiciye şunu diyebiliriz. “Abicim eğer yer varsa lütfen bi zahmet bunu işlemcinin register’inda sakla. Yoksa da optimize filan etme kolayda tut lazım olunca hemen çekelim.” Derdinizi anlatmayı bilirseniz derleyici dileğinizi yerine getirir. Bunun için ona şunu yazmalısınız:

volatile uint32_t cu32MaxConnectionCnt=1988;

1	volatile uint32_t cu32MaxConnectionCnt=1988;

Bunları karıştırmak mümkün. Misal static const dediğinizde iki isteğiniz aynı anda gerçekleştirilir. Ancaak birbiriyle çatışan istekler aynı anda kullanılamaz. Mesela const volatile diyemezsiniz 🙂 İşin temel mantığı budur. Bunu bildikten sonra bu operasyonların felsefi yorumlarını yapmak hakikaten zor değil. Misal static olan bir değişkenin yeri bellekte değişmediğinden, o değişken son değerini her zaman korur. Bütün C tutorial’larnda static değişkenin fonksiyon içinde yalnızca bir kez initialize edildiğini herkes anlatır. İşte onun altına yatan nedeni de burda buldunuz. Artık aynı mantıkla hepsini yorumlamak mümkün 🙂 Misal şu bilgi de her yerde var; bir c dosyasında global olara tanımlanmış statik bir değişken yalnız o dosyada kullanılabilir. Neden? Çünkü derleyici her dosyayı bir obje olarak derler. Sonra da objeler linker dayı tarafından birleştirilir. Bir objede bir değişkenin yeri sabit tutuluyorsa o bellek alanı, sinemada rezerve edilen koltuğa benzer. Başkasına satmazlar 🙂 Neyse işte bu bilgi setiyle tüm bu yorumları yapmak mümkün.

Bir de extern ön eki var ama kendisini hiç mi hiç sevmem. Kullanımı bence kötü mimarinin habercisidir. Uzaklardaki, başka dosyalardaki değişkene erişmek için de, fonksiyona erişmek için de header dosyası kullanımı daha mantıklıdır. Zamanı gelince ona da daha detaylı değineceğim.

Bizim yazdığımız kod derlendiğinde kodun işletilecek olan kısmı ile, değeri sabit olan değişkenler flash’a atılır. Değişecek değişkenler, fonksiyon stack’leri ise ram’de tutulur. Burda dikkat edilmesi gereken konu fonksiyonun kendisinin genelde flash’ta tutulduğudur. Ama fonksiyon argümanları filan ram’den kopyalanabilir. Neticede fonksiyon da bellek içindeki bir veri. C dilinde fonksiyonlar dahil olmak üzere her şey değişken çeşidirir demek esasen mümkün. Fonksiyon farklı olarak işletilebiliyor. Yani bellek içindeki veri, işlemci için anlamlı bir operasyon koduna (opcode’a) tekabül ediyor. Ama sonuçta değişken mi? Paşa paşa değişken 🙂 Sadece daha pahalı bir değişken 🙂 O zaman benzer kurallar fonksiyonlar için de geçerli 😉

Neyse bu kısmı da çeşitli ibretlerle atlattık. Gelelim bir diğer önemli kısıma. İsimlendirme….

Sen bellekten yer ayırmışsın, adını düzgün koymadıktan sonra neye yarar? Bir programda eğer, devreye bağlı olan LED’in açık mı kapalı mı olduğunu anlatan değişkenin adı fiveVFlag ise ühüüüü yandı onu okuyan, yandı onu geliştirmeye çalışan… Ama asıl onun adını fiveVFlag koyan yandı çünkü kulakları çok çınlar. isCommErrorLedOn koysan değişkenin adını eline mi yapışır. Bu yazının başında bir meşhur söz paylaşmıştım. Dayı ne güzel demiş… Kodu öyle yazmak lazım ki, insan anlasın insan… Kodu okuyan kimse, kodlama yapan kişinin niyetini çok açık şekilde anlamalıdır. Ancak anlamalıdır derken, anlamasını sağlama sorumluluğu kodu yazandadır. Hatta sorumluluk öylesine kodu yazandadır ki, okuyanın işini kolaylaştıran hemen her şeyi düşünmek zorundadır kodu yazan. Aynı zamanda kod self-documenting olmalıdır yani dökümana gerek kalmaksızın işlevini açıkça anlatabilmelidir. Kod, konuyla alakası olmayan biri tarafından bile anlaşılabilmelidir. Sadece başkası için düşünmeyin, yazdığınız koda 2 sene sonra bakmanız gerekirse siz de tam olarak sıfırdan başlayacaksınız. Her zaman bunun korkusu ile ve bilinci ile kod yazmakta sayısız faideler var. Şimdi bunları biraz somutlaştıralım.

Macar Notasyonu

Macar notasyonu (Hungarian Notation) der ki değişkenin ismini öyle güzel yaz ki hem derdini anlatsın hem de tipini. İyi demiş ne güzel demiş ama Macar Notasyonu bile çoğu kişi tarafından farklı farklı yorumlanmış, temeli aynı kalmak kaydıyla farklı estetiklerle uygulanmıştır. İnternette arattığınızda Macar notasyonu ile ilgili çok farklı örneklere rastlayacaksınız. Ama dediğim gibi amacı hep aynıdır, tip bilgisini vermek ve açıklayıcı olmak. Misal:

int8_t* strIpAddressV4;

1	int8_t* strIpAddressV4;

Buna rağmen notasyon seçimde tecrübeler der ki, çalışılan platform çok çok önemlidir. Mesela çalışma ortamı Visual Studio olacaksa, ve hep öyle kalacaksa tip bilgisini değişken ismine gömmek ahmakçadır. Çünkü kodu yazan kişi değişkeni çağırırken tipi zaten hintBox’da otomatik görünmektedir. Keza o değişkeni başka bir değişkene atayacakken değişkenin adını yazmaya başladığında değişkenin tipi zaten hintBox’da çıkmaktadır. O zaman ne gereği var? Bir de değişkenin tipini değişkenin başına koymak auto code completition (otomatik kod tamamlama) olan geliştirme ortamlarında sorun yaratacaktır. Çünkü siz ip adresini kullanmak istediğinizde onun string olmasından daha çok ip adresi olmasıyla ilgileneceğinizden değişkeni yazmaya ipAddress diye başlayacaksınız. Eğer ortamınız VisualStudio ise yine yırttınız ama Eclipse’in bu günkü bir versiyonu ise yandınız çünkü değişken ipAddress ile değil de str ile başladığı için auto code completition yapılamayacak değişken bulunamayacaktır. Ama Keil uVision gibi taş gibi, ama taş devrinden kalmış izlenimi veren dümdüz ama delikanlı bir IDE ile çalışıyorsanız tip bilgisini değişkene ekleseniz iyi edersiniz 🙂

Benim isimlendirme stilimi bu yazı dizisi boyunca yeterince tanıyacağınızdan şimdi detaylıca anlatmıyorum 🙂 Siz de kendinizinkini oluşturmakta özgürsünüz, ya da bir standardı kullanabilirsiniz [ki belki daha iyi bir seçim olabilir, tartışılır] ama her durumda kafanızdakini Blale anlatırcasına açıkça koda aktarmakla yükümlüsünüz.

Efendim değişken derken ben fonksiyonları da ayırmadığımı söylemiştim. Fonksiyon, asıl işi yapacak olan yazılım bloğu olduğundan çok doğru isimlendirilmeli, çok doğru yaratılmalıdır. Çoğu zaman fonksiyon isimleri, hatalı kodları ele vermektedir. Nasıl ki yazılan değişken neyi temsil ettiğini açıkça anlatmalı ise, fonksiyon da yapacağı işi açıkça anlatmalıdır. Aynı zamanda her fonksiyon yalnızca ama yalnızca bir işi yapmalıdır. Bunu ilerde fonksiyonlar kısmında daha detaylı anlatacağım ama misal şu fonksiyonun mesela isminde hayır olmadığından kendinin de hayırlı bir iş yapmadığı açıktır:

void ikiDegiskeniToplaVeSeriPortaYaz(uint32_t a, uint32_t b)
{
uint32_t c= a+b;

UART5.RESET = 1;
UART5.DREG = c>>24; 
UART5.TX = 1;

UART5.RESET=1;
UATRT5.DREG=c>>16;
UART5.TX = 1;

UART5.RESET=1;
UART5.DREG=c>>8;
UART5.TX =1;

UART5.RESET=1;
UART5.DREG=c;
UART5.TX=1;
}

void ikiDegiskeniToplaVeSeriPortaYaz(uint32_t a, uint32_t b)

{

uint32_t c= a+b;

UART5.RESET = 1;

UART5.DREG = c>>24;

UART5.TX = 1;

UART5.RESET=1;

UATRT5.DREG=c>>16;

UART5.TX = 1;

UART5.RESET=1;

UART5.DREG=c>>8;

UART5.TX =1;

UART5.RESET=1;

UART5.DREG=c;

UART5.TX=1;

}

Arkadaş bir kere bu fonksiyonun adı o kadar saçma ki, C dilini ve bu hayali mikrodenetleyiciyi bilen hemen her kes bu kodun iki sayıyı toplayıp seri porta yazdığını görebilir. İyi de niye yazdı? Fonksiyonun adının bunu anlatması gerekir. Ki yazımı da çok kötü zaten ya neyse. Hadi biraz düzeltelim madem.

typedef union
{
   uint32_t u32Veri;
   uint8_t  au8Veri[4];
}tu_VeriPaketi32Bit;

void bilgisayaraByteGonder(uint8_t u8Veri)
{
 UART5.RESET=1;
 UART5.DREG=u8Veri;
 UART5.TX = 1;
}

uint32_t hasilatiHesaplaTL(uint16_t u16BazUcretTL, uint16_t u16KomisyonUcretiTL)
{
    return (u16BazUcretTL+u16KomisyonUcretiTL);
}

void hasilatiGonder(uint32_t u32HasilatTL)
{
 tu_VeriPaketi32Bit UHasilat.u32Veri=u32HasilatTL;
 for(uint8_t i=0;i<sizeof(tu_VeriPaketi32Bit); i++)
 {
    bilgisayaraByteGonder(UHasilat.au8Veri[i]);
 }
}

typedef union

{

uint32_t u32Veri;

uint8_t au8Veri[4];

}tu_VeriPaketi32Bit;

void bilgisayaraByteGonder(uint8_t u8Veri)

{

UART5.RESET=1;

UART5.DREG=u8Veri;

UART5.TX = 1;

}

uint32_t hasilatiHesaplaTL(uint16_t u16BazUcretTL, uint16_t u16KomisyonUcretiTL)

{

return (u16BazUcretTL+u16KomisyonUcretiTL);

}

void hasilatiGonder(uint32_t u32HasilatTL)

{

tu_VeriPaketi32Bit UHasilat.u32Veri=u32HasilatTL;

for(uint8_t i=0;i<sizeof(tu_VeriPaketi32Bit); i++)

{

bilgisayaraByteGonder(UHasilat.au8Veri[i]);

}

Artık her fonksiyon adına yanaşır şekilde bir iş yapıyor ve kodun iki sayıyı toplayıp seri porttan yollamakla hangi problemi çözdüğünü anlayabiliyoruz. Ayrıca belli ki auto code completition olmayan bir yerde kodu yazmışız. Bir diğer önemli nokta ise kodun dili. Kodun yarısı İngilizce yarısı Türkçe olmamalı. Hangisini seçtiyseniz ona sadık kalın. Normalde C dilinin anahtar sözcükleri İngilizce olduğundan ben tamamını İngilizce yazmayı tercih ediyorum. Ancak İngilizce bilmeyen arkadaşlar da anlatmak istediğim şeyi anlayabilsin diye bu defa Türkçe yazdım. Union kısmını anlamadıysanız şimdi ona çok takılmayın. İbret alınacak başka noktalara bakalım. İlk fonksiyonun adının ne kadar amaçsız olduğu konusunda anlaştığımızı sanıyorum. Bir diğer hata da isminden de anlaşıldığı üzere iki işi birden yapmaya çalışması. İşte bu tekrar kullanılabilirliği öldürüyor. Üstteki koddaki adam seri porta başka bir şey yazmak istediğinde kod tekrarı yapacak ve birinde hata yaparsa belki hatayı bulamayacak. Alttaki kodda ise bilgisayaraByteGonder fonksiyonu çiçek gibi çalıştığından çağırıldığı her yerde hataya mahal vermeksizin çalışmaya devam edecek. Ayrıyeten bilgisayara bilgi gönderecek her fonksiyon onu tekrar tekrar kullanabilecek. Bu nedenle fonksiyon isminde and, or, if filan var ise bilin ki o fonksiyon çok çirkin bir fonksiyondur. Ayrıca isimlendirme, dilin anlatamadığını anlatmayı hedeflemelidir. Değişkenin adını uzun yazmakta bir sakınca yoktur. Derleyici zaten derleyince onu adrese dönüştürecektir. Bir harfle isimlendirilen değişken de, uzunca ismi olan değişken de tipi aynı olduğu takdirde aynı miktarda yer kaplayacaktır.

Güzel kodlama pratikleri üzerinde ileriki konularda da konuşacağız. Şimdilik görüşmek üzere 🙂

Önceki Sayfa Sonraki Sayfa

Gömülü C – 2 : Gömülü C’ye Giriş : Merhaba dünya

7 November 20149 June 2016 by ozenozkaya

Yol haritamız malumunuz, karanlıkta klavuzumuz. Efendim ne diyor harita, sanatsal programlama pratikleri diyor. Peki nerden başlayacağız? C dilinden başlayacağız. C dili ile ilgili bir çok yorum yapılır; orta seviye bir dil, hem makinaya, hem insana yakın gibi… Hepsi geyik muhabbeti! Şu yıllarda, C dili hala varsa ve hala bu kadar popülerse bunun sebebi dilin gömülü sistemlerle olan şahane uyumudur. Mevzuya aşkın bu penceresinden bakalım. Gömülü C, en nihayetinde özünde bildiğimiz C dili. O sebeple bu kısım aman aman gömülü yazılıma özgü değil, ama merhaba dünya kodunu gömülü sistemci kafasından pestil edeceğiz. Sıksak ne kadar suyu çıkar? Göreceğiz…

C dili malumunuz, ISO/IEC 9899 standardları ile tanımlanmış bir ifade biçimi. Bir dil bir insan derler ya, o misal bir dil 🙂 Kendisi diller familyasında,”yapısal” diller sınıfında yer alıyor. Yani ne diyor? Benim tasarımım yapılar (struct, enum, union) üzerine dayanır diyor. Benimle konuşacaksan, yapılar üzerinden konuşsan sen karlı çıkarsın diyor. İyi de neymiş bu yapılar? Struct, enum, union dedin, de ne bunlar? Hemen döndük yol haritasına, ne yazıyordu bilinene referans ver kıymetliyi anlat. O zaman bu yazıyı okumadan önce C dilini bir yerden tanımış olmanız gerekiyor. Üç beş örnek kodu çalıştırmanız gerekiyor. Yani dostlar, dost acı söyler, struct, enum, union nedir bilmeniz gerekiyor ki sonraki adım olarak işin felsefesini konuşalım. Çok da tatava yapmayacağım, inanıyorum ki bilmeyen de gitti okudu öğrendi geldi. Bilmeyen ama öğrenmek isteyenleri de duyar gibiyim; iyi de kaynak önermedik? Kitap olarak: Deitel&Deitel. Online kaynak olsun ve Türkçe olsun: ahanda burada. Online olsun İngilizce olsun eyvallah o da burada. Şimdi heyecanıma yenik düşüp hemen struct, enum, union dedim ama onlardan daha önce çok önemli sorular var. İbretlerle dolu “Merhaba Dünya” var. Ezber bozan Merhaba Dünya!

Yazdığınız kodları derlemek için program olarak, dev C++’ı, codeblocks’u, eclipse cdt’yi önerebilirim. Sadistseniz, komut satırından Gcc ile de derleme yapabilirsiniz, ki çok keyiflidir, bilen bilir. 🙂

Şimdi, bir C kitabının gittiği sıra ile mevzunun inceliklerini konuşacağız. Anlı şanlı, Sanatsal Gömülü C başlıyor!

SANATSAL GÖMÜLÜ C!

Yanlış Bildiklerimizi Bir Kenara Koyabilmek, Öğrenmeye Açık Olmak…

C diliyle yazılan en basit kod diye tanıtılan merhaba dünya kodu ile başlayalım. Dakika bir, gol bir olsun. Acaba bin defa gördüğümüz merhaba dünya kodundan ne kadar ibret çıkarabiliriz ki? Üç beş satır kod. E hadi bakalım, suyunu sıkacağız demiştik. Kodun suyunu sıkalım neler neler çıkacak, görelim 🙂

#include <stdio.h>

int main()
{
   /* c ile merhaba dünya */
   printf("Hello, World! n");
   
   return 0;
}

#include <stdio.h>

int main()

{

/* c ile merhaba dünya */

printf("Hello, World! n");

return 0;

}

Şimdi bir kere, iş yapan, bir şey döndüren en basit C kodu bu mu? Merhaba dünya hakikaten temelin temeli mi? Hiç alakası yok. Ahanda size, Bahçeli’ye yardımcı iş yapan çok daha basit C kodu. Koda hiç bir şey eklemeye gerek yok, derleyicide aynen çalışır. Bir şey eksik diye düşünmeyin.

int main()
{  
   return (29+11);
}

int main()

{

return (29+11);

}

Ee ne farketti ki? Çok şey farketti. Bir kere <stdio.h> kütüphanesini kullanmadık. “Yahu o, olmazsa olmaz değil miydi ya?”. Hayır efendim değildi. <stdio.h> yalnızca adı üstünde standart giriş çıkış (i/o) işleri yapılacaksa kullanılır. Merhaba dünya kodunda printf fonksiyonu çağırıldığından elimiz kolumuz bağlandı, <stdio.h> kütüphanesini göreve çağırdık. Peki niye <> ile çağırdık, bazen “selam.h” gibi de çağırılıyor bunun hikmeti nedir? Derleyici, çağırılacak bazı header dosyalarının konumunu ezbere bilir. Derleyicinizin “include directories” ayarında bunları görebilirsiniz. Deleyicinin yerini ezbere bildiği, uzak yerlerde de bulunabilen headerlar #include <selam.h> şeklinde çağırılır. Eğer selam.h dosyası, bu header’ı çağırdığımız selam.c dosyası ile aynı dizinde(klasörde) ise onu #include “selam.h” ile çağırırız. Peki #include nasıl bişi? C dilinde “#” ile başlayan komutlar preprocessor komutları diye adlandırılır ve yalnızca derleme zamanında çalışır. Yani biz selam.c fonksiyonunda selam.h’ı include edince derleyici derleme esnasında gider _selam.c diye geçici bir dosya oluşturur, selam.h’da ne var ne yoksa gider selam.c’nin tepesine koyarak toplam içeriği _selam.c’de saklar.

İyi de int veri tipi var kodda, o nerden geliyor? Ahanda ibret detected, int veri tipi C dilinin standard tanımlamalarında bulunan bir veri tipi olduğunadan, derleyici adam olacak, onu kütüphane olmaksızın tanıyacak.

Ama main olmazsa olmaz dmi? Hiç alakası yok. En sevmediğim genellemelerden biri de budur. Ezberdir, kötüdür, kemdir. Örneğin ARM Cortex mimarisinde kod her zaman main’den değil ResetInterruptHandler’dan başlar. İnanmazsınız, bu platformda main, reset interrupt handler tarafından herhangi bir fonksiyon gibi çağırılır. Nasıl yani main demesek ecmain desek kod ecmain fonksiyonuna mı gidecek? Evet. Ne derseniz ona gider. Ama alışanları hayal kırıklığına uğratmamak adına yine yalandan bir main çağırılır. Hmmm. Belki bu birilerini şaşırtmıştır. Hemen aydınlanmış hissetmemek lazım çünkü mevzu biraz daha derin. Main fonksiyonu aslında linker dayının, kodun başlangıç noktası olarak adreslediği bir fonksiyon. Main her şeyin başlangıç noktası olsa, işletim sistemi nasıl çalışırdı 🙂 Siz kodu çalıştırmadan önce, onu çalıştıracak sistemin çalışması gerekiyor. Demişler ki “aga, biz bu dili bulduk, elemanlar da kod yazsın da nerden başlayacak olm bu kod?” Biri demiş ki “ilk satırdan başlasın işte”, öbürü demiş “yok aga ön bilgiler lazım bir sabit bir fonksiyon adı belirleyelim, derleyici gitsin en azından o fonksiyonu arasın onun adresini bulsun bizim işletim sistemi de gitsin programı da ordan başlatsın nasıl ama”? Ve akla yatmış tamam demişler. Biz bi linker yazsak, windows üzerinde çalışsa ne yazmamız gerekirdi? Window’s bunu nasıl çalıştırırdı? Mevzuyu anlamamızı sağlayan soru bu? C programı nasıl çalışır değil. Bu ters yönden hedefe varmamızı sağlayacak. Compiler gitti bizim dosyaları derledi biz de birleştirerek çalıştırılabilir hale getireceğiz. Ne yapacağız? Diyeceğiz ki; misal bizim program “bigbang” fonksiyonundan başlasın. Ben bir dil yazsam her şey bigbang ile başlardı çünkü. Neyse bizim c dosyalarında kullanılan sembolleri, başka dosyalarda da arayıp bulup birleştirdik. Adam düzgün yazdı diye varsayım yapıyoruz ki bigbang fonksiyonu da yazmış bir tane. Süper! İşletim sistemi ne yapacak? Gidecek bakacak; bu program ne kadar ram kullanacaksa, o kadar yeri ayıracak ayarlayacak. Sembollere adresler atayacak, kendi task scheduler’ının stack’ini filan ayarlayıp bizim programı “bigbang” fonksiyonunun bellekteki adresinden başlatacak. Sonra da malumunuz bizim merhaba dünya kodu çalışacak. Vay beee. Ne yolculuk görüyor musunuz? Bunun da öncesi var, bilgisayar nasıl ayağa kalkıyor filan? Ama onlar sonranın mevzusu. Almamız gereken ibret şu: main de neticede bir fonksiyon… Linker, bizim elemanların aldığı karar yüzünden onu arıyor. Arasın dursun madem. Şimdi ibretlere devam.

“int main()” yazdık. Bu ne demek; “int main(void)” demek aslında ama biz kısa olsun diye öyle yazdık dmi? Değil. İkisi arasında ince bir fark var. Buna da geleceğiz ama, önce sırayla gidelim. Bir kere, fonksiyonu soldan sağa inceleyelim. int döndürmesi ne demek fonksiyonun? Şu demektir ki; fonksiyon bir makine gibi çalışırsa, işini bitirince bize bir sayı verecek demektir. İyi de bizim program çalıştı bitti 0(sıfır) döndürdü, bu 0(sıfır) kime, niye gitti, ne anlatmaya çalıştı? Burada main özel bir fonksiyon etiketi olduğundan verdiği mesaj işletim sistemine gider. Yani bizim Merhaba dünya, doğru düzgün çalışıp işini bitirirse, bir yerde takılmazsa işletim sistemine 0(sıfır) sayısını gönderir. Ama niye sıfır? Çünkü bir çok hata çıkabilir, ama programın hatasız tamamlanma ihtimali bir tanedir. Biz her bir hataya sıfırdan farklı bir sayı değeri atarsak, hatasızlığa da tek bir şekilde(tek bir sebeple) gerçekleşeceğinden sıfır değerini atarsak ne olur? Çiçek olur çiçek. Bizim programda diyelim bellek ayrılamadı… O hataya 1 desek, printf ekrana bir şey yazamadı; o hata 2 desek, başkasına 3 desek filan tüm hataları indeksleyebiliriz. Hata kodunun 0(sıfır) olması, hata yok demektir. O nedenle 0(sıfır) döndürülür. Hata kodu da sayı olacağından dolayı da main int döndürür, ki hakkıdır yapar. Önceden main’in adı niye main onu anlatmıştık.Şimdi şu “()” vs “(void)” farkına gelelim. Bir fonksiyon parametre olarak “()” alıyorsa, bu şu demektir: sen parametre olarak ne verirsen ver ben sallamayacağım ve onu kullanmayacağım. “(void)” ise daha otoriter bir mesaj veriyor: sen parametre olarak bana bir şey veremezsin. Parametre olarak (void) alan bir “seviyorumDe(void)” fonksiyonu uydurun, çağırırken “seviyorumDe();” şeklinde çağırın derleyici hiç kızmaz. Ama “seviyorumDe(“Sevmiyorum”);” şeklinde çağırırsanız derleyici size kızar. Sonra gidin fonksiyon tanımını “seviyorumDe(void)” yerine “seviyorumDe()” olarak tanımlayın derleyici size hiç kızmaz. Ama fonksiyonun içinde “Sevmiyorum” argümanına doğrudan erişemezsiniz. Demek ki neymiş, bunun bile bir nedeni varmış. Bu bile aslında fonksiyonu çağıracak kişiyi yönlendiriyor, kısıtlıyormuş. Yeni ibret; ezber yok.

Dostlar, gördüğünüz gibi “hello world” kodu bile bize neler neler gösterdi. Ki mevzuyu kısa kestiğimizi de belirtmek isterim. printf’in nasıl çalıştığını da anlatmak isterdim, ama şimdi öyle yapsam burası çok uzun olacak, belki sıkılacaksınız. İleride yeri geldi mi ondaki ibretleri de anlatacağım 🙂 O zamana kadar sabırla okuyun olur mu? Bu daha başlangıç, mücadeleye devam!

Dosya uzantıları: Selam.c ve selam.h örneklerini anlatmıştım. C programlamada muhakkak kaynak dosyaları .c uzantılı, header dosyaları .h uzantılı olmalı dimi? Alakası yok. selam.h dosyasını gidin selam.ozkaya dosyası olarak adlandırın. Sonra selam.c’de gidin #include “selam.ozkaya” yazın ve cayır cayır çalıştığını görün. gcc kullanmayı bilen varsa selam.c’yi de selam.ozen diye adlandırıp derlemeyi deneyebilir 🙂 Peki niye .c ve .h diye adlandırıyoruz? Çünkü derleyici bir dosyayı açtığında uzantısından, ona yapacağı muameleyi otomatik anlayabilsin istiyoruz. Aynı dili konuşalım istiyoruz.

DİPNOT: Sırf değiştirebiliyoruz diye header işlevi gören bir dosyanın uzantısını adınız soyadınız yapıp milleti kanser etmeyin 🙂 İnsan okuyacak o kodu, insan 🙂

/* c ile merhaba dünya */

1	/* c ile merhaba dünya */

Yukarıdaki yorum satırı hakkında ne düşünüyorsunuz? Ben kendisini iğrenç buluyorum çünkü bir amaca hizmet etmiyor. Koda bakan herkes o kodun C dili ile yazılmış bir merhaba dünya kodu olduğunu anlayabilir. Böyle yorum satırı olmaz, hiç bir işe yaramaz, sadece kalabalık yapar. Gereksiz kalabalığı da Gömülü C’ci sevmez. Buradan yorum satırlarına karşı olduğumu çıkarmayın, yorum satırları da sanatsal şekilde kullanılabilir. Yeri gelince detaylı anlatacağım 🙂

Şimdi devam…

Önceki Sayfa Sonraki Sayfa

Gömülü C – 1 : Gömülü Programlama Yol Haritası

6 November 2014 by ozenozkaya

YOL HARİTASI

Düşündüm yazının başlığını, daha güzel ifade edemedim. Bu yazıda, bu yazı dizisine ilişkin hayallerimi, yol haritasını anlatacağım ve umuyorum ki hepsi adım adım gerçekleşecek. Kararlılıkla, sabırla gerçekleşecek. Ve diliyorum ki hayatımıza bir katkı sağlanabilecek. Eğer bu yol haritasını sonuna kadar okuduysanız, ama heyecanlanmadıysanız lütfen yazı dizisine devam etmeyin.

Önceki yazılarda gömülü sistemler için gerekli donanım altyapısını tahsis etmeye katkı sağlamaya çalışmıştım. Nihayetinde heyecanla beklediğim an geldi çattı 🙂 Yazı dizisinin bu bölümünde her yerde bulunabilecek bilgilere referans vererek, her yerde bulanamayacak bilgileri paylaşmaya çalışacağım. Paylaşırken de öyle sıkıcı şekilde değil de, sohbet muhabbet tadında paylaşmaya çalışacağım. Neyse şimdi laga-lugayı kısa kesip konuya gireyim 🙂

Malumunuz gömülü sistemler kısıtlı kaynaklı sistemler. Gel gelelim bu ifade artık, her durumda doğru bir ifade sayılmaz. Hakikaten bir çok görev için son derece “kısıtlı kaynaklı” olarak değerlendirilebilecek sistemlerin yanında bayağı bayağı “bol kaynaklı” gömülü sistemler de mevcut. Bir “gömülü webserver” yapmak için Microchip firmasının PIC16F84A mikrokontolörü çok kısıtlı kaynaklı kalabilir, öte yandan bu iş ARM Cortex A15 barındıran, doğru tasarlanmış bir gömülü sistem için genelde çocuk oyuncağının bir kaç mertebe altında bir iştir. Sözün özü, kısıtlı kaynak, spesifik bir görev için söz konusudur. Ancak yine de, rekabette var olabilmek için genelde bir işi olabilecek en ucuz ve en kaliteli şekilde yapmak, amaçtır. Bu da kaynakların kısıtlı kalmasına neden olur.

Kaynaklar kısıtlı olduğu gibi, zaman da çoğunlukla kısıtlıdır. Bu sebeple yazılan kodların son derece optimize, kolay anlaşılabilir, tekrar kullanılabilir, yani aslında “kaliteli” olması gerekmektedir. Efendim yazılım neye göre kaliteli olacak? Meselenin aslı ortaya kondu mu, cevap bulmak kolay olur demişler(N.E.). Cevap basit, “yazılım tasarımı kalitesi standartlarına” göre kaliteli olacak. Yani isim verecek olursak ISO/IEC-14598, ISO/IEC 250×0 standart serisine göre. Evet, sizi duyar gibiyim ve ben de aynı fikirdeyim ama var işte yazılım kalitesinin de standardı 🙂

Efendim neymiş bu standartlar? Standartlar mı yönetecek bizi? Hayır efendim, standartlar yönetmeyecek, standartlar tanımları yapacak, ortak dili belirleyecek sonra biz o ortak dilden konuşacağız ve yazılımlarımızın kalitesini ölçülebilir hale getireceğiz. İyi tamam, ama gömülü sistemler ne alaka? Gömülü sistemler, belki de kaliteli tasarıma en çok ihtiyaç duyulan yazılım tasarım ortamıdır. Zaten zaman kısıtlı, kaynaklar kısıtlı, işin içinde donanım olduğundan değişkenlerin sayısı çok fazla, ürün sürekli güncelleniyor gibi bir ton sebep, rekabette öne geçmek için tasarımın kaliteli olmasını zorunlu kılıyor. İyi de madem standard var, ben ne konuşuyorum? Dedim ya standardlar sadece ortak dili anlatıyor ve bazı ölçüm yöntemlerini belirliyor. İyi olana gitmek bize kalıyor. Dil ortak ama ne konuşacağımızı yine biz belirliyoruz.

Bu yazı dizisinde C dili, C++ dili anlatılmayacak. Deitel&Deitel’in kitabı o işi çok çok iyi yapıyor. Ancak bu yazı dizisinde onun yerine, sanatsal seviyede programlama pratikleri, gömülü sistemlere özel tasarım kalıpları, modelleme yöntemleri ve iyi programlama pratikleri anlatılacak. Bunların bir kısmının, benim bildiğim bir kaç düzine önemli kitaplarda dahi yer almadığını belirtmek isterim. Uzmanlar için bile faydalı olabilecek bir iki numaram olduğunu düşünüyorum 🙂 Peki nasıl olacak? Her şeyden önce sabırla, sebatla, ilim irfan aşkıyla, azimle olacak. Her zaman yaptığımız gibi, bitirememek üzere başladığımız 1632. iş olmayacak bu. Önce eğer C bilmiyorsanız, bir kaynaktan C öğreneceksiniz. Önerdiğim kaynak Deitel&Deitel’in kitabı. Ardından bu yazı dizisini okuduğunuzda hakikaten keyif alacaksınız. Gerçi bir dili bilmek iddiası fazla özgüvenlice bir iddia bence, her zaman birbirimizden öğrenecek şeylerimiz var o ayrı mevzu ama C dilini zaten biliyorsanız doğrudan yazılara devam edebilirsiniz. Böylelikle gömülü sistemler için çok net, taş gibi bir yazılım alt yapısı edinmiş olacaksınız. Zaten varsa da onu cilalamış olacaksınız. Yazıda C ile birlikte C++ konseptlerine de değineceğim.

Sonra ne olacak? Yazı dizisi nasıl devam edecek? Donanım bilgisi oluştu, yazılım bilgisi kültürü oluştu, sırada ne olacak. Sırada artık ellerin kirlenmesi var. Microchip firmasının 8 bitlik PIC mikrodenetleyicilerini programlama’yı ince detaylarla anlatacağım. Bu sayede küçük bir sistemde çalışmanın faydalarını, temelleri ve detayları tertemiz görmeyi öğreneceğiz. Aynı zamanda basit sürücüler yazacağız, sensörleri ve komponentleri tanıyacağız. Ardından Atmel firmasının Atmega serisi ile analoji kuracağım, onu her şeyiyle kullanmayı da anlatacağım. Burada araya Arduino’nun iç yapısını, anlatılmayanlarını sıkıştıracağım, malum çoğunun içinde Atmega var. Sonra 16 bitlik bir mikrodenetleyici serisine geçeceğiz. Aynı zamanda bu ultra-low power bir seri olacak; Texas Instruments MSP430 serisi. Buradan hem 16-bit’lik bir mikrodenetleyici nasıl kullanılır, farkı nedir, low-power sistem tasarlamanın püf noktaları nedir onları da anlatacağım. Sonra geleceğiz ARM Cortex M3-M4 serisi işlemci barındıran 32-bit’lik mikrodenetleyicilere. Burada da STM32 ve LPC17 serisinden örnekler vereceğim. Hemen hemen aynı şeyler, ama aynılıkları farklılıkları bilmek bence önemli bir bilgi seti olacak. Aynı zamanda DMA gibi, EMC gibi yepyeni modülleri tanıyacağız. Bu sayede mikrokontolörlerin tüm çevresellerine hükümdar olacağız. TFT ekran, thermal printer, manyetik kart okuyucu, rf modem gibi cihazlar ile çalışacağız, sensörler kullanacağız. Seviye atlamış olacağız. Burada RTOS kullanmanın inceliklerine de değineceğim. Çok çok önemli bir bilgi seti RTOS. Ya sonra? Bitmedi mi bu mikrokontrolörler filan? Hayır efendim bitmedi. Çok çekirdekli sistemler nasıl programlanır onu anlatacağım. 64-bit’lik platformlara değineceğim. Malum son IPhone’larda 64 bitlik işlemciler var, neticede o da gömülü sistem. Ya sonra? Sonra 32-bit’e döneceğiz ama mikrobilgisayar seviyesindeki çekirdekleri inceleyeceğiz. Burada gömülü linux ile platform bazında kapanışı yapacağım. Kafama eserse VxWorks de yazabilirim ama elzem değil. En sonunda açık kaynaklı yazılımlarla çalışma, açık kaynak lisans tiplerine değineceğiz.

Burada yazı dizisi sonlanacak sanıyorsanız yanılırsınız. Neticesinde sadece gömülü sistem temeli tahsis edilmiş olacak. Ama öyle bir temel ki, üstüne artık ne kurarsan kur. Sonra her telden çalacağız, başına gömülü etiketi koyacağız. Ne demek istiyorum? Gömülü görüntü işleme yapacağız. Gömülü kontrol sistemi tasarlayacağız. Gömülü haberleşme tekniklerini ağlatacağız, havadan karadan giden gelen veriye hükmedeceğiz. Gömülü sistemlerde pastanın üstüne çilekler koyacağız, kriptopgrafi yapacağız. Sonra FPGA konuşuruz. Sonra PSOC konuşuruz. Ve daha nicesi 🙂

Bu yol uzun olacak, zaman alacak, fedakarlık isteyecek ama yol bu olacak. Her türlü öneriye açık olduğumu da belirtmek isterim. Ülkemizin, teknoloji üretiminde ileriye gitmesine, yani sizlere, hayatımıza bir nebze katkıda bulunabilirsem ne mutlu bana.

Şimdi devam.

Önceki Sayfa Sonraki Sayfa

Gömülü Sistemler – 11 – Mikrodenetleyici I/O Modları

5 November 2014 by ozenozkaya

Mikrodenetleyicinin genel amaçlı giriş çıkış (general purpose input/output (GPIO)) pinleri, giriş çıkış bakımından farklı modlarda konfigure edilebilir. Giriş modları arasında pull-up, pull-down dirençleri, hysteresis, ya da benzeri kombinasyonlar söz konusu olabilir. Benzer şekilde çıkış modları push-pull, high-drive ya da open-drain olabilir.

Resim 1

ÖNEMLİ BİLGİ

Gömülü sistemler üzerinde çalışacak bir kişinin I/O modlarını mutlaka bilmesi gerekmektedir.

Giriş Modları

GPIO giriş modları genellikle, yüksek empedans(high impedance, high-z), pull-up, pull-down ve tekrarlayıcı(repeater) olarak tasarlanır. Yine bazı mikrodenetleyiciler I/O arayüzlerinde histerizis (hysteresis) özelliği de barındırır ve bu sayede suni (bouncing gibi) durum değişiklikleri önlenir.

Pull Up/Down

Eğer bir giriş, dahili (mikrodenetleyicinin içindeki) pull-up modunda ise o pin içeride bir direnç ile lojik bir seviyesine çekilmiştir. Bu da şu demektir ki, o pin dışarıdan lojik sıfıra sürülene kadar, lojik 1 durumunda kalmaya devam edecektir. Tam tersi durum da pull-down için geçerlidir. Eğer bir giriş, dahili pull-down modunda ise o pin içeride bir direnç ile lojik sıfır seviyesine çekilmiştir. Bu da şu demektir ki, o pin dışarıdan lojik bire sürülene kadar, lojik sıfır durumunda kalmaya devam edecektir.

Repeater: Bazı mikrokontrolörlerde bazı pinlerin durumu dinamik olarak pull-up ya da pull-down olarak değiştirilebilmektedir ve bunun için repeater mod kullanılır.

Floating, High Impedance, Tri-Stated

High Impedance: Bir giriş pini yüksek empedans(high impedance, high-z) durumunda olduğunda pinin durumu, o pin lojik sıfıra ya da lojik bire bağlanana kadar bilinemez.

Floating: Yüksek empedans yapısındaki bir pin, lojik sıfıra ya da lojik bire bağlanmadıysa, pin floating (belirsiz, salınan) moddadır denir.

Tri-stated: Üç durumlu anlamındaki bu mod, floating ile aynı durum için kullanılır.

ÖNEMLİ BİLGİ

Mikrokontrolörün dışında herhangi bir yere bağlanmamış bir pinin floating durumda kalmasını önlemek için,mikrokontrolörün içerisindeki pull up/down dirençleri aktive edilir.

Hysteresis

Bir pinin lojik sıfırda mı lojik birde mi olduğuna karar verebilmek için genelde bir eşik değeri kullanılır. Ancak bu eşik değeri bir aralık ifade etmediğinden eşik değerinin çok az üstü de lojik bir olur, epey üstü de lojik bir olur. Benzer şekilde eşik değerinin çok az altı da lojik sıfır olur, epey altı da lojik sıfır olur. Gerçek hayatta bu durum bouncing (sekme, salınma) problemini doğurur. Siz lojik birdeki bir pini lojik sıfıra çekerken pin eşik değerinin etrafında kararsız bir duruma girer ve ardışıl olarak 1,0,1,0,1,0 durumları görülür. Bunu önlemek için güvenli bir aralık belirlenmiştir.

Çıkış Modları

Push-Pull

Push-pull bir çıkış hem source hem de sink akımı akıtabilir. Bu da pin çıkışı sıfıra da çekilse, bire de çekilse o pin üzerinden akım akıtabilmeyi sağlar. TTL ve CMOS devreler push-pull çıkış kullanır.

Open-Drain

Resim 1’de “open-drain” yazan kısmı görebilirsiniz. Gerilimle sürülen bir transistör türü olan MOSFET’i tanıyanlar için “open-drain” kavramı zaten açıklamaya mahal gerek bırakmayacak kadar anlaşılırdır. Ancak MOSFET’i bilmeyenler için anlatmak gerekirse bir MOSFET üç pine sahiptir: gate(kapı, giriş), source (kaynak), drain(akaç). Open-drain durumda source toprağa bağlıdır,gate içeriden sürülmüş durumdadır ve drain açıktadır. Open-drain çıkış yalnızca sink akımı akıtabilir yani dışarıdan akım çekebilir. Dışarıya doğru akım basamaz. Esasen bu da iki durumda kalabilmesine imkan verir: düşük empedans ve yüksek empedans.

High Drive

High Drive (yüksek sürüşlü) pinler esasen yüksek akım verebilen push-pull pinlerdir. Normal bir push pull pin +/- 8mA akım akıtabilirken high drive pinler 40mA’e kadar akım akıtabilir. Ancak genelde elektriksel karakteristik datasheette belirtilir. Eğer pin ile doğrudan yüksek akım çeken elemanlar sürülecekse, pinin üst sınırına kadar akım çekecek cihazlar, ek bir devre olmasızın high drive pinler ile sürülebilirler.