pemrograman mikrokontroler vs pemrograman berorientasi objek

11

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?

gila
sumber
4
Kurva pembelajaran terbesar adalah bagaimana menggerakkan perangkat keras spesifik dalam mikro Anda. Itu akan melibatkan meneliti lembar data selama berjam-jam. Sayangnya, tidak ada jalan keluar yang mudah.
drxzcl
@rrazd, saya perhatikan bahwa Anda telah memasukkan tag arduino. Apakah ini karena Anda ingin menggunakan bahasa kabel arduino dan perpustakaan? Atau apakah Anda akan menulis aplikasi yang disematkan dalam C murni? Jika Anda ingin tetap menggunakan lingkungan Arduino, itu cukup aman dan mudah untuk dimainkan karena mereka telah melakukan beberapa abstraksi jauh dari perangkat keras.
Jon L
@Jon saya berencana untuk menggunakan papan Arduino untuk pemula. Bukankah ini mirip dengan bahasa C? Saya pikir itu melibatkan konsep dasar yang sama ....
1911
1
Saya bertanya-tanya apakah maksud Anda apa yang oleh banyak orang disebut 'pemrograman I / O', atau apakah Anda mengantisipasi mengatur ulang perangkat keras dengan kode. Arduino jelas merupakan yang pertama; yang terakhir akan menjadi domain FPGA.
JustJeff
1
@rrazd - Saya mengubah judul; "pemrograman perangkat keras" terdengar terlalu mirip HDL (Bahasa Deskripsi Perangkat Keras), misalnya VHDL dan Verilog, yang digunakan untuk memprogram FPGA dan CPLD.
stevenvh

Jawaban:

10

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.

Adam Lawrence
sumber
1
Anda tidak harus sepenuhnya meninggalkan paradigma berorientasi objek, tetapi pada micros yang lebih kecil mungkin perlu untuk meninggalkan implementasi objek kelas berat dan benar-benar berpikir tentang apa cara terbaik untuk menyelesaikan setiap masalah. Seringkali yang bersifat prosedural, tetapi benda-benda ringan, diimplementasikan dengan baik (biasanya dengan tangan), kadang-kadang dapat mengecilkan ukuran proyek mikrokontroler yang rumit.
Chris Stratton
6
Semua ini benar kecuali mengabaikan orientasi objek. Anda mungkin tidak akan menggunakan bahasa dengan fitur OO tetapi itu tidak mengesampingkan orientasi objek. Untuk mikrokontroler, Anda akan menulis driver untuk semua periferal perangkat keras (ADC, pengontrol bus serial, PWM, dll.). Driver seperti itu harus selalu ditulis dengan cara yang berorientasi objek sehingga 1) otonom dan tidak tahu / peduli tentang sisa program, dan 2) menerapkan enkapsulasi pribadi sehingga sisa program tidak dapat masuk dan bermain-main dengan itu. Ini 100% dimungkinkan dalam C dan tidak akan memengaruhi kinerja.
Lundin
1
Saya sangat tidak setuju dengan kalimat pertama, semua proyek mikrokontroler saya dibangun dengan C ++ dan pendekatan berorientasi objek, dan micros yang kami gunakan tidak terlalu besar (32kB ROM), bootloader yang juga berorientasi objek kurang dari 2kB, saya tidak benar-benar melihat batasan. Anda tidak dapat melakukan hal-hal gila tetapi desainnya bisa berorientasi objek tanpa masalah.
Arsenal
@Arsenal Note Saya mengatakan 'most', dan perhatikan bahwa Anda mengomentari utas berusia empat tahun. :)
Adam Lawrence
Saya sepenuhnya tidak setuju dengan kalimat pertama dan terakhir. Dan juga perakitan digunakan sangat jarang dan, kebanyakan, hanya untuk MCU 8-bit (cukup periksa forum ini, berapa banyak posting dengan kode perakitan yang dapat Anda temukan?). Anda tentu bisa dan (IMHO) harus menulis dalam gaya OO untuk MCU 32-bit
Andrejs Gasilovs
10

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.

jujur
sumber
3
+1 untuk "Anda dapat menggunakan paradigma OO jika Anda mau". Yang perlu Anda periksa di pintu bukanlah desain OO. OOD hanyalah sebuah filosofi yang mendorong Anda untuk menjaga kode dan data terkait. Yang perlu Anda tinggalkan adalah cara OO diimplementasikan dalam sistem perusahaan, dengan beberapa lapisan abstraksi, inversi kontrol, dan semua jazz itu. Tugas firmware Anda adalah mengemudikan perangkat keras, itu saja.
drxzcl
7

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.

darron
sumber
5

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.

μ

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.

stevenvh
sumber
Saya telah menulis game untuk Atari 2600, yang merupakan platform yang agak terbatas; permainan pertama saya yang diterbitkan pada dasarnya adalah kode 4K (karena saya memiliki troli 32K, saya menambahkan beberapa barang tambahan, tetapi versi 4K sepenuhnya dapat dimainkan); RAM adalah 128 byte. Saya merasa menarik untuk merenungkan bahwa pada tahun saya menulis game itu (2005), game-game lain diterbitkan yang, secara harfiah, jutaan kali lebih besar.
supercat
@supercat - Ya, tapi itu sudah diduga, pada 2005 Atari 2600 sudah berusia 200 tahun! Saya belum pernah memainkan game aksi seperti FPS, tetapi ketika saya melihat apa yang diperlukan untuk memainkannya, GPU jauh lebih kuat daripada CPU Anda, baik secara program dan elektrik, saya tidak dapat membantu tetapi menggelengkan kepala :-). Saya bermain catur (Sargon) pada 16k TRS-80 IIRC. Simulator Penerbangan saudara saya tidak perlu lagi.
stevenvh
Umurnya belum 200 tahun. Ini debut pada tahun 1977, jadi bahkan belum 30 tahun. Sementara saya setuju bahwa itu adalah masa lalu dalam hal teknologi, saya masih terpesona oleh fakta bahwa tidak hanya ada peningkatan seratus terus, atau peningkatan ribuan kali lipat , tetapi peningkatan JUTAAN lipat baik dalam RAM dan ukuran kode. Kecepatan belum terlalu meningkat, karena 2600 adalah 1,19MHz dan sistem yang lebih baru hanya dalam kisaran GHz rendah. Mereka dapat melakukan lebih banyak per siklus daripada 2600 (yang dapat - dan harus - menghasilkan 1/76 dari garis video setiap siklus) tetapi saya tidak berpikir mereka 1.000.000 x lebih cepat.
supercat
3

"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.

Wouter van Ooijen
sumber
1

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 .

Jon L
sumber
0

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).

Pematrolian
sumber
Dalam hal kekhawatiran, mereka yang berada di sekitar alokasi memori dinamis (re) cenderung menjadi penghalang yang lebih besar untuk OO tradisional daripada waktu .
Chris Stratton
Mungkin Anda benar. Tetapi ada orang yang diprogram dalam 80-90an untuk perangkat lunak mode nyata MSDOS, dengan 64K (segmen memori data) ruang RAM tersedia dan bagi mereka itu "alami". Mungkin MSDOS PC lebih "tertanam" daripada STM32F4 todays :)
Flanker
STM32F4 biasanya memiliki lebih banyak memori program dalam bentuk flash, tetapi PC biasanya datang dengan memori RAM yang jauh lebih besar untuk menyimpan objek runtime yang dapat diubah. Sementara hal-hal yang jauh yang dipaksakan oleh pengalamatan tersegmentasi adalah menyusahkan, keduanya tidak memiliki MMU yang benar, dan itu akan menjadi lebih mengkhawatirkan pada sistem dengan RAM yang lebih sedikit, yaitu STM32F4. Waktu uptime PC cenderung lebih pendek, dan tingkat kegagalan yang dapat diterima lebih tinggi.
Chris Stratton