mikrodenetleyici programlama vs nesne yönelimli programlama

C ++ ile bazı temel nesne yönelimli programlama yaptım (bir B-Ağacı, Hashing Algoritmaları, Çift Bağlantılı Listeler oluşturma) ve C'de küçük bir proje yaptım (bilimsel bir hesap makinesi yapmak gibi)

Donanım programlama (özellikle mikro kontrolörler için) zihniyet ve programcının sahip olması gereken "düşünme" açısından yazılım / nesne yönelimli programdan ne kadar farklıdır?

Biri çoğu insanımdan diğerinden daha zor kabul edilir mi?

Arka planımla (yukarıda açıklandığı gibi) donanım programlamaya girmek için çok fazla hazırlık yapmam gerekir mi yoksa çok fazla hazırlık yapmadan doğrudan dalabilir miyim?

Çoğu mikrodenetleyici ile uğraşırken nesne yönelimli paradigmayı tamamen terk etmeniz gerekecektir.

Mikrodenetleyiciler genellikle kayıt ve RAM sınırlıdır, yavaş saat hızları vardır ve boru hattı / paralel kod yolu yoktur. Örneğin bir PIC'de Java'yı unutabilirsiniz.

Bir montaj dili zihniyetine girmeli ve prosedürel olarak yazmalısınız.

RAM sınırlamaları genellikle yığın sorunlarına yol açabileceğinden, kodunuzu nispeten düz tutmalı ve yinelemeyi önlemelisiniz.

Verimli olan kesme servisi rutinlerinin nasıl yazılacağını öğrenmelisiniz (genellikle montaj dilinde).

Derleyicinin desteklemediği (veya desteklemediği) bir işlevsellik uygulamak için kodun bazı bölümlerini montaj dilinde el ile yeniden düzenlemeniz gerekebilir.

Çoğu mikrodenetleyicinin kelime boyutunu ve FPU yeteneklerinin eksikliğini dikkate alan matematiksel kod yazmanız gerekir (örn. 8 bitlik mikro = kötülükte 32 bit çarpma yapmak).

Farklı bir dünya. Bana göre, bir bilgisayar bilimi veya profesyonel programlama geçmişine sahip olmak, mikro denetleyicilerle uğraşırken hiçbir bilgiye sahip olmak kadar bir engel olabilir.

Birkaç şey düşünmeniz gerekiyor:

• C'yi dil olarak kullanacaksın
• Hala işlev işaretçileri kullanarak nesne yönlendirme hissi oluşturabilirsiniz, böylece işlevleri vb. Geçersiz kılabilirsiniz. Bu yöntemi geçmişte ve mevcut projelerde kullandım ve çok iyi çalışıyor. Yani OO kısmen orada ama C ++ anlamında değil.

Sınırlı hız ve bellek gibi diğer sınırlamalar da var. Genel bir kural olarak, kaçınıyorum:

• Yığını kullanarak, Malloc olmadan sorunu çözmenin bir yolu varsa, bunu yaparım. Örneğin, arabellekleri önceden konumlandırıyorum ve sadece kullanıyorum.
• Derleyici ayarlarındaki yığın boyutunu kasıtlı olarak yığın boyutu sorunlarıyla karşılaşacak şekilde küçültüyorum, bunu dikkatlice optimize edin.
• Kodun her satırının bir olay tarafından kesintiye uğratılacağını varsayıyorum, bu yüzden evresel olmayan kodlardan kaçınıyorum
• Kesintiler bile iç içe olduğunu varsayalım, bu yüzden bu kodu buna göre yazıyorum
• Gerekli olmadıkça işletim sistemini kullanmaktan kaçınırım. Gömülü projelerin% 70'inin gerçekten bir işletim sistemine ihtiyacı yoktur. Bir işletim sistemi kullanmam gerekirse, yalnızca kaynak kodu olan bir şey kullanırım. (Freertos vb.)
• Bir işletim sistemi kullanıyorsam, neredeyse her zaman soyutlarım, böylece işletim sistemini birkaç saat içinde değiştirebiliyorum.
• Sürücüler vb. İçin sadece satıcı tarafından sağlanan kütüphaneleri kullanacağım, başka seçeneğim olmadığı sürece hiçbir zaman bitleri doğrudan kemanlamam. Bu, kodu okunabilir hale getirir ve hata ayıklamayı geliştirir.
• Döngülere ve diğer şeylere, özellikle ISR'de, yeterince hızlı olduklarından emin olmak için bakıyorum.
• Bazı GPIO'ları her zaman bir şeyler, bağlam değiştirme, ISR çalışma süresi vb.

Liste devam ediyor, yazılım programlama açısından muhtemelen ortalamanın altındayım, daha iyi uygulamalar olduğundan eminim.

İkisini de yapıyorum, işte benim görüşüm.

Bence en önemli yetenek, hata ayıklama yeteneğinizdir. Gerekli zihniyet çok daha farklıdır, çünkü çok daha fazlası yanlış gidebilir ve yapmaya çalıştığınız tüm farklı yolları yanlış gidebileceğini düşünmeye çok açık olmalısınız.

Bu, yeni yerleşik geliştiriciler için en büyük sorun. PC halkı, daha çok onlar için çalışmaya alıştıklarından, daha kaba olma eğilimindedir. Onlar yerine bir şeyler yapmak için araçlar aramak için çok zaman harcayacaklardır (ipucu: çok fazla yok). Başka ne yapacağını bilmeden, duvarlara defalarca çarpan kafalar var. Sıkıştığınızı düşünüyorsanız, geri adım atın ve neyin yanlış gittiğini tespit edip edemeyeceğinizi öğrenin. Siz çözene kadar sistematik olarak potansiyel sorunlar listenizi daraltın. Doğrudan bu süreçten sonra, bir kerede çok fazla değişmeyerek sorunların kapsamını sınırlamanız gerekir.

Deneyimli yerleşik insanlar hata ayıklamak için hata ayıklama eğilimindedir ... iyi yapamayan insanların çoğu uzun sürmez (veya belirli bir özelliğin neden bir cevap olarak sadece "ürün yazılımı zor" olduğunu kabul eden büyük şirketlerde çalışır yıllar geçti)

Platformdan platforma, hedefinize değişen derecelerde görünürlük ile harici bir sistemde geliştirme sisteminize yönelik kod üzerinde çalışıyorsunuz. Kontrolünüz altındaysa, hedef sisteminizde bu görünürlüğü artırmaya yardımcı olacak geliştirme yardımları için itin. Hata ayıklama seri portlarını, bit vurma hata ayıklama çıkışını, ünlü yanıp sönen ışığı, vb. Kullanın. İnsanların gerekenden daha uzun yıllar mücadele etmelerini izledim, çünkü uygun bir JTAG hata ayıklayıcı bağlantısını nasıl kullanacaklarını / öğreneceklerini hiç rahatsız etmediler.

Bilgisayara göre tam olarak hangi kaynaklara sahip olduğunuzu bilmek çok daha önemlidir. Veri sayfalarını dikkatle okuyun. Yapmaya çalıştığınız her şeyin kaynağını 'maliyetini' düşünün. Yığın kullanımını izlemek için yığın alanını sihirli bir değerle doldurma gibi kaynak odaklı hata ayıklama püf noktalarını öğrenin.

Hem PC hem de gömülü yazılım için bir dereceye kadar hata ayıklama becerisi gerekli olsa da, gömülü ile çok daha önemlidir.

C ++ deneyiminizin PC tabanlı olduğunu varsayıyorum.

Bilgisayardan mikro denetleyiciye geçen programcılar tarafından sıklıkla yapılan bir hata, kaynakların ne kadar sınırlı olabileceğini anlamamasıdır . Bir PC'de 100.000 girişli bir tablo oluşturduğunuzda veya 1MB makine koduyla derlenen bir program yazdığınızda kimse sizi durduramaz.
Orada olan özellikle yüksek sonunda, bellek kaynaklarının zenginliği var mikroişlemcisi, ama alışık olacak ne hala bir feryat. Bir hobi proje için muhtemelen her zaman en fazla gidebilir ama profesyonel projede sık sık çalışmak zorunda olacak küçük bir cihaza bunun nedeni daha ucuz .
Bir projede bir TI MSP430F1101 ile çalışıyordum. 1 KB program belleği, 128 bayt yapılandırma Flash, 128 bayt RAM. Program 1K'ya uymadı, bu yüzden Flash'ta 23 baytlık bir işlev yazmak zorunda kaldım. Bu küçük kontrolörler ile bayt tarafından hesaplanır . Başka bir durumda program belleği 4 bayt çok küçüktü. Patron, denetleyiciyi daha fazla bellekle kullanmama izin vermedi, ancak bunun yerine, zaten 4 bayt sığacak şekilde zaten optimize edilmiş bir makine kodunu (zaten montajcıda yazılmış) optimize etmek zorunda kaldım.

Üzerinde çalıştığınız platforma bağlı olarak, çok düşük seviyeli G / Ç ile uğraşmak zorunda kalacaksınız . Bazı geliştirme ortamlarının LCD'ye yazma işlevleri vardır, ancak diğerlerinde tek başınıza olursunuz ve nasıl kontrol edeceğinizi öğrenmek için LCD'nin veri sayfasını baştan sona okuması gerekir.
Bir röleyi kontrol etmeniz gerekebilir, bu bir LCD'den daha kolaydır, ancak mikrodenetleyicinin kayıt seviyesine gitmenizi gerektirir. Yine bir veri sayfası veya kullanım kılavuzu. Bir blok diyagramda bulacağınız mikro denetleyicinin yapısını tekrar veri sayfasında tanımanız gerekir. Mikroişlemcinin günlerinde bir programlama modelinden bahsettiktemelde işlemci kayıtlarının bir dizisi. Günümüzün mikro denetleyicileri o kadar karmaşıktır ki, tüm kayıtların bir açıklaması 100 sayfalık veri sayfasının en iyi kısmını alabilir. IIRC sadece MSP430 için saat modülünün açıklaması 25 sayfa uzunluğundaydı.

$\mu$

Mikrodenetleyiciler genellikle C'de programlanır . C ++ kaynaklar açtır, bu yüzden genellikle dışarıdadır. (Mikrodenetleyiciler için çoğu C ++ uygulaması sınırlı bir C ++ alt kümesi sunar.) Dediğim gibi, platforma bağlı olarak, size oldukça biraz zaman kazandırabilecek kapsamlı bir işlev kütüphanesine sahip olabilirsiniz. Çalışmak için biraz zaman ayırmaya değer, neyin mevcut olduğunu biliyorsanız daha sonra size zaman kazandırabilir.

"donanım programlama" birçok şey anlamına gelebilir. Çok küçük bir çipin programlanması (10F200, 512 talimatlar, birkaç bayt RAM düşünün) neredeyse bir elektronik devre tasarlamaya benzer. Diğer tarafta programlama büyük bir Cortex mikrodenetleyici (1 Mb FLASH, 64 kB RAM), büyük bir GUI araç seti kullanarak PC / GUI programlama gibi bir şey olabilir. IMHO iyi bir gömülü / gerçek zamanlı programcı, hem yazılım belirleme tarafından hem de devre tasarımı tarafından yeteneklere ihtiyaç duyar. Daha büyük uC için C ++ iyi bir dil seçimidir, çünkü çok küçük olanlar için C tek seçenek olabilir. Assemby bilgisi kullanışlı olabilir, ancak ciddi projelerin tamamen montajda yapılmasını tavsiye etmem.

Her iki (SWI ve EE) taraflardan insanlarla ciddi gömülü çalışmalar yaptım. Çok iş parçacıklı programlama konusunda deneyim sahibi olmaları koşuluyla genellikle SWI çalışanlarını tercih ederim.

Sorunuz gömülü programlamaya dalmak istediğiniz gibi geliyor. Elbette öyle. Düşük seviyeli yönler için (çipinizdeki çevre birimleri ve etrafındaki donanımları birbirine bağlamak) bazı yeni beceriler öğrenmeniz gerekecektir, ancak birçok yeni kavram olmadan sadece çok fazla iş var. Projelerinizin daha yüksek katmanları için mevcut knwoledge'inizden yararlanabilirsiniz.

Çağıracağınız her arduino kütüphanesi yöntemi için, bunu mümkün kılan zengin bir C / C ++ kodu var, bir API olarak kullanmanız için güzelce paketlenmiştir. Hardware / arduino / * dizini altındaki arduino kaynak koduna bakın ve AVR mikro denetleyicisinin kayıtları ile doğrudan etkileşime giren sizin için yazılmış tüm C / C ++ 'ı göreceksiniz. Amacınız (doğrudan donanım için) böyle bir şeyleri nasıl yazacağınızı öğrenmekse, kapsayacak çok şey var. Amacınız kütüphanelerini kullanarak çalışmak için bir şeyler elde etmekse, sizin için zor işlerin çoğunun yapıldığı ve kütüphanelerinin ve geliştirme ortamının kullanımı çok kolay olduğu için konuşacak çok şey olmayabilir.

Arduino ortamına veya diğerlerine uygulanabilecek kaynak kısıtlı cihazlarla çalışırken bazı temel kurallar:

Ne kadar bellek kullandığınıza dikkat edin. Hem kod boyutu (flash belleğe gider) hem de statik RAM kullanımı (kodunuzda her zaman RAM'de bulunacak sabitler). Statik RAM kullanımının başlangıçtan biraz daha önemli olduğunu savunuyorum, çünkü üzerine bakmak kolaydır. Yığınız, yığınınız ve sabitleriniz için birlikte çalışacak yalnızca 1000 bayt olması nadir değildir. Nasıl harcadığınız konusunda akıllı olun, bu nedenle bayt veya imzasız karakterlerin (her biri 1 bayt) yeterli olacağı uzun uzun tamsayı dizileri (her biri 4 bayt) gibi şeylerden kaçının. Buradaki başka bir cevap diğer bazı önemli noktaları da çok iyi kapsıyor, bu yüzden burada duracağım, esas olarak arduino kütüphanesini kullanmıyorsanız ve kendi C kütüphanelerinizi yazmamanız gereken çok şey olduğu noktasını ele almak istedim .

Mikrodenetleyici ve OOP programlamaya gelince, bunlar karşıt bir şey değildir. Tüm satıcı kitaplıklarının C düzünde olduğu doğrudur, ancak tüm platformlar C ++ OOP'yi de destekler. Geliştiriciler bunun üzerine C ++ üst düzey kitaplıklar ve cihaz ürün yazılımı oluşturabilir ve oluşturabilir. Bunun en iyi örneği, resmi ve kullanıcı tarafından oluşturulan Arduino kütüphaneleri - çoğunlukla C ++ sınıfları. Belki tüm OOP avantajları gömülü ortamda tam olarak kullanılamaz, ancak iyi bilinen C ++ vs C avantajları burada da geçerlidir.

Zihniyet ve düşünme ile ilgili olarak, diğer cevaplarda belirtildiği gibi, mikrodenetleyiciler çok kaynak kısıtlı platformlardır (özellikle RAM'de, daha az hızda) - dinamik bellek tahsisi gibi şeyler, C ++ istisnaları genellikle göz ardı edilir. Doğru donanım seçildiğinde, bu sınırlamalara uymak ve diğer teknikleri (diğer platformlarda da yaygın olarak kullanılır) kullanmak kolaydır.

Benim görüşüme göre, daha zor olan zorluk gömülü programlama zamanlamasında bulunan bir ekstra boyut daha olabilir. Bunun nedeni genellikle gömülü yazılımın gerçek zamanlı olaylarla, çevre donanımını ve genel görevin kendisini yürütmek için kesin olarak zamanlanmış protokollerle çok fazla uğraşmasıdır (bunlar, çok iş parçacıklı uygulamalar gibi diğer "yüksek düzey" platformlarda da bazı paralelliklerdir).

Yeni donanım ile uğraşırken çok sayıda veri sayfasını okumaya hazır olun - sanırım "zihniyet" soru kısmı ile ilgili olabilir :) Kesinlikle bazı EE ve donanım bilgisine ihtiyaç duyulacaktır.

Ayrıca, bu günlerde gömülü yazılım geliştirmenin montaj dili gerektirmediğini de belirtmek isterim. Aslında Java (BTW varsayılan olarak OOP'tur) zaten burada ve güçleniyor (en azından bazı gömülü cihazlar, örneğin IoT cihazları için çok parlak bir geleceğe sahip olabilir).