Gömülü geliştirme için C ++ yerine C kullanmak için herhangi bir neden var mı?

Soru

C ++ ve C89 donanımımda iki derleyicim var

Sınıflarla ancak polimorfizm olmadan (vtables'dan kaçınmak için) C ++ kullanmayı düşünüyorum. C ++ kullanmak istememin ana nedenleri:

• Makro tanımları yerine "satır içi" işlevleri kullanmayı tercih ederim.
• Önekler kodu karıştırdığından ad alanlarını kullanmak istiyorum.
• C ++ 'ın temel olarak şablonlar ve ayrıntılı döküm nedeniyle biraz daha güvenli olduğunu görüyorum.
• Aşırı yüklenmiş fonksiyonları ve yapıcıları gerçekten seviyorum (otomatik döküm için kullanılır).

Çok sınırlı donanım (4kb RAM) için geliştirirken C89'a bağlı kalmak için herhangi bir neden görüyor musunuz?

Sonuç

Cevaplarınız için teşekkür ederim, gerçekten yardımcı oldular!

Konuyu iyice düşündüm ve esas olarak C'ye bağlı kalacağım çünkü:

1. C'de gerçek kodu tahmin etmek daha kolaydır ve eğer sadece 4kb ramınız varsa bu gerçekten önemlidir.
2. Ekibim çoğunlukla C geliştiricilerinden oluşuyor, bu nedenle gelişmiş C ++ özellikleri sıklıkla kullanılmayacak.
3. C derleyicimde (C89) satır içi işlevler bulmanın bir yolunu buldum.

Bu kadar çok iyi cevap verdiğiniz için bir cevabı kabul etmek zor. Ne yazık ki bir wiki yaratıp kabul edemiyorum, bu yüzden beni en çok düşündüren bir cevap seçeceğim.

C ++ üzerinde C kullanmanın iki nedeni:

1. Çok sayıda gömülü işlemci için ya C ++ derleyicisi yoktur ya da bunun için fazladan ödeme yapmanız gerekir.
2. Benim deneyimim, gömülü yazılım mühendislerinin önemli bir kısmının C ++ konusunda çok az deneyimi olduğu veya hiç olmadığı yönündedir - ya (1) nedeniyle ya da elektronik mühendisliği derecelerinde öğretilmeme eğilimindedir - ve bu nedenle bağlı kalmak daha iyi olacaktır. ne biliyorlar.

Ayrıca, orijinal soru ve birkaç yorum, 4 Kb RAM'den bahsediyor . Tipik bir gömülü işlemci için, kod depolandığı ve flash'tan çalıştırıldığı için RAM miktarı (çoğunlukla) kod boyutuyla ilgisizdir.

Kuşkusuz, kod depolama alanı miktarı akılda tutulması gereken bir konudur, ancak piyasada yeni, daha yetenekli işlemciler göründükçe, maliyete duyarlı projeler dışında hepsi için eskisinden daha az sorun olur.

Gömülü sistemlerle kullanım için bir C ++ alt kümesinin kullanımı hakkında: artık bir MISRA C ++ standardı var ve bu da bir göz atmaya değer olabilir.

DÜZENLEME: Gömülü sistemler için C ile C ++ arasında bir tartışmaya yol açan bu soruya da bakın .

Bir İçin Çok böyle RAM 4KB'den olarak kaynak kısıtlı hedefi, ben saf ANSI C uygulamasının içine kolayca taşınmış geri olamaz çaba taahhütte bulunmadan önce bazı örnekleri ile suları test ediyorum.

Gömülü C ++ çalışma grubu, dilin standart bir alt kümesini ve onunla uyumlu standart kitaplığın standart bir alt kümesini önerdi. Maalesef C User's Journal öldüğünde bu çabanın izini kaybettim. Görünüşe göre Wikipedia'da bir makale var ve komite hala var.

Gömülü bir ortamda, bellek ayırma konusunda gerçekten dikkatli olmalısınız. Bu bakımı güçlendirmek için, küresel operator new()olanı ve onun arkadaşlarını, kullanılmadığını bilmeniz için bağlantılı bile olmayan bir şeye tanımlamanız gerekebilir . Yerleştirmenew bir ahırda, evreli ve gecikme garantili tahsis şeması ile birlikte mantıklı kullanıldığında diğer taraftan muhtemel arkadaşın olmaktır.

Satır içi işlevler, ilk etapta gerçek işlevler olmaları gerekecek kadar büyük olmadıkça çok fazla soruna neden olmaz. Elbette makroların değiştirilmesinde de aynı sorun vardı.

Şablonlar da, somutlaştırılmaları yanlış çalışmadıkça bir soruna neden olmayabilir. Kullandığınız herhangi bir şablon için, yalnızca kullanmayı amaçladığınız örneklemelerin gerçekleştiğinden emin olmak için oluşturulan kodunuzu (bağlantı haritası yeterli ipucu içerebilir) denetleyin.

Ortaya çıkabilecek diğer bir sorun, hata ayıklayıcınızla uyumluluktur. Başka türlü kullanılabilen bir donanım hata ayıklayıcısının orijinal kaynak koduyla etkileşim için çok sınırlı desteğe sahip olması alışılmadık bir durum değildir. Derlemede etkili bir şekilde hata ayıklamanız gerekiyorsa, C ++ 'ın ilginç adı karıştırması göreve fazladan karışıklık ekleyebilir.

RTTI, dinamik yayınlar, çoklu kalıtım, ağır polimorfizm ve istisnaların tümü, kullanımları için bir miktar çalışma süresi maliyetiyle birlikte gelir. Kullanıldıklarında tüm programa mal olan bu özelliklerden birkaçı, diğerleri sadece onlara ihtiyaç duyan sınıfların ağırlığını arttırır. Farkı bilin ve en azından üstünkörü bir maliyet / fayda analizi hakkında tam bilgi sahibi olarak gelişmiş özellikleri akıllıca seçin.

Küçük bir gömülü ortamda ya doğrudan gerçek zamanlı bir çekirdeğe bağlanacak ya da doğrudan donanım üzerinde çalışacaksınız. Her iki durumda da, çalışma zamanı başlangıç ​​kodunuzun C ++ 'ya özgü başlangıç ​​işlerini doğru şekilde işlediğinden emin olmanız gerekir. Bu, doğru bağlayıcı seçeneklerini kullandığınızdan emin olmak kadar basit olabilir, ancak sıfırlama giriş noktasında güç kaynağı üzerinde doğrudan kontrole sahip olmak yaygın olduğundan, her şeyi yaptığından emin olmak için bunu denetlemeniz gerekebilir. Örneğin, üzerinde çalıştığım bir ColdFire platformunda, geliştirici araçları C ++ başlatıcılarının bulunduğu ancak yorum yapan bir CRT0.S modülüyle birlikte geldi. Kutudan çıkardığım gibi kullansaydım, kurucuları hiç çalışmayan küresel nesneler beni şaşırtacaktı.

Ayrıca, gömülü bir ortamda, donanım aygıtlarını kullanılmadan önce başlatmak gerekir ve işletim sistemi ve önyükleyici yoksa, bunu yapan kodunuzdur. Global nesneler için kurucuların çağrılmadan önce çalıştırıldığını hatırlamanız gerekecek, bu main()nedenle yerel CRT0.S'nizi (veya eşdeğerini) global kurucuların kendileri çağrılmadan önce donanım başlatmayı yapmak için değiştirmeniz gerekecektir . Açıkçası, tepesi main()çok geç.

Hayır. Sorunlara neden olabilecek C ++ dil özelliklerinden herhangi biri (çalışma zamanı çok biçimliliği, RTTI, vb.), Gömülü geliştirme yapılırken önlenebilir. Gömülü C ++ geliştiricilerinden oluşan bir topluluk var (eski C / C ++ Users 'Journal'da C ++ kullanan yerleşik geliştiricilerin sütunlarını okuduğumu hatırlıyorum) ve seçim bu kadar kötü olsaydı çok sesli olacağını hayal edemiyorum.

C ++ Performansına Teknik Rapor şey bu tür için büyük bir kılavuzdur. Gömülü programlama sorunlarıyla ilgili bir bölümü olduğunu unutmayın!

Ayrıca ++, yanıtlarda Gömülü C ++ 'dan bahsedildiğinde. Standart zevklerime göre% 100 değil, ancak C ++ 'nın hangi bölümlerini bırakabileceğinize karar verirken iyi bir referans kaynağıdır.

Küçük platformlar için programlama yaparken, istisnaları ve RTTI'yi devre dışı bıraktık, sanal kalıtımdan kaçındık ve etrafta yatan sanal işlevlerin sayısına çok dikkat ettik.

Arkadaşınız bağlayıcı harita olsa da: sık sık kontrol edin ve kod kaynaklarını ve statik bellek şişkinliğini çabucak fark edeceksiniz.

Bundan sonra, standart dinamik bellek kullanımıyla ilgili hususlar geçerlidir: Bahsettiğiniz gibi kısıtlı bir ortamda, dinamik ayırmaları hiç kullanmak istemeyebilirsiniz. Bazen küçük dinamik allocs için bellek havuzlarından veya bir bloğu önceden tahsis edip her şeyi daha sonra attığınız "çerçeve tabanlı" ayırmadan kurtulabilirsiniz.

C ++ derleyicisini kullanmanızı, ancak C ++ 'ya özgü özelliklerin kullanımınızı sınırlamanızı öneririm. C ++ 'da C gibi programlayabilirsiniz (C ++ yapılırken C çalışma zamanı dahil edilir, ancak çoğu gömülü uygulamada zaten standart kitaplığı kullanmazsınız).

Devam edebilir ve C ++ sınıflarını vb. Kullanabilirsiniz.

• Sanal işlev kullanımınızı sınırlandırın (söylediğiniz gibi)
• Şablon kullanımınızı sınırlayın
• Gömülü bir platform için, yeni operatörü geçersiz kılmak ve / veya bellek ayırma için yeni yerleşimi kullanmak isteyeceksiniz.

Bir aygıt yazılımı / gömülü sistem mühendisi olarak, size C'nin neden hala C ++ 'ya göre 1 numaralı seçim olduğunu söyleyebilirim ve evet, her ikisinde de akıcıyım.

1) Geliştirdiğimiz bazı hedefler, hem kod hem de veri için 64kB RAM'e sahiptir, bu nedenle her baytın sayıldığından emin olmalısınız ve evet, bana 2 saate mal olan 4 bayt tasarruf etmek için kod optimizasyonu ile uğraştım ve bu 2008.

2) Boyut sınırlaması nedeniyle, her C kütüphanesi işlevi, son koda izin verilmeden önce gözden geçirilir, bu nedenle insanların bölme (donanım bölücü yok, bu nedenle büyük bir kitaplığa ihtiyaç vardır), malloc (çünkü yığın yok , tüm bellek 512 bayt yığınındaki veri arabelleğinden ayrılır ve kod gözden geçirilmelidir) veya büyük ceza gerektiren diğer nesne yönelimli uygulamalar. Unutmayın, kullandığınız her kitaplık işlevi sayılır.

3) Yer paylaşımı terimini hiç duydunuz mu? o kadar az kod alanınız var ki, bazen bir şeyleri başka bir kod setiyle değiştirmek zorunda kalıyorsunuz. Bir kitaplık işlevini çağırırsanız, kitaplık işlevi yerleşik olmalıdır. Bunu yalnızca bir kaplama işlevinde kullanırsanız, çok fazla nesne yönelimli yönteme güvenerek çok fazla alan harcarsınız. Bu nedenle, C ++ 'ın kabul edilmesini, herhangi bir C kütüphanesi işlevini varsaymayın.

4) Sınırlı donanım tasarımı (yani belirli bir şekilde bağlanan bir ECC motoru) nedeniyle veya bir donanım hatasıyla başa çıkmak için döküm ve hatta paketleme (hizalanmamış veri yapısının kelime sınırını geçtiği yerlerde) gereklidir. Açıkça çok fazla şey varsayamazsınız, öyleyse nesne neden onu çok fazla yönlendirsin?

5) En kötü durum senaryosu: Nesne yönelimli yöntemlerden bazılarının ortadan kaldırılması, patlayabilen kaynakları kullanmadan önce geliştirmeyi düşünmeye zorlayacaktır (yani bir veri arabelleğinden ziyade bir yığına 512 bayt ayırmak) ve bu olası en kötü durum senaryosunun bazılarını önleyecektir. tüm kod yolu için test edilmez veya tamamen ortadan kaldırılmaz.

6) Donanımı yazılımdan uzak tutmak ve kodu olabildiğince taşınabilir ve simülasyon dostu hale getirmek için çok fazla soyutlama kullanıyoruz. Donanım erişimi, farklı platformlar arasında koşullu olarak derlenen bir makro veya satır içi işlevle sarılmalıdır, veri türü hedefe özel değil bayt boyutu olarak dönüştürülmelidir, doğrudan işaretçi kullanımına izin verilmez (çünkü bazı platformlar bellek eşlemeli G / Ç'nin veri belleğiyle aynı) vb.

Daha fazlasını düşünebilirim, ama sen anladın. Biz bellenim adamlarının nesneye yönelik eğitimi var, ancak gömülü sistemin görevi donanım odaklı ve düşük seviyeli olabilir, bu yüksek seviye veya doğası gereği soyutlanamaz.

BTW, bulunduğum her ürün yazılımı işi kaynak kontrolünü kullanıyor, bu fikri nereden aldığınızı bilmiyorum.

-SanDisk'ten bir aygıt yazılımı uzmanı.

Kişisel tercihim C çünkü:

• Her kod satırının ne yaptığını (ve maliyetini) biliyorum
• C ++ 'ı her kod satırının ne yaptığını (ve maliyetini) bilecek kadar iyi bilmiyorum

İnsanlar bunu neden söylüyor? Sen yok sen asm çıkışını kontrol sürece C'nin her satırı ne yaptığını biliyorum. Aynısı C ++ için de geçerli.

Örneğin, bu masum ifade ne üretir:

a[i] = b[j] * c[k];

Oldukça masum görünüyor, ancak gcc tabanlı bir derleyici bu asm'yi 8 bitlik bir mikro için üretir

CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP

Üretilen talimatların sayısı büyük ölçüde şunlara bağlıdır:

• A, b ve c boyutları.
• bu işaretçiler yığında mı depolanıyor yoksa genel mi
• i, j ve k yığında mı yoksa global mi

Bu, özellikle işlemcilerin C'yi işleyecek şekilde ayarlanmadığı küçük gömülü dünyada doğrudur. Bu yüzden cevabım, asm çıktısını her zaman incelemediğiniz sürece C ve C ++ 'nın birbirleri kadar kötü olduğu olacaktır, bu durumda bunlar birbirleri kadar iyidir.

Hugo

Bazı insanların daha basit ve dolayısıyla üretilecek gerçek kodu tahmin etmenin daha kolay olması nedeniyle gömülü çalışma için C'yi tercih ettiğini duydum.

Ben şahsen C tarzı C ++ yazmanın (tür güvenliği için şablonlar kullanmak) size birçok avantaj sağlayacağını düşünürdüm ve bunu yapmamak için gerçek bir neden göremiyorum.

C ++ yerine C kullanmak için bir neden göremiyorum. C ile ne yaparsanız yapın, C ++ ile de yapabilirsiniz. VMT'nin ek yüklerinden kaçınmak istiyorsanız, sanal yöntemler ve çok biçimlilik kullanmayın.

Bununla birlikte, C ++ ek yükü olmadan çok kullanışlı bazı deyimler sağlayabilir. Favorilerimden biri RAII. Sınıflar hafıza veya performans açısından pahalı değildir ...

IAR Workbench üzerinde ARM7 gömülü platform için bazı kodlar yazdım. Derleme zamanı optimizasyonu ve yol tahmini yapmak için şablonlara güvenmenizi şiddetle tavsiye ederim. Veba gibi dinamik yayınlardan kaçının. Andrei Alexandrescu'nun Modern C ++ tasarımı kitabında belirtildiği gibi özellikleri / politikaları kendi yararınıza kullanın .

Biliyorum, öğrenmesi zor olabilir ama eminim ki ürününüz bu yaklaşımdan fayda sağlayacaktır.

İyi bir neden ve bazen tek neden, belirli gömülü sistem için hala C ++ derleyicisinin olmamasıdır. Örneğin Microchip PIC mikro denetleyiciler için durum budur. Yazmaları çok kolaydır ve ücretsiz bir C derleyicisine sahiptirler (aslında, C'nin hafif bir varyantı), ancak görünürde C ++ derleyicisi yoktur.

4K ram ile kısıtlanmış bir sistem için, C ++ yerine C kullanırım, sırf olup biten her şeyi görebilmeniz için. C ++ ile olan şey, koda bakmaktan çok daha fazla kaynak (hem CPU hem de bellek) kullanmanın çok kolay olmasıdır. (Oh, bunu yapmak için başka bir BlerfObject oluşturacağım ... hoppala! Bellek yetersiz!)

Bunu daha önce de belirtildiği gibi C ++ ile yapabilirsiniz (RTTI yok, vtables yok, vb.), Ancak C ++ kullanımınızın C'deki eşdeğerini yaptığınız gibi sizden uzaklaşmamasını sağlamak için çok zaman harcayacaksınız. .

İnsan zihni, karmaşıklığı olabildiğince değerlendirerek ve ardından neye odaklanılması gerektiğine karar vererek ve geri kalanını atarak veya değerini düşürerek başa çıkar. Pazarlamada markalaşmanın ve büyük ölçüde simgelerin arkasındaki tüm temel budur.

Bu eğilimle mücadele etmek için C'yi C ++ 'ya tercih ederim, çünkü sizi kodunuz ve donanımla nasıl daha yakından etkileşime girdiğini düşünmeye zorluyor - durmaksızın yakın.

Uzun deneyimlerime dayanarak, C'nin sizi sorunlara daha iyi çözümler bulmaya zorladığına inanıyorum, kısmen yolunuzdan çekilerek ve sizi bir kısıtlamayı tatmin etmek için çok fazla zaman harcamaya zorlamayın. veya "örtülerin altında" neler olduğunu anlamak.

Bu bağlamda, C gibi düşük seviyeli diller, donanıma odaklanmak ve iyi veri yapısı / algoritma paketleri oluşturmak için çok zaman harcarken, yüksek seviyeli diller, orada neler olup bittiğini merak etmek için çok fazla zaman harcamanızı sağlar. ve neden özel bağlamınızda ve ortamınızda tamamen makul bir şey yapamıyorsunuz? Derleyicinizi teslim etmek için yenmek (güçlü yazım en kötü suçtur) zamanın verimli kullanımı DEĞİLDİR.

Muhtemelen programcı kalıbına iyi uyuyorum - kontrolü seviyorum. Benim görüşüme göre, bu bir programcı için bir kişilik kusuru değil. Kontrol, yapmamız için para aldığımız şeydir. Daha spesifik olarak, KUSURSUZ bir şekilde kontrol edin. C size C ++ 'dan çok daha fazla kontrol sağlar.

Kişisel olarak 4kb bellek ile C ++ 'dan o kadar fazla mesafe alamadığınızı söyleyebilirim, bu yüzden iş için en iyi derleyici / çalışma zamanı kombinasyonu gibi görünen birini seçin, çünkü dil muhtemelen çok fazla önemli olmayacak.

Kütüphane de önemli olduğundan, her şeyin dil ile ilgili olmadığını unutmayın. Genellikle C kitaplarının minimum boyutu biraz daha küçüktür, ancak gömülü geliştirmeyi hedefleyen bir C ++ kitaplığının azaltıldığını hayal edebiliyorum, bu yüzden test ettiğinizden emin olun.

C taşınabilirlik konusunda kazanır - çünkü dil spesifikasyonunda daha az belirsizdir; bu nedenle farklı derleyiciler vb. arasında çok daha iyi taşınabilirlik ve esneklik sunar (daha az baş ağrısı).

Bir ihtiyacı karşılamak için C ++ özelliklerinden yararlanmayacaksanız, C ile devam edin.

Çok sınırlı donanım (4kb RAM) için geliştirirken C89'a bağlı kalmak için herhangi bir neden görüyor musunuz?

Kişisel olarak, gömülü uygulamalar söz konusu olduğunda (Gömülü dediğimde, bugün winCE, iPhone vb. Şişirilmiş gömülü cihazları kastetmiyorum). Kaynak sınırlı cihazlar demek istiyorum. C ++ ile de epey çalışmış olsam da C'yi tercih ediyorum.

Örneğin, bahsettiğiniz cihazda 4kb var RAM var, bu nedenle C ++ 'ı dikkate almam. Elbette, C ++ kullanarak küçük bir şey tasarlayabilir ve diğer yayınların önerdiği gibi uygulamanızda kullanımınızı sınırlayabilirsiniz, ancak C ++ potansiyel olarak uygulamanızı kapaklar altında karmaşıklaştırabilir / şişirebilir.

Statik olarak bağlanacak mısınız? C ++ ve c kullanarak statik bir kukla uygulamayı karşılaştırmak isteyebilirsiniz. Bu, bunun yerine C'yi düşünmenize neden olabilir. Öte yandan, bellek gereksinimleriniz dahilinde bir C ++ uygulaması oluşturabiliyorsanız, bunun için gidin.

IMHO, Genel olarak gömülü uygulamalarda olup biten her şeyi bilmek isterim. Bellek / sistem kaynaklarını kim kullanıyor, ne kadar ve neden? Onları ne zaman serbest bırakırlar?

X miktarda kaynak, cpu, bellek vb. Olan bir hedef için geliştirme yaparken, bu kaynakları kullanmanın alt tarafında kalmaya çalışıyorum çünkü gelecekte hangi gereksinimlerin ortaya çıkacağını asla bilemiyorsunuz ve böylece projeye daha fazla kod eklemiş oluyorsunuz. basit ve küçük bir uygulama olması gerekiyordu, ancak çok daha büyük hale geliyor.

Seçimim genellikle, kullanmaya karar verdiğimiz, cihazın ne yapması gerektiğine göre seçilen C kütüphanesi tarafından belirlenir. Yani, 9/10 kere .. uclibc veya newlib ve C olur. Kullandığımız çekirdek de bu konuda büyük bir etkiye sahip veya kendi çekirdeğimizi yazıyorsak.

Aynı zamanda bir ortak zemin seçimi. Çoğu iyi C programcısının C ++ kullanmakta bir sorunu yoktur (birçok kişi onu kullandıklarından şikayet etse de) .. ama ben bunun tersini doğru bulmadım (deneyimlerime göre).

Üzerinde çalıştığımız (temelden çekirdek içeren) bir projede, çoğu şey C'de yapılır, ancak C ++ 'da küçük bir ağ yığını uygulanmıştır, çünkü ağları C ++ kullanarak uygulamak daha kolay ve daha az sorunluydu.

Sonuç olarak, cihaz ya çalışacak ve kabul testlerini geçecek ya da geçmeyecektir. Xx yığınında foo ve z dilini kullanarak yy yığın kısıtlamalarını uygulayabilirseniz, bunun için gidin, sizi daha üretken yapan her şeyi kullanın.

Kişisel tercihim C çünkü:

• Her kod satırının ne yaptığını (ve maliyetini) biliyorum
• C ++ 'ı her kod satırının ne yaptığını (ve maliyetini) bilecek kadar iyi bilmiyorum

Evet, C ++ konusunda rahatım, ancak bunu standart C kadar iyi bilmiyorum.

Şimdi bunun tersini söyleyebiliyorsanız, peki, bildiklerinizi kullanın :) Çalışıyorsa, testleri geçerse vb .. sorun nedir?

Ne kadar ROM / FLASH'ınız var?

4kB RAM, gerçek kodu ve statik verileri depolamak için yüzlerce kilobayt FLASH olduğu anlamına gelebilir. Bu boyuttaki RAM, yalnızca değişkenler içindir ve bunlara dikkat ederseniz, kod satırları açısından oldukça büyük bir programı belleğe sığdırabilirsiniz.

Bununla birlikte, C ++, nesneler için çalışma zamanı oluşturma kuralları nedeniyle FLASH'a kod ve veri koymayı daha zor hale getirme eğilimindedir. C'de, sabit bir yapı FLASH belleğe kolayca yerleştirilebilir ve bir donanım sabit nesnesi olarak erişilebilir. C ++ 'da sabit bir nesne, derleyicinin kurucuyu derleme zamanında değerlendirmesini gerektirir, ki bu hala bir C ++ derleyicisinin yapabileceğinin ötesinde bir şeydir (teorik olarak bunu yapabilirsiniz, ancak pratikte yapmak çok zordur) .

Yani "küçük RAM", "büyük FLASH" türü bir ortamda C ile her gün giderdim. Sınıfa dayalı olmayan kod için güzel C ++ özelliklerinin çoğuna sahip olan iyi bir ara seçim olan C99 olduğunu unutmayın.

Genel olarak hayır. C ++ süper bir C kümesidir. Bu özellikle yeni projeler için geçerli olacaktır.

Cpu süresi ve bellek ayak izi açısından pahalı olabilecek C ++ yapılarından kaçınmak için doğru yoldasınız.

Çok biçimlilik gibi bazı şeylerin çok değerli olabileceğini unutmayın - bunlar aslında işlev işaretçileridir. Onlara ihtiyacınız olduğunu fark ederseniz, akıllıca kullanın.

Ayrıca, iyi (iyi tasarlanmış) istisna yönetimi, yerleşik uygulamanızı geleneksel hata kodlarıyla işleyen bir uygulamadan daha güvenilir hale getirebilir.

Bellek ayırma sorunu için, Quantum Platform'u ve başlatma anında ihtiyacınız olan her şeyi tahsis ettiği için durum makinesi yaklaşımını kullanmanızı tavsiye edebilirim. Ayrıca çekişme sorunlarını hafifletmeye yardımcı olur.

Bu ürün hem C hem de C ++ üzerinde çalışır.

Bazıları, C derleyicilerinin çok daha verimli kod üretebileceğini, çünkü gelişmiş C ++ özelliklerini desteklemeleri gerekmediğini ve bu nedenle optimizasyonlarında daha agresif olabileceğini söylüyor.

Elbette, bu durumda iki özel derleyiciyi test etmek isteyebilirsiniz.

C IMHO'yu tercih etmenin tek nedeni, platformunuz için C ++ derleyicisinin iyi durumda olmamasıdır (hatalı, zayıf optimizasyon, vb.).

Oyun Programcıları için C ++ kitabı, C ++ ' daki özelliklere bağlı olarak kod boyutunun ne zaman artacağına ilişkin bilgilere sahiptir.

C99'da satır içi var. Belki ctor'ları seviyorsunuz, ama dansçıları doğru bulma işi karmaşık olabilir. C'yi kullanmamanın tek nedeni ad alanları ise, gerçekten C89'a bağlı kalırım. Bunun nedeni, onu biraz farklı bir gömülü platforma taşımak isteyebilmenizdir. Daha sonra aynı kod üzerinde C ++ ile yazmaya başlayabilirsiniz. Ancak aşağıdakilere dikkat edin, burada C ++ C'nin bir üst kümesi DEĞİLDİR, biliyorum bir C89 derleyiciniz olduğunu söylediniz, ancak yine de C99 ile bu C ++ karşılaştırması yapıyor, çünkü örneğin ilk öğe K & R'den beri herhangi bir C için doğrudur.

sizeof 'a' > 1, C ++ 'da değil. C'de VLA değişken uzunluklu dizileriniz var. Örnek: func (int i) {int a [i] . C'de VAM değişken dizisi üyeleriniz var. Örnek: struct {int b; int m [];} .

Derleyiciye bağlıdır.

Gömülü derleyicilerin tümü tüm C ++ 'yı uygulamaz ve yapsalar bile, kod şişkinliğini önleme konusunda iyi olmayabilirler (bu, şablonlar için her zaman bir risktir). Birkaç küçük programla test edin, herhangi bir sorunla karşılaşıp karşılaşmadığınızı görün.

Ancak iyi bir derleyici verildiğinde , hayır, C ++ kullanmamak için bir neden yok.

Sadece "SINIRSIZ" kaynaklara sahip bir sistem olmadığını söylemek istiyorum. Bu dünyadaki her şey sınırlıdır ve ASM, C, JAVA veya JavaScript olsun, HER uygulama kaynak kullanımını dikkate almalıdır. "Emin olmak için" birkaç Mbs ayıran aptallar iPhone 7, Pixel ve diğer cihazları son derece çekici kılıyor. 4kb veya 40 Gb'ye sahip olmanız fark etmez.

Ancak başka bir taraftan kaynak israfına karşı çıkmak - bu kaynakları kurtarmak için gereken bir zamandır. C ++ 'ı kullanmak yerine birkaç tik ve birkaç bayt kaydetmek için basit bir şey yazmak için 1 hafta fazladan sürüyorsa, zaten uygulanmış, test edilmiş ve dağıtılmış. Neden uğraşıyorsun? USB hub satın almak gibi. evet kendiniz yapabilirsiniz ama daha iyi olacak mı? daha güvenilir? zamanını sayarsan daha mı ucuz?

Sadece bir yan düşünce - prizinizden gelen güç bile sınırsız değildir. Nereden geldiğini araştırmaya çalışın ve çoğunlukla bir şeyler yakmaktan olduğunu göreceksiniz. Enerji ve malzeme yasası hala geçerlidir: hiçbir malzeme veya enerji görünmez veya kaybolmaz, aksine dönüşür.

Gömülü geliştirme için ISO C ++ 'nın nasıl kullanılacağına dair bir örnek buldum, bu, C ++ veya C'yi her kullandığında karar veren biri için ilginç olabilir.

Bjarne Stroustrup tarafından ana sayfasında sağlandı :

ISO C ++ 'nın ciddi gömülü sistem programlamasında nasıl kullanılabileceğine bir göz atmak için JSF hava aracı C ++ kodlama standartlarına bakın .

Sorunun farklı bir yönüne farklı yanıt gönderimi:

"malloc"

Daha önceki bazı yanıtlar bunun hakkında biraz konuşuyor. Neden bu aramanın var olduğunu düşünüyorsun? Gerçekten küçük bir platform için, malloc kullanılamaz veya kesinlikle isteğe bağlı olma eğilimindedir. Dinamik bellek tahsisini uygulamak, sisteminizin altında bir RTOS'a sahip olduğunuzda anlamlı olma eğilimindedir - ancak o zamana kadar, tamamen tehlikelidir.

Onsuz çok uzağa gidebilirsin. Yerel değişkenler için uygun bir yığını bile olmayan tüm eski FORTRAN programlarını bir düşünün ...

Dünya çapında çok sayıda farklı denetleyici üreticisi vardır ve bunların tasarımlarına ve yapılandırmak için kullanılması gereken talimat setlerine baktığınızda birçok sorunla karşılaşabilirsiniz. Assembly dilinin temel dezavantajı makineye / mimariye bağlı olmasıdır. Bir geliştiriciden, farklı denetleyiciler için kodlama yapmak için orada belirtilen tüm talimatları yürekten istemek gerçekten çok büyük bir şey. C'nin gömülü geliştirmede daha popüler olmasının nedeni budur, çünkü C, algoritmaları ve veri yapılarını donanıma bağlı ayrıntılardan soyutlayacak kadar yüksek seviyededir ve kaynak kodunu çok çeşitli hedef donanım, mimariden bağımsız dilde taşınabilir hale getirir ve kullanımı çok kolaydır. kodu dönüştürün ve koruyun. Ancak C, C ++, Python, Java vb. Gibi bazı üst düzey diller (nesne yönelimli) görüyoruz.

Sınırlamalar ve notlar ile C ++ 'ı öneririm.

1. Pazarlama ve sürdürülebilirlik zamanı. C ++ geliştirme daha kolay ve daha hızlıdır. Bu nedenle, tasarım aşamasındaysanız, C ++ kullanmak için yeterince harika bir denetleyici seçin. (Bu seçimi yapamayacağınız bazı yüksek hacimli pazarların mümkün olduğunca düşük maliyet gerektirdiğini unutmayın.)

2. Hız. C, C ++ 'dan daha hızlı olabilir, ancak bunun hız kazanımının büyük olmadığından emin olun. Böylece C ++ ile gidebilirsiniz. Algoritmalarınızı geliştirin, test edin ve gerektiğinde daha hızlı hale getirin (!). C hızına ulaşmak için darboğazları işaret etmek ve bunları harici "C" şeklinde yeniden yazmak için profil oluşturucuları kullanın . (Hala yavaşsa, bu bölümü ASM'de uygulayın)

3. İkili boyut. C ++ kodları daha büyük, ancak burada ayrıntıları anlatan harika bir yanıt var. Belirli bir C kodunun derlenmiş ikilisinin boyutu, C veya C ++ derleyicisi kullanılarak derlenmiş olsa da aynı olacaktır. "Yürütülebilir dosya boyutu dil ile pek ilgili değil, projenize dahil ettiğiniz kitaplıklarla ilgilidir." C ++ ile gidin ama gelişmiş işlevleri önlemek gibi streams, string, new, virtualfonksiyonlar, vb İnceleme tüm kütüphane işlevi nedeniyle boyut sınırlaması, son kod onları izin vermeden önce (dayanan bu cevap)