Saya memiliki 20+ tahun sistem embedded, kebanyakan 8 dan 16 micros. Jawaban singkat untuk pertanyaan Anda sama dengan pengembangan perangkat lunak lainnya - jangan optimalkan sampai Anda tahu Anda perlu, dan kemudian jangan optimalkan sampai Anda tahu apa yang perlu Anda optimalkan. Tulis kode Anda sehingga dapat diandalkan, dapat dibaca dan dipelihara terlebih dahulu. Optimalisasi prematur adalah sebanyak, jika tidak lebih dari, masalah dalam sistem embedded
Ketika Anda memprogram "tanpa membuang sumber daya apa pun.", Apakah Anda menganggap waktu Anda sebagai sumber daya? Jika tidak, siapa yang membayar Anda untuk waktu Anda, dan jika tidak ada, apakah Anda ada hubungannya dengan itu. Sekali pilihan setiap perancang sistem tertanam harus membuat adalah biaya perangkat keras vs biaya waktu rekayasa. Jika Anda akan mengirim 100 unit, gunakan mikro yang lebih besar, dengan 100.000 unit, penghematan $ 1,00 per unit sama dengan 1 tahun pengembangan perangkat lunak (mengabaikan waktu ke pasar, biaya peluang, dll.), Dengan 1 Juta unit, Anda mulai mendapatkan ROI karena terobsesi dengan penggunaan sumber daya, tetapi berhati-hatilah karena banyak proyek yang disematkan tidak pernah mencapai angka 1 juta karena mereka dirancang untuk menjual 1 juta (investasi awal yang tinggi dengan biaya produksi rendah), dan bangkrut sebelum mereka sampai di sana.
Yang mengatakan, hal-hal yang perlu Anda perhatikan dan sadari dengan sistem tertanam (kecil), karena ini akan menghentikannya bekerja, dengan cara yang tidak terduga, tidak hanya membuatnya lambat.
a) Stack - Anda biasanya hanya memiliki ukuran tumpukan kecil dan ukuran bingkai tumpukan sering terbatas. Anda harus waspada dengan pemanfaatan tumpukan Anda setiap saat. Hati-hati, masalah tumpukan menyebabkan beberapa cacat paling berbahaya.
b) Heap - lagi, ukuran heap kecil jadi hati-hati tentang alokasi memori yang tidak beralasan. Fragmentasi menjadi masalah. Dengan dua ini, Anda perlu tahu apa yang Anda lakukan ketika Anda kehabisan - itu tidak terjadi pada sistem besar karena OS disediakan paging. yaitu ketika malloc mengembalikan NULL, apakah Anda memeriksanya dan apa yang Anda lakukan. Setiap mallow membutuhkan cek dan penangan, kode mengasapi? Sebagai panduan - jangan menggunakannya jika ada alternatif. Sebagian besar sistem kecil tidak menggunakan memori dinamis karena alasan ini.
c) Gangguan perangkat keras - Anda harus tahu cara menanganinya dengan cara yang aman dan tepat waktu. Anda juga perlu tahu cara membuat kode masuk kembali yang aman. Sebagai contoh, lib standar C umumnya tidak masuk kembali, jadi sebaiknya tidak digunakan di dalam interrupt handler.
d) Majelis - hampir selalu optimasi prematur. Paling sedikit jumlah (inline) diperlukan untuk mencapai sesuatu yang tidak bisa dilakukan C. Sebagai latihan, tulis metode kecil dalam perakitan kerajinan tangan (dari awal). Lakukan hal yang sama dalam C. Ukur kinerja. Saya yakin C akan lebih cepat, saya tahu itu akan lebih mudah dibaca, dipelihara, dan diperpanjang. Sekarang untuk bagian 2 dari latihan - tulis sebuah program yang berguna di assembly dan C.
Sebagai latihan lain, lihat berapa banyak Linux kernal assembler, setelah itu baca, paragraf di bawah ini tentang kernel linux.
Perlu mengetahui cara melakukannya, bahkan mungkin layak untuk mahir dalam bahasa untuk satu atau dua mikroskopi umum.
e) "register unsigned int variable_name", "register" adalah, dan selalu menjadi, petunjuk bagi kompiler, bukan instruksi, pada awal 70-an (40 tahun yang lalu), masuk akal. Pada tahun 2012, ini merupakan pemborosan penekanan tombol karena kompilernya sangat pintar, dan instruksi mikrokompleks sangat kompleks.
Kembali ke komentar linux Anda - masalah yang Anda miliki di sini adalah bahwa kita tidak berbicara hanya 1 juta unit, kita berbicara 100-an juta, dengan waktu hidup selamanya. Waktu dan biaya teknik untuk mendapatkannya seoptimal mungkin secara manusiawi layak dilakukan. Meskipun contoh yang baik dari praktik rekayasa terbaik, itu akan menjadi bunuh diri komersial bagi sebagian besar pengembang sistem embedded untuk menjadi sama hebatnya dengan yang diperlukan linux kernal.