1. Amaç    3

2. Öğrenme    3

2.1. Edilgen Öğrenme    3

2.1. Etkin Öğrenme    3

2.1. Öğrenmenin Maliyeti    4

3. Temel Bilgi ve Tecrübeler    4

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

5. Proje Seçimi    7

6. Proje Analizi    12

6.1. Proje Analizinde Gerçekçilik    14

6.2. Proje Analizi Sonrası Projenin Yapılabilirlik Kararı    14

6.3. Proje Gereksinimlerinin Belirlenmesi    15

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

7.1. Donanım Gereksinimlerinin Belirlenmesi    17

7.2. Donanım Birimlerinin Belirlenmesi    18

7.3. Belgeleme    19

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

8.1. Yazılım Gereksinimlerinin Belirlenmesi    19

8.2. Yazılımı Birimlerinin Belirlenmesi    21

8.3. Yazılım Dili Seçimi    23

8.4. Kütüphanelerin Belirlenmesi    23

8.5. Yazılım Mimarisini Belirleme    24

8.6. Belgeleme    25

8.7. Kodlama    26

8.7.1 Peki ön çalışmaya uygun olarak kodlarken bir yazılımcılar ne kadar özgürüz?    26

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

8.7.3 Yazdığımız kodlar sadece projeye mi ait olmalı?    27

8.8. Birim Testi    28

9. Test ve Hataların Düzeltilmesi    28

10. Proje Sunum Belgesi    28

11. Son    29

Bu belgenin pdf halinu buradan indirebilirsiniz.

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.

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/ 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.aselsan.com.tr/tr/cozumlerimiz/askeri-haberlesme-sistemleri/ic-konusma-sistemiic-haberlesme-sistemi-birimleri/6680-ic-konusma-sistemi-urunleri

https://tacticalintercom.com/vehicle-ics

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/ 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

https://www.analog.com/en/analog-dialogue/articles/class-d-audio-amplifiers.html#

https://www.soundonsound.com/techniques/what-class-d-amplification

  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)
  6. lwIP kütüphanesini kullanmak,
  7. Ethernet donanımının ayağa kaldırılmasını seçilen işlemci için öğrenmek,
  8. 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,
  16. Ses sıkıştırma yöntemlerini öğrenmek,
  17. Ses sıkıştırma kütüphanesi bulup kullanmak,
  18. Paralel LCD sürmek (480×270),
  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
  26. Harici bellek (Hyperflash yada QSPI Flash) kullanmak,
  27. IMX RT1050 Canbus kullanmak,
  28. 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
  36. Canbus üzerinden cihaza özgü komutların işlenmesi
  37. Yazılım birimlerini oluşturup kodlama planı yapmak,
  38. 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.
  6. 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. 
  8. 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.
  16. Cihaz PC bağlantısı ile konfigürasyon dosyası yüklenecektir. 
  17. Ses iletiminde VoIP kullanılmalıdır
  18. 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.
  6. 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.
  8. 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.
  16. Board üzerinde 2 adet debug ledi olmalıdır. 
  17. Cihazın mikro ve kilitlemeli SD kart bağlantısı olmalıdır.
  18. 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.

Link 1
Link 2

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.
  6. 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.
  8. 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. 
  16. Ses transferi şifresiz olarak yapılacaktır.
  17. Ses iletimi gecikmesiz ve gürültü filtreleme kullanılarak yapılacaktır.
  18. 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ı” 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) 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 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 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. Zamana bırakın ve motivasyonunuzu yüksek tutun.

Zafer Satılmış – 15.02.2021


Reklam