Bagaimana Anda menyusun proyek tertanam besar? [Tutup]

Latar belakang :

Insinyur elektronik R & D Junior ( satu-satunya EE di perusahaan ) - perangkat keras dan pengkodean bukanlah masalahnya. Masalah terbesar saya adalah mendapatkan gambaran umum proyek yang tepat, dan dari mana harus memulai.

Sejauh ini saya hanya membuat proyek perangkat lunak kecil (sub 500 baris kode), tetapi saya tidak dapat membayangkan diri saya melakukan proyek yang lebih besar tanpa kehilangan tinjauan fungsionalitas atau kurangnya fungsionalitas.

Bagaimana Anda menyusun struktur terbaik / alat apa yang Anda gunakan untuk menyusun sistem perangkat lunak tertanam besar?

Apa yang saya lakukan saat ini :

Saya biasanya memulai, dengan membuat sketsa fungsi proyek. Ini bisa berupa diagram alir berlapis atau diagram terkait (diagram blok, dll.) Dan melakukan riset terhadap komponen / chip. Kemudian saya langsung masuk ke pengkodean (gagal cepat saya kira) sambil referensi lembar data / Internet, Coding satu fungsi pada suatu waktu dan mengujinya dengan data dummy, atau tes serupa. Bisa jadi menulis data ke chip MEM, dan kemudian jika itu bekerja maka itu bisa menjadi driver SPI antara chip utama dan chip MEM.

Apa jawaban yang saya cari :

Apapun benar-benar. Saya akan memilah apa yang menurut saya masuk akal. Itu bisa berupa buku, artikel, pengalaman pribadi, rekomendasi, dll.

Saya sangat tertarik mengetahui bagaimana senior mengatasi hal ini.

Edit

Pertama, terima kasih telah berbagi pengalaman bertahun-tahun! Semua jawaban sangat kami hargai. Yang saya ambil dari ini adalah;

• Buat dokumen spesifikasi yang jelas dan tepat.
• Buat dokumen desain perangkat lunak. (Sesuatu yang sekarang akan saya tambahkan) Desain template dokumen
• Pikirkan dalam modul seberapa berlebihan hal itu kelihatannya. (Sesuatu yang saya perlu lebih fokus pada)
• Ikuti standar pengkodean untuk menyusun file header / sumber. (Tidak pernah melakukan ini) Barr Group C standar
• Fokus pada menciptakan implementasi tingkat rendah terlebih dahulu. (Komunikasi dll.)
• Menerapkan pola desain jika memungkinkan / masuk akal. Pola desain
• Siapkan sesuatu untuk kontrol revisi (Github dll. - tidak pernah digunakan sebanyak ini)
• Riset integrasi terus-menerus / penerapan berkelanjutan (Sesuatu yang baru saya temui) Dasar-dasar CI & CD

Ada beberapa aspek yang mempengaruhi tingkat detail penataan kebutuhan proyek. Bagi saya salah satu faktor utama adalah apakah saya satu-satunya pengkodean (yang tampaknya menjadi masalah bagi Anda saat Anda menulis, Anda adalah satu-satunya EE) atau jika ada orang lain yang terlibat. Lalu ada pertanyaan tentang apa sebenarnya arti "besar". Biasanya saya membagi proses desain menjadi langkah-langkah berikut:

Definisi persyaratan Jika Anda mendapatkan spesifikasi perangkat lunak yang tepat untuk bekerja dengan banyak perencanaan sudah dilakukan. Jika Anda hanya mendapatkan persyaratan yang tidak jelas, hal pertama yang harus Anda lakukan adalah memilah apa yang sebenarnya diinginkan pelanggan (kadang-kadang mereka tidak benar-benar tahu sejak awal). Saya tahu itu tergoda untuk langsung masuk ke pengkodean, tetapi itu membawa risiko kehilangan fitur penting yang mungkin tidak jelas di tempat pertama dan tidak bisa dengan mudah dimasukkan ke dalam kode Anda di suatu tempat di tengah pengembangan.

Batas sistem dan rawatan Dalam sistem tertanam Anda sering memiliki beberapa antarmuka sistem, beberapa di luar (operator) tetapi juga di dalam. Tetapkan ini dengan baik dan cobalah untuk menjaga ketergantungan serendah mungkin, ini akan menyederhanakan rekayasa berkelanjutan dan pemeliharaan. Juga komentar / kode dokumen jika diperlukan, Anda tidak pernah tahu siapa lagi yang harus bekerja dengannya, (s) ia akan senang tidak harus menggali selusin lapisan kode sebelum benar-benar mengetahui apa fungsi tidak.

Tentukan tugas yang dapat diverifikasi Khususnya jika pengembang lain bekerja pada basis kode yang sama tidak dapat dihindari untuk menentukan tugas yang jelas (fitur) dan antarmuka yang diperlukan di antara mereka. Bilamana mungkin, masing-masing fitur harus diuji / diverifikasi independen dari yang lain, di situlah Anda memerlukan antarmuka yang terdefinisi dengan baik sehingga Anda dapat menentukan kasus pengujian Anda.

Satu fitur setelah Orang lain suka kemajuan, jadi jika Anda memiliki berbagai tugas mereka biasanya mengerjakan apa pun yang menjanjikan kemajuan paling. Saya biasanya mencoba menyelesaikan tugas dan membawanya ke keadaan terverifikasi dan teruji sebelum saya mulai dengan yang berikutnya. Ini memungkinkan kode Anda diuji oleh orang lain dan Anda tidak akan melupakan sesuatu.

Kontrol Revisi Selama masa proyek Anda kadang-kadang membutuhkan versi yang lebih lama, mungkin untuk mengidentifikasi bug yang diperkenalkan dengan beberapa rilis baru atau hanya untuk membangun perangkat yang berperilaku persis sama dengan yang Anda kirim 3 tahun yang lalu. Pastikan Anda memiliki revisi dan tag build yang jelas dalam kode Anda. Git jelas teman Anda di sini.

Humpawumpa menulis jawaban yang bagus ! Saya hanya ingin menambah beberapa poinnya, tetapi karena ini terlalu lama untuk menjadi komentar, saya akan menulis jawaban yang terpisah.

Saya pernah berada di posisi OP - bukan hanya EE, tetapi satu-satunya EE yang telah melakukan pengembangan MCU di perusahaan kecil.

Saya tidak bisa menekankan pentingnya modularitas , bahkan jika Anda satu-satunya pengembang. Ini satu-satunya cara untuk tetap waras saat proyek berkembang. Anda harus tegas dalam menulis modul yang masing-masing hanya menangani satu konsep fungsional, dan menjaga antarmuka eksternal seminimal mungkin. Modul tingkat tinggi akan sesuai dengan persyaratan fungsional, sedangkan modul tingkat rendah akan memiliki ikatan erat dengan sumber daya perangkat keras (yaitu, penggerak perangkat).

Saya menghabiskan banyak waktu mempertahankan diagram alir data rinci ¹ , yang menunjukkan dengan tepat bagaimana berbagai modul berbagi informasi. Beberapa fitur akan memiliki persyaratan yang sangat berbeda dalam hal kinerja waktu nyata; pastikan Anda tahu bagaimana pengaruh berbagi informasi itu. Diagram tersebut memiliki batas yang ditarik di atasnya yang memisahkan kode non-interupsi dari berbagai domain yang digerakkan interrupt.

¹ Sangat berbeda dari diagram alur, yang difokuskan pada aliran kontrol .

Untuk setiap proyek besar, saya merencanakannya seolah-olah ada beberapa pengembang yang terlibat bahkan jika saya berniat melakukan semuanya sendiri.

Alasannya sederhana:

1 Kompleksitas. Sebuah proyek besar akan selalu memiliki kerumitan yang terlibat. Setelah merencanakan proyek seolah-olah ada banyak tim yang terlibat berarti kompleksitas telah dipertimbangkan dan didokumentasikan . Banyak kali saya melihat proyek besar mengalami masalah tinggi dan biasanya karena sesuatu 'menyelinap melalui celah-celah'. Jangan lupa bahwa perakitan mekanis juga harus dipertimbangkan dan tidak hanya untuk ukuran kotak - apakah akan ada kebutuhan untuk heat sink? Haruskah kotak dibumikan untuk keselamatan? Ada banyak pertanyaan dalam kategori ini saja.

2 Persyaratan. Dengan asumsi beberapa orang terlibat berarti bahwa persyaratan tingkat atas (yang sering saya tantang karena mereka dapat membawa kompleksitas dan biaya yang tidak perlu) harus dipecah menjadi berbagai tugas yang lebih kecil yang diperlukan dan dapat dicapai (yang dapat dimasukkan ke tim lain dalam organisasi yang lebih besar). ) daripada hanya melihat satu gumpalan.

3 Mempartisi. Ada dua jenis utama partisi; fungsionalitas perangkat keras dan perangkat keras / perangkat lunak. Tipe pertama adalah menentukan blok fungsional apa yang terpisah (tetapi berkomunikasi) perlu ada. Yang kedua adalah trade-off dari perangkat keras dan perangkat lunak yang lebih sederhana (kadang-kadang) tetapi perlu diingat bahwa hanya memindahkan lebih banyak hal ke perangkat lunak tidak akan serta merta memperbaiki masalah perangkat keras. Pindah lebih ke perangkat lunak sebenarnya dapat sangat meningkatkan kompleksitas perangkat keras dalam beberapa keadaan (lebih banyak memproses tenaga kuda, antarmuka yang lebih kompleks, dan banyak lagi).

4 Antarmuka. Proses partisi akan membantu mendefinisikan antarmuka internal; antarmuka eksternal biasanya merupakan bagian dari persyaratan keseluruhan (walaupun tidak selalu). Ada banyak cara bagi berbagai bagian sistem untuk bekerja sama yang mungkin merupakan protokol komunikasi yang kompleks atau pensinyalan yang baik / buruk.

5 Verifikasi. Ini adalah campuran pengujian tingkat rendah (untuk perangkat keras dan driver) dan tingkat sistem. Setelah melakukan proyek dalam blok yang terdefinisi dengan baik memungkinkan verifikasi yang kuat (yang mungkin dengan analisis atau tes aktual dan biasanya merupakan campuran dari keduanya; pembaruan desain dapat menggunakan argumen kesamaan).

6 standar. Saya menggunakan standar pengkodean dan menggambar seolah-olah itu adalah tim yang lebih besar. Saya menggunakan standar pengkodean Barr group karena tidak terlalu memberatkan tetapi mencegah banyak kelas bug berada dalam kode. Untuk dokumentasi keluaran PCB, saya mengikuti IPC-D-326 (yang memanggil IPC-D-325) karena itu adalah metode yang sudah terbukti untuk mengkomunikasikan maksud saya kepada perakit dan perakit PCB. Ini mungkin tampak aneh tetapi memiliki disiplin untuk mengikuti sejumlah standar berarti kualitasnya konsisten.

7 Kontrol versi. Saya menggunakan kontrol revisi untuk semua bagian proyek (sistem, perangkat keras, perangkat lunak, mekanik, persyaratan pengujian - semuanya). Alat CAD yang saya gunakan mendukung versi seperti halnya semua perangkat lunak dan alat bantu FPGA.

Saya telah bekerja pada banyak proyek tertanam (seperti halnya banyak dari orang-orang yang berpengalaman di sekitar sini) dan ukuran tim bervariasi dari 1 (saya sendiri) hingga lusinan (atau ratusan pada satu set proyek tertentu) yang tersebar di berbagai disiplin ilmu dan kadang-kadang lainnya secara geografis terpencil situs. Menggunakan pendekatan over-arching yang sama (yang diketahui bekerja) berarti saya dapat mengambil tugas tertentu dalam isolasi relatif dan menyelesaikannya dan mengujinya secara menyeluruh sebagai bagian yang berdiri sendiri dari proyek yang lebih besar. Itu juga berarti saya dapat memberikan beberapa hal keluar jika perlu.

Melakukan semua hal ini menambah sedikit waktu di muka tetapi pada akhirnya merupakan rute yang lebih cepat untuk sistem embedded yang kompleks.

Jawaban lainnya memberikan banyak tips hebat. Berikut adalah dua yang saya temukan paling penting dalam karier pengembangan tertanam saya:

1. Buat sebanyak mungkin kode menjadi modul terpisah dan terdefinisi sebaik mungkin.
2. Jadikan modul dapat diuji secara otomatis pada PC.

Itulah yang Anda butuhkan untuk melakukan pengembangan gaya "integrasi berkelanjutan" pada sistem embedded. Akan selalu ada sejumlah kode yang terlalu terikat dengan perangkat keras untuk pengujian otomatis, tetapi cobalah untuk menguranginya. Anda bisa mendapatkan cukup jauh dengan menggunakan data simulasi atau tangkapan data dari perangkat keras yang sebenarnya, yang kemudian Anda masukkan ke dalam sistem pengujian.

Untuk menambah jawaban yang ada ...

Saya selalu memulai dari bawah ke atas. Dari desain perangkat keras Anda, Anda tahu apa I / O Anda. Mulailah dengan membuat modul driver yang merangkum I / O itu, sehingga kode tingkat tinggi Anda tidak perlu tahu terlalu banyak tentang hal-hal tingkat rendah.

Saat Anda membangun antarmuka tingkat rendah, tentu saja Anda memerlukan test harness. Jika Anda merancang ini untuk menghubungkan ke PC dari awal (mungkin dengan port RS-232, mungkin USB, mungkin telnet melalui Ethernet) maka Anda dapat menjaga antarmuka uji coba ini tetap di tempatnya saat Anda membangun aplikasi. Anda dapat terus menambahkan lebih banyak kait uji harness saat aplikasi terbentuk, dan itu akan memungkinkan Anda menguji kembali kode Anda sambil melanjutkan.

Saya cenderung berpikir dalam empat pertanyaan. Dua yang pertama adalah bagian dari permulaan proyek sistem, dua berikutnya menjelang akhir.

1. Apakah mereka benar-benar menginginkan sistem? Apakah sistem akan memecahkan masalah pelanggan, pada skala waktu dan biaya yang akan mereka terima? Masalah umum adalah membangun sistem yang tidak akan digunakan pelanggan.

2. Bisakah kita benar-benar membangun sistem itu? Apakah mungkin untuk memberikan kinerja, presisi, penggunaan daya yang diperlukan, ...?

Membuat prototipe awal adalah cara yang baik untuk menjawab dua pertanyaan pertama ini. Mitigasi risiko sangat penting dalam fase awal.

Dua pertanyaan berikutnya lebih ditargetkan pada fase selanjutnya dari proyek:

3. apakah kita benar-benar selesai? Semuanya dirancang, dikodekan, diuji, dikirim

4. Apakah mereka benar-benar menggunakan sistem?