Использование шаблонного метапрограммирования для микроконтроллеров AVR

Наверное «тяжёлое» наследие мнемокода ассемблера. Там всё в 3 или 4 буквы расписано. Регистрам «повезло» чуть больше.
Ну ещё в каждом даташите есть раздел сокращений где каждое расписано что и как. Ну или по ходу текста тоже есть разъяснения.
А кто с «камнями» каждый день работает, тот все сокращение наизусть помнит (или помнит куда смотреть и освежить память).

Позволю себе предположить, что данные аббревиатуры не инициатива разработчиков программного инструментария, а следование именованию, предложенному разработчиками железа. Наверное было бы странно видеть что-то типа Sleep_Mode_Control_Register в названии регистра, который у схемотехников называется просто SMCR.

Рискну предположить, что такие названия лучше смотрятся в здоровенной таблице в начале даташита с отображением регистров на адреса памяти, на диаграммах изменения состояния регистров (тех, где показано, какие биты в какой момент меняются при приходе какого-нибудь сигнала), логических схемах отдельных блоков, и еще, может быть, в трехэтажных выражениях с побитовыми операциями в коде.

С другой стороны, какой-нибудь «младший бит выбора режима таймера номер три» — вот как его красиво назвать?

Это очень удобно, потому что совпадает с даташитом — и названия регистров, и названия битов.

Эта проблема решается очень легко. #define новое_удобное_название_вещи = СТНЗВ в отдельном файле, и подключить его в начале проекта.
А вот что дальше потом с этим делать…

Да что может быть проще — берёте Arduino IDE и вперёд.

Бытует почему-то расхожее мнение что под Ардуино пишут на каком-то мистическом языке «wiring». На самом деле это настоящий честный C++ с шаблонами, классами и всем остальным, что поддерживает компилятор avr-gcc.

Откровенно говоря начал было волноваться, когда увидел цикл в функции записи в порт. Когда дочитал до списков типов, успокоился, да это действительно соответствует теме моей статьи. Аналогичная проблема имеет место с ЖКИ тачскринами, при использовании покупного дисплея контакты шины данных устройства также оказываются раскидаными по разным битам разных портов. При использовании стратегий мы могли бы получить примерно следующий интерфейс:

template
<
    class pin_ctrl,
    class device = LCD_C505,
    class orient = tftcd::ORIENTATION<PORTRAIT,240,320>,
    ...
    class dbg = NO_DEBUG
>
struct TFT_LCD;

Шаблонный параметр device скрывает все детали, специфические для конкретной модели дисплея, их существует множество и для каждой определен особый порядок инициализации как минимум. Параметр orient определяет ориентацию дисплея и позволяет существенно оптимизировать функции, связанные с расчетом координат.
А вот единственная вещь, которая является платформенно зависимой, это pin_ctrl — стратегия, которая скрывает всю механику работы с шиной данных устройства. На роль именно этой стратегии годится шаблон описанный в приведенной Вами статье.
Главный же класс TFT_LCD занимается собственно отрисовкой линий, окружностей и шрифтов.

Спасибо

Я все-таки предположу, что пустая функция типа

void inline debug(const char*, type_of_somevar)
{
}

которая игнорирует аргументы, таки же будет удалена. Здесь print наверное имелся в виду, а не debug.
Однако ничто не мешает это проверить.
Или возможно я не понял Вашего вопроса?

Вероятно Вы имеете в виду пункт 11? Вначале он появился как шутка, потом я решил оставить его в качестве маркера прочитали / не прочитали.
Вы первый, поздравляю!

Очень правильное замечание. Должен признаться, мне пришлось одновременно работать над двумя версиями данной статьи. Русскоязычная версия находится перед вами, англоязычная, при благоприятном стечении обстоятельств, скоро тоже может стать доступной.
Говоря «производительность» (что у нас обычно воспринимается как скорость исполнения), я имею в виду значение слова «performance», которое имеет несколько более широкий смысл и в данном случае разумнее было бы применить слово «эффективность».
Спасибо Вам, видимо имеет смысл внести соответствующее исправление.
Что касается читабельности, зачастую код, в котором используются шаблоны, оказывается более читабельным. Разработка шаблонного кода штука действительно не простая, приходится иметь дело с очень недружелюбным синтаксисом, а вот для использования больших усилий не требуется, STL — хороший пример.
Еще раз спасибо за Вашу внимательность.

IAR вроде бы C++11 пока не поддерживает, к примеру.

Спасибо, порадовали. Честное слово, именно на этот эффект я очень надеялся. Первая пена прошла, рабочая неделя закончилась и настало время для вдумчивого прочтения-осознания.
По поводу типизации спорить не буду, она конечно же статическая, она же и строгая, в конце концов говорим мы здесь о C++ и упоминаем C. От кастинга enum-ов лично я бы воздержался, но удерживать кого-либо еще, не в праве. А вот по поводу причины отчего это все выглядит а-ля 2008. Причина видимо та же, что и у ребят, имена которых вы видите в списке литературы. Портируемость или как минимум стремление к ней. На моей рабочей машинке до сих пор живет win XP с 2008-й студией, там я бываю редко, а если и бываю, то лишь с одной целью — собрать какой-нибудь очередной кусок кода, который должен быть исполнен/продемонстрирован за пределами моего рабочего пространства.
Так что придирайтесь конечно, как бы мы ни старались, всегда еще остается над чем работать.
А за теплое слово спасибо, действительно приятно.