Как ПРАВИЛЬНО программировать на С++, Вопросы по программированию на С++ для микроконтроллеров. Опции

[Serega Doc]

Добрый день. Учусь программировать на С++.
И иногда возникают вопросы в правильном проектировании классов.
Сейчас описываю класс для работы с последовательными регистрами 74HC595.
Уже есть класс для работы с SPI.
Где инициализировать SPI блок AT Mega 168 в классе работы с регистром или же глобально во всей программе.
Сейчас SPI будет использоваться только в регистрах.
Но в будущем планирую параллельно регистрам подключить еще и FLASH память (еще один класс по работе с памятью FLASH) на SPI.

Что посоветуете?

Вдогонку PS
И как правильно писать классы для регистров и FLASH наследовать от SPI или же внутри классов объявлять член класса SPI?

[neiver]

Господа/Товарищи/Эмбеддеры/Радио коты (нужное подчеркнуть), я таки худо-бедно да дописал ранее обещенную статью про организацию ввода-вывода для МК семейства AVR на Си++.
Собственно, статья состоит из двух основных частей. Первая - обзорная о том как ввод-вывод организуется на цистом Си. Вторая - как это можно сделать на Си++.
Конструктивные комментарии/замечания/пожелания приветствуются.

Прикрепленные файлы

 CppGpioForAvr.zip ( 139.07 килобайт ) Кол-во скачиваний: 262

 

[Сергей Борщ]

Конструктивные комментарии/замечания/пожелания приветствуются.

Опенофис показал множество опечаток. Периферия пишется через "е" - это сразу бросилось в глаза. Продолжаю читать.

Код

#define PortaBits (*((Bits*)&PORTA))

пропущен volatile

Код

    static void Set()
    {
        *(uint8_t*)(PORT + __SFR_OFFSET) |= (1 << PIN);
    }

Снова пропущен volatile

Код

    typedef TPin<Porta, 0> Pa0;

....
    Pa0.SetDirWrite(); // <- разве тут не должно быть Pa0::SetDirWrite() ?

[Сергей Борщ]

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

[ReAl]

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

+1
Нутром чуял, что что-то такое реально сделать, но всё страшно за Александреску взяться :-) Точнее, за глубокое влезание в шаблоны.
Увы, у меня С++ больше как «С с классами» идёт, хоть я и понимаю, что этого мало.

p.s[0] Отличная иллюстрация того, что программисты на С борятся с аппаратурой (вручную маски битов собирают), а программисты на С++ борятся с компилятором (заставляют его делать тупую работу).

p.s[1] По поводу лицензии.
scmRTOS тоже поначалу была (L)GPL, но там не совсем понятно с использованием в проектах с закрытыми исходниками вот таких библиотек уровня исходников. И Гарри перевёл её на нечто MIT/BSD-подобное.

[halfdoom]

p.s[0] Отличная иллюстрация того, что программисты на С борятся с аппаратурой (вручную маски битов собирают), а программисты на С++ борятся с компилятором (заставляют его делать тупую работу).

Позволю себе добавить, что отличная, но однобокая иллюстрация. Автор абсолютно не упоминает о возможности описания проекта на языках с гораздо более гибкими и удобными конструкциями. Ведь никто не обязывает втискивать себя в прокрустово ложе препроцессора C или шаблонов C++. Современные скриптовые языки вроде ruby или python позволяют эффективно описать проект (причем не только МК но и всю периферию) и автоматически сгенерировать все требуемые макроопределения, функции, файлы конфигурации и документации, причем генератор легко может учитывать особенности целевого компилятора или ассемблера. При этом сложность описания не ограничивается парой портов.

Приведу усеченный пример:

Код

require 'atmega162'
require 'unitimer'

M = ATMega162.new

M.device_name = "My Super Device"
M.clksrc = :FAST_CRYSTAL
M.clkfreq = 14.3e6
M.bldr_size = 2048

M.hw_version = [1, 2]
M.fw_version = [1, 1]

#
# Pins configuration
#
M.dp :A, 0, :KBDR0,     :IN,  :PULLUP    :desc => "kbd row 0"
M.dp :A, 1, :KBDR1,     :IN,  :PULLUP    :desc => "kbd row 1"
...
M.dp :C, 0, :LED_A,    :OUT,  :INIT1,        :desc => "Display1, seg A"
M.dp :C, 1, :LED_E,    :OUT,  :INIT1,        :desc => "Display1, seg E"
M.dp :C, 2, :LED_C,    :OUT,  :INIT1,        :desc => "Display1, seg C"
M.dp :C, 3, :LED_F,    :OUT,  :INIT1,        :desc => "Display1, seg F"
M.dp :C, 4, :LED_B,    :OUT,  :INIT1,        :desc => "Display1, seg B"
M.dp :C, 5, :LED_D,    :OUT,  :INIT1,        :desc => "Display1, seg D"
M.dp :C, 6, :LED_G,    :OUT,  :INIT1,        :desc => "Display1, seg G"
M.dp :C, 7, :LED_H,    :OUT,  :INIT1,        :desc => "Display1, seg H"

#
# define pins group for display segements
#
M.dg :LED_SEGMENTS, 8, [:LED_A, :LED_B, :LED_C, :LED_D, :LED_E, :LED_F, :LED_G, :LED_H]

#
# unitimer configuration, period 20uS, mode - OCR
#
M.unitimer(20e3, :OCR)
M.UT.add "05S",     500e3, :timer_05s_handler
M.UT.add "LED",        200, :led_timer
M.UT.add "MODBUS",    :MODBUS_TIMER_TICK, :mb_timer
...
M.sources=%@
  main.c
  leds.c
  control.c
  heater.c
@

Функциональность объекта ATMega162 имеющего общим предком семейство МК АВР понимает не только определения портов и групп битов, но и может быть расширена за счет подключения дополнительных модулей как unitimer в этом примере. Так, аналогичные расширения имеются для шин Modbus, Microlan, pcuart, пресловутого 44780, sed1520. Более того, поскольку уже все описано на языке высокого уровня, генератор учитывает конфигурацию фьюзов и генерирует соответствующие секции Makefile'ов учитывая особенности AvReal или avrdude.

Значительным преимуществом данного подхода является и то, что вся конфигурация собрана в один или несколько однородных файлов, что резко снижает вероятность непреднамеренных ошибок.

[dxp]

Позволю себе добавить, что отличная, но однобокая иллюстрация. Автор абсолютно не упоминает о возможности описания проекта на языках с гораздо более гибкими и удобными конструкциями. Ведь никто не обязывает втискивать себя в прокрустово ложе препроцессора C или шаблонов C++.

То, о чем вы говорите, - это ортогональная вещь. Нативный код - это нативный код, и он обладает такими свойствами, которые не заменят никакие кодогенераторы. Есть отличный кодогенератор COG, который позволяет писать определения прямо в исходном коде. И в ряде случаев это действительно удобная и мощная штука. Но пример использования С++, приведенный в обсуждаемой статье, не нуждается ни в каких кодогенераторах - он предельно лаконичен, полон, прост в использовании и эффективен. Да, он сложен в реализации. Все эти трюки тов. Александреску - это высший пилотаж плюсового программирования, они требуют глубокого понимания концепций языка, а это приходит только с опытом его использования. Вот это и есть главная проблема для эмбеддеров - такого опыта у них, как правило, нет (по вполне объективным причинам). Поэтому этот код с шаблонами, списками типов и прочим для большинства - китайская грамота. Хотя при наличии отлаженной библиотеки можно использовать и не страдать. Необходимость вникать потребуется в случае портирования ее на другую платформу.

Но в любом случае есть мотив осваивать подобные средства. А автору статьи - большущий респект: очень нетипично для эмбеддера поднять такой уровень понимания С++! В статье навести корректуру (поправить опечатки, ошибки) и однозначно поместить в библиотеку форума.