Bagaimana Anda menentukan berapa banyak flash / RAM yang Anda butuhkan untuk mikrokontroler?

24

Katakanlah Anda memulai proyek tertanam dengan beberapa fungsi yang diketahui. Ketika Anda memilih mikrokontroler, bagaimana Anda memilih berapa banyak RAM yang Anda butuhkan?

Apakah Anda menggunakan papan pengembang dan kode proyek Anda terlebih dahulu dan kemudian melihat berapa banyak memori yang Anda gunakan dan kemudian pilih mikrokontroler yang sesuai yang sesuai dengan memori itu?

Apakah Anda hanya memilih mikrokontroler gemuk untuk prototipe dan kemudian menurunkan setelah Anda memiliki produk yang berfungsi?

Apakah Anda hanya memilih sesuatu yang Anda yakin akan cukup dan jika Anda kehabisan ruang, cukup tingkatkan ke kepadatan memori yang lebih tinggi jika tidak, Anda hanya mempertahankan mikrokontroler yang ada?

Apa yang dianggap sebagai praktik yang baik?

— efox29
sumber

Tampak bagi saya bahwa seharusnya dimungkinkan, dari sudut pandang teoritik informasi, untuk memperkirakan kebutuhan RAM hingga dalam urutan besarnya (gaya penalaran dimensi), dari spesifikasi tugas. Hmmm ...

— Lyndon White

Jika Anda menggunakan perpustakaan, Anda dapat meneliti jejak memori mereka. Dengan kode Anda sendiri, Anda harus menggunakan pengalaman. Bandingkan proyek baru dengan yang lama dan tentukan apakah Anda mengharapkannya lebih besar atau lebih kecil.

— jwsc

20

Secara pribadi untuk proyek hobi saya cenderung menggunakan mikrokontroler paling kuat di keluarga dengan jejak yang benar. Saya kemudian mengembangkan PCB, menulis beberapa kode dan menghasilkan prototipe.

Ini memiliki keuntungan bahwa saya tahu sejumlah kecil mikrokontroler cukup baik, jadi saya dapat dengan cepat membuat prototipe tanpa harus membaca seluruh lembar data. Saya juga punya papan breakout dan templat kode untuk mereka.

Jika berfungsi dan saya membuat lebih dari beberapa, saya kemudian membeli mikrokontroler termurah yang memiliki periferal yang tepat dan memori yang cukup untuk apa pun yang saya kodekan sebelumnya. Ini dapat mengganggu jika register internal berubah (terjadi pada PIC) atau jika salah satu mikrokontroler memiliki periferal tambahan yang perlu dinonaktifkan untuk membuat kode berfungsi.

Namun untuk tujuan produksi ini akan memungkinkan Anda mencukur jumlah yang wajar dari setiap unit.

— David
sumber

Untuk proyek pribadi saya, saya cenderung menggunakan pendekatan yang serupa. Metode yang sama juga merayap masuk ke kantor bersama saya. Ini tidak salah, ia bekerja, tetapi apakah ada cara yang lebih baik dll. Menghargai input!

— efox29

Pasti akan ada cara yang lebih baik di lingkungan "nyata", mari kita tunggu jawaban lain!

— David

Secara relatif. Berkembang di kotak pasir besar, dan kurangi nanti. Waktu Anda akan menghemat akan lebih dari menutupi $ 4 ekstra yang Anda habiskan per mikrokontroler untuk dikembangkan. Ini berfungsi untuk lebih dari sekadar hal-hal tingkat hobi - dan pada kenyataannya bahkan lebih penting. Gambar 12 orang menunggu perubahan agar pengontrol yang lebih besar tidak terjadi !!

— Scott Seidman

13

Tentu saja, untuk prototipe buatan sendiri mungkin merupakan rekomendasi yang baik untuk memulai dengan yang paling kuat dari semua mikros kompatibel dan turunkan setelahnya.

Namun jika Anda ingin memenangkan penawaran, Anda harus memberi tahu pelanggan harga sebelum Anda memiliki uang untuk mengimplementasikan apa pun.

Oleh karena itu, praktik yang baik adalah menuliskan semacam spesifikasi sebelum Anda memulai pemrograman. Anda tahu apa yang ingin Anda lakukan, dan Anda harus menuliskan bagaimana Anda akan melakukannya.

"Bagaimana" ini juga termasuk memikirkan tentang desain perangkat lunak, menjawab pertanyaan seperti:

Apakah Anda memerlukan Sistem Operasi? Yang mana? Sumber daya apa yang dibutuhkan?
Apakah Anda ingin memiliki arsitektur berlapis? Ini membutuhkan antarmuka, yang dapat mengkonsumsi RAM
Perpustakaan apa yang sudah tersedia dan berguna / diperlukan untuk tujuan Anda, dan berapa banyak memori yang mereka butuhkan (dokumentasi perpustakaan yang baik menjawab ini berdasarkan setidaknya satu referensi membangun)?
Struktur dan variabel apa yang harus Anda terapkan untuk driver Anda sendiri dan aplikasi Anda?

Menyimpulkan semua nilai itu memberi Anda perkiraan kasar. Seberapa jauh Anda bisa percaya itu tergantung pada seberapa rinci analisis Anda, dan itu tergantung pada pengalaman Anda :-)
Menambahkan margin minimal 30.,50% dari estimasi Anda tentu merupakan ide yang bagus.

Setelah produk Anda selesai dan Anda memiliki sekitar 80..90% RAM yang digunakan, Anda dapat yakin bahwa pilihan Anda benar - setidaknya mengenai RAM.

— mik
sumber

2

Re: "80..90% RAM sedang digunakan". Praktik standar adalah untuk memastikan bahwa Anda hanya menggunakan utilisasi maksimum 50% pada CPU dan memori untuk dapat mengakomodasi peningkatan di masa depan dan perbaikan bug.

— Dunk

1

@Dunk: Tergantung pada bisnis. Di Otomotif, 80% dari semua sumber daya (CPU, RAM, Flash) di SOP diterima secara umum. Dalam, misalnya, barang elektronik konsumen murah bahkan mungkin lebih: Seberapa besar kemungkinan untuk memiliki peningkatan dalam sistem dengan masa hidup hanya 2-3 tahun?

— mic

@Dunk: Saya bisa saja salah, tetapi sepertinya Anda terbiasa dengan perangkat lunak gaya desktop dengan memori dinamis dan semua ketidakpastian yang menyertainya. Sebagian besar aplikasi tertanam mengalokasikan semuanya secara statis. Dijamin tidak ada kebocoran memori. Maka Anda dapat menggunakan tepat 100% dan baik-baik saja selamanya selama Anda tidak memodifikasinya. Tentu saja, itu hanya berfungsi jika Anda memiliki tumpukan yang terpisah dari RAM Anda yang bekerja atau jika Anda tahu persis bagaimana tumpukan akan berperilaku setiap saat. Sebaiknya sisakan sedikit ruang untuk itu, tetapi 10-20% cukup mudah untuk apa yang telah saya lakukan.

— AaronD

Masalah yang lebih besar dalam perangkat lunak tertanam adalah pointer jahat, buffer overruns, dibagi dengan nol, dan hal-hal seperti itu. Beberapa MCU dapat mengeluarkan pengecualian dalam perangkat keras, mirip dengan interupsi, tetapi semua yang saya gunakan akan dengan ceria melanjutkan seolah-olah tidak pernah terjadi apa-apa. Akan ada semacam hasil, tetapi mungkin bukan itu yang Anda harapkan, jadi Anda harus memeriksanya. Beberapa hal, seperti aritmatika over / underflow, mudah untuk diperiksa dan diperbaiki segera; hal-hal lain, seperti pointer nakal, dapat benar-benar diperhatikan sampai fungsi yang bekerja selama bertahun-tahun memutuskan untuk meledak.

— AaronD

3

Apakah Anda ingin menargetkan 80% target atau 50% target akan tergantung pada pelanggan Anda. Dengan spesifikasi tetap & hanya perbaikan bug yang diperlukan, 80% baik-baik saja. Spek tidak dapat diandalkan, creep fitur yang diharapkan, dan margin yang cukup besar sehingga memungkinkan Anda membayar ekstra untuk ruang kepala lebih banyak. Kami pernah membeli mikro-controller 2x sebanyak yang kami butuhkan dan memilih yang overclock untuk memberi kami kinerja yang kami butuhkan, yang jauh lebih murah daripada desain ulang PCB untuk chip yang lebih kuat.

— Mark Booth

3

Kalau saja mungkin untuk membuat kode sistem tertanam Anda terlebih dahulu dan kemudian membangun perangkat keras. Itu akan membuat hidup semua orang lebih mudah. Sayangnya, itu juga berarti tenggat waktu Anda di luar jendela. Biasanya perangkat keras harus dirancang jauh sebelum perangkat lunak dilakukan karena bagian-bagian perangkat keras seringkali memiliki waktu tunggu yang lama.

Dengan demikian, pengembang sw yang tertanam biasanya perlu memperkirakan kebutuhan memori dan CPU program mereka. Langkah pertama Anda harus mencoba dan meyakinkan orang-orang perangkat keras untuk memberi Anda mikrokontroler / CPU paling kuat dengan RAM sebanyak mungkin. Itu jarang berhasil karena mereka memiliki persyaratan tujuan mereka sendiri, tetapi sesekali Anda beruntung.

Jika itu tidak berhasil, maka hal berikutnya yang akan Anda lakukan adalah desain perangkat lunak tingkat tinggi dan memecah modul menjadi fungsionalitas. Anda kemudian akan memperkirakan garis kode untuk setiap fungsi untuk setiap modul dalam sistem. Anda kemudian dapat menggunakan rumus untuk mengonversi baris kode ke perkiraan rata-rata memori kode. Anda juga akan menyelidiki persyaratan memori yang tidak biasa (seperti array besar) dan menambahkan beberapa perkiraan untuk mengakomodasi itu. Kemudian tambahkan beberapa persentase di atas total itu untuk menutupi apa pun yang Anda lewatkan. Kemudian gandakan bahwa untuk memenuhi persyaratan pemanfaatan 50% khas.

Ya, itu butuh waktu. Ya, perlu untuk melewati semua rintangan karena mengubah perangkat keras benar-benar sulit setelah dibangun.

— Dunk
sumber

Di mana kita dapat menemukan rumus untuk mengubah baris kode ke memori kode?

— EasyOhm

Yang itu tergantung pada bahasa dan kompiler apa yang Anda gunakan. Jika Anda menggunakan Assembler satu baris kira-kira sama dengan satu kata memori (apa pun ukuran kata chip Anda). Jika Anda menggunakan C mungkin sekitar 3-5 kata per baris dan jika Anda menggunakan C ++ atau sesuatu yang lebih kompleks mungkin masih jauh lebih banyak. Hal terbaik untuk dilakukan adalah mengkompilasi beberapa program yang ditulis dalam bahasa itu dan membandingkan baris kode dengan memori kode untuk mendapatkan rata-rata.

— Dakkaron

2

Secara umum, vendor mikrokontroler menaruh berbagai memori dalam perangkat mereka yang cocok untuk aplikasi tipikal. Jadi, jika Anda hanya memerlukan beberapa pin I / O dan satu SPI dalam perangkat footprint kecil, Anda tidak akan menemukan apa pun yang dikirimkan dengan 500 kBytes Flash dan 64 kBytes RAM. Dengan perangkat yang lebih besar, yang lebih dekat ke paket SoC, bahkan yang terkecil hampir pasti cukup besar kecuali jika Anda berencana untuk melakukan sejumlah angka serius seperti pemrosesan gambar.

Dalam lingkungan profesional kunci untuk memilih mikrokontroler yang tepat adalah dengan menggunakan data historis. Anda akan memiliki catatan tentang proyek lain yang telah Anda kembangkan dan tahu apa memori dan sumber daya silikon lain yang diperlukan untuk mengimplementasikan setiap fitur. Anda akan tahu apa yang diharapkan dilakukan oleh produk dan oleh karena itu memiliki daftar fitur yang baik dan dapat dengan cepat dan akurat menghitung sumber daya yang perlu disediakan oleh mikrokontroler. Mencoba menebak kebutuhan sumber daya dari spesifikasi desain di muka (dikembangkan pada awal proyek ketika sedikitnya informasi tentang sistem tersedia) tidak dapat diandalkan pada saat terbaik dan hanya insinyur yang sangat berpengalaman, yang telah membangun sebuah komprehensif database data historis di kepala mereka sendiri, akan memiliki segala jenis keberhasilan dalam menggunakan metode ini.

Banyak perusahaan telah mengadopsi pendekatan 'Agile' untuk perangkat lunak dan desain elektronik, yang melibatkan pembuatan 'perpustakaan' papan fitur kecil (misalnya papan RS-485, papan ADC, dll.) Bersama dengan papan platform generik yang menjadi tuan rumah mikrokontroler , dengan cara yang mirip dengan menggunakan dev-kit dan plug-in. Suatu produk kemudian dapat diujicobakan dengan cepat (dalam beberapa jam) dengan memilih dan menghubungkan set board yang diperlukan untuk fitur. Perangkat lunak ini dirakit dengan cara yang sama dari modul perpustakaan dan dapat porting dan diuji dengan cepat. Setelah ukuran bagian hardware-spesifik dari kode diketahui itu biasanya cukup untuk memilih bagian terkecil yang akan berisi itu. Pengecualian adalah yang disebutkan di atas di mana fungsi perangkat melibatkan data besar atau algoritma yang sangat kompleks. Metode ini memberikan

(Keuntungan lain dari pendekatan Agile adalah memungkinkan pengembangan perangkat lunak dan elektronik dilakukan secara paralel, dengan desain elctronics menjadi latihan dalam mengintegrasikan set papan fitur dan melakukan EMC yang relevan dan hal-hal sulit lainnya pada saat yang sama dengan perangkat lunak aplikasi sedang dikembangkan pada rakitan protoype. Beberapa porting dan integrasi masih diperlukan, tetapi hal ini dilakukan ketika perangkat lunak dan elektronik yang berfungsi keduanya tersedia.)

— Pai Anjing Jahat
sumber