Questa è più un'opinione / commento che una risposta.
Non vuoi e non dovresti programmare in C. C ++, se usato nel modo giusto , è di gran lunga superiore. (OK, devo ammetterlo, se usato nel modo sbagliato è molto peggio di C.) Questo ti limita ai chip che hanno un compilatore C ++ (moderno), che è praticamente tutto ciò che è supportato da GCC, incluso AVR (con alcune limitazioni, filo menziona i problemi di uno spazio di indirizzi non uniforme), ma escludendo quasi tutti i PIC (potrebbe essere supportato PIC32, ma non ho ancora visto nessuna porta decente).
Quando si programmano algoritmi in C / C ++, la differenza tra le scelte che si menziona è piccola (tranne per il fatto che un chip a 8 o 16 bit sarà in grave svantaggio quando si eseguono molti aritmetici a 16, 32 o più bit). Quando hai bisogno dell'ultima oncia di prestazione, probabilmente dovrai usare l'assemblatore (il tuo o il codice fornito dal venditore o da una terza parte). In tal caso, potresti voler riconsiderare il chip selezionato.
Quando si codifica l'hardware è possibile utilizzare un livello di astrazione (spesso fornito dal produttore) o scrivere il proprio (basato sul foglio dati e / o sul codice di esempio). Le astrazioni C esistenti dell'IME (mbed, cmsis, ...) sono spesso funzionalmente (quasi) corrette, ma falliscono in modo orribile nelle prestazioni (controlla che oldfarts abbia circa 6 livelli di riferimento indiretto per un'operazione di set di pin), usabilità e portabilità. Vogliono esporre tutte le funzionalità di quel particolare chip a te, che in quasi tutti i casi non ti serviranno e preferiresti non preoccuparti, e blocca il tuo codice a quel particolare fornitore (e probabilmente quel particolare chip).
Questo è dove C ++ può fare molto meglio: se fatto correttamente, un set di pin può passare attraverso 6 o più livelli di astrazione (perché ciò rende possibile un'interfaccia migliore (portatile!) E un codice più breve), ma fornisce un'interfaccia indipendente dal target per i casi semplici , e risulta comunque nello stesso codice macchina che scriveresti in assemblatore .
Un frammento dello stile di codifica che uso, che può renderti entusiasta o allontanarti dall'orrore:
// 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 > >;
In realtà ci sono altri strati di astrazione. Tuttavia l'uso finale del led, diciamo per accenderlo, non mostra la complessità o i dettagli del target (per un arduin uno o una pillola blu ST32 il codice sarebbe identico).
target::led::init();
target::led::set( 1 );
Il compilatore non è intimidito da tutti quei livelli, e poiché non ci sono funzioni virtuali coinvolte, l'ottimizzatore vede attraverso tutto (alcuni dettagli, omessi, come abilitare il clock periferico):
mov.w r2, #134217728 ; 0x8000000
ldr r3, [pc, #24]
str r2, [r3, #16]
str r2, [r3, #48]
Ecco come l'avrei scritto in assembler - SE mi fossi reso conto che i registri PIO possono essere usati con offset da una base comune. In questo caso probabilmente lo farei, ma il compilatore è molto meglio nell'ottimizzare tali cose di me.
Quindi, per quanto ho una risposta, è: scrivere un livello di astrazione per il tuo hardware, ma farlo nel moderno C ++ (concetti, modelli) in modo che non danneggi le tue prestazioni. Con quello in atto, puoi passare facilmente a un altro chip. Puoi persino iniziare a sviluppare su alcuni chip casuali che hai in giro, avere familiarità, avere buoni strumenti di debug per, ecc. E rimandare la scelta finale a più tardi (quando hai più informazioni sulla memoria richiesta, sulla velocità della CPU ecc.).
Una delle menzogne dello sviluppo integrato dell'IMO è scegliere prima il chip (è una domanda spesso posta su questo forum: quale chip dovrei scegliere per ... La migliore risposta è generalmente: non importa.)
(modifica - risposta a "Quindi per quanto riguarda le prestazioni, C o C ++ sarebbero allo stesso livello?")
Per gli stessi costrutti, C e C ++ sono gli stessi. Il C ++ ha molti più costrutti per l'astrazione (solo alcuni: classi, template, constexpr) che possono, come qualsiasi strumento, essere usati per il bene o per il male. Per rendere le discussioni più interessanti: non tutti sono d'accordo su ciò che è buono o cattivo ...