Kendini Geliştirmek İsteyen Gömülü

Yazılımcıya Etkin Yol

Kaynak Tarih Versiyon İşlem

Zafer SATILMIŞ 2021-02-01 0.1 Döküman oluşturuldu

1. Amaç

Bu belgede kendini geliştirmek isteyen bir gömülü yazılımcının

uygulayabileceği bir yöntem anlatılacaktır. Bu yöntem ile kişi
hangi seviyede olunursa olunsun kesinlikle kendisine bir şeyler
katacaktır.

Kendini geliştirmek isteyen birçok yazılımcı aslında hedef

bulamama, odaklanamama ve zorluklardan/eksiklerden
sıkılma gibi nedenlerle gelişim çalışmalarını yarıda
bırakmaktadır. Hatta youtube/udemy gibi platformlarda
oturduğu yerde video seyretme azmini bile
gösterememektedir. Kitap/belge okuma kısmında da başarı
oldukça düşüktür.

Burada anlatılacak yöntem kesinlikle kitap okuma, video

seyretme, kursa gitme gibi bilgi edinme yöntemlerinden çok
daha zor ve yorucu bir yöntemdir. Fakat sıkıcı olmaması
nedeniyle yazılımcının zihnini canlı tutup gelişim süresince
öğrenmesini arttırmaktadır. Ayrıca bu yöntem ile kişi çıkarım
yapmayı, kıyaslamayı, problem çözümünü ve en önemlisi
istikrar ve sonuca varmayı öğrenecektir.
2. Öğrenme

Detaylarıyla açıklanacak bu yöntemde kişinin öğrenmesi

yüksek oranda etkin öğrenme biçimine dayanmaktadır.

2.1. Edilgen Öğrenme

Edilgen öğrenme için internette görülen en basit açıklama şu

şekilde: Etkileşim ve geri bildirim içermeyen, öğretim
sürecindeki öğrenci işlevini izleyicilik ile sınırlayan öğrenme.
Öğretim sürecinin, etkileşim ve geribildirim içermeyen
öğrenme etkinliklerinden oluşan kısmı. Bu kavram bazen belli
bir tür öğrenme etkinliğini ifade edecek; bazen de etkileşim
içermeyen öğrenme etkinliklerine yönelik bir yergiyi içerir
biçimde kullanılır.

Kendini geliştirmek isteyen birçok yazılımcı farkında olmadan

edilgen öğrenme yöntemi kullanıyor. Fakat farkına varılmayan
konu ise edilgen öğrenme direnci. Edilgen direnç, öğretim
sürecine katılmama ya da öğrenmeden kaçınma olarak
tanımlanmaktadır. Video seyretmek, kitap okumak gibi
eğitimleri uygulayıp bir türlü istediği sonucu alamayan
arkadaşlar geriye dönüp yaşadıklarını düşündüklerinde edilgen
direnç kavramını daha net anlayacaktır. Edilgen direnç için
daha fazla bilgiye bu linkten ulaşabilirsiniz.
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://toad.halileksi.net/sites/default/files/pdf/ogrenm
eye-edilgen-direnc-olcegi-
toad.pdf%26amp;sa%3DD%26amp;source%3Deditors%26amp;
ust%3D1613429118485000%26amp;usg%3DAOvVaw2_Y3Uy5
JO5kZbbOrWcDku3&sa=D&source=editors&ust=16134291185
51000&usg=AOvVaw3lJ2Cuv3zS05FGz7wynNTf)

2.1. Etkin Öğrenme

Edilgen öğrenme için internetten bulunan en basit açıklama şu
şekilde: Etkin öğrenme, öğrenmeyi öğrenme ve anlamlı
öğrenmeye olanak veren bir yaklaşımdır. Etkin öğrenme eğitim
programının tüm öğelerini etkilemek- tedir.

Etkin öğrenme yöntemini iş hayatındaki çalışmalarımızdan

edindiğimiz bilgilere örnek verebiliriz. Özellikte tecrübe
dediğimiz bilgi birikimlerimizin çoğu aslında etkin öğrenme ile
elde ediyoruz. Hatta bu konuyu çok iyi özetleyen bir
atasözümüz var: “Sütten ağzı yanan yoğurdu üfleyerek yer.”

Peki bizler yazılımcı olarak sadece etkin öğrenme yöntemini

mi kullanmalıyız. Tabiki de hayır, hem etkin hem de edilgen
öğrenme yöntemlerinin ikisini de kullanmayı bilmeliyiz.
Örneğin linux device driver çalışma yapısı, device tipleri,
device tree ile olan bağlantısı gibi bilgileri edilgen yöntem ile
(kitap yada belge okuyarak) öğrenmeliyiz. Çünkü bu bilgilerin
hepsini etkin yöntem ile öğrenmek oldukça zordur. Edilgen
yöntem ile öğrendiğimiz bu tür bilgileri en az birkaç uygulama
ile pekiştirip tam olarak nereleri öğrenmediğimizi, eksiklerimizi
görmüş ve sonrasında tamamlamış oluruz. İşte etkin ve
edilgen öğrenme yöntemlerini bu şekilde beraber
kullanmalıyız.

2.1. Öğrenmenin Maliyeti

Her öğrenmenin bir bedeli vardır. Kimi öğrenme zaman olarak

maliyet çıkarırken, kimi öğrenme ise emek/enerji harcama
olarak maliyet çıkarır. Tahmin edileceği üzere zaman bazlı
maliyet edilgen öğrenim için geçerli iken, emek bazlı maliyet
etkin öğrenme için geçerlidir.

Öğrenme maliyetleri her öğrenme biçimi için ödenmesi

gerekir. Bundan kaçış yoktur. Dolayısıyla bedavadan, kolay
yollu öğrenme hayallerine girilmemelidir. Maliyet konusundaki
güzel haber ise maliyetleri ödedikçe bir sonraki maliyetlerin
miktarı giderek azalmaktadır.
3. Temel Bilgi ve Tecrübeler

Gömülü sistemler alanında çalışan(çalışmak isteyen) her

yazılım mühendisinin bilmesi gereken temel konular vardır. Bu
temel konuların öğrenilmesi bu belgenin amacı olmadığı için
temel bilgi eksiklerini okurun kendisi tamamlamalıdır.

Aşağıda belirtilen temel bilgilerin birkaçında eksiğiniz varsa

bile bu belgeyi okumaya ve örnek projeyi yapmaya devam
edebilirsiniz.

C programlama Diline Hakimiyet: Bilindiği üzere C dili

donanıma en yakın dil olarak kabul edilmektedir. Bu yüzden C
dili hala en popüler ve kullanışlı diller arasındadır. İyi dil bilgisi
yazılımcının her zaman en kuvvetli silahıdır. Bu yüzden her
zaman C bilgisi canlı ve güncel tutulmalıdır.

Donanım Bilgisi: Gömülü sistemlerde çalışan her yazılımcı ne

kadar üst seviye dil kullansa da donanımla içli dışlıdır.
Özellikle cihaz sürücüleri(device driver) katmanında çalışıyor
ise zaten donanım bilgisi olmadan olmaz. Gömülü yazılımcı
olarak donanım bilgisi ile donanım yapmak arasındaki farkı
bilerek donanım konusunda bilgi edinmeliyiz. Örneğin I2C
okumasında problem yaşandığında pull-up ve pull-down direnç
kontrolü, adres çakışması gibi bilgiler ile yazılımı
doğrulayabilir yada problemin yazılımda olduğu kararına
varabiliriz.

Donanım bilgisi kart tasarım aşamasında da oldukça

faydalıdır. Yazılımı kolaylaştıracak bilgiler donanım ekibi ile
paylaşılarak tasarım aşamasında yazılımın kolaylaştırılır.

İşlemci Çevre Birimlerinin Kullanımı: Gömülü yazılımda I2C,

SPI, UART, PWM, TIMER gibi birimler oldukça sık kullanılır.
Hatta bu birimlerin kullanılmadığı proje yoktur. Dolayısı ile bu
çevre birimlerin nasıl çalıştığı konusunda eksiksiz bilgimiz
olması gerekir.
Bellek Kullanımı: Veri yapıları da gömülü sistemlerde oldukça
kullanılır. En bilinen olan dizilerin kullanılmadığı uygulama
yoktur. Bunun yanında Link List, Binary Tree, Queue, Stack gibi
yapıları da bilmekte fayda var.

İşlemci Marka ve Modelleri: Her ne kadar bir gömülü

yazılımcının donanım bağımsız kod geliştirmek gibi hedefi
olsa da işin içinde işlemci ve donanım vardır. Bu yüzden
kullanılan işlemcini özellikleri bilinmelidir. Örneğin ARM
mimarisi bilgisi, özel çevre birimileri(ekran sürmek, keypad
okumak gibi) gibi bilgileri bilmek gerekir. Piyasadaki
işlemcilere genel olarak tanımak gerekir.

IDE Kullanım Bilgisi: Günümüzde kullanılan işlemciye göre IDE

seçimi yapılması gerekiyor. Örneğin STM için StmCubeIDE,
NXP için MCUXpresso, Infineon için DAVE kullanılan ideler.
Her ne kadar bu ideler Eclipse bazlı olsa da her birinin kendine
has özellikleri var. Bu yüzden piyasada yaygın olarak kullanılan
işlemcilere ait IDE hakkında az da olsa bilgi sahibi olunması
fayda sağlar.

Cross Compile Bilgisi: Özellikle embedded linux geliştirmesi

yapıldığında cross compiler bilgisinin faydası olmaktadır.
Çünkü embedded linux platformları için özel IDE
bulunmamakta. Yazılımcılar Eclipse üzerinden cross compiler
ayarlarını yaparak kod geliştirmektedir.

Derleme Araçları: Derleme araçlarının en bilineni Makefile’ dır.

Bunun yanında CMake de bilmekte fayda var.

Diğer Yardımcı Araçlar: Seriport terminalleri (minicom gibi),

canbus terminalleri gibi kod geliştirirken yardımcı olan diğer
araçları da bilmekte fayda vardır.

Ubuntu Kullanımı: Linux PC ortamında çalışmak bazı projeler

için (hatta çoğu denilebilir) mecburi olmasada bir gömülü
yazılımcı linux Pc kullanımını seçmelidir. Bu onun hem linux
bilgisini arttırır hem de embedded linux ortamına geçişini
kolaylaştırır.

4. Tek miyiz, Takım mıyız?

Gömülü yazılım sektöründe bulunup iyi bir kariyer edinmek

gerçekten de kolay değildir. Çünkü yazılım dışında birçok
alanda da bilgi sahibi olunması gerekmektedir. Ayrıca
edinilmesi gereken bilgiler de sabit değildir. Teknolojinin
ilerlemesi ile sürekli öğrenilmesi gereken yeni bilgiler
çıkmaktadır.

Gömülü yazılımcı olmanın zorluklarına Temel Bilgiler ve

Tecrübeler başlığındaki maddelere bakarak da anlayabiliriz.
Birden fazla alanda bilgi edinmek kimi zaman yorgunluk kimi
zamanda motivasyon eksikliği oluşturur. Yazılımcıların
yaşadığı bir diğer yaygın problem ise zaman yönetimidir.
Kişisel zaman, iş zamanı ve bireysel gelişim zamanlarını ya
karıştırırlar yada hiç kullanmazlar. Kısacası bu üç problemi
aşmak yada çözüm bulmak kariyerimizde hızlı ve dolu
ilerlememizi sağlar.

Yorgunluk, motivasyon eksikliği ve zaman yönetimi konularını

çözmenin en iyi yolu ekip olmaktır. Konu ve sorunların
paylaşımı, sosyal ilişki, yalnız olmamak, danışacak birini
olması bulunmaz nimettir. Tabi bu ekibin birbiri ile uyumlu
olması gerektiği konusuna girmeye hiç gerek yok. Okul
arkadaşları, iş arkadaşlar, eski işyerinden arkadaşlarla hobi
projeleri yada yarı amatör projeler için ekip oluşturmak
oldukça iyidir. Hatta ekip içinde farklı sektörlerde çalışan
kişilerin olması hem projeye hem de kişilere oldukça fayda
sağlar. Bu yüzden bu belgeyi okuduktan sonra eğer bir takım
kurma ihtimaliniz var ise hiç beklemeden o takımı kurun.

Takım olmanın da zorlukları olduğunu unutmamak gerekir.

Kimi zaman ikna çabaları, sözlerin tutulmaması yada
ödevlerin yapılmaması gibi durumlar yaşanır. Bunlar olağan
konulardır. Eğer bu durumlar can sıkıcı boyuta ulaşır ise artık o
takımda olunmaması gerekir. Takım olgusunun nerede bittiği
konusu sizi proje yönetimi ve karar alma konusunda da
geliştirir.

Takım olmanın yazılım tarafından bakınca saymakla bitmeyen

faydası vardır. En azından yazdığınız kodu gözden geçirip size
hataları söyleyecek birisi var demektir. Takım olarak kod
yazıldığında doğal olarak iş paylaşımı olacaktır. Bu da birden
fazla kişinin yazdığı kodun günün sonunda birleşmesi ve
çalışması demektir. Birden fazla kişinin kod yazması kulağa
hoş gelse de oldukça zor ve sıkıntılı yanları da vardır. Örneğin
en azından bir versiyonlama sistemi -git- kullanılması gerekir,
kodların çakışmaması gerekir, farklı bilgideki kişilerin
oluşturacağı farklı seviyede buglar oluşur…. Takım
çalışmasında işte bu hatalı ve sıkıntılı konular ne kadar az
yaşanıyor ise takım içindeki herkesin kodlama ve yazılım
bilgisi artıyor demektir. Takım olmaktaki amaç da budur, takım
olarak kodlama yapan kişiler bireysel olarak zaten kodlama
yapabilir. Birde uyum içinde çalışan bir ekibin neredeyse
yapamayacağı iş yoktur.

Eğer takım oluşturacak kişi yok ise etrafımızda doğal olarak

tüm yapılacaklar bize kalır. Tek olmamız birşeylar yapılamaz
demek değildir. Fakat bu durumda çalışmalarımızı
tamamlama isteğimizi hep yukarda tutmamız gerekir, tıpkı
Linus Torvalds gibi. :)

Tek başına çalışmanın da avantajları vardır. Takım içindeki

kişisel problemlerle uğraşmamak, arkadaşların bilgi
eksikliğinden kaynaklanan problem ve sorunları yaşamamak
gibi. Tek başına çalışmada yapılması mantıklı olan iş ise
kodları açık hale getirip başka kişilerin yorum yapmasına
olanak sağlamaktır.

5. Proje Seçimi
Bu başlığa kadar sadece ön bilgilendirme yapıldı. Yazılımcının
kendini nasıl geliştireceği ise bu başlıktan sonra detaylı
anlatılacaktır. Bu anlatılanları uygulamak hiç şüphe yok ki her
seviyedeki yazılımcıya katkı sağlayacaktır.

Yukarıda etkin ve edilgen öğrenmeden bahsettik ve öğrenim

planımızın çoğunu etkin öğrenme üzerine kurmamız
gerektiğini açıkladık. Etkin öğrenme yöntemini kullanarak
yazılımcının kendini geliştirme yolu PROJE YAPMAKTIR.
Yapılan her projede yazılımcı farklı konularda birçok bilgi
edinir, karşılaştığı birçok problemi çözer, tecrübe ve düşünme
hızını arttırır.

Proje yapmak için yüksek motivasyon ile başlanmalıdır. Fakat

motivasyon sabırsızlığa neden olmamalıdır. Sabırsız
davranışlar ilgi ve odaklanma azalması yaşattığı için önce
motivasyon düşer, devamında da proje yarım kalır ve unutulur.
Bu yüzden kendimize bir şeyler katmak için uğraştığımız
projelerde sabırlı olmak gerekir. Kimi zaman bir donanım
ürününün elimize ulaşmasını, kimi zaman ise kodlamanın bitip
sonraki adıma geçmeyi beklemeyi bilmek gerekir. Bilgi
edinmenin yanında projeden zevk de alınmalıdır. Bu yüzden
belge okuma, kodlama, uygulama, test gibi adımlar acele
etmeden sindire sindire yapılmalıdır.

Peki hangi proje, amaç ne olacak, ne yapayım da kendime

birşeyler katayım? İşte en büyük soru bu. Hatta proje yapmak
isteyipte bu sorulara cevap veremediğimiz için bir türlü proje
beğenmediğimiz ve sonrasında bir şey yapmadığımız çok
olmuştur. Bu yüzden kendi seviyenize göre aklınıza gelen bir
projeyi çok da irdelemeden hemen yapmaya koyulun. Fakat
proje içeriği ve alanı tekrarlayan konular olmamasına özen
gösterin.

Proje bulamama sorununun çözümü aslında oldukça basit ve

elimizin altındadır. Bulunduğumuz yada çalışmak istediğiniz
sektörü araştırdığımızda yüzlerce proje bulabiliriz. Örneğin
sayaç sektöründe isek kablolu yada kablosuz okunan
sayaçları inceleyip bu tür bir proje yapabiliriz. Benim
kullandığım yöntem aynen budur. Firma sitelerinden ürünleri
inceleyip ya o ürünün bir özelliğini veya tamamını yapmayı
hedef kılarak proje oluşturuyorum.

Savunma sanayi alanında da bireysel veya takım olarak

yapılabilecek birçok ürün bulunmaktadır. İlk akla gelen firma
olan Aselsan’ ın sitesine girip ürünlerine bakabilirsiniz. Ben
daha fazla bilgi edinmek için http://www.army-guide.com/
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttp://www.army-
guide.com/%26amp;sa%3DD%26amp;source%3Deditors%26a
mp;ust%3D1613429118489000%26amp;usg%3DAOvVaw1qoz
V3S-
ABzLnVUFMZKXuX&sa=D&source=editors&ust=16134291185
54000&usg=AOvVaw2CezSn4muReQ5u0mqM_Qzo) sitesini
kullanıyorum. Bu sitede tüm askeri ürünler bulunmaktadır.
Aramayı hangi ülke ne üretiyor veya bir ürünü hangi ülkeler
üretiyor şeklinde aratabilirsiniz. Ayrıca bu sitede aylık olarak
yayınlanan ücretsiz dergi de bulunmaktadır. Bu sayede sektör
ve ürünler hakkında bilgi de edinmiş olursunuz. Bu siteyi
oldukça kullanışlı buluyorum.
Ana sayfada Information->Product tıkladığımızda karşımıza
ürün arama alanı çıkar. Bu alanda Country kısmına Turkey
yazarsak Türkiye'de üretilen tüm ürünleri görmüş oluruz.
Örnek ekran görüntüsü aşağıdadır.

Proje olarak Araç İçi Konuşma sistemini belirledim ve bu site

üzerinden bu tür ürün üreten firmaları inceledim. İnceleme
sonunda üç farklı firmadan bilgi edindim.

https://at-communication.com/en/
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://at-
communication.com/en/%26amp;sa%3DD%26amp;source%3
Deditors%26amp;ust%3D1613429118490000%26amp;usg%3
DAOvVaw3icKrQi1M8UCC8aIqL4bNq&sa=D&source=editors&
ust=1613429118554000&usg=AOvVaw1N-YA-esY4a8lnN-
iix223)

https://www.aselsan.com.tr/tr/cozumlerimiz/askeri-
haberlesme-sistemleri/ic-konusma-sistemiic-haberlesme-
sistemi-birimleri/6680-ic-konusma-sistemi-urunleri
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://www.aselsan.com.tr/tr/cozumlerimiz/askeri-
haberlesme-sistemleri/ic-konusma-sistemiic-haberlesme-
sistemi-birimleri/6680-ic-konusma-sistemi-
urunleri%26amp;sa%3DD%26amp;source%3Deditors%26amp;
ust%3D1613429118490000%26amp;usg%3DAOvVaw3nHn1t_
2sY116Jfj6j4vi9&sa=D&source=editors&ust=1613429118554
000&usg=AOvVaw2dsFEvCvESs-oSjw39p7ov)

https://tacticalintercom.com/vehicle-ics
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://tacticalintercom.com/vehicle-
ics%26amp;sa%3DD%26amp;source%3Deditors%26amp;ust%
3D1613429118491000%26amp;usg%3DAOvVaw1Xv8TtUz8dT
OyBs-
h40s3o&sa=D&source=editors&ust=1613429118554000&usg
=AOvVaw0Wzg0rO1B8gEcjcwLK6i9Y)
Yukarıdaki resimler üç firmanın ürünlerine ait resimler ve firma
web sitelerinden ulaşılabilir. Bu ürünlerin özelliklerini de yine
firmaların web sitelerinden ulaşabilirsiniz.

Ayrıca savunma sanayi ürünlerini takip etmek için

https://defense.tecknowledgey.com/
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://defense.tecknowledgey.com/%26amp;sa%3DD%
26amp;source%3Deditors%26amp;ust%3D161342911849100
0%26amp;usg%3DAOvVaw25EckyOnBf885KFBXzr2T5&sa=D&
source=editors&ust=1613429118555000&usg=AOvVaw1Un9
UJnDzt2q7daQaAEWd9) sitesini de takip edebilirsiniz.
Proje belirlerken özetle aşağıdaki kriterleri göz önünde
bulundurmak faydalı olur.

Çalışılan yada çalışılmak istenen sektör kapsamında olması,

Eksik bilgimiz olan konuları içermesi,

Öğrenilecek yeni teknoloji yada konu içermesi,

Kodlama konusunda tatmin edecek seviyede olması,

Kişisel yada takım olarak geliştirilebilecek seviyede olması,

Çok fazla donanım gereksinimi olmaması,

Zevk alınacak konu olması,

Projenin bire bir yapılması şartı konulmaması,

Projenin tamamlanması 6-8 ayın üzerinde olmaması. (Çok

uzun süre sıkılmaya neden olabilir, ayrıca detaylarda boğulup
gelecekte yapılabilecek projelerin vaktini çalabilir)

Projeyi için gerekli belgelere ulaşılabilir olması,

Projenin fazla maliyetli olmaması,

Proje geliştirme kartları yada hazır boardlar ile yapılabilir

olması,

6. Proje Analizi

Proje seçiminden sonra sıra proje analizine gelir. Yapılan

analiz sonrasında eğer proje uygun görünmez ise
değiştirilebilir. Bu yüzden bu adım projeye başlamadan önceki
son geri dönüş noktasıdır. Eğer analizler sonucu projeye
başlama kararı alınmış ise proje bitene kadar devam
edilmelidir. Yarım bırakılan işler yarım bilgi, kaybolmuş
motivasyon ve özgüvensizlik oluştururken tamamlanmamış ve
başarısızlığa uğramış bir proje oluşur.
Proje analizinde hem donanım hem de yazılım alanında
analizler yapılmalıdır. Donanım analizi, donanım tasarımı
yapmaya yönelik olmamalıdır. Bizler gömülü yazılım alanında
gelişme sağlamak istediğimiz için donanım bizim için şuan
uğraş konusu değildir. Ama eğer istenirse projenin başarılı bir
şekilde tamamlanmasından sonra donanım konusunda da
detaylı çalışma yapılabilir. Donanım analizinde genel olarak ne
tür işlemci yada mikrokontrolör kullanılmalı, olmazsa olmaz
çevre birimler neler , mecburi sensörler neler, çalışmayı
yapmak için geliştirme kartı yada piyasada hazır ürün var mı
gibi araştırmalar yapılmalıdır. Özetle gerekli donanım
teknolojileri incelenmeli ve bunları en az çaba ile nasıl temin
edilebilir ona bakılmalıdır.

Yazılım analizinde proje baştan sona detaylı incelenmelidir.

Hangi teknolojiler kullanılmalı, harici kütüphane gerekli mi,
örnek uygulama yada kodlar var mı, kodlama bilgimiz yada
zamanımız bu iş için yeterli mi, birden fazla dil yada uygulama
yazılması gerekiyor mu, bizi geliştirecek yada yeni şeyler
öğretecek içerikler var mı şeklinde araştırmalar yapılmalıdır.
Düşünsenize 2-3 yıllık deneyimli bir gömülü yazılımcının led
yakan yada röle süren bir projeden alacağı katkı nedir. Proje
yazılım konusunda kesinlikle bizi tatmin etmeli ve bazı
noktalarda sınırlarımızı aşmalıdır.

Seçtiğimiz VIS (Vehicle Intercom System) projesinin analizini

yaparak neler ile karşı karşıya olacağımızı görelim. Ben burada
okumayı ve yazmayı kolaylaştırmak için analizi kısa ve
detayları azaltarak ele aldım. Sizler daha detaylı analiz
yapabilirsiniz. Araç içi iç konuşma sistemi projesi için benim
analiz sonucum aşağıdaki gibidir.

1. Mikrofondan alınan ses verisinin yardımcı entegre ile dijitale

çevrilmesi,

2. SAI çevre birimini öğrenmek.

 3. Hoparlör sürücü yükselteç tipleri olan Class-B, Class-AB,
Class-C, Class-D öğrenmek. (Merak edenler için aşağıdaki
linklerde bulunan yazıları okuyabilir.i

1. I2S çevre birimini öğrenmek,

2. SD karta üzerine dosya sistemi kurmak ve ses dosyası

kaydetmek.

3. SD kart yada flash bellek içindeki ses dosyasını çalmak.

4. SD kart ile ilgili bir hata olduğunda kullanıcı görsel olarak

bilgilendirilecektir.

5. WM8960 ve CS43L22 gibi dijital kulaklık, mikrofon ve hoparlör

sürücü entegrelerini tanımak ve kullanmak.(Driver yazmak)

. lwIP kütüphanesini kullanmak,

7. Ethernet donanımının ayağa kaldırılmasını seçilen işlemci için

öğrenmek,

. VoIP hakkında araştırma yapmak ve öğrenmek,

9. RTP hakkında araştırma yapmak ve öğrenmek,

10. SIP hakkında araştırma yapmak ve öğrenmek

11. TCP ve UDP soket kullanmak

12. Ethernet üzerinden ses verisi göndermek

13. Ethernet üzerinden kayıtlı ses verisini göndermek

14. Ethernet üzerinden alınan ses verisini çalmak (RTP)

15. Noise Reduction öğrenmek ve kullanmak,

1 . Ses sıkıştırma yöntemlerini öğrenmek,

17. Ses sıkıştırma kütüphanesi bulup kullanmak,

1 . Paralel LCD sürmek (480x27),

19. UI tasarımı yapmak

20. UI üzerinden kullanıcı girdilerini almak,

21. GUI GUIDER aracının kullanmak,

22. LVGL kütüphanesini kullanmak,

23. MCUXpresso IDE kullanmak,

24. IMX RT 1050 işlemcisini tanımak ve kullanmak,

25. Harici RAM(sram) kullanmak

2 . Harici bellek (Hyperflash yada QSPI Flash) kullanmak,

27. IMX RT1050 Canbus kullanmak,

2 . Log kütüphanesi kullanmak/yazmak,

29. İkincil bootloader kullanmak/yazmak (ethernet, canbus yada

uart üzerinden),

30. Etkili RTOS kullanmak(sadece task oluşturmak rtos kullanmak

değildir.)

31. İşletim sistemini sarmalayarak farklı işletim sistemleri

üzerinde çalışmasını sağlayacak yapı oluşturmak.

32. RTOS için RAM kullanımını yönetmek (task heap ve stack

alanlarını belirlemek),

33. Hem grafik işlerini yapacak hemde gerçek zamanlı çalışacak

yapının yazılım tasarımını oluşturmak,

34. MVC (model-view-control) tasasımına benimsemek ve

kullanmak.

35. Konfigürasyon dosyası yada web server alt yapısı ile

sistem/cihaz ayarlarının yapılabilmesi

3 . Canbus üzerinden cihaza özgü komutların işlenmesi

37. Yazılım birimlerini oluşturup kodlama planı yapmak,

3 . Kodlama doğruluğunu sağlamak için birim testlerin

planlanması ve yazılması
39. Detaylı döküman oluşturmak

Görüldüğü üzere sistemimizde 42 maddelik yazılım konusu

bulunmakta. Bu konular üzerinde bilgi ve hakimiyet
sağladıktan sonra projenin yapılabilirliği oldukça olasıdır.

6.1. Proje Analizinde Gerçekçilik

Yukarıda proje analizi için çıkardığımız maddelerin gerçekçiliği

ne kadar fazla ise projeye olan hazırlığımız ve tutumumuz o
kadar kuvvetli olur. Örneğin projeyi sadece ethernet üzerinden
ses aktarımı olarak bakarsak planlamadığımız ve bilmediğimiz
birçok nokta ile projeyi gerçekleştirme esnasında karşılaşırız.

Proje analizini oluşturmak aslında birçok alanda araştırma

yapmayı içerir. Örneğin biz yukarıdaki kırkbir maddeyi yazmak
için işlemci, kütüphaneler, donanım ve yazılım teknolojileri,
yazılımın akış yapısının ana kriterleri, ana entegreler, ana
iletişim formatları (SAI, I2C), yardımcı programlar gibi birçok
alanda inceleme yaptık. Hatta bu adımda yapılan analizler
sonrasında proje, ekip/kişi gözünde neredeyse tüm adımları
belli olan ve sadece uygulanması gereken iş kıvamına
dönüşür.

Proje analizinde tüm detayları belirledikten sonra eğer bazı

konular bizi zorluyor ise yada yapmaya gerek yok ise
elenebilir. Örneğin konfigürasyon dosyası yada web server alt
yapısı ile sistem güncelleme bu projede ana kriter değildir.
Eğer daha öncesinde bu tür çalışma yapıldıysa bu madde
çıkarılabilir.

6.2. Proje Analizi Sonrası Projenin

Yapılabilirlik Kararı

Bazı konularda ekleme yada çıkarma yaparak proje analizinde

son noktaya geldiğimizi düşünelim. Bu noktada doğal olarak
projenin kritik gereksinimleri varlığını koruyacaktır. Bu kritik
gereksinimlere daha öncelik vererek tüm maddeleri göz önüne
aldığımızda bu projenin bizim için uygun olup olmadığı
kararına varmamız gerekir. Aşağıdaki koşulların olması
durumunda benim kararım ya o projeyi iptal etmek yada
dahada basitleştirerek yapmak olur.

Bilinmeyen konu %60 üzerinde ise,

Donanımsal olarak çalışma ortamı sağlanamıyor ise

Projenin yapılması 6-8 aydan fazla sürüyor ise. Bu durumda

proje alt projelere ayrılıp istenirse alt projeler tamamlanır.
Yada detaylar azaltılarak zaman kazanılabilir.

Proje kişisel gelişim açısından katkısı çok az ise.

Proje piyasada buluna birçok hazır kütüphanenin tekrarından

oluşuyor ise. (örneğin Mod-Bus kütüphanesi yazmak ne kadar
avantajlı olabilir. Mod-Bus kütüphanelerini aktif kullanmak/
öğrenmek daha verimli bir çalışma olur.)

Kişisel ilgi alanınıza girmiyor ise.

Yukarıdaki koşulları göz önüne aldıktan sonra projeyi yapma

kararı aldığımızı düşünelim. Bundan sonrası ise tamamen
odaklanıp çalışmaktır. Gerçekten iyi yapılmış bir proje
analizinden sonra proje inanın gözünüzde canlanacaktır. Hatta
eksik alanları bile nasıl tamamlayacağınızın planı kafanızda
oluşur.

6.3. Proje Gereksinimlerinin Belirlenmesi

Projeyi yapma kararından sonra sıra, en kritik belgelerden biri

olan proje gereksinimlerini hazırlamaya geldi. Bu belge hem
donanım hem de yazılım işlerine ve ekibine yön verecektir.
Kendi projemizi kendimiz yaptığımız için dolayısı ile burada işi
isteyen de yapacak olan da biz olacağız ve belgenin
oluşturulması bizim işimizdir. Proje gereksinimi oluşturmak
aslında bize proje yönetimi ve sektör bilgisi de katar. İlerleyen
zamanlarda edinilen bu tür bilgiler iş hayatında farklı açılardan
bakmayı, vizyon kazanmayı ve oluşacak eksikleri/problemleri
önceden görme gibi çok kıymetli özellikleri kazanmamızı
sağlar.

Proje gereksinimi hazırlamak başlı başına bir iş olup doğru

proje gereksinimi hazırlamak tecrübe ve bilgi ile olur. Bu
yüzden hazırlayacağınız proje gereksiniminin kusursuz
olmasını amaçlamayın. Ana hatları ile seçilen projenin
gereksinimlerini belirtmesi yeterlidir. Proje gereksinimleri
üzerinde internetten birçok kaynak bulabilirsiniz.

Örnek olması amacıyla aşağıda bazı proje gereksinimleri

yazılmıştır. VIS projesinin tüm gereksinimlerine ise bu linkten
ulaşabilirsiniz.

1. Cihazın açma ve kapatma arayüzü olacaktır.

2. Cihaz acil durumda komutan tarafından tüm kişileri ve

telsizleri birbiri ile iletişim sağlamasını isteyecek bir arayüzü
olacaktır.

3. Cihaz 4.3 inch dokunmatik ekrana sahip olacaktır.

4. Komutan kullanıcısı tarafından cihaz dokunmatik ekran ile

yönetilecektir.

5. Cihaz araç içinde 16 kişiye kadar iç konuşma hizmeti

sağlayacaktır.

. Cihaz, farklı iki araç telsizi ile bağlantı kurup telsizleri iç

konuşma sistemine dahil edecektir.

7. Komutan telsizlere ses çıkışını tek tek açıp kapatabilecektir.

Bu durumda dinleme durumu aktif olacaktır.

. Dinlemesi kapatılan telsizlere otomatik olarak ses çıkışı da

kapatılacaktı. (Dinleme olmaz ise konuşma da olmaz)

9. Komutan askerlerin mikrofon çıkışını telsizlere

yönlendirebilecek..
10. Komutan telsizlere erişimi olan asker bağlantısını istediği
zaman kapatabilecektir.

11. VIS konuşmaları komutan kararı ile iç hoparlöre

verilebilecektir.

12. VIS içindeki tüm konuşmalar sıkıştırılarak SD karta

kaydedilecektir.

13. Ses kayıt dosyaları VIS sistemi her çalıştırıldığında zaman

etiketi ile oluşturulacaktır. Eğer kayıt boyutu 100 MByte aşar
ise kayıt dosyası kapatılıp yenisi açılacaktır.

14. SD kart içindeki veriler dışarı aktarılabilecektir.

15. Cihaz PC bağlantısı ile güncelleme yapılabilecektir.

1 . Cihaz PC bağlantısı ile konfigürasyon dosyası yüklenecektir.

17. Ses iletiminde VoIP kullanılmalıdır

1 . Ses iletimi en fazla 10 ms gecikme ile olacaktır.

19. Komutan ve askerler ses seviyesi ayarlanabilir olacak.

20. Cihazın konuşmaların net anlaşılabilir olması için aktif gürültü

önleyici özelliği olmalıdır.

Yukarıdaki örnek maddeler gibi tüm proje gereksinimleri

yazıldığında artık donanım ve yazılım ekibi çalışmak için
uygundur. Yazılım ve donanım ekibi bu gereksinimleri
karşılayacak plan ve işler ile projeyi tamamlar. Tabi biz burada
sadece yazılım çalışması yapacağımız için donanım
konusunda ne yapılacağı ile pek ilgilenmeyeceğiz. Fakat
okuyucuya yinede örnek olması amacıyla donanım analizi
başlığı altında yüzeysel bilgiler verilmiştir.

Bir gömülü yazılımcının kendini geliştirmesi için kodlama

öncesinde bu kadar zahmete gerek var mı diye
düşünebilirsiniz. Genelde hemen kodlama yapmak, yapılanın
çalıştığını görmek gibi aceleci istek oluyor. Bu çalışmaları
yapmadan VIS projesini gerçekleştirmeye başladığımızda
inanın birkaç kodlamadan sonra şimdi neyi kodlayacağım,
burası da böyle olsun yada böyle olmasada olur gibi hiçbir
bağlılığı ve amacı olmayan kod yığınları oluşur. Zate bu
durumda daha da devam edildiğinde kod içinde kaybolup
proje iptal olur. Bu yüzden tembellik etmeden bu belge içindeki
tüm adımları sabırla uygulamak faydalı olur.

7. Donanım Analizi ve Çalışmaları

Sistem gereksinimlerinden donanım gereksinimleri

çıkartılarak donanım ekibi kendi çalışmalarını yapar. Donanım
gereksinimlerinden de donanım tasarım belgesi oluşturur ve
sonrasında donanım tasarımı yapılır. Donanım tasarımı(devre
tasarımı), yazılım ekibi için donanım kaynaklarını nasıl
yöneteceğini bilmesini sağlar. Örneğin mikrofondan sesin
hangi bağlantı arayüzü(SAI, I2S) ile alınacağı yada tft ekranın
nasıl sürüleceği bilgisi devre tasarımından görülür.

7.1. Donanım Gereksinimlerinin

Belirlenmesi

Donanım tasarımı yapmadan yapmadan önce donanım

gereksinimleri belirlenmelidir. Donanım gereksinimleri
belirlenirken her ne kadar sistem gereksinimleri öncülük
etsede donanım mühendisliğinin getirdiği öngörüleri de
gereksinim listesine eklemek gerekir. Örneğin ters voltaja
karşı korumalı olması, dijital girişler için hem gürültü hem de
yüksek voltaj korumasının eklenmei gibi gereksinimler
eklenebilir. Aşağıda örnek donanım gereksinimleri verilmiştir.
VIS projesinin tüm donanım gereksinimlerine bu linkten
ulaşabilirsiniz.

1. Sistem 12-36V aralığındaki girişlerde çalışmalıdır.

2. Tüm sistem kullanımda iken max 5A çekmelidir.

3. Sistem ters voltaj bağlanmasına karşı korumalı olmalıdır.

 4. Ethernet hattı 10/100 Mbit hızı desteklemelidir.

5. LCD backlight ayarlanabilir olmalıdır.

. LCD paralel bağlantılı arayüze sahip olmalıdır ve minimum 16

bit bağlantı ile sürülmelidir.

7. Cihaz ekranı gerektiğinde tamamen kapatılabilir olmalıldır.

. Sistem üç adet analog ses girişine sahip olmalıdır.

9. Cihaz en az 500 MHz de çalışma hızına sahip olmalıdır ve min

32 Mbyte hafıza alanı ile 16 Mbyte RAM alanı olmalıdır.

10. Sitemin bir adet RS422 hattı olmalıdır.

11. Sistemin bir adet 1 Mbit Canbus hattı olmalıdır.

12. Sistemin TTL 3V3 seviyesinde debug mesajları için

kullanılacak bir adet UART hattı olmalıdır.

13. Sistemin hem 12V hem de 24V seviyesinde 4 adet dijital

girişleri olacaktır.

14. Sistemin 24V çıkış veren 4 adet dijital çıkışları olacaktır.

15. Sistemin 0-24V seviyesindeki analog girişleri ölçmek için 12

bit çözünürlükte 4 adet ADC girişi olacaktır.

1 . Board üzerinde 2 adet debug ledi olmalıdır.

17. Cihazın mikro ve kilitlemeli SD kart bağlantısı olmalıdır.

1 . Cihazın 1 adet USB-Host girişi olmalıdır.

19. Cihaz JTAG üzerinden programlanabilir olmalıdır.

20. Cihaz araç dışındaki ve içindeki hoparlöre istenilen sesi

gönderecektir

7.2. Donanım Birimlerinin Belirlenmesi

Donanım gereksinimlerinden sonra sıra donanım birimlerini
belirlemeye gelir. Daha öncede dediğim gibi bir gömülü
yazılımcı olarak donanım işleri ile normalde bu kadar içli dışlı
olmamamıza rağmen yinede okuyucuya ufak da olsa bilgi
vermesi amacıyla donanım başlıkları altında özet bilgiler
yazıyorum.

7.3. Belgeleme

Ister bitirme projesi yapın isterseniz de kendinizi geliştirmek

için yaptığınız proje olsun her zaman belge yazmayı,
yapılanları not almayı ihmal etmeyin. Aksi takdirde aklınızdaki
planlar uçup gider. Ayrıca kişisel olarak başladığınız projeler
kimi zaman vakit darlığından dolayı ara verilerek ilerleyebilir.
Bu gibi durumlarda projeyi tekrar ilerletmek istediğinizde
planlarınız, tasarımlarınız, yapmak istedikleriniz, çözülecek
problemler gibi birçok konuyu tekrar hatırlamak gerekir. Söz
uçar yazı kalır ve yazılan belgeler bir okumada tüm geçmişi,
edinilen bilgileri, kararları bir çırpıda size getirir.

Belge yazmanın bir diğer avantajı da projeye başka biri daha

dahil olmak istediğinde bilgi aktarımını kolaylaştırmasıdır.
Belgelendirmesi iyi yapılan projenin ayrıca hem donanımı hem
de yazılımı iyi olur. Balık baştan kokar :)

8. Yazılım Analizi ve Çalışmaları

Sonunda yazılım başlığına ulaştık diyenleri duyar gibiyim.

Yazılım bilgimizi geliştirmek isterken bir sürü konu ile uğraştık
diyenleriniz olabilir. Eğer iki led yakan, röle süren yada sadece
I2C üzerinden sıcaklık okuyan işler yapmak istemiyorsanız
daha önceki yazılan başlıkların faydasını dişe dokunur bir
proje yaptığınızda anlayacaksınız.

Yazılım projeleri de tıpkı diğer konular gibi önce belge

yazmakla başlıyor. Yazılan belgeler yol haritasını ve
gereksinimleri ne kadar detaylı açıklar ise yazılan kod da hem
o kadar iyi olur hem de projenin/müşterinin isteklerini eksiksiz
karşılar. Kod yazarken kervanı yolda düzmek yapılacak en
büyük hatadır. Öyle projeler gördüm ki bitti denilen projenin
tüm çalışmalarının çöpe atılıp baştan yazıldığına şahit oldum.
Bence iyi yazılımcı olmak için önce planlı ve ileriye dönük
çalışmayı öğrenmek gerekir. Kodlama tüm bu çalışmaların
resmedilmiş hali olacaktır. Kodlamaya başlamadan önce tüm
yapı her noktasıyla kafamızda canlanıyor olması gerekir ve bu
plan belgelerde olması gerekir.

Yazılım analizi proje gereksinimlerinden yola çıkılarak yapılır.

Proje gereksinimlerine bakarak yazılım gereksinimleri
oluşturulur ve sonrasında yazılım tasarım belgesi oluşturulur.
Yazılım gereksinimleri ne kadar detaylı ve net olursa yazılacak
kod da o kadar doğru olur. Kendi projemizi gelişim amaçlı
yaptığımız için yazılım gereksinimi yazma konusunda
eksikliğimiz olabiliriz. Hiç önemli değil, az da olsa bir şeylerin
yazılması yeterlidir. Zaten kod da belge yazmak da yazdıkça
gelişir.

8.1. Yazılım Gereksinimlerinin Belirlenmesi

Kodlamaya doğru giderken yazılım için ilk yapacağımız iş hem

proje gereksinimlerini hem de donanım gereksinimlerini göz
önüne alarak yazılım gereksinimlerini yazmaktır. Bu
gereksinimlere yazılımın yada projenin gelecekte
güncellenmesi ihtimaline karşı da gereksinimler eklenebilir.
Örneğin projenin farklı işletim sistemleri üzerinde
çalışabilmesini istemek yazılımcı gözüyle eklenmiş bir
gereksinimdir. Bir diğer örnek, dosya yazma okuma
işlemlerinin farklı işletim sistemleri için çalışabilir olmasını
istemek olabilir. Yazılım gereksinim hakkında aşağıdaki iki
linkten daha fazla bilgi alabilirsiniz.

VIS projesi için örnek yazılım gereksinimleri verilmiştir. VIS

projesinin tüm yazılım gereksinimlerine ise bu linkten
ulaşabilirsiniz.

1. Sistem güç verilmesinden sonra kesintisiz olarak çalışmalıdır.

2. Cihaz açılış esnasın ATLAS Embedded Software Academy

yazısı ve logosunu basacaktır.

3. Sistem komutan ekranı üzerinden kontrol edilecektir.

4. Canbus üzerinden sistem diagnostik bilgileri gönderilecektir.

5. PC bağlantısı sağlandığında sistem yazılım verisoyonu

görülebilecektir.

. Sistem PC ile ethernet üzerinden yüklenen yeni konfigürasyon

dosyasına göre cihaz çalışması düzenlenecektir.

7. Sistem web server arayüzü ile konfigure edilebilecektir.

. Sistem istenildiğinde çalıştı konfigürasyon dosyaını ethernet

üzerinden dışa aktaracaktır.

9. Yazılım hem FreeRTOS hem de linux sistemleri üzerinde

çalışabilir olacaktır.

10. SD kart okuma, yazma gibi işlemlerde hata olduğunda LCD

ekranda uyarı verilecektir.

11. SD kart üzerinde FAT32 dosya sistemi olacaktır.

12. Her cihaz açılışında sistem kullanılmaya başlandığında tarih-

saat etiketi ile yeni kayıt dosyası oluşturulacaktır.

13. Ses kayıt dosyalarının boyutu 100 MByte geçmeyecektir. 100

Mbyte sınırına dayanan kayıtlar için tekrar tarih-saat etiketi ile
yeni dosya oluşturulacaktır.
14. SD karta veriler DSB(daha sonra belirlenecek) sıkıştırma
yöntemini kullanan DSB kütüphanesi kullanarak
kaydedilecektir.

15. Ses transferi için RTP yapısı kullanılacaktır.

1 . Ses transferi şifresiz olarak yapılacaktır.

17. Ses iletimi gecikmesiz ve gürültü filtreleme kullanılarak

yapılacaktır.

1 . Ekran parlaklığı dokunmatik ekran üzerinden

ayarlanabilecektir.

19. Hem Canbus üzerinden hem de ayrık sinyal olarak araç

karartma sinyali yakalanacaktır.

20. Karartma sinyali sonrasında ekran kapatılacaktır.

Tahmin edileceği üzere bu projenin yazılım gereksinimleri bu

20 maddenin çok daha fazlasından oluşmaktadır. Burada
örnek olması amacıyla 20 madde verilmiştir. Tüm
gereksinimlerin eksiksiz yazıldığını düşündüğümüzde
yazılımın hangi koşulları sağlaması gerektiğini ve hangi
koşullarda ne yapması gerektiğini açıkça görmüş oluruz. Bu
maddeleri yazmadan yada eksik olarak kodlamaya
başladığımızı düşünsenize, çölde yön bulmak gibi bir şey olur.
Tekrar söylemekte fayda var kervanı yolda düzmeye çalışan
tüm projeler başarısız olur. İtiraz edilmesine rağmen bizzat
şahit olunmuştur :)

8.2. Yazılımı Birimlerinin Belirlenmesi

Yazılım tarafında işin heyecanı artarak ilerlerken sırada

yapılması gereken iş yazılım birimlerinin belirlenmesidir.
Yazılım gereksinimlerini karşılayan birimleri
oluşturduğumuzda hangi gereksinimi hangi birim oluşturmuş
olur görürüz. Yazılım birimleri hakkında “Baştan Sona Gömülü
Yazılım Projesi Yapımı” (https://www.google.com/url?
q=https://www.google.com/url?
q%3Dhttps://zafersatilmis.com/2021/01/24/bastan-sona-
gomulu-yazilim-projesi-
yapimi/%26amp;sa%3DD%26amp;source%3Deditors%26amp;
ust%3D1613429118505000%26amp;usg%3DAOvVaw1cmnxX
gCmtYDrBtCFGvTUi&sa=D&source=editors&ust=1613429118
563000&usg=AOvVaw2lwX-RxQ5cKBgrGNqdXpy5) yazımda
da bilgi vermiştim, isterseniz orayı da bir okuyun.

Yazılım birimleri oluşturma yazılım gereksinimleri yazmaya

göre biraz daha fazla dikkat ve tam olarak yazılımcı gözüyle
bakılmasını ister. Çünkü birimleri oluştururken şu düşünceler
akılda olmalıdır:

Oluşturulacak birim birden fazla gereksinimi karşılamalıdır.

Oluşturulacak birimin görevi karşılayacağı gereksinimlerin

ötesine geçmemelidir

Birimin diğer birimlerle olan ilişkisi planlanmalıdır.

Birimin görevi açık ve tek olmalıdır.

Birimler tek başına kodlanabilir olmalıdır.

Gereksinimleri karşılamanın dışında yazılımı yada kodlamayı

kolaylaştıracak birimler de oluşturulmalıdır. Örneğin
MVC(model-view-controller) yapısını sağlayan birim

Bu bilgiler ile yazılım birimlerini oluşturduktan sonra yavaş

yavaş yazılım mimarisi ufak ufak kafamızda canlanmaya
başlar. En azından bare-metal mi RTOS mu yoksa linux sistemi
mi kullanmamız gerektiği kendini göstermeye başlar. Örneğin
bizim projemizde ekran sürme, UI, gerçek zamanlı ses iletimi,
yüksek hızda canbus mesajlaşması, dokunmatik ekrandan UI
bağlı kullanıcı girişlerini alma, SD karta kaydetme, sistem
hatalarını takip edip diagnostik mesajı oluşturma ve
donanımları sürme işi gibi birçok iş var. Bunların hepsi
oluşturacağımız yazılım birimlerinde görülecektir. Doğal olarak
projeyi Bare Metal kodlamak doğru bir seçim olmayacaktır.
Düşündüğümüzde birimler bize RTOS yada linux sisteminin
olmasını gösteriyor. Aşağıda oluşturulan yazılım birimleri
görülmektedir.

8.3. Yazılım Dili Seçimi

Yazılım birimlerini de oluşturduktan sonra kodlama adımına

doğru gidiyoruz. Kodlama yapacağız ama hangi dili kullanarak
kodlayacağız. Dil seçiminde birden fazla etken vardır. Hatta bu
etkenlerden bazılarını kendimiz de oluşturduğumuz olur.
Örneğin açık kaynak kodlu bir proje üzerine proje
gerçekleştirilmek istenirse doğal olarak o projenin yazıldığı dil
ile devam ederiz. Genel olarak aşağıdaki maddeler proje dilinin
belirlenmesinde etkilidir diyebiliriz.

Açık kaynak kodlu proje üzerine geliştirme yapılacaksa o

projenin dili kullanılır.

Aktif olarak kullandığımız dil çeşidi az ise bilinen dil kullanılır,.

Örneğin sadece C dili yetkinliğimiz var ise doğal olarak projeyi
de C dili ile kodlamamız gerekir.

Takım çalışmasında takımın farklı dillerde olan yetkinliği az

ise aktif olarak kullanılan dil kullanılır. Takım içinde bir kişinin
C++ bilmesi projenin C++ ile kodlanmasını sağlamaz.

Kullanılacak kütüphanelerin dili proje dilini belirleyebilir. Eğer

kullanılacak kütüphane projenin çok büyük bölümünde kolaylık
sağlıyor ise yada proje bu kütüphane etrafında şekilleniyor ise
projeyi o kütüphanenin yazıldığı dil ile oluşturmak gerekebilir.
Bu durum kütüphane diline göre zorunluluk olmaktan çıkabilir.
 Örneğin kütüphane C dili ile yazılmış olmasına rağmen proje
dili olarak C++ seçebiliriz. Fakat tersi geçerli olmayacaktır.

Projenin büyüklüğü ve karmaşıklığı daha üst seviye dil

kullanımında kodlama kolaylığı sağlayabilir. Bu yüzden bu
kolaylığı kullanmak için ilgili dil seçilebilir.

Projenin Object Oriented Programming yapısına yakın olması

durumunda doğal olarak OOP dillerinden biri kullanılır.

Takımın yada kişinin daha önce yapmış olduğu benzer işlerde

kullanılan dil tekrardan kullanılması mantıklı olur.

Görüldüğü üzere dil seçiminde kararı etkileyen birçok etken

vardır. Fakat proje için uygun dil seçilmesi her zaman fayda
sağlar. Kodlama zorluğunu ve süresi seçilen uygun dil ile
kolaylaşır ve azalır. Üst seviye dillerin getirdiği avantajlar ile
hata oluşumu önceden yakalanabilir. Dillerin standart
kütüphanelerinin sağladığı kolaylık ve faydalar projelere büyük
katkıda bulunur. C dilindeki Link List ile mi kodlama yapmak
istersiniz yoksa C++ dilindeki vektor ile mi, C dilindeki string
fonksiyonları ile mi string işleri yapmak istersiniz yoksa C++
dilindeki string sınıfı ile mi… Bu tür soruların cevabını kendi
içinizde veya ekip içinde verdikten sonra uygun dil seçilir.

8.4. Kütüphanelerin Belirlenmesi

Dil seçimi kadar kütüphane seçimi ve kullanımı da çok

önemlidir. Dünyanın yuvarlak olduğunu tekrar kanıtlamaya
gerek yok. Bu yüzden kullanılabilecek ne kadar hazır
kütüphane var ise kullanılmalıdır. Kütüphaneleri hem dil
kütüphalleri hemde harici kütüphaneler olarak düşünmeliyiz.

Harici kütüphane kullanımında seçilen kütüphanenin güvenilir

olmasına dikkat etmeliyiz. İşimize yarıyor diye internetten
bulduğumuz herhangi bir kütüphaneyi kullanmak ileride
başımızı ağrıtabilir. Bu yüzden onaylanmış yada çokça kişi
tarafından kullanış kütüphaneleri projemize dahil etmeliyiz.
Kütüphanenin ayrıca belgelerinin de olması bize avantaj
sağlayacaktır. Eğer bir iş için birden fazla kaynak var ise
elimizde belgeleri çok olan kaynağı seçmek avantaj sağlar.

Projenin geliştirildiği donanım üreticisinin örnek uygulamaları,

SDK, BSP var ise bunlar da kesinlikle proje gerçekleştirilirken
kullanılmalıdır. Dilin kendi kütüphanesinden tut da harici
kütüphanelere, BSP’ lere, SDK’ lara kadar tüm kaynakları
bilmek de öncesinde iyi bir araştırma yapmayı gerektiriyor.
Yoksa tüm bu yardımcı kaynakları nasıl bileceksiniz. Örneğin
projemizde sesleri kaydetme adımında önce ses verilerini
sıkıştırmak istiyoruz. Bu durumda sıkıştırma algoritmalarını ve
kütüphanelerini bulmak gerekir.

Hangi konular için kütüphane araştırması yapmamız

gerektiğini bize belirlediğimiz yazılım birimleri söyler. Örneğin
sıkıştırma işlemi yapan yazılım birimimizi kodlamaya
başlamadan önce bununla ilgili kütüphane yada algoritma
araştırması yapmamız gerektiği açık. Diğer bir örnek RTP ile
ses iletimi. RTP için de araştırma yaptığımızda çok fazla
kaynak göreceğiz.

Kütüphaneler belirlendikten sonra sıra onların belgelerini

okuyup nasıl kullanıldğını anlamaya geliyor. Örneğin ethernet
için LwIP kütüphanesini kullanmaya karar verdik diyelim. LwIP
nedir, nasıl çalışır, nelere ihtiyaç duyar(belki bizim donanımız
için uygun değil), soket nasıl açılır, nasıl veri gönderilir bunları
öğrenmek gerekir. Belgeler okunduktan sonra da birkaç örnek
yapmak yada hazır örnekleri çalıştırmak da kütüphane
kullanımını anmaka için gereklidir. Doğru kullanılmayan
kütüphanelerin hem bug oluşturma hem de çalışmama
ihtimali vardır.

8.5. Yazılım Mimarisini Belirleme

Yazılım birimlerini oluşturduk, dili ve kullanılacak
kütüphaneleri seçtik kodumuzu yazmak için hazır
görünüyoruz. Peki kodumuzu yazacağız ama uygulamanın
akışı nasıl olacak. Birbirinden bağımsız ve birbirine bağlı bir
sürü iş döngüsü var. Bu bağımsız ve bağımlı iş döngülerini
nasıl yöneteceğiz? Paralel ve seri yapıların nasıl
yönetileceğinin belirlendiği, yapılacak işlerin oluşma biçimi ve
ele alınacağı sıra gibi konular -aslında tüm kodun akışı-
yazılım mimarisi ile belirlenir.

Yazılım mimarisini belirlemek, geçmiş deneyimlerimiz ve

okuduğumuz kitapların bizde oluşturdu bilgi birikimi ile
mümkündür. Ne kadar çok farklı mimariler ile çalıştıysak, ne
kadar çok yazılım mimarisi üzerine kitap okuduysak tüm bu
bilgiler aklımızda sentezlenir ve yazılım için uygun olan mimari
seçilir. Bu cümleden sakın yanlış anlaşılmasın, yazılım
mimarisi kişiye gelen ilham ve biraz düşünmeyle bir anda
oluşan bir şey değildir.

Yazılım mimarisini oluştururken üzerinde düşünülmesi

gereken ana kriterlerden bazıların aşağıda kendimce
sıraladım.

Sürekli yapılması gereken paralel iş sayısı

Bir tetiklenme sonrasında yapılması gereken paralel iş sayısı

Kullanıcı ve sistem girdilerinin ele alınma imkanları ve

yöntemleri (interrupt yada polling)

Birbirine bağlı olarak çalışan seri iş yapıları

Birbiri ile etkileşim içinde olan paralel iş yapıları

Birbiri ile etkileşim içinde olan paralel iş yapılarını

senkronlama yapısı

Sistemim çalışma hızı. Gerçek zamanlılık şartı.

Hangi işlerin gerçek zamanlı çalışması gerektiği

 Ekran/UI varlığı,

UI pencere sayısı

UI üzerinden girdi alınıp alınmayacağı (dokunmatik ekran

buton kullanımı)

UI ile arka tarafta çalışan yapının ilişkisi (MVC için uygun mu)

Yazılım mimarisini belirlerken yukarıdaki parametrelere daha

da ekleme yapılabilir. Fakat mimariyi oluştururken bu
karmaşıklığın içinde bize yardımcı olan bilgiler de vardır.
Yazılım kalıpları(Software Design Pattern
(https://www.google.com/url?q=https://www.google.com/url?
q%3Dhttps://tr.wikipedia.org/wiki/Tasar%2525C4%2525B1m_
%2525C3%2525B6r%2525C3%2525BCnt%2525C3%2525BCler
i%26amp;sa%3DD%26amp;source%3Deditors%26amp;ust%3D
1613429118509000%26amp;usg%3DAOvVaw0zilr0t2ot0-
LPSddbNjZ3&sa=D&source=editors&ust=1613429118565000
&usg=AOvVaw08dMbc4qw8UGW5eqts9deH)) mimari
oluşturmada oldukça faydalıdır. Yazılım kalıpları tasarımınızın
hem nasıl olması gerektiği yönünde hemde nasıl olmaması
gerektiği yönünde bize yol gösterir. Eğer yazılım kalıpları
konusunda hiç bilginiz yok ise en azından kalıpların
özetlenmiş halini okumanızı öneririm. Yazılıma ve kodlamaya
karşı bakış açınızı değiştirip ufkunuzu açacaktır. Hem yazılım
kalıpları hem yukarıdaki liste hem de geçmiş deneyimlerimizi
göz önüne alarak proje için uygun mimari belirlenir. Kararsız
kalınan noktalarda yardım almayı yada bir şekilde test etmeyi
ihmal etmeyin. Çünkü mimarinin sadeliği ve akıcılığı projenin
seyrini belirler. Karmaşık ve çalışması zor bir yapıda ilerlemek
zor olacaktır ve belkide bir noktadan sonra tıkanma olacaktır.

8.6. Belgeleme

Kodlamaya geçmeden önceki son adım tüm işlerin doğru

şekilde belgelenmiş olmasıdır. Bu kadar belge yazdıktan,
araştırma yaptıktan, kütüphane inceledikten sonra kod
yazmaya hevesim kalmadı diyecek gibi iseniz az daha
sabredin. Eksiksiz belgeleme yaptıktan sonra inanın kendiniz
belgelemesi eksik olan projelerde çalışmak istemeyeceksiniz
ve kodlamadan önce belgeleri tamamlamak isteyeceksiniz.

Yazılım gereksinimleri yazılmış, yazım birimleri çıkarılmış, dil

seçimi nedenleri ile belirtilmiş, kullanılacak tüm kütüphaneler
listelenmiş ve son olarak mimarinin de belirlenmiş olduğunu
düşünün. Kodlama yaparken nerede ne yapacağınız hangi
kalıpları kullanacağınız, kodun nasıl akacağı önünüzde
ayrıntıları ile belirlenmiş olur. Bundan sonrası kodlama
beceriniz ile projeyi kodlamaktır. Ayrıca bu kadar ön hazırlıktan
sonra projenin başarısız olması yada çok vahim bug/hata
içermesi neredeyse imkansızdır. İllaki hatalar/buglar olacaktır
ama bunlar büyük problemler olarak karşınıza çıkmayacaktır.

Kodlamadan zevk almak için öncesinde tüm belirsizliklerin

ortadan kaldırılması gerekir. Eğer yazılımcı kodlamayı
belirsizliklerin içinde yapmaya kalkar ise hem kodlamayı
bitiremez hem de birçok hata ve eksiklikler oluşur. Tam proje
bitti yada bu yoldan ilerlersem bu isterleri karşılarım
diyorsunuz ve sonrasında müşterinin öyle istemediğini yada
çalışma koşulunun düşündüğünüz gibi olmadığını fark
ediyorsunuz. Bu durumda hem işten hem projeden hem de
kodlamadan soğursunuz. Bu durumu birçok yazılımcı
yaşamıştır hatta hala yaşayanlar vardır.

8.7. Kodlama

Tüm ön çalışmadan sonra kodlama adımına geldik.

Edindiğimiz bilgiler ve verilen kararlar sonrasında artık gidişatı
belli olan projeyi kodlayacağız. Yazılımcının en zevk aldığı
adım burasıdır diyebiliriz. Kulaklığı takıp yapılan planları,
tasarımları kısaca projeyi satır satır kodlamak yazılımcı ya
oldukça zevk verir. Hatta kodlama ilerledikçe projenin belli
kısımları ortaya çıkıp çalıştığı görüldükçe alınan zevk ve
motivasyon daha da artar.
Peki ön çalışmaya uygun olarak kodlarken bir yazılımcılar ne
kadar özgürüz? Tek görevimiz ön çalışmalara bağlı olarak
cihazı çalıştıracak kodu yazmak mı? Yazdığımız kodlar sadece
projeye mi ait olmalı? Bu sorular bizim kodlama becerimizin
gelişmesini ve daha iyi bir yazılımcı olmamızı sağlar. Sırasıyla
bu sorulara cevap verelim ve cevapların içinde bize katkı
sağlayacak bilgilere bakalım.

8.7.1 Peki ön çalışmaya uygun olarak kodlarken biz

yazılımcılar ne kadar özgürüz?

Tahmin edileceği üzere yazılımcı kodlama yaparken belli

kurallara uymak zorundadır. İstediği gibi kodlama yapmak gibi
bir özgürlüğü yoktur. Hatta kimi noktada oluşturacağı
değişkene isim verme konusunda bile tamamen özgür
değildir. Bu durum kulağa sıkıcı yada yanlış gibi gelsede
aslında yazılımcıya çok fazla katkı sağlar. Hatta bug/hata
oluşumunu bile engeller.

Her ne kadar özgürlük kısıtlamak olarak isimlendirdik isekte

aslında kurallar, yazılımcıyı geliştirme ve projeyinin kod
kalitesini sağlama almak içindir. Örneğin katmanlı mimaride
bir yazılımcı uygulama katmanında driver katmanına ait
fonksiyonu çağıramaz. Bunu yapması durumunda katmanlı
yapıyı delmiş olur. Bir diğer örnek ise bir fonksiyon
oluştururken fonksiyona birden fazla görev atamamız doğru
değildir. Yazılan her fonksiyonun tek bir görevi olmalıdır. Son
örneği ise const anahtar sözcüğünü kullanarak vermek
istiyorum. Okuma amaçlı kullanılan referans olarak iletilmiş
değişkenler const olması hem hata oluşumun önüne geçer
hem de okunabilirliği arttırır. Bu şekilde avantajları olan
kodlama yöntemlerinin kullanılma zorunluluğu vardır.
Gözünüzde canlanması için aşağıdaki iki fonksiyonu inceleyin.

int sendData(const char *buff, size_t leng); //tercih edilen

int sendData(char *buff, size_t leng);
Bu kuralların bazıları firmanın kendisinin belirlediği kurallar da
olabilir. Örneğin embedded sistemlerde özellikle MCU tabanlı
projelerde malloc/calloc kullanılması çoğunlukla istenmez.
Eğer firmanız bu fonksiyonların kullanımını yasakladıysa doğal
olarak sizler de bu kurala uymak zorundasınız. Çok bilinen bir
diğer yasaklı araç ise goto anahtar kelimesidir. Neredeyse hiç
bir projede kullanıldığını görmedim ve genellikle de
kullanılması istenilmez.

Kodlama kalitemizi artıracak ve ayrıca yazılım dünyasında

kabul görmüş kurallar nelerdir diye düşündüğümüzde cevap
olarak karşımıza YAZILIM PRENSİPLERİ çıkar. Bu linkteki
yazımda (https://www.google.com/url?
q=https://www.google.com/url?
q%3Dhttps://zafersatilmis.com/2019/10/10/yazilim-
prensipleri/%26amp;sa%3DD%26amp;source%3Deditors%26a
mp;ust%3D1613429118511000%26amp;usg%3DAOvVaw2spG
A2ZP1Pf-
oXaaMqZ25t&sa=D&source=editors&ust=1613429118567000
&usg=AOvVaw0Gi_xsm-pqrxnjJgabz_H9) yazılım prensipleri
üzerine özet bilgi vermiştim. Daha kapsamlı bilgi internetten
araştırılarak uygulanmalıdır. Diğer kurallar ise kod yazdıkça ve
ekip içinde oldukça öğrenilecektir.

Peki kodlama özgürlüğümüzün kısıtlı olması kendimizi

geliştirmek amacıyla yaptığımız projeler için de geçerli midir?
Cevap fazlasıyla Evet. Hatta bu kuralları bulup uygulamak
zaten gelişimi sağlayan ana unsurlardır. Aksi durumda kendi
dünyanızda kendi doğrularınız ile kod yazmış olursunuz.

8.7.2 Tek görevimiz cihazı çalıştıracak kodu yazmak

mı?

Genel olarak yazılımda özellikle gömülü yazılımda kod başarısı

cihazı çalıştırmak yada istenenleri yapması olarak görünüyor.
Tabiki günün sonunda ürün çalışır hale gelmelidir ama
yazılımın görevi ürünü oluşturmanın ötesindedir.
Sadece ürün odaklı geliştirilmiş birçok yanlış kodlama
gördüm. Yanlışın oluşma sebebi ise sadece ürünün
oluşmasına odaklanmaktan kaynaklanmaktadır. Eğer siz ürün
çalışsın da içerisi nasıl çalışırsa çalışsın derseniz karşınıza bir
yığın Spagetti Kod çıkar. Bu yüzden projedeki yazılımcılar
ürünü oluşturmanın yanında OKUNABİLİRLİK, TAŞINABİLİRLİK,
ESNEKLİK gibi hedefleri de yerine getirmelidir. Sadece
kendilerinin anlayacağı yada 3 ay sonra kimsenin birşey
hatırlamayacağı kod yazmak hem kişiye hem de firmaya
oldukça zarar verir.

İster kendimiz için proje yapalım ister firma için proje yapalım
bu özellikleri her zaman hedeflememiz gerekir. Bir yazılımcı,
bir yazılımcı hakkında fikir beyan ederken aslında ürün çalıştı
diye o yazılımcıyı met etmez. Hatta cihazın çalışıp
çalışmaması pek konu olan bir durum değildir. Yazılım
prensipleri, yazılım kalıpları, okunabilirlik, taşınabilirlik,
esneklik gibi konular hakkında yorum yapar.

8.7.3 Yazdığımız kodlar sadece projeye mi ait

olmalı?

Bizler kodlama yaparken sadece içinde bulunduğumuz projeye

ait kodlar yazmayız. Hatta kodlama zorluğunu oluşturan bir
durum da kodun başka projelerde de kullanıma elverişli
olması amacından kaynaklanır. Diğer projelerde de kullanıma
elverişli kod yazmak sonraki projeler için zaman kazanılmasını
sağlar. Ayrıca yazılımcının sürekli aynı konular üzerinde kod
yazması onun için sıkıcı olacaktır.

İleriye yönelik kodlama yapmanın belli bir sınırı vardır. Projeyi

tamamen bir kenara koyup kocaman bir kütüphane yazmaya
kalkışmak yanlıştır. İş gücünü ve zamanı iyi kullanarak belli
oranda ileriye yönelik geliştirme yapılabilir. Zaten bu tür kodlar
tek seferde son haline ulaşmaz ve ulaşması da
beklenmemelidir. Bir sonraki projede de ilgili kodlara biraz
daha katkıda bulunulur ve bu şekilde kod birimi tamamlanır.
Unutmayın ilk seferde en iyi kodu yazmak, en iyi projeyi
oluşturmak, en iyi mimariyi kurmak gibi bir durum yoktur.
Mükemmeli ararken gerçeği kaybedebilirsiniz.

Kodlama kalitenizi her ne kadar kod yazarak ve okuyarak

geliştirebilseniz de yazdığınız kodları başkasına kontrol
ettirme (Code Review) ve beraber kodlama (Pair
Coding) yapmak kod kalitesini arttırma konusunda hem hızlı
sonuç veren hem de oldukça etkili yöntemlerdir. Kod kalitesini
arttıracak bir diğer yöntem ise Static Test araçları
kullanmaktır. Bu araçlar hem yazım hatalarını hemde belli bir
seviyede mantık hatalarını yakalar. Örneğin adres atanmadan
kullanılan bir pointer static test araçları ile yakalanır.

Özetle kodlama kalitesinin artması için ne kadar kitap okusak

ne kadar araştırma yapsak da proje yapmadan, kod yazmadan
istenilen sonuçlar alınamaz.

8.8. Birim Testi

Birim test(unit test) kodlama kalitemizi ölçmek ve hataları

görmek için vazgeçilmez bir yöntemdir. Proje testi öncesinde
eğer birim test uygulanmaz ise birçok gizli hata/bug
kodumuzun içinde kalacaktır. Çünkü birim testler yazılımcı
tarafından yazılan test kodları ile yapılır iç tarafta neler
olabileceği koşulları en detaylı haliyle test edilmiş olur.

Her ne kadar zaman yada kaynak sıkıntısı olsa da belli bir

derinlikte birim testi yapılmalıdır. Örneğin bir projemizdeki
Record Manager birimini ele alalım. Bu birim başka
birimlerden gelen verileri kaydetmek için kullanılacak. Dolayısı
ile başlık dosyasında yaptığı işleri anlatan fonksiyonları
olacaktır. Bu global fonksiyonları diğer birimler tereddüt
etmeden güvenerek kullanabilmelidir. Eğer Record Manager
global fonksiyonları için birim test yapılmadıysa bu
fonksiyonları kullanan birimler için tehlike oluşmuş olur. Birim
testler en azından global fonksiyonlar için yapılmalıdır.
9. Test ve Hataların Düzeltilmesi

Birim testi uygulayarak kodlama sonrasına sıra projemizi test

etmeye gelir. Proje testleri test ekibi tarafından yapılsa da
bizler kişisel projelerimizde bu testleri de yapmak zorundayız.
Çünkü tüm çalışmaların kalitesini bu aşamada net olarak
görürüz. Örneğin bizim projemizde ses iletiminde
planlanandan fazla gecikme var ise ya mimari ya da kodlama
yanlış olabilir.

Testler sonrasında görülen hatalar kodlamada nerelerde eksik

olduğumuzu yada planlamada nerenin yanlış olduğunu bize
bildirir. Başarılı test sonucu edindiğimiz tecrübeleri
onaylamamızı sağlar. Ayrıca test edilmiş ve onaylanmış
bilgileri bir sonraki projede gönül rahatlığı ile kullanabiliriz.

10. Proje Sunum Belgesi

Projemizi tamamladıktan sonra onları mümkün ise paylaşmak

bizlere fayda sağlar. Yapılan geri bildirimlerden birçok şey
öğrenebilriz. Daha profesyonel kişilerin bilgisine ve bakış
açısına ulaşma şansı yakalarız.

Projenin sunulması başka kişilerin sizi fark etmesine ve ekip

oluşturmanıza da katkı sağlar. Sizinle aynı motivasyondaki
kişiler ile tanışmanıza fırsat oluşturur. Başka projelere dahil
olma tekliflerini alma şansınız oluşur. Ayrıca projeniz ne
seviyede olursa olsun projenizi paylaşarak alacağınız beğeni
ve tebrikler ile kendi motivasyonunuzu da artırırsınız.

11. Son

Gömülü yazılım alanında kendini geliştirmek isteyenler proje

yapmanın gelişime olan etkisini yukarıdaki başlıklarda
görecektir. Proje yapmak projenin doğası gereği birçok alanda
sizlerin bilgi edinmesini sağlayacaktır. Gömülü yazılım sadece
kodlamadan ibaret olmadığı, hangi alanlarda bilgi edinilmesi
gerektiği sıralanmıştır. Yazılım kalıplarından donanıma kadar
birçok alanda bilgi sahibi olmamız gerekmektedir.

Proje yapılırken yada bir şeyler öğrenirken sabırlı olmak

gerekir. Öğrenme zaman içerisinde planlı çalışma ile sağlanır.
Ne bir haftada ne de bir ayda öğrenilecekler bitmez. Zaman
bırakın ve motivasyonunuzu yüksek tutun.

Zafer Satılmış - 15.02.2021