20 yıldan fazla gömülü sistemim var, çoğunlukla 8 ve 16 mikro. Sorunuzun kısa cevabı diğer yazılım geliştirmeleriyle aynıdır - ihtiyacınız olduğunu bilinceye kadar optimizasyon yapmayın ve neyi optimize etmeniz gerektiğini bilinceye kadar optimizasyon yapmayın. Önce güvenilir, okunabilir ve bakımı kolay olacak şekilde kod yazın. Erken optimizasyon, gömülü sistemlerde daha fazla olmasa da bir sorundur
"Kaynak israf etmeden" programladığınızda zamanınızı bir kaynak olarak mı değerlendiriyorsunuz? Değilse, zamanınız için size kim ödeme yapıyor ve kimse yoksa, bununla daha iyi bir şeyleriniz var mı? Seçim bir kez herhangi bir gömülü sistem tasarımcısı yapmak zorunda donanım maliyeti vs mühendislik zaman maliyeti. 100 birim gönderiyorsanız, 100.000 birimde daha büyük bir mikro kullanın, birim başına 1,00 ABD doları tasarruf, 1 milyon yıllık yazılım geliştirme (piyasaya çıkış süresini, fırsat maliyetini vb. Göz ardı ederek) ile aynıdır, 1 Milyon birimde, kaynak kullanımı konusunda takıntılı olduğu için yatırım getirisi elde etmek, ancak dikkatli olun çünkü birçok gömülü proje 1 milyon puan vermedi çünkü 1 milyon (düşük üretim maliyetiyle yüksek ilk yatırım) satmak için tasarlandı ve oraya varmadan büstü gitti.
Bununla birlikte, (küçük) gömülü sistemlerle ilgili düşünmeniz ve farkında olmanız gereken şeyler, çünkü bunlar onu yavaşlatmakla kalmayıp, beklenmedik şekillerde çalışmasını durduracaktır.
a) Yığın - genellikle sadece küçük bir yığın boyutuna ve genellikle sınırlı yığın çerçeve boyutlarına sahipsiniz. Yığın kullanımınızın her zaman ne olduğunun farkında olmalısınız. Dikkat edin, yığın sorunları en sinsi kusurların bazılarına neden olur.
b) Yığın - yine, küçük yığın boyutları bu yüzden haksız bellek ayırma konusunda dikkatli olun. Parçalanma bir sorun haline gelir. Bu iki ile, bittiğinde ne yaptığınızı bilmeniz gerekir - OS tarafından sağlanan disk belleği nedeniyle büyük bir sistemde olmaz. yani malloc NULL döndürdüğünde, onu ve ne yaptığınızı kontrol edersiniz. Her ebegümeci bir kontrol ve işleyici, kod şişkinlik gerekir ?. Bir rehber olarak - bir alternatif varsa kullanmayın. Çoğu küçük sistem bu nedenlerden dolayı dinamik bellek kullanmaz.
c) Donanım kesintileri - Bunların güvenli ve zamanında nasıl ele alınacağını bilmeniz gerekir. Ayrıca güvenli yeniden giriş kodunun nasıl oluşturulacağını da bilmeniz gerekir. Örneğin, C standart kütleleri genellikle yeniden giriş yapmazlar, bu nedenle kesme işleyicileri içinde kullanılmamalıdır.
d) Montaj - neredeyse her zaman erken optimizasyon. C'nin yapamayacağı bir şeyi başarmak için en az küçük bir miktar (satır içi) gereklidir. Bir egzersiz olarak, el yapımı montajda küçük bir yöntem yazın (sıfırdan). Aynı işlemi C'de yapın. Performansı ölçün. Bahse girerim C daha hızlı olur, daha okunabilir, bakımı ve genişletilebilir olacağını biliyorum. Şimdi egzersizin 2. bölümü için - montaj ve C'de yararlı bir program yazın
.
Bunu nasıl yapacağınızı bilmeye değer, hatta bir veya iki ortak mikron için dillerde yetkin olmaya değer olabilir.
e) "imzasız int değişken_adı kaydet", "register" her zaman 70'lerin başında (40 yıl önce) derleyici için bir talimat değil, bir ipucu olmuştur. 2012'de, derleyiciler çok akıllı olduğu ve tuş takımlarının çok karmaşık olduğu için tuş vuruşları israfı.
Linux yorumunuza geri dönün - burada yaşadığınız sorun, sadece 1 milyon üniteden bahsetmiyoruz, 100 milyondan bahsediyoruz, sonsuza kadar yaşam süresiyle. İnsanca mümkün olduğunca optimum hale getirmenin mühendislik süresi ve maliyeti, buna değer. Her ne kadar en iyi mühendislik uygulamasına iyi bir örnek olsa da, çoğu gömülü sistem geliştiricisinin linux çekirdeğinin gerektirdiği kadar bilgiç olmaları ticari bir intihar olacaktır.