pemrograman mikrokontroler vs pemrograman berorientasi objek

Saya telah melakukan beberapa pemrograman berorientasi objek dasar dengan C ++ (membuat B-Tree, Hashing Algorithms, Double Linked Lists) dan saya telah melakukan proyek kecil di C (seperti membuat kalkulator ilmiah dll.)

Seberapa berbeda pemrograman perangkat keras (khusus untuk pengontrol mikro) dari perangkat lunak / pemrograman berorientasi objek dalam hal pola pikir dan "pemikiran" yang harus dimiliki oleh programmer?

Apakah yang satu dianggap lebih sulit daripada yang lain kebanyakan orang?

Dengan latar belakang saya (seperti dijelaskan di atas) apakah saya perlu banyak persiapan untuk masuk ke pemrograman perangkat keras atau dapatkah saya terjun langsung tanpa terlalu banyak persiapan?

Anda harus sepenuhnya meninggalkan paradigma berorientasi objek ketika berhadapan dengan sebagian besar mikrokontroler.

Microcontrollers umumnya register-dan RAM-terbatas, dengan laju clock lambat dan tidak ada jalur pipelining / kode paralel. Anda bisa melupakan Java pada PIC, misalnya.

Anda harus masuk ke pola pikir bahasa majelis, dan menulis secara prosedural.

Anda harus menjaga kode Anda relatif datar dan menghindari rekursi, karena keterbatasan RAM sering dapat menyebabkan masalah tumpukan.

Anda harus belajar bagaimana menulis rutinitas layanan interupsi yang efisien (biasanya dalam bahasa assembly).

Anda mungkin harus memperbaiki bagian kode secara manual, dalam bahasa assembly, untuk mengimplementasikan fungsionalitas yang tidak didukung oleh kompiler (atau kurang mendukung).

Anda harus menulis kode matematika yang memperhitungkan ukuran kata dan kurangnya kemampuan FPU dari sebagian besar mikrokontroler (yaitu melakukan perkalian 32-bit pada mikro 8-bit = jahat).

Ini adalah dunia yang berbeda. Bagi saya, memiliki ilmu komputer atau latar belakang pemrograman profesional bisa menjadi penghalang sama seperti tidak memiliki pengetahuan sama sekali ketika berhadapan dengan mikrokontroler.

Anda perlu memikirkan beberapa hal:

• Anda akan menggunakan C sebagai bahasa
• Anda masih dapat membuat perasaan orientasi objek menggunakan pointer fungsi sehingga Anda dapat menimpa fungsi dll. Saya telah menggunakan metode ini di masa lalu dan proyek saat ini dan bekerja dengan sangat baik. Jadi OO ada sebagian tetapi tidak dalam pengertian C ++.

Ada batasan lain yang akan dimainkan seperti kecepatan dan memori yang terbatas. Jadi sebagai pedoman umum, saya menghindari:

• Menggunakan heap, jika ada cara untuk menyelesaikan masalah tanpa Malloc, saya melakukannya. Sebagai contoh, saya mengalokasikan buffer dan hanya menggunakannya.
• Saya sengaja mengurangi ukuran stack dalam pengaturan compiler untuk menghadapi masalah ukuran stack sejak awal, mengoptimalkannya dengan hati-hati.
• Saya berasumsi setiap baris kode akan diinterupsi oleh suatu peristiwa, jadi saya menghindari kode non reentrant
• Saya menganggap interupsi bahkan bersarang jadi saya menulis kode yang sesuai
• Saya menghindari menggunakan OS kecuali itu perlu. 70% dari proyek tertanam tidak benar-benar membutuhkan OS. Jika saya harus menggunakan OS, saya hanya menggunakan sesuatu dengan kode sumber yang tersedia. (Freertos dll)
• jika saya menggunakan OS, saya hampir selalu abstrak sehingga saya bisa mengganti OS dalam hitungan jam.
• Untuk driver dll. Saya hanya akan menggunakan perpustakaan yang disediakan oleh vendor, saya tidak pernah secara langsung mengutak-atik bit, kecuali saya tidak punya pilihan lain. Ini membuat kode dapat dibaca dan meningkatkan debugging.
• Saya melihat loop dan hal-hal lain, terutama di ISR, untuk memastikan mereka cukup cepat.
• Saya selalu menyimpan beberapa GPIO berguna untuk mengukur hal-hal, pengalihan konteks, waktu menjalankan ISR dll.

Daftar berjalan, saya mungkin di bawah rata-rata dalam hal pemrograman perangkat lunak, saya yakin ada praktik yang lebih baik.

Saya melakukan keduanya, jadi inilah pandangan saya.

Saya pikir keterampilan yang paling penting sejauh ini dalam tertanam adalah kemampuan debug Anda. Pola pikir yang diperlukan jauh berbeda karena jauh lebih banyak yang bisa salah, dan Anda harus sangat terbuka untuk mempertimbangkan semua cara berbeda yang Anda coba lakukan bisa salah.

Ini adalah masalah terbesar tunggal untuk pengembang tertanam baru. Orang-orang PC cenderung memilikinya lebih kasar, karena mereka terbiasa bekerja hanya untuk mereka. Mereka akan cenderung membuang banyak waktu mencari alat untuk melakukan hal-hal bagi mereka (petunjuk: tidak banyak). Ada banyak membenturkan kepala ke dinding berulang kali, tidak tahu harus berbuat apa lagi. Jika Anda merasa macet, mundurlah dan cari tahu apakah Anda dapat mengidentifikasi apa yang salah. Secara sistematis lakukan penyempitan daftar masalah potensial Anda sampai Anda mengetahuinya. Ini mengikuti langsung dari proses ini bahwa Anda harus membatasi ruang lingkup masalah dengan tidak mengubah terlalu banyak sekaligus.

Orang tertanam yang berpengalaman cenderung menerima debugging begitu saja ... sebagian besar orang yang tidak dapat melakukannya dengan baik tidak bertahan lama (atau bekerja di perusahaan besar yang hanya menerima "firmware sulit" sebagai jawaban untuk alasan mengapa fitur tertentu terlambat tahun)

Anda sedang mengerjakan kode yang berjalan pada sistem eksternal ke sistem pengembangan Anda, dengan berbagai tingkat visibilitas ke target Anda dari platform ke platform. Jika di bawah kendali Anda, dorong alat bantu pengembangan untuk membantu meningkatkan visibilitas ini ke sistem target Anda. Gunakan port serial debug, bit debug output debug, lampu berkedip terkenal, dll. Tentunya minimal belajar bagaimana menggunakan osiloskop dan gunakan pin I / O dengan 'lingkup untuk melihat kapan fungsi tertentu masuk / keluar, ISR terbakar, dll. Saya telah menyaksikan orang-orang berjuang selama bertahun-tahun lebih lama dari yang seharusnya hanya karena mereka tidak pernah repot mengatur / mempelajari cara menggunakan tautan debug JTAG yang tepat.

Jauh lebih penting untuk sangat menyadari sumber daya apa yang Anda miliki relatif terhadap PC. Baca lembar data dengan cermat. Pertimbangkan 'biaya' sumber daya apa pun yang Anda coba lakukan. Pelajari trik debugging yang berorientasi sumber daya seperti mengisi ruang stack dengan nilai ajaib untuk melacak penggunaan stack.

Sementara beberapa tingkat keterampilan debug diperlukan untuk PC dan perangkat lunak tertanam, itu jauh lebih penting dengan tertanam.

Saya menganggap pengalaman C ++ Anda berbasis PC.

Kesalahan yang sering dibuat oleh pemrogram yang berpindah dari PC ke mikrokontroler adalah mereka tidak menyadari betapa terbatasnya sumber daya . Pada PC tidak ada yang akan menghentikan Anda ketika Anda membuat tabel dengan 100.000 entri, atau menulis program yang mengkompilasi kode mesin 1MB.
Ada yang mikrokontroler yang memiliki kekayaan sumber daya memori, terutama di high end, tapi masih jauh dari apa yang Anda akan digunakan untuk. Untuk proyek hobi Anda mungkin selalu dapat mencapai yang maksimal, tetapi dalam proyek profesional Anda akan sering dipaksa untuk bekerja dengan perangkat yang lebih kecil karena lebih murah .
Pada satu proyek saya bekerja dengan TI MSP430F1101. 1KB memori program, 128 byte konfigurasi Flash, 128 byte RAM. Program tidak sesuai dengan 1K, jadi saya harus menulis fungsi 23 byte di Flash konfigurasi. Dengan pengontrol kecil ini Anda menghitung dengan byte . Pada kesempatan lain, memori program 4 byte terlalu kecil. Boss tidak akan membiarkan saya menggunakan controller dengan lebih banyak memori, tetapi saya harus mengoptimalkan kode mesin yang sudah dioptimalkan (sudah ditulis assembler) agar sesuai dengan tambahan 4 byte. Anda mendapatkan gambar.

Bergantung pada platform yang Anda kerjakan, Anda harus berurusan dengan I / O tingkat sangat rendah . Beberapa lingkungan pengembangan memiliki fungsi untuk menulis ke LCD, tetapi pada yang lain Anda harus melakukannya sendiri, dan harus membaca lembar data LCD dari awal hingga selesai untuk mengetahui cara mengontrolnya.
Anda mungkin harus mengendalikan relai, itu lebih mudah daripada LCD, tetapi itu akan mengharuskan Anda untuk pergi ke level register mikrokontroler. Lagi lembar data atau manual pengguna. Anda harus mengenal struktur mikrokontroler, yang akan Anda temukan dalam diagram blok, lagi di lembar data. Pada zaman mikroprosesor kami berbicara tentang model pemrograman, yang pada dasarnya adalah deretan register prosesor. Mikrokontroler saat ini sangat kompleks sehingga deskripsi semua register dapat mengambil bagian terbaik dari lembar data 100 halaman. IIRC hanya deskripsi modul jam untuk MSP430 adalah 25 halaman.

$\mu$

Microcontrollers sering diprogram dalam C . C ++ agak haus sumber daya, jadi itu biasanya keluar. (Sebagian besar implementasi C ++ untuk mikrokontroler menawarkan subset terbatas dari C ++.) Seperti yang saya katakan, tergantung pada platform Anda mungkin memiliki pustaka fungsi yang luas yang tersedia yang dapat menghemat waktu pengembangan. Sebaiknya luangkan waktu untuk mempelajarinya, mungkin akan menghemat banyak waktu nanti jika Anda tahu apa yang tersedia.

"pemrograman perangkat keras" dapat berarti banyak hal. Memprogram chip yang sangat kecil (pikirkan 10F200, 512 instruksi, beberapa byte RAM) dapat hampir seperti merancang sirkuit elektronik. Di sisi lain pemrograman mikrokontroler Cortex besar (FLASH 1 Mb, RAM 64 kB) bisa sangat banyak seperti pemrograman PC / GUI, menggunakan toolkit GUI besar. IMHO programmer yang tertanam / real-time yang baik membutuhkan keterampilan baik dari sisi perangkat lunak egineering dan dari sisi desain sirkuit. Untuk UC yang lebih besar C ++ adalah pilihan bahasa yang baik, untuk yang sangat kecil C mungkin satu-satunya pilihan. Pengetahuan assemby bisa berguna, tetapi saya tidak akan merekomendasikan melakukan proyek serius sepenuhnya dalam perakitan.

Saya telah melakukan pekerjaan tertanam serius dengan orang-orang dari kedua sisi (SWI dan EE). Saya biasanya lebih suka orang-orang SWI, asalkan mereka memiliki pengalaman dengan pemrograman multu-threaded.

Pertanyaan Anda sepertinya Anda ingin menyelami pemrograman tertanam. Dengan segala cara melakukannya. Untuk aspek tingkat rendah (menghubungkan periferal dalam chip Anda dan perangkat keras di sekitarnya) Anda perlu mempelajari beberapa keterampilan baru, tetapi itu hanya banyak pekerjaan tanpa banyak konsep baru. Untuk lapisan yang lebih tinggi dari proyek Anda, Anda dapat menggunakan knwoledge yang ada.

Untuk setiap metode perpustakaan Arduino yang Anda panggil ada banyak kode C / C ++ yang memungkinkan, itu hanya dikemas dengan baik untuk Anda gunakan sebagai API. Lihatlah kode sumber Arduino di bawah hardware direktori / Arduino / * dan Anda akan melihat semua C / C ++ ditulis untuk Anda yang berinteraksi langsung dengan register mikrokontroler AVR. Jika tujuan Anda adalah mempelajari cara menulis hal-hal seperti ini (langsung untuk perangkat keras) maka ada banyak hal yang harus dibahas. Jika tujuan Anda adalah untuk mendapatkan sesuatu untuk bekerja menggunakan perpustakaan mereka maka mungkin tidak ada banyak untuk dibicarakan karena sebagian besar kerja keras dilakukan untuk Anda dan perpustakaan mereka dan lingkungan pengembangan sangat mudah digunakan.

Beberapa aturan praktis ketika bekerja dengan perangkat sumber daya terbatas yang dapat berlaku untuk lingkungan Arduino atau yang lain:

Waspadai berapa banyak memori yang Anda gunakan. Baik ukuran kode (yang masuk ke memori flash) dan penggunaan RAM statis (konstanta dalam kode Anda yang akan selalu ada dalam RAM). Saya berpendapat bahwa penggunaan RAM statis sedikit lebih penting memulai, karena mudah terlihat berlebihan. Ini tidak biasa bagi Anda untuk hanya memiliki 1000 byte untuk bekerja dengan tumpukan, tumpukan, dan konstanta Anda. Jadilah bijak dalam bagaimana Anda menghabiskannya, jadi hindari hal-hal seperti array panjang bilangan bulat (masing-masing 4-byte) ketika byte atau karakter yang tidak ditandatangani (masing-masing 1 byte) sudah cukup. Jawaban lain di sini mencakup beberapa poin penting lainnya dengan sangat baik jadi saya akan berhenti di sini, saya terutama ingin mendapatkan poin bahwa ada banyak yang harus dibahas jika Anda tidak menggunakan perpustakaan Arduino dan menulis perpustakaan C Anda sendiri .

Mengenai pemrograman mikrokontroler vs OOP, mereka bukan sesuatu yang bertentangan. Memang benar bahwa semua pustaka vendor berada di C polos, tetapi semua platform mendukung C ++ OOP juga. Pengembang dapat membangun dan membuat pustaka tingkat tinggi C ++ dan firmware perangkat selain itu. Contoh yang bagus adalah pustaka Arduino, resmi dan buatan pengguna - kebanyakan kelas C ++. Mungkin tidak semua keunggulan OOP dapat sepenuhnya digunakan dalam lingkungan tertanam, tetapi keunggulan C ++ vs C yang terkenal juga berlaku di sini.

Mengenai pola pikir dan pemikiran, seperti dicatat dalam jawaban lain, mikrokontroler adalah platform yang sangat terbatas sumber daya (khususnya dalam RAM, kurang dalam kecepatan) - hal-hal seperti alokasi memori dinamis, pengecualian C ++ biasanya dikesampingkan. Mengingat perangkat keras yang tepat dipilih, mudah untuk mengadopsi batasan ini dan menggunakan teknik lain (juga banyak digunakan di platform lain).

Dalam pandangan saya, tantangan yang lebih sulit mungkin satu dimensi tambahan lagi yang ditemukan dalam pemrograman tertanam - waktu. Ini karena biasanya perangkat lunak yang disematkan menangani banyak peristiwa waktu nyata, protokol yang tepat waktu untuk menggerakkan perangkat periferal dan tugas umum itu sendiri (ini juga paralel dengan platform "tingkat tinggi" lainnya, seperti aplikasi multi-threaded).

Bersiaplah untuk membaca banyak lembar data ketika berhadapan dengan perangkat keras baru - saya kira itu bisa terkait dengan bagian pertanyaan "pola pikir" :) Tentunya beberapa pengetahuan EE dan perangkat keras akan diperlukan.

Saya juga ingin mencatat bahwa saat ini pengembangan perangkat lunak yang disematkan tidak memerlukan bahasa assembly. Bahkan Java (BTW itu adalah OOP secara default) sudah ada di sini dan semakin kuat (setidaknya untuk beberapa kelas perangkat yang disematkan, misalnya perangkat IoT, ini bisa memiliki masa depan yang sangat cerah).