Flash dan RAM: Eksekusi Kode


13

Baru-baru ini saya mulai mempelajari perakitan dan mengetahui tentang skrip tautan dan detail pemrograman perangkat keras tingkat rendah lainnya. Saya juga belajar sendiri arsitektur komputer dan di suatu tempat saya takut bahwa gambar saya tentang model memori mungkin salah selama ini.

Menurut apa yang saya pahami saat ini, semua kode dan data berada pada memori non-volatil tepat setelah kita 'membakar' biner ke prosesor - RAM yang tidak stabil tidak mengandung apa-apa saat reset. Ketika program mulai 'mengeksekusi', ia melakukannya dari alamat 0x0000 yang hampir selalu (AFAIK) alamat terendah di Flash. Jadi, instruksi terkunci ke bus yang menghubungkan Flash ke inti CPU dan di situlah eksekusi sebenarnya terjadi. Namun, ketika kita berbicara tentang CPU mengambil atau menyimpan data dari memori, kita biasanya berbicara tentang RAM - saya sadar bahwa kita dapat membaca / menulis data dari memori program juga (saya telah melihat ini dilakukan pada AVR) tetapi apakah itu tidak biasa? Apakah karena RAM lebih cepat dari ROM sehingga kami lebih suka menyimpan data di sana?

Jawaban yang diterima untuk pertanyaan ini mengatakan bahwa sebagian besar kode dijalankan dari RAM.

Apakah ini berarti bahwa kode runtime start-up (yang dijalankan sendiri dari Flash) harus menyalin semua opcode program dari Flash ke RAM dan entah bagaimana memetakan alamat dalam Flash untuk menunjuk ke RAM sehingga CPU mengambil opcode dari sana? Apakah mirip dengan proses di mana kita memindahkan bagian data. Dari ROM ke RAM saat startup?

Saya bisa membayangkan ini menjadi lebih sederhana dalam arsitektur von Neumann di mana program dan memori data berbagi bus, tetapi dalam arsitektur Harvard bukankah ini berarti bahwa semua kode dan data harus melewati register CPU terlebih dahulu?

Seperti yang mungkin bisa Anda tebak, saya agak terlalu bingung dengan seluruh bisnis ini. Setelah selalu diprogram pada tingkat abstraksi yang lebih tinggi, saya mudah bermasalah dengan detail seperti itu. Bantuan apa pun dihargai.


2
Dalam mikrokontroler sederhana tidak perlu menyalin dari memori program (sering flash saat ini) ke RAM untuk mengeksekusi.
David

Itu semua karena RAM lebih cepat dari Flash, tetapi karena kehilangan data setelah kehilangan daya, ada memori Flash yang tidak mudah menguap. Ketika daya menyala, data dimuat dari Flash ke RAM dan CPU mulai bekerja, semua itu berulang.
Lazar

Jawaban:


13

Ini tergantung pada perangkat.

RAM dapat dibangun lebih cepat dari Flash; ini mulai menjadi penting dalam kisaran 100MHz.

Mikrokontroler sederhana

Mikrokontroler lambat kecil mengeksekusi langsung dari Flash. Sistem ini biasanya memiliki lebih banyak Flash daripada SRAM.

Sistem midrange

Setelah perangkat Anda semakin cepat maka situasinya sedikit berbeda. Sistem ARM Midrange dapat melakukan itu juga, atau mereka mungkin memiliki bootloader mask ROM yang melakukan sesuatu yang lebih cerdas: mungkin mengunduh kode dari USB atau EEPROM eksternal ke dalam SRAM internal.

Sistem besar

Sistem yang lebih besar, lebih cepat akan memiliki DRAM eksternal dan Flash eksternal. Ini adalah tipikal arsitektur ponsel. Pada titik ini, ada banyak RAM yang tersedia dan lebih cepat daripada Flash, sehingga bootloader akan menyalin dan menjalankannya. Ini mungkin melibatkan menyekopnya melalui register CPU atau mungkin melibatkan transfer DMA jika unit DMA tersedia.

Arsitektur Harvard biasanya kecil sehingga tidak perlu repot dengan fase penyalinan. Saya telah melihat ARM dengan "hybrid harvard", yang merupakan ruang alamat tunggal yang berisi berbagai memori tetapi dua unit pengambilan yang berbeda. Kode dan data dapat diambil secara paralel, asalkan tidak dari memori yang sama. Jadi Anda bisa mengambil kode dari Flash dan data dari SRAM, atau kode dari SRAM dan data dari DRAM dll.


1

RAM umumnya lebih cepat daripada flash, tetapi tidak terlalu penting sampai Anda mencapai kecepatan clock lebih dari 80-100MHz atau lebih - selama waktu akses flash lebih cepat dari waktu yang diperlukan untuk menjalankan instruksi, itu seharusnya tidak masalah.

Konstruksi fisik RAM memungkinkan kita untuk membangun perangkat yang sangat cepat; jauh lebih cepat daripada flash. Pada titik ini, masuk akal untuk menyalin blok kode ke dalam RAM sebelum eksekusi. Ini juga membawa manfaat tambahan bagi pengembang, seperti bisa memodifikasi kode saat runtime.

dalam arsitektur von Neumann di mana program dan memori data berbagi bus tetapi dalam arsitektur Harvard bukankah ini berarti bahwa semua kode dan data harus melewati register CPU terlebih dahulu?

Belum tentu. Di sinilah pengalamatan virtual masuk. Alih-alih kode program merujuk ke alamat RAM perangkat keras mentah, itu sebenarnya merujuk ruang alamat virtual. Blok ruang alamat virtual dipetakan ke perangkat memori fisik, yang dapat berupa RAM, ROM, flash, atau bahkan buffer perangkat.

Misalnya, ketika Anda merujuk alamat 0x000f0004 pada mikro, Anda mungkin membaca alamat 0x0004 dari flash. The alamat virtual adalah 0x000f0004, tapi alamat fisik hanya 0x0004 - seluruh ruang alamat 0x000fxxxx dipetakan ke perangkat 4KB memori fisik. Ini hanya contoh, tentu saja, dan metode mengelola dan mengatur ruang alamat virtual sangat berbeda di seluruh arsitektur.

Dengan demikian, ketika Anda mengatakan bahwa "program mulai mengeksekusi [...] dari alamat 0x0000 yang hampir selalu merupakan alamat terendah dalam flash", Anda tidak dijamin benar. Bahkan, banyak mikrokontroler mulai dari 0x1000.


3
Saya akan mengatakan perbedaannya menjadi relevan sekitar 20-40MHz, bukan 100MHz, karena sebagian besar perangkat flash yang saya lihat mulai membutuhkan kondisi tunggu di sekitar titik itu. Dalam banyak kasus, kode flash akan menyertakan sirkuit sehingga setiap pengambilan akan mengambil beberapa kata instruksi, sehingga untuk banyak jenis kode "penalti" untuk lari dari flash hanya sekitar 5-10%, tetapi untuk beberapa jenis lain kode (misalnya dengan banyak lompatan) hukumannya mungkin jauh lebih parah.
supercat

Itu bukan pengalamatan virtual, itu dipetakan memori I / O (wilayah memori memetakan ke I / O menggunakan periferal, nama pada banyak MCU adalah "Static Memory Controller"). Tentu saja, I / O menjangkau ke memori lain, jadi kita kadang-kadang tidak menganggapnya sebagai I / O. Tapi itu jelas bukan pemetaan memori virtual.
Ben Voigt

1

Apa yang Anda katakan tidak sepenuhnya benar atau salah. Ada beberapa skenario untuk ini.

Itu tergantung pada apakah Anda memprogram pada perangkat keras mentah atau pada perangkat keras yang diinstal dengan OS.

Sistem operasi Anda yang berjalan pada komputer tujuan umum mengambil kode dari HDD dan menyimpannya pada RAM untuk akses yang lebih cepat. Jika prosesor Anda mencoba mengambil langsung dari HDD secara terus-menerus, maka operasinya akan jauh lebih lambat karena kecepatan ketidakcocokan antara keduanya. Jadi RAM Anda ikut bermain di mana sepotong kode berulang Anda disimpan untuk akses yang lebih cepat. Dan itu terlalu jauh dibuat pada memori cache prosesor untuk membuatnya lebih cepat.

Sekarang ketika Anda bekerja pada pengontrol mikro, itu benar-benar tergantung pada Anda di mana Anda menemukan data Anda pada chip. Jika data statis Anda mungkin ingin menemukannya pada memori kode yang akan menghemat RAM Anda yang relatif jauh lebih kecil dari memori Kode. Dalam bahasa C ketika Anda menginisialisasi datatype menggunakan statis atau dalam beberapa data awalan const kompiler akan disimpan pada memori kode atau yang lain akan disimpan dalam RAM. Dan dalam perakitan Anda langsung menggunakan DB (Tentukan Byte dalam kasus Basic 8051) untuk menginisialisasi data di lokasi tertentu. Sekarang bahkan di beberapa pengontrol seperti PIC ARM Anda dapat menulis ROM dalam waktu berjalan tetapi mengambil data akan memakan banyak waktu.

Plus ada boot loader hardware di tingkat menengah & pengontrol canggih yang memberi tahu pengontrol atau prosesor tempat menjalankan kode start up atau itu sendiri adalah kode start up yang sebenarnya tersegmentasi ke dalam memori Jadi ada banyak kemungkinan karena kemajuan , Saya lebih suka mengatakan advnacement hybrid di industri yang salah mengartikan seluruh konsep RAM ROM konvensional & memori. Jadi pada dasarnya kebingungan Anda valid.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.