Это больше мнение / комментарий, чем ответ.
Вы не хотите и не должны программировать на C. C ++, при правильном использовании , намного лучше. (Хорошо, я должен признать, что при неправильном использовании он намного хуже, чем C.) Это ограничивает вас чипами, которые имеют (современный) компилятор C ++, что примерно всегда поддерживается GCC, включая AVR (с В некоторых ограничениях Filo упоминает о проблемах неравномерного адресного пространства), но исключая почти все PIC (PIC32 может поддерживаться, но я еще не видел приличного порта).
Когда вы программируете алгоритмы на C / C ++, разница между упомянутыми вами вариантами невелика (за исключением того, что 8 или 16-битная микросхема будет иметь серьезный недостаток, если вы выполняете большую 16, 32-битную или более высокую арифметику). Когда вам нужна последняя унция производительности, вам, вероятно, потребуется использовать ассемблер (либо ваш собственный, либо код, предоставленный поставщиком или третьей стороной). В этом случае вы можете пересмотреть выбранный вами чип.
Когда вы кодируете аппаратное обеспечение, вы можете использовать какой-либо уровень абстракции (часто предоставляемый производителем) или написать собственный (на основе таблицы данных и / или примера кода). Существующие абстракции C в IME (mbed, cmsis, ...) часто функционально (почти) правильны, но ужасно терпят неудачу в производительности (проверьте oldfarts rant о 6 уровнях косвенности для операции набора выводов), удобстве использования и переносимости. Они хотят предоставить вам всю функциональность конкретного чипа, который почти во всех случаях вам не понадобится, и, скорее, вам это не нужно, и он блокирует ваш код для этого конкретного поставщика (и, вероятно, именно этого чипа).
Это то, где C ++ может работать намного лучше: при правильном выполнении набор выводов может проходить через 6 или более уровней абстракции (поскольку это делает возможным лучший (переносимый!) Интерфейс и более короткий код), но в то же время обеспечивает интерфейс, который не зависит от цели. для простых случаев , и все еще приводят к тому же машинному коду, который вы написали бы на ассемблере .
Фрагмент стиля кодирования, который я использую, который может вызвать у вас энтузиазм или отвратить в ужасе:
// 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 > >;
На самом деле есть еще несколько уровней абстракции. Тем не менее, окончательное использование светодиода, скажем, для его включения, не показывает сложности или деталей цели (для ардуина uno или синей таблетки ST32 код будет идентичен).
target::led::init();
target::led::set( 1 );
Компилятор не пугается всех этих уровней, и поскольку в нем нет виртуальных функций, оптимизатор просматривает все (некоторые детали опущены, например, включение периферийных часов):
mov.w r2, #134217728 ; 0x8000000
ldr r3, [pc, #24]
str r2, [r3, #16]
str r2, [r3, #48]
Вот как бы я написал это на ассемблере - если бы я понял, что регистры PIO могут использоваться со смещениями из общей базы. В этом случае я бы, наверное, но компилятор гораздо лучше оптимизирует такие вещи, чем я.
Поэтому, насколько мне известно, это так: напишите уровень абстракции для своего оборудования, но делайте это на современном C ++ (концепции, шаблоны), чтобы он не повредил вашей производительности. С этим на месте, вы можете легко переключиться на другой чип. Вы даже можете начать разработку на каком-то случайном чипе, который у вас есть, с которым вы знакомы, у вас есть хорошие инструменты для отладки и т. Д., И отложить окончательный выбор до следующего (когда у вас будет больше информации о необходимой памяти, скорости процессора и т. Д.).
IMO - одна из ошибок встроенной разработки - сначала выбрать чип (на этом форуме часто задают вопрос: какой чип выбрать?). Лучший ответ, как правило, не имеет значения.)
(edit - ответ на вопрос «Значит, производительность будет выше, C или C ++ будут на одном уровне?»)
Для одинаковых конструкций C и C ++ одинаковы. C ++ имеет гораздо больше конструкций для абстракции (всего несколько: классы, шаблоны, constexpr), которые, как и любой инструмент, могут быть использованы как во благо, так и во вред. Чтобы сделать обсуждение более интересным: не все согласны с тем, что хорошо или что плохо ...