Gömülü Yazılım ve Tasarım Kalıpları

[volkanunal]

Merhabalar, şu şekilde bir kitap mevcut.

Design Patterns for Embedded Systems in C isminde, sizlere sormak istediğim şu. Kendi yazılım projelerinizde tasarım kalıplarını ne kadar kullanıyorsunuz ? bu konuda görüşlerinizi merak ediyorum.

Görüşlerini belirten tüm arkadaşlar için çok teşekkür ederim, kolay gelsin.

[muhittin_kaplan]

Sırf cleancode ve Design patern için kitaplar aldım, okudum uyguladım. Ama nedense bende davranış değişikliği oluşturmadı.Olmuyor, alışılmış yerden yürüyorsunuz

[tunayk]

Yazdığınız yazılım sizde başlayıp siz de bitiyor ise, buna çok takılmaya gerek yoktur. Uygularsanız faydanıza olur elbetteki. Ama bu kalıpları uygulamadan yazılmış yazılım kötüdür anlamına da gelmez.

Bir yazılımcı olarak bir ekibin parçasıysanız işte o zaman işler değişir.  O ekibin ortak hareketi için belli başlı kalıplar üzerinde mütabık olmaları şarttır.

[mylord92]

Biz iş yerinde mecburen kullanıyoruz. Clean codedan ziyade tekrar kullanılabilir olması önemli. 5-6 noktada argemiz var ve kodları olabildiğince ortak kullanmaya çalışıyoruz. Kendi yazmış olduğumuz bir framework mevcut. O framework üzerinde diğer argeler cihazlarına uygun yazılımları geliştiriyorlar. Framework'e ait devicelar, middlewarelar haliyle ortak ve cihaz spesifik olmaktan uzak olmalı.

Bunun ne gibi bir artısı var;
- Bir argenin yazdığı bir device(devicetan kastımız misal bir linear interpolasyon algoritması olabilir, timeout algoritması olabilir vs.) veya middleware veya mcu spesifik driverlar başka bir argede ihtiyaç duyulduğunda tekrar yazılmasına gerek kalmıyor. İş gücü kazancı.
- Framework belli olduğundan hangi algoritma nereye ne şekilde bağlanmalı hızlıca anlayabiliyorsunuz.
- Okunabilirlik ve dökümante edilebilirlik artıyor. Arge süresini azalttığı için aslında yazdığınız aplikasyonu dökümante edecek zamanı buluyorsunuz.

Mutluluk kaynağı adeta

İş harici kendi uğraştığım şeylerde ne sıklıkla kullanıyorum diye sorarsan sanırım hiç yada çok az. Geri dönüp baktığımda geçmişten bu yana kullandığım ortak kodlar neredeyse yok.

[PhD]

GitHup ve benzeri programlar tamda bu iş için ancak keşke uygulayabilsem..

[Erol YILMAZ]

Bircok yazilim yaptiktan sonra artik bu yazilimlari takip edemeyecegimi farkettim.
Sonucta biz bu konularda yeniyiz. Compiler in yazildigi ulkede bu isler nasil donuyor diye arastirmaya basladiktan sonra,
"Design pattern" konusuyla tanistim.
Ve hemen o andan itibaren yazilimlarimdaki iyi yonleri bir sablon haline getirmeye basladim. Eksik olan yerleri de zamanla topladik. 12 senedir bunu kullaniyoruz.
Ve en ciddi avantaji olarak, hata yapmamizi buyuk oranda engelliyor.

[z]

Cocuklar muhakkak lehim yapmayi ogrenebilirler fakat dikkatsizlik sonucu yangin cikartabilirler, kendilerini yakabilirler.

Lisedeyken havya ile kolumu yaktim. Masadaki elimi yumruk yapip cenemin altina koyarken pazu ve kol birbirine yaklasiyor ya iste tam o araya havyanin isinan kismi denk geldi ve kolumla havyayi o araya sikistirdim.

Aptalca bir kaza.

[tunayk]

Cocuklar muhakkak lehim yapmayi ogrenebilirler fakat dikkatsizlik sonucu yangin cikartabilirler, kendilerini yakabilirler.

Lisedeyken havya ile kolumu yaktim. Masadaki elimi yumruk yapip cenemin altina koyarken pazu ve kol birbirine yaklasiyor ya iste tam o araya havyanin isinan kismi denk geldi ve kolumla havyayi o araya sikistirdim.

Aptalca bir kaza.

Sanki yanlış konuya gelmiş bu mesaj 

[brandice5]

Ben de bisiklet surerken pesime kopek takilmisti. Kopekten kacmak icin daha hizli sureyim derken cakil yolda bisiklet kaydi ve dustum. Dustugumu goren kopek kosarak uzaklasti.

Bu da boyle bir animdir.

Tasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.

[kantirici]

Gömülü sistem mühendisi unvanı ve aramaları gittikçe azalıyor, yerini gömülü yazılım mühendisi unvanı ve unvanın beklentileri alıyor. Bu noktada biz elektronik kökenli yazılımcılar olarak en büyük eksiğimiz algoritmalar, bilgisayar organizasyonu, veri yapıları, tasarım desenleri ve prensipleri gibi konular karşımıza çıkıyor.

Bence tasarım kalıpları ve prensipleri oldukça önemli. Ne kadar bilinirse o kadar iyi tabi uygulamak ve benimsemek önemli.

C dilinde nesne yönemli programlama yapılabilmekte ve tasarım desenleri uygulanabilmekte.

32 bit mcu'ların yaygınlaşması ve donanım kaynaklarının artmasıyla çoğu gömülü sistemlerde artık "trick"'li yazılım, elle yapılan optimizasyonlara v.b ihtiyaç azalıp bunların yerini anlaşılır ve esnek yazılım aldı. HAL altyapılarının hazır sunulmasıyla da programlarda "business logic" katmanı tamamen bağımsız bir şekilde geliştirilebiliyor.

Konu özelinde TDD(Test Driven Dev.) konusu da yazılımı belirli kriterlere göre yazmayı gerektiriyor.

Kullanıcı elektroniğinin git gide cep telefonlarından kumanda edilmesi, internete çıkmaları gibi konularda gömülü sistemleri giderek karmaşıklaştırıyor. Bu noktada ise açık kaynak alt yapısı, pek çok platformu destekleyen kütüphane ve framworkler kaşımıza çıkıyor. Bu kaynaklar ise yukarıdaki yazılım kriterlerine göre yazılmış oluyorlar. Yani git gide gömülü sistem/yazımlar klasik yazılım Dünyası ile iç içe geçiyor. Bu geçiş ise bizlere o Dünyayı keşfetmeyi oranın raconuna uymayı gerektiriyor.

Son olarak gömülü sistemlerde (mcu tabanlı) c++ yaygınlaşıyor, rust da C'ye alternatif olarak öenmli bir oyuncu gibi.

Biraz uzun oldu ama konular birbirlerine bağlı olduğundan görüşlerimi paylaşmak istedim.

[volkanunal]

Biz iş yerinde mecburen kullanıyoruz. Clean codedan ziyade tekrar kullanılabilir olması önemli. 5-6 noktada argemiz var ve kodları olabildiğince ortak kullanmaya çalışıyoruz. Kendi yazmış olduğumuz bir framework mevcut. O framework üzerinde diğer argeler cihazlarına uygun yazılımları geliştiriyorlar. Framework'e ait devicelar, middlewarelar haliyle ortak ve cihaz spesifik olmaktan uzak olmalı.

Bunun ne gibi bir artısı var;
- Bir argenin yazdığı bir device(devicetan kastımız misal bir linear interpolasyon algoritması olabilir, timeout algoritması olabilir vs.) veya middleware veya mcu spesifik driverlar başka bir argede ihtiyaç duyulduğunda tekrar yazılmasına gerek kalmıyor. İş gücü kazancı.
- Framework belli olduğundan hangi algoritma nereye ne şekilde bağlanmalı hızlıca anlayabiliyorsunuz.
- Okunabilirlik ve dökümante edilebilirlik artıyor. Arge süresini azalttığı için aslında yazdığınız aplikasyonu dökümante edecek zamanı buluyorsunuz.

Mutluluk kaynağı adeta

İş harici kendi uğraştığım şeylerde ne sıklıkla kullanıyorum diye sorarsan sanırım hiç yada çok az. Geri dönüp baktığımda geçmişten bu yana kullandığım ortak kodlar neredeyse yok.

Örnek vermeniz mümkünse nasıl bir senaryoda hangi tasarım kalıbına nasıl bir ihtiyaç oluştu hocam, örnek vermeniz mümkün müdür ?

[volkanunal]

Ben de bisiklet surerken pesime kopek takilmisti. Kopekten kacmak icin daha hizli sureyim derken cakil yolda bisiklet kaydi ve dustum. Dustugumu goren kopek kosarak uzaklasti.

Bu da boyle bir animdir.

Tasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.

Bu görüşünüze katılmıyorum hocam, bu konu için yukarda bahsettiğim kitabi incelemenizi tavsiye ederim.

[brandice5]

@kantirici ya cevaben, benim zaten C de OOP yapilamaz gibi bir iddiam yok, zamaninda benimde kullanmisligim var AMA ingilizce tabiriyle "feasible" degil.

@volkanunal a cevaben, kitabi inceledim ve bunun verimli olmadigi gorusumde hakli oldugumu gordum.
cunku C de DP uygulamak icin hem DP hem de OOP implementasyonuyla ugrasmaniz gerek, yani iki kat is yuku ve iki kat hata orani.

adam sadece bir object yaratmak icin malloc ile bellek ayirip ustune birde init fonksiyonu cagiriyor. polymorphism icin switch kullanmis. subclassing ve virtual function implementasyonuna hic girmiyorum bile, tamamen copluk.

calistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.

[AsHeS]

@kantirici ya cevaben, benim zaten C de OOP yapilamaz gibi bir iddiam yok, zamaninda benimde kullanmisligim var AMA ingilizce tabiriyle "feasible" degil.

@volkanunal a cevaben, kitabi inceledim ve bunun verimli olmadigi gorusumde hakli oldugumu gordum.
cunku C de DP uygulamak icin hem DP hem de OOP implementasyonuyla ugrasmaniz gerek, yani iki kat is yuku ve iki kat hata orani.

adam sadece bir object yaratmak icin malloc ile bellek ayirip ustune birde init fonksiyonu cagiriyor. polymorphism icin switch kullanmis. subclassing ve virtual function implementasyonuna hic girmiyorum bile, tamamen copluk.

calistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.

Design paternlerinden kastiniz Gang of Four kitabinda ki ise tumunu zaten uygulayamiyorsunuz. Ekseri olarak bir yazilimci en fazla 5 tanesinde uzmanlasiyor kariyer hayatinda. Diger yandan, is mimari kurup yazilim yapinizi oturtmak ise zorunlulugunuz, bu paternlerle kisitli kalmayin. En guzel ornegi Linux Kernel (tamamiyle C) kaynak kodudur. Mimarisi gavur dilinde "state-of-art" yani sanat eseridir. Binlerce farkli sisteme, cipe, yaklasima hizmet vermektedir.

Dizayn paternleri kitabi da zaten en cok kullanilan 20'den fazla paterni ortaya koymaktadir. Ustunu sizde tasarlayip kullanabilirsiniz.

Simdi gelelim C++ embedded ici uygunluguna bu konuda cok cevap duyarsiniz. Olur, olmaz, deneriz, yer yarilsa olmaz, guzel olur vs... Dananin kuyrugunun koptugu yer eger dolu dolu object-oriented yazacaksaniz dinamik hafizaya ihtiyaciniz var. Bunu yapmak icinde evvela hafizaya daha sonra ise islem gucune ihtiyaciniz var.
Ornek vermek gerekirse 8kb ROM lu 256 byte RAM li bir PIC16 da bu islemi yapmak ne kadar makul dusunulur. Arduino ile genelde karsi ornek uretilir bu duruma lakin Arduino ile ne kadar zaman hassasiyeti saglayabilirsiniz ne kadar karmasik bir sistem uretebilirsiniz her zaman soru isaretidir. Gelelim en karmasik cevaplarin yerildigi yere yeni nesil Cortex M serilerine. RAM i ROM u nispeten buyuk dinamik hafiza kullanabileceginiz islem gucu nispi oranda yuksek atlara . Acikcasi dinamik hafiza kullanmak, yonetmek her zaman ek bir sorumluluktur. Yaziliminizin karmasikligina gore profilleme (profiling) denilen sistem seviyesinde kim ne yapiyor diye izlemeniz (tracing) gerekiyordur. Bu tarz durumlarin yol actigi hatalari yakalamak her zaman lineer olmayan bir akista zordur. Burada yol catallanir aslinda 1. yontem goz yordamiyla inceleyip bulabilirsiniz. 2. yontem para dokersiniz ek araclara ornegin; statik kod analizi, dinamik kod analizi gibi araclara. Bunlarin iyisi gercekten iyi paraya satilir. Open-source olanlari nispeten ufak bir kodda dertlerinizi yasamadan ortaya cikarir ama biraz isler karisinca onlarinda gozunden kaciverir.

@kantirici bahsettigi TDD metodu her zaman zorlu bir metoddur. Dizayninizi yaparken once testlerini hazirlayip ciktilarinizi kesin olarak belirleyip tasarima gecmenizi "force" eder. Insan kaynaginin coklugu/azligina gore uygulanabilir.

Sonuc olarak; C her zaman pseudo-assembly dir . Iyi bir mimari ile cok sorununuza care bulunabilinir. En buyuk ornegi icin Linux Source Code a bakabilirsiniz. 

[LukeSkywalker]

Her zaman driver yazan birilerine ihtiyaç olacak. Firmaların hal kütüphanelerini öğrenip bunlar üzerinde yüksek seviye proje geliştirmek, işlemcileri register seviyesinde kodlamaya göre nispeten kolaydır ve insanoğlu kolaylığa çabuk alışır. Özellikle 32 bit mcularda geliştirilen katmanlarla kod yazarken işlemciden bağımsız kod yazmak aşırı alışkanlık yapıcı. Bu kötü birşey değil aslında fakat elektronikçiler yine de işlemcilerin datasheetleriyle haşır neşir olmayı bırakmamalı. En azından yeni çıkan mcuların dökümanlarına göz gezdirmeli arada sırada. Gün gelir lazım olur. ELAN isimli mcu çok cazip mesela fiyatıyla.