Ini lebih merupakan pendapat / komentar daripada jawaban.
Anda tidak ingin dan tidak seharusnya pemrograman dalam C. C ++, bila digunakan dengan cara yang benar , jauh lebih unggul. (OK, saya harus akui, ketika digunakan dengan cara yang salah itu jauh lebih buruk daripada C.) Yang membatasi Anda untuk chip yang memiliki kompiler C ++ (modern), yang kira-kira semuanya didukung oleh GCC, termasuk AVR (dengan beberapa keterbatasan, filo menyebutkan masalah ruang alamat yang tidak seragam), tetapi mengecualikan hampir semua PIC (PIC32 dapat didukung, tapi saya belum melihat port yang layak).
Ketika Anda memprogram algoritma dalam C / C ++ perbedaan antara pilihan yang Anda sebutkan kecil (kecuali bahwa chip 8 atau 16 bit akan sangat dirugikan ketika Anda melakukan banyak aritmatika bit 16, 32 atau lebih tinggi). Ketika Anda membutuhkan ons kinerja terakhir, Anda mungkin perlu menggunakan assembler (baik kode Anda sendiri atau yang disediakan oleh vendor atau pihak ketiga). Dalam hal ini Anda mungkin ingin mempertimbangkan kembali chip yang Anda pilih.
Ketika Anda membuat kode ke perangkat keras Anda dapat menggunakan beberapa lapisan abstraksi (sering disediakan oleh pabrikan) atau menulis sendiri (berdasarkan lembar data dan / atau kode contoh). IME abstraksi C yang ada (mbed, cmsis, ...) sering berfungsi (hampir) benar, tetapi gagal dalam kinerja (periksa old old bart sekitar 6 lapisan tipuan untuk operasi set pin), kegunaan dan portabilitas. Mereka ingin mengekspos semua fungsionalitas chip tertentu kepada Anda, yang dalam hampir semua kasus Anda tidak perlu dan lebih suka tidak peduli, dan itu mengunci kode Anda ke vendor tertentu (dan mungkin chip tertentu).
Inilah yang C ++ dapat melakukan jauh lebih baik: ketika dilakukan dengan benar, set pin dapat melewati 6 atau lebih lapisan abstraksi (karena itu membuat antarmuka yang lebih baik (portabel!) Dan kode lebih pendek mungkin), namun menyediakan antarmuka yang independen terhadap target untuk kasus sederhana , dan masih menghasilkan kode mesin yang sama seperti yang Anda tulis di assembler .
Cuplikan gaya pengkodean yang saya gunakan, yang bisa membuat Anda bersemangat atau berpaling dengan ngeri:
// GPIO part of a HAL for atsam3xa
enum class _port { a = 0x400E0E00U, . . . };
template< _port P, uint32_t pin >
struct _pin_in_out_base : _pin_in_out_root {
static void direction_set_direct( pin_direction d ){
( ( d == pin_direction::input )
? ((Pio*)P)->PIO_ODR : ((Pio*)P)->PIO_OER ) = ( 0x1U << pin );
}
static void set_direct( bool v ){
( v ? ((Pio*)P)->PIO_SODR : ((Pio*)P)->PIO_CODR ) = ( 0x1U << pin );
}
};
// a general GPIO needs some boilerplate functionality
template< _port P, uint32_t pin >
using _pin_in_out = _box_creator< _pin_in_out_base< P, pin > >;
// an Arduino Due has an on-board led, and (suppose) it is active low
using _led = _pin_in_out< _port::b, 27 >;
using led = invert< pin_out< _led > >;
Pada kenyataannya ada beberapa lapisan abstraksi lagi. Namun penggunaan akhir led, katakanlah untuk menyalakannya, tidak menunjukkan kompleksitas atau rincian target (untuk arduin uno atau pil biru ST32 kode akan identik).
target::led::init();
target::led::set( 1 );
Kompiler tidak terintimidasi oleh semua lapisan itu, dan karena tidak ada fungsi virtual yang terlibat, pengoptimal melihat semuanya (beberapa detail, dihilangkan, seperti mengaktifkan jam periferal):
mov.w r2, #134217728 ; 0x8000000
ldr r3, [pc, #24]
str r2, [r3, #16]
str r2, [r3, #48]
Begitulah cara saya akan menulisnya di assembler - JIKA saya menyadari bahwa register PIO dapat digunakan dengan offset dari basis umum. Dalam hal ini saya mungkin akan, tetapi kompiler jauh lebih baik dalam mengoptimalkan hal-hal seperti itu daripada saya.
Jadi sejauh yang saya punya jawaban, itu adalah: menulis lapisan abstraksi untuk perangkat keras Anda, tetapi lakukan di C ++ modern (konsep, template) sehingga tidak membahayakan kinerja Anda. Dengan itu, Anda dapat beralih dengan mudah ke chip lain. Anda bahkan dapat mulai mengembangkan beberapa chip acak yang telah Anda letakkan, familiair dengan, memiliki alat debugging yang baik untuk, dll. Dan menunda pilihan terakhir sampai nanti (ketika Anda memiliki lebih banyak info tentang memori yang diperlukan, kecepatan CPU dll).
IMO salah satu kesalahan dari pengembangan yang disematkan adalah memilih chip terlebih dahulu (ini adalah pertanyaan yang sering ditanyakan di forum ini: chip mana yang harus saya pilih untuk .... Jawaban terbaik umumnya: tidak masalah.)
(sunting - respons terhadap "Jadi, kinerja bijak, C atau C ++ akan berada pada level yang sama?")
Untuk konstruksi yang sama, C dan C ++ adalah sama. C ++ memiliki lebih banyak konstruksi untuk abstraksi (hanya beberapa: kelas, templat, constexpr) yang dapat, seperti alat apa pun, digunakan untuk yang baik atau yang buruk. Untuk membuat diskusi lebih menarik: tidak semua orang setuju apa yang baik atau buruk ...