Bootloader adalah program yang berjalan di mikrokontroler untuk diprogram. Ia menerima informasi program baru secara eksternal melalui beberapa sarana komunikasi dan menulis informasi itu ke memori program prosesor.
Ini berbeda dengan cara normal memasukkan program ke dalam mikrokontroler, yaitu melalui perangkat keras khusus yang dibangun ke dalam mikro untuk tujuan itu. Pada PIC, ini adalah antarmuka seperti SPI. Jika saya ingat benar, AVR menggunakan Jtag, atau setidaknya beberapa dari mereka melakukannya. Either way, ini memerlukan beberapa perangkat keras eksternal yang menggoyangkan pin pemrograman tepat untuk menulis informasi ke dalam memori program. File HEX yang menggambarkan konten memori program berasal dari komputer tujuan umum, jadi perangkat keras ini terhubung ke komputer di satu sisi dan pin pemrograman khusus mikro di sisi lain. Perusahaan saya membuat programmer PIC antara lain sebagai sampingan, jadi saya cukup akrab dengan proses ini pada PICs.
Poin penting dari pemrograman eksternal melalui perangkat keras khusus adalah ia berfungsi terlepas dari isi memori program yang ada. Mikrokontroler memulai dengan memori program terhapus atau dalam keadaan tidak dikenal, sehingga pemrograman eksternal adalah satu-satunya cara untuk membuat program pertama menjadi mikro.
Jika Anda yakin tentang program yang ingin Anda muat ke dalam produk Anda dan volume Anda cukup tinggi, Anda dapat meminta pabrikan atau distributor program chip untuk Anda. Chip disolder ke papan seperti chip lainnya, dan unit siap untuk pergi. Ini bisa cocok untuk sesuatu seperti mainan, misalnya. Setelah firmware selesai, cukup banyak dilakukan, dan akan diproduksi dalam volume besar.
Jika volume Anda lebih rendah, atau yang lebih penting, Anda mengharapkan pengembangan firmware dan perbaikan bug yang sedang berlangsung, Anda tidak ingin membeli chip yang sudah diprogram. Dalam hal ini chip kosong dipasang di papan tulis dan firmware harus dimuat ke chip sebagai bagian dari proses produksi. Dalam hal ini jalur pemrograman perangkat keras harus tersedia entah bagaimana. Ini bisa melalui konektor eksplisit, atau bantalan pin pogo jika Anda bersedia membuat fixture uji produksi. Seringkali produk tersebut harus diuji dan mungkin dikalibrasi pula, sehingga biaya tambahan penulisan program ke prosesor biasanya minimal. Terkadang saat prosesor kecil digunakan, firmware uji produksi khusus pertama kali dimuat ke dalam prosesor. Ini digunakan untuk memfasilitasi pengujian dan kalibrasi unit, maka firmware yang sebenarnya dimuat setelah perangkat keras dikenal baik. Dalam hal ini ada beberapa pertimbangan desain sirkuit untuk memungkinkan akses ke jalur pemrograman cukup untuk proses pemrograman untuk bekerja tetapi juga tidak terlalu merepotkan sirkuit. Untuk detail lebih lanjut tentang ini, lihat mypenulisan pemrograman dalam sirkuit .
Sejauh ini bagus, dan tidak perlu bootloader. Namun, pertimbangkan sebuah produk dengan firmware yang relatif kompleks yang Anda inginkan dapat diperbarui di lapangan atau bahkan memungkinkan pelanggan akhir untuk meningkatkan. Anda tidak dapat mengharapkan pelanggan akhir untuk memiliki gadget pemrogram, atau tahu cara menggunakannya dengan benar bahkan jika Anda menyediakannya. Sebenarnya salah satu pelanggan saya melakukan ini. Jika Anda membeli opsi penyesuaian bidang khusus mereka, Anda mendapatkan salah satu programmer saya dengan produk.
Namun, dalam kebanyakan kasus Anda hanya ingin pelanggan menjalankan program pada PC dan memperbarui firmware secara ajaib. Di sinilah bootloader masuk, terutama jika produk Anda sudah memiliki port komunikasi yang dapat dengan mudah berinteraksi dengan PC, seperti USB, RS-232, atau ethernet. Pelanggan menjalankan program PC yang berbicara dengan bootloader yang sudah ada dalam mikro. Ini mengirimkan biner baru ke bootloader, yang menuliskannya ke memori program dan kemudian menyebabkan kode baru dijalankan.
Kedengarannya sederhana, tetapi tidak, setidaknya tidak jika Anda ingin proses ini menjadi kuat. Bagaimana jika kesalahan komunikasi terjadi dan firmware baru rusak pada saat ia tiba di bootloader? Bagaimana jika daya terputus selama proses boot? Bagaimana jika bootloader memiliki bug dan craps sendiri?
Skenario sederhana adalah bahwa bootloader selalu berjalan dari reset. Mencoba berkomunikasi dengan tuan rumah. Jika tuan rumah merespons, maka ia memberi tahu bootloader bahwa tidak ada yang baru, atau mengirimkannya kode baru. Ketika kode baru tiba, kode lama ditimpa. Anda selalu menyertakan checksum dengan kode yang diunggah, sehingga bootloader dapat mengetahui apakah aplikasi baru itu utuh. Jika tidak, ia tetap berada di bootloader secara konstan meminta unggahan sampai sesuatu dengan checksum yang valid dimuat ke dalam memori. Ini mungkin dapat diterima untuk perangkat yang selalu terhubung dan mungkin di mana tugas latar belakang dijalankan pada host yang menanggapi permintaan bootloader. Skema ini tidak baik untuk unit yang sebagian besar otonom dan hanya sesekali terhubung ke komputer host.
Biasanya bootloader sederhana seperti dijelaskan di atas tidak dapat diterima karena tidak ada kegagalan yang aman. Jika gambar aplikasi baru tidak diterima secara utuh, Anda ingin perangkat melanjutkan menjalankan gambar yang lama, tidak mati sampai unggahan yang berhasil dilakukan. Untuk alasan ini, biasanya sebenarnya ada dua modul khusus dalam firmware, pengunggah dan bootloader. Pengunggah adalah bagian dari aplikasi utama. Sebagai bagian dari komunikasi reguler dengan tuan rumah, gambar aplikasi baru dapat diunggah. Ini membutuhkan memori terpisah dari gambar aplikasi utama, seperti EEPROM eksternal atau menggunakan prosesor yang lebih besar sehingga setengah ruang memori program dapat dialokasikan untuk menyimpan gambar aplikasi baru. Pengunggah hanya menulis gambar aplikasi baru yang diterima di suatu tempat, tetapi tidak menjalankannya. Ketika prosesor diatur ulang, yang bisa terjadi atas perintah dari tuan rumah setelah unggahan, bootloader berjalan. Ini sekarang adalah program yang sepenuhnya mandiri yang tidak memerlukan kemampuan komunikasi eksternal. Ini membandingkan versi aplikasi saat ini dan yang diunggah, memeriksa checksum mereka, dan menyalin gambar baru ke area aplikasi jika versi berbeda dan memeriksa checksum gambar baru. Jika gambar baru rusak, itu hanya menjalankan aplikasi lama seperti sebelumnya.
Saya telah melakukan banyak bootloader, dan tidak ada dua yang sama. Tidak ada bootloader serba guna, terlepas dari apa yang ingin Anda percayai oleh beberapa perusahaan mikrokontroler. Setiap perangkat memiliki persyaratan dan keadaan khusus dalam berurusan dengan tuan rumah. Berikut adalah beberapa konfigurasi bootloader dan terkadang pengunggah yang saya gunakan:
- Bootloader dasar. Perangkat ini memiliki saluran serial dan akan terhubung ke host dan dihidupkan sesuai kebutuhan. Bootloader dijalankan dari reset dan mengirim beberapa respons permintaan unggah ke host. Jika program unggahan berjalan, itu akan merespons dan mengirim gambar aplikasi baru. Jika tidak merespons dalam waktu 500 ms, bootloader akan menyerah dan menjalankan aplikasi yang ada. Untuk memperbarui firmware, Anda harus menjalankan aplikasi pembaru pada host terlebih dahulu, kemudian sambungkan dan nyalakan perangkat.
- Pengunggah memori program. Di sini kami menggunakan ukuran berikutnya PIC yang memiliki memori program dua kali lebih banyak. Memori program secara kasar dibagi menjadi 49% aplikasi utama, 49% gambar aplikasi baru, dan 2% bootloader. Bootloader akan dijalankan dari reset dan menyalin gambar aplikasi baru ke gambar aplikasi saat ini dalam kondisi yang tepat.
- Gambar EEPROM eksternal. Seperti # 2 kecuali bahwa EEPROM eksternal digunakan untuk menyimpan gambar aplikasi baru. Dalam hal ini prosesor dengan memori lebih besar juga akan secara fisik lebih besar dan di sub-keluarga yang berbeda yang tidak memiliki campuran periferal yang kami butuhkan.
- TCP bootloader. Ini adalah yang paling kompleks dari semuanya. PIC 18F besar digunakan. 1/4 memori terakhir memegang bootloader, yang memiliki salinan lengkap sendiri dari tumpukan jaringan TCP. Bootloader dijalankan dari reset dan mencoba untuk terhubung ke server unggah khusus di port yang dikenal di alamat IP yang sebelumnya dikonfigurasi. Ini untuk instalasi besar di mana selalu ada mesin server khusus untuk seluruh sistem. Setiap perangkat kecil akan check-in dengan server unggah setelah reset dan akan diberikan salinan aplikasi baru yang sesuai. Bootloader akan menimpa aplikasi yang ada dengan salinan baru, tetapi hanya menjalankannya jika checksum diperiksa. Jika tidak, itu akan kembali ke server unggah dan coba lagi.
Karena bootloader itu sendiri merupakan bagian rumit dari kode yang berisi tumpukan jaringan TCP penuh, itu juga harus dapat diupgrade. Cara kami melakukannya adalah agar server unggah memasukkannya ke aplikasi khusus yang tujuannya hanya untuk menimpa bootloader setelah dieksekusi, lalu mengatur ulang mesin sehingga bootloader baru akan berjalan, yang akan menyebabkan server unggah mengirim gambar aplikasi utama terbaru. Secara teknis kesalahan daya selama beberapa milidetik diperlukan aplikasi khusus untuk menyalin gambar baru dari bootloader akan menjadi kegagalan yang tidak dapat dipulihkan. Dalam praktiknya ini tidak pernah terjadi. Kami baik-baik saja dengan kemungkinan yang sangat kecil karena perangkat ini adalah bagian dari instalasi besar di mana sudah ada orang yang akan melakukan perawatan pada sistem, yang terkadang berarti mengganti perangkat yang disematkan untuk alasan lain.
Semoga Anda dapat melihat bahwa ada sejumlah kemungkinan lain, masing-masing dengan pengorbanan risiko, kecepatan, biaya, kemudahan penggunaan, waktu henti, dll.