Menulis perangkat lunak tertanam tanpa perangkat keras

8

Pertimbangkan bahwa tim perangkat keras akan membutuhkan waktu 2 bulan untuk mengembangkan beberapa perangkat keras, tetapi pada saat itu saya perlu menyiapkan perangkat lunaknya.

Pertanyaan saya adalah bagaimana saya bisa menulis perangkat lunak dan mengujinya tanpa memiliki perangkat keras?

Apakah ada standar yang harus diikuti? Bagaimana Anda melakukannya?

embedded software

— anishkumar
sumber

Bergantung pada seberapa kompleksnya perangkat keras, Anda dapat mencoba simulator. Itu cukup bisa dilakukan jika itu hanya mikro-controller dengan perangkat sederhana. Lebih dari itu dan Anda kurang beruntung di rute itu.

— Mast

6

Cobalah menemukan papan pengembangan untuk perangkat mikro dan perangkat periferal lain yang Anda gunakan, dan coba sambungkan semuanya dengan cara yang paling mirip dengan desain tim perangkat keras Anda. Ini akan menjadi besar & jelek, tetapi Anda harus dapat menyusun sebuah sistem yang cukup dekat dengan hal yang nyata - setidaknya sejauh yang dapat dikatakan oleh firmware Anda ...

— brhans

Paling buruk, jika Anda tidak dapat mensimulasikan perangkat keras dengan benar, ada cara untuk menonaktifkannya. Hanya beberapa minggu yang lalu saya ingin menguji komunikasi jaringan dengan program lain, hanya untuk menemukan itu exit()karena mencoba untuk mmap alamat hardcoded di / dev / mem.

— isanae

1

Sebenarnya lebih disukai, dalam banyak kasus, untuk menggunakan simulator untuk pengembangan perangkat lunak tertanam - lebih mudah untuk di-debug. Masalahnya, tentu saja, adalah bahwa Anda memerlukan simulator yang layak. Kadang-kadang ada yang generik yang bisa diadaptasi, kadang magang yang cerdik bisa menulis satu di hiruk-pikuk pengkodean kafein.

— Hot Licks

34

Tidak memiliki perangkat keras selama tahap awal pengembangan firmware terjadi. Strategi umum untuk menghadapi ini adalah:

Habiskan waktu di muka merancang sistem dengan cermat sebelum Anda menulis kode apa pun. Tentu saja Anda harus melakukan ini, tetapi dalam hal ini bahkan lebih penting daripada biasanya. Jauh lebih mudah untuk men-debug perangkat lunak yang dipikirkan dengan baik daripada kekacauan berbasis pasta.
Memodulasi semuanya dengan benar, meminimalkan antarmuka antar modul. Ini akan membantu mengandung bug pada modul individual, dan memungkinkan pengujian modul individual yang lebih mudah.
Tulis kode dari bawah ke atas, driver yang menyentuh perangkat keras duluan, logika aplikasi tingkat tinggi yang terakhir. Ini memungkinkan menemukan ketidaknyamanan yang dipaksakan oleh arsitektur sejak awal. Jangan takut untuk mengubah arsitektur ketika realitas perangkat keras terungkap, tetapi pastikan semua dokumentasi diperbarui.
Simulasikan. Sebagian besar perusahaan mikrokontroler menyediakan simulator perangkat lunak mikrokontroler mereka. Ini hanya bisa sejauh ini, tetapi masih bisa sangat berguna. Mensimulasikan input dan mengukur output perangkat keras mungkin sulit, tetapi memeriksa logika tingkat yang lebih tinggi dengan cara ini seharusnya tidak terlalu sulit.

Di sinilah desain modular membantu lagi. Jika Anda tidak dapat secara wajar mensimulasikan beberapa interaksi perangkat keras tingkat rendah, Anda menggunakan versi berbeda dari modul yang menyentuh perangkat keras itu tetapi yang meneruskan tindakan simulasi sendiri ke tingkat atas. Level atas tidak akan tahu ini sedang terjadi. Anda tidak akan memeriksa modul tingkat rendah dengan cara ini, tetapi sebagian besar yang lainnya.

Singkatnya, gunakan praktik desing perangkat lunak yang baik, yang tentu saja harus Anda lakukan juga.

— Olin Lathrop
sumber

Ingin menambahkan: dapatkan papan dev (ya, banyak, karena Anda mungkin akan membunuh setidaknya satu ...) di ASAP dan dapatkan driver level rendah di tempatnya. Uji unit sebanyak mungkin kode Anda. Ya, Anda dapat menyatukan kode yang menyentuh perangkat keras. Tidak, Anda tidak dapat sepenuhnya mensimulasikan perangkat keras, tetapi Anda bisa mendapatkan 90% dari fungsi yang benar bahkan sebelum menginstal untuk pertama kalinya. Saya melakukan semua hal di atas pada proyek baru-baru ini, dan kami memiliki fungsionalitas 99% di tempat dan bekerja ketika perangkat keras yang sebenarnya datang. Itu luar biasa.

— CHendrix

13

Tanpa wawasan apa pun yang sedang Anda kembangkan, atau keluarga mikrokontroler yang akan menjadi basis perangkat keras Anda, sebagian besar keluarga mikrokontroler memiliki sistem pengembangan berbiaya rendah yang memiliki serangkaian periferal umum padanya, yang memungkinkan Anda untuk mensimulasikan setidaknya beberapa perangkat keras target Anda.

— Techydude
sumber

1

Sepakat. Saya akan mengatakannya dengan lebih kuat. Dalam situasi seperti ini di mana perangkat lunak harus diselesaikan bersamaan dengan perangkat keras, saya hanya akan menggunakan mikrokontroler yang memiliki papan pengembangan atau evaluasi yang sesuai.

— Steve G

Bahkan jika Anda memiliki wawasan tentang apa yang dikembangkan OP, sebagian besar keluarga mikrokontroler masih memiliki simulator.

— Olin Lathrop

Saya menggunakan kedua metode ini. Namun saya juga mengawasi peralatan uji jalur produksi yang dibutuhkan. Anda dapat berkumpul dengan insinyur produksi dan merancang perangkat keras untuk menguji driver Anda yang kemudian dapat menjadi bagian dari pengujian produksi. Jika Anda beruntung, mereka bahkan dapat membangun perangkat keras untuk papan pengembangan / prototipe sehingga mereka dapat maju dari proses juga. Semuanya tergantung pada bagaimana Anda mengajukan permintaan bantuan ...

— Sendok

Ini adalah jawaban terbaik untuk pertanyaan ini, karena saya selalu memiliki papan dev untuk memprogram fungsi inti terlebih dahulu sebelum mencobanya di pcb.

— lucas92

2

Tergantung pada bagaimana perangkat keras tergantung pada aplikasi yang akan terjadi, Anda bisa mulai mengimplementasikan proyek pada pc standar (Windows, Linux ...). Sebagian besar akses periferal harus diabstraksikan, jadi ini bukan masalah besar untuk mengimplementasikan beberapa fungsi dummy, yang akan diganti nanti. Jika tidak mungkin untuk mensimulasikan beberapa perilaku, Anda setidaknya bisa melakukan mockup sistem (API ...), sehingga implementasi aktual akan berjalan jauh lebih cepat dan lebih jelas, segera setelah perangkat keras siap.

Tentu saja ada banyak hal yang tidak dapat disimulasikan, seperti perilaku waktu nyata atau driver perangkat keras yang kompleks. Di sisi lain, ADC yang didorong oleh interupsi dapat dengan mudah disimulasikan menggunakan utas yang membaca nilai dari file atau port jaringan.

Tentu saja semua ini sangat tergantung pada berbagai faktor:

Bisakah Anda menggunakan toolchain yang sama / serupa pada pengontrol dan pc (mis. Gcc)?
Seberapa tergantung perangkat keras sistemnya?
Seberapa berpengalaman Anda dengan pemrograman pc?

Saya, untuk satu merancang hampir setiap modul firmware pada pc terlebih dahulu.

— erebos
sumber

Sama disini. Beberapa perbedaan antara kompiler (intrinsik, kata kunci khusus, OS sumber tertutup dan tumpukan jaringan tidak cukup kompatibel dengan BSD) dan bug (dengan C ++) memaksa penggunaan besar file pra-termasuk file spesifik dan preprosesor, tetapi kode itu sendiri dapat hampir identik antara DSP dan PC. Untuk versi PC saya dapat menggunakan pengecekan error runtime yang kuat dan berat (CodeGuard) dan kemampuan debuggingnya tidak dapat ditandingi pada platform tertanam. Bonus tambahan adalah bahwa saya dapat memiliki beberapa perangkat virtual tambahan untuk setiap jaringan dan pengujian beban.

— TMSZ

Dengan ketersediaan Raspberry Pi dan BeagleBone, lingkungan pengembangan Anda bisa dengan mudah menjadi lingkungan runtime Anda - tidak ada masalah dengan toolchain, dll. Selain itu, Anda dapat menggunakan valgrind / helgrind, gdb, dll.

— jhfrontz

1

Cobalah untuk mendapatkan simulator untuk chip Anda. Anda harus mensimulasikan semua input yang diharapkan dan beberapa yang tidak terduga juga. Modularisasi / abstrak sejauh yang Anda bisa dan tulis unit test. Jika Anda bisa, tes tersebut dapat menjadi bagian dari kode Anda yang sebenarnya dan itu berubah menjadi fitur (tes mandiri papan).

Jika Anda tidak bisa mendapatkan simulator, abstrak sebanyak yang Anda bisa melalui HAL (lapisan abstraksi perangkat keras). Semua pengemudi berada di belakangnya. Cobalah untuk mengabstraksikan semua rakitan khusus platform di belakang beberapa panggilan fungsi C dan menganggapnya sebagai driver juga. Tulis sisanya sebagai kode C / C ++ portabel dan buatlah HAL tipis untuk x86 dan jalankan di mesin Anda dengan semua case uji.

Dengan begitu, ketika Anda mendapatkan perangkat keras Anda hanya perlu men-debug HAL. Semakin tipis, semakin cepat Anda akan men-debug dan semuanya berfungsi. Ingat bahwa jika Anda menggunakan rakitan khusus platform untuk operasi yang lebih cepat, Anda INGIN SANGAT BANYAK untuk mendapatkan tes yang tepat .

— Ronan Paixão
sumber

Ketepatan bit sangat penting khususnya jika menggunakan DSP titik tetap.

— Ronan Paixão

Ini mungkin atau mungkin tidak berlaku untuk kasus tertentu, tetapi secara umum ketepatan bit memiliki harganya. QEMU baru-baru ini (2 tahun yang lalu) memutuskan untuk mengimplementasikan bit-exact FPU, dan tebak apa yang terjadi pada kinerja ?

— Dmitry Grigoryev

Ketepatan bit tidak begitu penting ketika menggunakan FPU. Hal ini sangat penting jika menggunakan fixed-point, meskipun. Khususnya karena titik tetap perangkat lunak memerlukan pemeriksaan tambahan di mana-mana.

— Ronan Paixão

Yang merupakan hasil dari praktik pengkodean yang buruk. Orang-orang telah belajar untuk mengambil tindakan pencegahan ketika menggunakan a == bperbandingan dengan pelampung, tetapi mereka masih menggunakannya tanpa berpikir dengan angka titik tetap.

— Dmitry Grigoryev

Walaupun praktik pengkodean yang buruk cukup menjadi masalah, ada banyak masalah lain, khususnya pada kasus tepi. Overflow datang ke pikiran dengan cepat, seperti kehilangan presisi , pembulatan , saturasi dan lebar vs bit-shifting . Dengan semua itu, mudah untuk mengabaikan beberapa kehilangan presisi dalam kasus uji umum. Masalahnya adalah ketika aplikasi Anda mencapai kasus yang lebih kecil dan kesalahan berpindah dari fraksional ke bit integer, yang terjadi jika rentang salah perhitungan. Cukup periksa halaman fitur Fixed-Point Designer MATLAB untuk melihat apa lagi yang bisa salah dalam sekejap.

— Ronan Paixão

1

Pertanyaan Anda agak luas. Perangkat Keras (HW) dapat berarti pengembangan ASIC / FPGA kustom penuh, DSP yang diprogram assembler, atau "hanya" sistem tertanam yang khas yang didasarkan pada mikroprosesor off-the-shelf / mikrokontroler / SoC dll. (Tentu saja SoC mungkin juga berisi DSP Anda mungkin ingin memprogram ....). Untuk jumlah penjualan yang tinggi, menjadikannya ASIC tidak biasa.

Tetapi untuk proyek 2 bulan saya berharap ini didasarkan pada beberapa mikrokontroler:

Bagaimanapun, Anda harus menekankan tim perangkat keras untuk memberi Anda prototipe Anda dapat mulai menguji kode Anda sebelum batas waktu absolut - ini mungkin hanya terdiri dari papan pengembangan generik, seperti beberapa orang telah sebutkan, tetapi menurut saya itu adalah milik mereka pekerjaan untuk menyediakan yang tepat untuk Anda, dan berpotensi juga beberapa periferal yang diperlukan / serupa untuk pengujian.

Simulator juga mungkin sampai batas tertentu, tetapi Anda mungkin masih perlu mengkarakterisasi beberapa sensor / data dunia nyata yang mungkin Anda dapatkan. Di sini tim perangkat keras juga perlu setidaknya membantu Anda.

Selain itu, desain perangkat lunak dapat dilakukan dan semua modul tingkat tinggi dapat (dan harus) diimplementasikan dan diuji unit tanpa perangkat keras yang sebenarnya. Idealnya, Anda juga akan mendefinisikan API bersama dengan tim perangkat keras, dan mereka akan memberi Anda fungsi tingkat terendah, sehingga setiap perubahan yang mereka lakukan pada sisi perangkat keras di sana (misalnya hanya mendefinisikan ulang pin port yang mereka gunakan), tidak akan selalu menjadi penting bagi Anda.

Dalam semua kasus, komunikasi adalah kuncinya.

— bluesceada
sumber

0

Ya, Anda dapat Mengembangkan kode Anda untuk papan target Anda sebelum papan mereka bisafactured.

Bagaimana?

Pertama, Anda harus tahu tujuan utama sistem itu. Jadi dari ini Anda dapat memilih controller dengan tepat dari sumber yang luas seperti digikey, mouser.

Dan Pilih simulator seperti Proteus. Ini akan mensimulasikan prosesor / pengontrol yang tepat sekarang Anda dapat memulai pengkodean. Tapi Anda tidak bisa mengharapkan akurasi seperti pada perangkat keras.

— Foton001
sumber

Mengapa downvote? Bolehkah saya tahu apa yang salah dengan jawaban ini?

— Photon001