Büyük gömülü projeleri nasıl yapılandırırsınız? [kapalı]

Arkaplan :

Junior Ar-Ge elektronik mühendisi ( şirketteki tek EE ) - donanım ve kodlama sorun değil. En büyük sorunum, projeye ve nereden başlayacağınıza dair genel bir bakış sağlamak.

Şimdiye kadar sadece küçük yazılım projeleri yaptım (alt 500 kod satırı), ancak fonksiyonelliğe genel bir bakış açısı kaybetmeden ya da işlevsellik eksikliği yaşamadan kendimi daha büyük projeler yapmayı hayal edemiyorum.

Büyük gömülü yazılım sistemlerini yapılandırmak için en iyi yapıları / hangi araçları kullanıyorsunuz?

Şu anda ne yapıyorum :

Genellikle projenin işlevselliğini çizerek başlarım. Bir - çok katmanlı akış şemaları veya ilgili şemalar (blok şemaları, vb.) Olabilir ve bileşenler / çipler üzerinde bazı araştırmalar yapılabilir. Sonra veri sayfalarına / Internet'e başvururken, bir kerede bir işlevsellik kodlayarak ve sahte verilerle veya benzer bir testle test ederken doğrudan kodlamaya atlarım (hızlı başarısız olur sanırım). Bir MEM yongasına veri yazıyor olabilir ve eğer çalışırsa ana yonga ile MEM yongası arasında bir SPI sürücüsü olabilir.

Aradığım cevap nedir :

Hiçbir şey gerçekten. Mantıklı bulduğum şeyi çözeceğim. Bir kitap, makale, kişisel deneyim, tavsiyeler vb. Olabilir.

Yaşlıların bununla nasıl başa çıkacağını bilmekle çok ilgileniyorum.

Düzenle

Öncelikle, yılların tecrübesini paylaştığın için teşekkür ederim! Tüm cevaplar çok takdir edilmektedir. Bundan benim almam;

• Net ve kesin bir özellik belgesi oluşturun.
• Bir yazılım tasarım dokümanı oluşturun. (Şimdi ekleyeceğim bir şey) Tasarım belgesi şablonları tasarlama
• Modüllerde ne kadar gereksiz göründüğünü düşünün. (Daha fazla odaklanmam gereken bir şey)
• Başlık / kaynak dosyalarının yapılandırılması için bir kodlama standardı izleyin. (Bunu hiç yapmadım) Barr Group C standardı
• Önce düşük seviyeli uygulamaları yaratmaya odaklanın. (İletişim vb.)
• Mümkün olan / mantıklı olan tasarım desenlerini uygulayın. Tasarım desenleri
• Revizyon kontrolü için bir şeyler ayarlayın (Github vs. - asla bu kadar kullanılmadı)
• Sürekli entegrasyon / sürekli dağıtım araştırması (üzerine bastığım yeni bir şey) CI ve CD'nin temelleri

Bir projenin yapılandırılmasının detaylandırma derecesini etkileyen birkaç yönü vardır. Benim için en önemli etkenlerden biri, tek kodlamanın benim mi (yoksa, sizin için tek EE olduğunuzu yazarken sizin için geçerli olan gibi) veya başkaları da var mı? Sonra "büyük" aslında ne anlama geldiği sorusu var. Genellikle tasarım sürecini aşağıdaki adımlara bölerim:

Gereksinim tanımı Uygun bir yazılım belirtimi ediniyorsanız, birçok planlama ile çalışmak için zaten hazırdır. Eğer belli belirsiz gereksinimler elde ederseniz, yapmanız gereken ilk şey müşterinin gerçekte ne istediğini çözmektir (bazen ilk başta gerçekten bilmezler). Kodlamanın hemen içine atlamanın cazip olduğunu biliyorum, ancak bu, ilk etapta açık olmayan ve geliştirme sürecinin tam ortasında herhangi bir yerde kodunuza kolayca sıkıştırılamayan önemli bir özelliği kaçırmama riskini getiriyor.

Sistem sınırları ve bakım kolaylığı Gömülü sistemlerde, genellikle dışarıya (operatöre) ama aynı zamanda içeriye doğru bazı sistem arayüzleri vardır. Bunları iyi tanımlayın ve bağımlılıkları mümkün olduğunca düşük tutmaya çalışın, bu sürekli mühendisliği ve bakımı kolaylaştıracaktır. Ayrıca gerektiğinde yorum / belge kodu verin, başka kiminle çalışmak zorunda kalacağını asla bilemezsiniz. (Ler) aslında bir işlevin ne yaptığını bilmeden önce bir düzine kod katmanında kazmak zorunda kalmayacağı için mutlu olacaktır.

Doğrulanabilir görevlerin tanımlanması Özellikle diğer geliştiriciler aynı kod tabanında çalışıyorsa, net görevler (özellikler) ve aralarında gereken arabirimleri tanımlamak kaçınılmazdır. Mümkün olduğunda, her bir özellik diğerlerinden bağımsız olarak test edilmeli / doğrulanmalıdır, burada iyi tanımlanmış arayüzlere ihtiyaç duyulur, böylece test durumlarınızı tanımlayabilirsiniz.

Diğer insanlar ilerlemeden sonraki özelliklerden biri , bu nedenle çeşitli görevleriniz varsa, genellikle en çok ilerleme vaat eden şey üzerinde çalışırlar. Genelde bir görevi bitirmeye ve bir sonrakine başlamadan önce doğrulanmış ve test edilmiş bir duruma getirmeye çalışırım. Bu, kodunuzun başkaları tarafından test edilmesini sağlar ve bir şeyleri unutmayı bırakmazsınız.

Revizyon Kontrolü Bir projenin ömrü boyunca bazen eski sürümlere ihtiyaç duyabilirsiniz, belki yeni sürümde ortaya çıkan bir hatayı tanımlamak veya sadece 3 yıl önce gönderdiğiniz şekilde davranan bir cihaz oluşturmak için. Kodunuzda derleme revizyonları ve etiketleri olduğundan emin olun. Git kesinlikle buradaki arkadaşın.

Humpawumpa harika bir cevap yazdı ! Sadece bazı noktalarına destek olmak istiyorum, ancak yorum yapmak için çok uzun olduğu için ayrı bir cevap yazacağım.

Bir zamanlar OP'nin konumundaydım - sadece EE değil, küçük bir şirkette herhangi bir MCU geliştirmesi yapmış olan tek EE.

Tek geliştirici olsanız bile modülerliğin önemini yeterince vurgulayamıyorum . Proje büyüdükçe aklı başında kalmak için tek yol bu. Her biri yalnızca bir işlevsel kavramı ele alan modüller yazma konusunda katı olmanız ve harici arayüzlerini mümkün olduğunca az tutmanız gerekir. Yüksek seviyeli modüller işlevsel gereksinimlere karşılık gelirken, düşük seviyeli modüller donanım kaynaklarıyla (yani aygıt sürücüleri) yakın bağlara sahip olacaktır.

Çeşitli modüllerin nasıl bilgi paylaştığını kesin olarak gösteren ayrıntılı bir veri akış şeması ^1'i korumak için çok zaman harcadım . Bazı özelliklerin gerçek zamanlı performans açısından çok farklı gereksinimleri olacaktır; bilgi paylaşımının bunu nasıl etkilediğini bildiğinizden emin olun. Diyagram, kesme-olmayan kodu çeşitli kesme-alanlı alanlardan ayıran sınırlar boyunca çizildi.

¹ Kontrol akışına odaklanan bir akış şemasından çok farklı .

Herhangi bir büyük proje için, her şeyi kendim yapmayı düşünmeme rağmen, birden fazla geliştirici varmış gibi planlıyorum.

Sebepleri basit:

1 Karmaşıklık. Büyük bir projede her zaman karmaşıklıklar olacaktır . Projeyi çok sayıda ekip varmış gibi planlamak, karmaşıklığın dikkate alındığı ve belgelendiği anlamına gelir . Büyük projelerin problemlerle karşı karşıya kaldığını gördüğüm sayı yüksekti ve genellikle 'çatlaklardan kaymış bir şey' yüzünden. Unutmayın, mekanik montaj da ayrıca kutunun boyutu için değil, aynı zamanda düşünülmelidir - ısı alıcılarına ihtiyaç olacak mı? Kutu güvenlik için topraklanmalı mı? Sadece bu kategoride birçok soru var.

2 Gereksinimler. Birden fazla insanın dahil olduğunu varsayalım, üst düzey gereksinimlerin (gereksiz karmaşıklık ve maliyet getirebileceği için sık sık meydan okudum) , daha küçük bir organizasyonda gerekli olan daha küçük gerekli ve başarılabilir görevlere (daha büyük bir kuruluştaki başka bir takıma verilebilecek ) ayrılması gerektiği anlamına gelir. ) sadece tek bir bloba bakmak yerine.

3 Bölümleme. İki ana bölümleme türü vardır; donanım işlevi ve donanım / yazılım. İlk tip, işlevsel blokların hangi ayrı (fakat haberleşmeli) olması gerektiğini belirlemektir. İkincisi, daha basit (bazen) donanım ve yazılım takasıdır, ancak yalnızca daha fazla şeyi yazılıma taşımanın donanım sorununu çözmeyeceğini unutmayın. Daha fazla yazılıma geçmek aslında bazı durumlarda donanım karmaşıklığını büyük ölçüde artırabilir (daha fazla işlem beygir gücü, daha karmaşık arayüzler ve daha fazlası).

4 Arayüzler. Bölümleme işlemi iç arayüzlerin tanımlanmasına yardımcı olacaktır; Dış arabirimler genellikle genel gereksinimlerin bir parçasıdır (her zaman olmasa da). Karmaşık bir iletişim protokolü veya basitçe iyi / kötü sinyalizasyon olabilen bir sistemin farklı bölümlerinin işbirliği yapmasının birçok yolu vardır .

5 Doğrulama. Bu, düşük seviye test (donanım ve sürücüler için) ve sistem seviyesinin bir karışımıdır. Projeyi iyi tanımlanmış bloklarda yapmış olmak, sağlam doğrulamaya izin verir (analiz veya gerçek testle olabilir ve genellikle ikisinin bir karışımıdır; tasarımlardaki güncellemeler benzerlik argümanlarını kullanabilir).

6 Standartları. Kodlama ve çizim standartlarını daha büyük bir ekipmiş gibi kullanıyorum. Barr grubunun kodlama standartlarını çok zahmetli olmadıkları için kullanıyorum ancak birçok hata sınıfının kodda bulunmasını önlüyorum. PCB çıktı dokümantasyonu için IPC-D-326'yı ( IPC-D-325'i çağıran) izlerim, bu da niyetimi PCB imalatçılarına ve montajcılarına iletmek için kanıtlanmış bir yöntemdir. Bu garip görünebilir, ancak disipline birkaç standart uyması, kalitenin tutarlı olduğu anlamına gelir.

7 Sürüm kontrolü. Projenin tüm parçaları için revizyon kontrolü kullanıyorum (sistem, donanım, yazılım. Mekanik, test gereksinimleri - her şey). Kullandığım CAD araçları, tüm yazılım ve FPGA oluşturma araçlarında olduğu gibi sürümlemeyi destekliyor.

Birçok gömülü projede çalıştım (buradaki tecrübeli halkın çoğunda olduğu gibi) ve takım boyutları 1 (kendim) ile düzinelerce (ya da belirli bir proje kümesinde yüzlerce) birden fazla disipline ve bazen de diğer coğrafi bölgelere yayıldı. Siteler. Aynı aşırı kemerli yaklaşımı kullanmak (işe yaradığı biliniyor), göreceli yalıtımda belirli bir görevi alıp, daha büyük projenin tek başına bir parçası olarak iyice test edebileceğim anlamına geliyor. Ayrıca, gerektiğinde bazen bazı şeyleri ortadan kaldırabilirim anlamına gelir.

Tüm bunları yapmak biraz ön hazırlık süresi sağlar ancak sonuçta karmaşık gömülü sistemler için daha hızlı bir yoldur.

Diğer cevaplar birçok harika ipucu veriyor. Gömülü gelişim kariyerimde en önemli bulduğum iki tane:

1. Kodun mümkün olduğunca ayrı, iyi tanımlanmış modüllere dönüştürülmesi.
2. Modülleri PC'de otomatik olarak test edilebilir hale getirin.

Gömülü sistemlerde "sürekli entegrasyon" tarzı geliştirme yapmak için ihtiyaç duyduğunuz şey budur. Her zaman otomatik test için donanıma çok sıkı bağlı olan bir miktar kod olacaktır, ancak en aza indirmeye çalışın. Simüle edilmiş verileri kullanarak veya daha sonra test sistemine beslediğiniz gerçek donanımdaki veri yakalamalarını kullanarak oldukça uzağa gidebilirsiniz.

Mevcut cevaplara eklemek için ...

Ben her zaman aşağıdan başlıyorum. Donanım tasarımınızdan, G / Ç'nizin ne olduğunu bilirsiniz. Yüksek seviye kodunuzun düşük seviye şeyler hakkında fazla bir şey bilmesi gerekmeyecek şekilde, G / Ç'yi içine alan sürücü modülleri oluşturarak başlayın.

Düşük seviye arayüzleri oluştururken, elbette bir test donanımına ihtiyacınız vardır. Bunu baştan itibaren PC'ye bağlamak için tasarlarsanız (belki bir RS-232 portu, belki de USB, Ethernet üzerinden telnet ile) o zaman uygulamanızı oluştururken bu test demeti arayüzünü yerinde tutabilirsiniz. Uygulama şekillendikçe daha fazla test demeti kancası eklemeye devam edebilirsiniz ve bu, devam ettikçe kodunuzu regresyon testi yapmanıza olanak sağlar.

Dört soruda düşünme eğilimindeyim. İlk ikisi, bir sistem projesinin başlangıcına, ikisi de sonlarına doğru.

1. Gerçekten sistemi istiyorlar mı? Sistem müşterilerin problemini, kabul edeceği bir zaman ve maliyet ölçeğinde çözecek mi? Yaygın bir sorun, müşterinin kullanmayacağı sistemler oluşturmaktır.

2. Bu sistemi gerçekten yapabilir miyiz? Gerekli performansı, hassasiyeti, güç kullanımını,… sunmak mümkün olacak mı?

İlk prototipleri oluşturmak, bu iki ilk soruyu cevaplamanın iyi bir yoludur. Riskin azaltılması, erken aşamalarda son derece önemlidir.

Sonraki iki soru, projenin sonraki aşamalarında daha hedeflidir:

3. İşimiz bitti mi? Her şey tasarlandı, kodlandı, test edildi, teslim edildi

4. Sistemi gerçekten kullanıyorlar mı?