Parameter untuk pemilihan sistem Operasi, memori dan prosesor untuk sistem tertanam?

Saya sedang mengembangkan perangkat lunak sistem waktu nyata tertanam (dalam bahasa C). Saya telah merancang arsitektur s / w - kita tahu berbagai objek diperlukan, interaksi diperlukan antara berbagai objek dan komunikasi IPC antara tugas. Berdasarkan informasi ini, saya perlu memutuskan persyaratan sistem operasi (RTOS), mikroprosesor dan ukuran memori.

(Kemungkinan besar saya akan menggunakan Quadros, seperti yang telah disarankan oleh klien berdasarkan pengalaman mereka sebelumnya dalam proyek serupa)

Tapi saya bingung harus mulai dari mana, karena pilihan yang satu bisa berdampak pada pemilihan yang lain.

Bisakah Anda juga membimbing saya pada parameter untuk mempertimbangkan memperkirakan kebutuhan memori dari desain s / w (batas bawah dan batas atas persyaratan memori)?

(Biaya komponen dapat diabaikan untuk evaluasi ini)

— James
sumber

Tentunya Anda dapat mencari ukuran yang terinstal dari masing-masing OS pada setiap arsitektur, dan memperkirakan dan menambahkan ukuran data yang Anda simpan dalam RAM. Yang tinggal menyisakan ukuran perangkat lunak Anda yang terinstal, bukan?

— dmckee

Itu juga terjadi pada saya bahwa Anda mungkin benar-benar menemukan lebih banyak keahlian dalam masalah ini pada Stack Overflow. Namun, saya tidak memiliki mojo untuk memilih untuk dimigrasi ... Anda dapat memanggil moderator untuk meminta bantuan jika Anda tidak mendapatkan respons yang baik di sini.

— dmckee

@ dmckee, Berdasarkan komentar Anda, inilah pemahaman saya: - mulai dengan pemilihan prosesor pertama - hitung ukuran OS pada masing-masing untuk mendapatkan persyaratan memori - Tambahkan ukuran s / w untuk mendapatkan total memori yang diperlukan Apakah pemahaman ini benar? Tetapi OS waktu nyata dapat dikonfigurasi untuk mendapatkan hanya komponen yang dibutuhkan. Dalam hal ini, bukankah akan sulit untuk bereksperimen dan menghasilkan persyaratan memori dasar?

— James

Jawaban:

Memori lebih murah daripada waktu Anda, setidaknya untuk beberapa sistem pertama yang diproduksi. Isi maksimal semua yang Anda bisa ke papan untuk sistem prototipe Anda dan instal kode Anda. Anda dapat membeli papan yang kurang populer untuk produksi tetapi sekarang Anda menginginkan sumber daya yang besar.

Alokasikan tumpukan yang jauh lebih besar daripada yang Anda pikir Anda perlukan dan isi dengan tumpukan teks berulang, seperti nama utas yang memiliki tumpukan itu. Berapa banyak dari itu yang akan ditulis akan menunjukkan kepada Anda berapa banyak tumpukan setiap thread yang digunakan. Terapkan faktor keamanan yang nyaman ke nomor itu untuk mendapatkan alokasi akhir Anda.
Alokasikan banyak tumpukan. Lebih baik lagi, daripada menggunakan tumpukan pada saat dijalankan, pra-alokasikan tumpukan saat start-up ke satu (atau beberapa) kumpulan memori dari (atau beberapa) ukuran blok tetap. Alokasikan dan alokasikan hanya dari mereka yang menjalankan waktu.
Catat penggunaan memori ke dalam buffer besar (atau bundar), atau catat ID pemohon ke dalam pembukaan yang berbeda dari ruang data aktual blok - apa pun yang akan meninggalkan jejak Anda dapat menemukan nanti untuk membantu menganalisis permintaan memori, kelaparan memori, atau crash.
Jauhkan penyangga keluar dari tumpukan Anda sehingga overruns tidak akan menghentikan semuanya, atau lebih buruk lagi, mengeluarkan transfer kendali liar.
Mengalahkan sistem. Masukkan melalui skenario apa pun yang menurut Anda akan menekankan persyaratan tumpukan dan memori. Daftarkan beberapa pengguna tipikal dan non-tipikal untuk melakukan hal yang sama. Beberapa dari mereka akan mencoba melakukan hal-hal yang tidak Anda antisipasi. Dorong itu.

Ketika Anda sudah melakukan semua itu, Anda akan memiliki pegangan yang jauh lebih baik pada kebutuhan memori Anda daripada yang bisa Anda dapatkan sekarang.

(Edit; komentar tidak tersedia untuk saya)

James:

'Kami ingin mendapatkan perkiraan kasar dari perangkat keras dan biaya yang terlibat pada tahap ini. Apakah Anda pikir ini mungkin? '

Jawaban singkatnya adalah ya, RAM kemungkinan merupakan bagian kecil dari biaya perangkat keras Anda, jadi teruskan dan perkirakan - Anda harus tetap dekat.

Sebagai pemeriksaan kasar, Anda mungkin mendapatkan perkiraan kasar untuk persyaratan memori statis - kode dan data statis - dengan menulis dan menyusun beberapa fungsi untuk mendapatkan rasio sumber-jalur kasar ke memori, dan ekstrapolasi. Anda akan memerlukan penghitungan kasar dan beberapa perkiraan waktu yang berpendidikan tentang bagaimana desain Anda akan berkembang menjadi fungsi dan garis kode. Dapatkah Anda membuat tebakan yang terpelajar tentang penggunaan waktu berjalan struktur dinamis desain Anda - tumpukan dan tumpukan atau kolam? Saya mungkin setidaknya akan menggandakan atau melipatduakan perkiraan saya.

Bisakah Anda menerapkan sistem pada komputer yang ada, fungsi hubungan pendek (dengan mengkompilasi kode dengan pengembalian pendek daripada # ifdef'ing it out) yang tidak masuk akal di lingkungan itu?

Jika Anda benar-benar perlu memperkirakan tanpa banyak mengimplementasikan, saya pikir Anda akan terjebak dengan ekstrapolasi.

— JRobert
sumber

@Jrobert, saya setuju ini pendekatan yang bagus untuk mendapatkan perkiraan memori. saya harus mengimplementasikan kode dan menyiapkan lingkungan pengembangan untuk melakukan percobaan ini. Sejauh ini, hanya desain s / w telah dilakukan dan kami ingin mendapatkan perkiraan kasar dari perangkat keras dan biaya yang terlibat pada tahap ini. Apakah Anda pikir ini mungkin?

— James

@Jrobert, Bisakah Anda menjelaskan apa yang Anda maksudkan dengan menerapkan sistem pada komputer yang ada? Saya belum memilih OS dan lingkungan pengembangan. Apakah maksud Anda memperkirakan ukuran kernel akan lebih mudah untuk memprediksi dan menggunakan prosedur Anda pada kompiler apa saja, OS apa pun untuk menentukan memori yang digunakan oleh aplikasi dummy yang secara kasar menyimulasikan aplikasi sebenarnya?

— James

Intinya ya. Untuk memperkirakan ukuran kode, Anda harus mulai dari suatu tempat. Mengapa tidak mesin pengembangan Anda? Jika target Anda akan berbeda secara signifikan, DSP, misalnya, daripada pada titik tertentu Anda harus memperkirakan bagaimana ukuran kode target Anda akan dibandingkan dengan sistem pengembangan, tetapi setidaknya Anda akan memiliki beberapa ide dari melihat beberapa nilai fungsi dari ukuran kode. Tapi saya masih bertanya-tanya apakah / mengapa, pada harga memori saat ini, Anda merasa biaya sistem akan cukup sensitif terhadap ukuran kode yang Anda perlukan untuk menjalani latihan ini?

— JRobert

Saya pikir masuk akal untuk menunda keputusan ukuran memori karena biaya memori jauh lebih kecil daripada OS atau biaya prosesor. Bisakah Anda berbagi beberapa pemikiran tentang parameter untuk dipikirkan dalam pemilihan prosesor dan Sistem Operasi?

— James

Apakah Anda memerlukan semua kecepatan yang dapat Anda peroleh (DSP, mungkin) atau akankah komputer papan tunggal yang biasa tersedia mendukung produk Anda? Dengan papan x86, Anda mungkin sudah memiliki toolset yang mumpuni pada mesin pengembangan Anda. Anda mungkin perlu relocater embedded-system linker untuk mengganti hoster (unix / MacOS / Windows) dan debugger jarak jauh, jika belum disediakan. Apakah papan akan tersedia untuk masa mendatang produk? Atau apakah produk itu hanya satu kali atau jangka pendek? Maka perangkat keras lebih murah daripada Anda; dapatkan semua kemampuan yang Anda bisa untuk membuat desain & pemeliharaan lebih mudah.

— JRobert

Sepertinya Anda sudah membuat beberapa pilihan desain.

kita tahu berbagai objek diperlukan, interaksi diperlukan antara berbagai objek dan komunikasi IPC antara tugas.

Anda memerlukan OS multi-ulir dan UC yang akan menjalankannya, biasanya berarti Anda ingin membidik prosesor dengan MMU. Opsi OS adalah hal-hal seperti Quadros, QNX, linux, meringis, dll.

Berdasarkan apa yang "objek" Anda (modul adalah istilah yang lebih baik untuk C :)) lakukan, Anda mungkin dapat menentukan jenis arsitektur apa yang Anda butuhkan. Apakah lengkungan 16bit cukup? butuh lebih banyak memori atau bekerja dengan angka yang lebih besar maka apakah 32bit jawaban yang tepat? banyak pekerjaan floating point? maka Anda mungkin membutuhkan prosesor dengan FPU. Apakah banyak DSP suka bekerja? mungkin Anda memerlukan DSP atau UC dengan instruksi seperti DSP atau co-proc. Menjalankan tampilan grafis? memerlukan SoC dengan pengontrol LCD bawaan atau berharap untuk melakukannya secara eksternal. Melakukan grafis 2D yang berat? memerlukan SoC dengan beberapa percepatan grafis.

Buatlah daftar fitur yang Anda butuhkan dan perkirakan berapa banyak kode Anda termasuk dalam kategori seperti operasi integer, perulangan, operasi floating point, operasi grafis, operasi DSP, dll.

Ini akan memungkinkan Anda untuk mengklasifikasikan tingkat perangkat yang Anda butuhkan. Untuk beberapa arsitektur Anda dapat mengkompilasi lintas beberapa kode menggunakan GCC dan menirunya menggunakan qemu di atas linux. Ini mungkin hanya layak jika Anda perlu menguji kinerja algoritma kritis pada arsitektur tertentu. Ini dapat membantu Anda mengukur kecepatan yang Anda butuhkan untuk aplikasi Anda.

Pertimbangan kedua harus penggunaan daya dan dukungan untuk manajemen daya. Dikombinasikan dengan kinerja yang diperlukan, Anda dapat memilih DSP, UC, prosesor aplikasi, dll.

Seperti yang orang lain katakan saya tidak akan khawatir tentang penggunaan memori, hanya bertujuan besar, seringkali ukuran ram berbeda pin yang kompatibel sehingga Anda hanya dapat memotong ram untuk produksi. Satu-satunya pertanyaan nyata untuk dijawab di sini adalah:

* Seberapa besar ruang alamat yang saya butuhkan? 16bit? 32bit? dll

* Apakah saya memerlukan ram eksternal atau ram internal UC akan cukup? <- jawab ini setelah Anda memilih arsitektur dan bisa pergi berburu SoC.

Untuk sebagian besar memilih di antara prosesor di kelas yang sama adalah "perang suci" alias di pasar 32bit risc beberapa akan kembali ARM, beberapa akan kembali coldfire, beberapa bahkan mungkin mendukung PIC32. Pada akhirnya mungkin ada yang akan berhasil. Anda harus memilih berdasarkan SoC yang tersedia dengan periferal yang diperlukan, kemudahan pengembangan (seberapa baik rantai alat) dan biaya.

Hal yang sama berlaku untuk pilihan OS, linux vs QNX vs quadros adalah pilihan untuk sebagian besar aplikasi, biasanya jawaban terbaik adalah yang paling Anda miliki. Sekalipun sedikit lebih mahal, pengurangan waktu pengembangan seringkali mengimbangi biaya pembangunan. Pastikan OS memiliki fitur yang diperlukan, pustaka bersama, komunikasi antar-proses, pipa, apa pun yang Anda butuhkan.

Sebagai aturan umum saya akan memilih arsitektur Anda terlebih dahulu. Ini akan memiliki dampak yang jauh lebih tinggi pada kinerja perangkat Anda daripada sistem operasi. Selain itu sistem operasi di ruang ini sering didukung pada banyak arsitektur. Juga OS yang lebih baik adalah POSIX compliant, ditulis dengan benar sebagian besar kode Anda harus dapat dijalankan pada banyak OS.

Jangan merasa buruk jika Anda harus melakukan beberapa upaya untuk membuat pilihan yang benar. Anda mungkin menemukan inti yang sangat sesuai dengan kebutuhan kode Anda, tetapi setelah beberapa penelitian menemukan bahwa itu tidak mendukung beberapa fitur minor yang Anda butuhkan, atau tidak ada SoC tersedia dengan periferal yang Anda butuhkan, atau bahkan benda itu dipesan kembali. selama 6 bulan. Pastikan setelah membuat pilihan awal bahwa Anda meneliti bagaimana desain akan datang bersama-sama berdasarkan pada bagian itu sehingga Anda melihat batu sandungan sekarang daripada setengah jalan melalui pengembangan.

— Menandai
sumber