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

[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.

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

[MrYuran]

Позволю себе добавить, что отличная, но однобокая иллюстрация.

Ну так представьте народу второй бок, в виде контр-статьи. Чтобы можно было пользоваться, а не голословно.

[halfdoom]

Ну так представьте народу второй бок, в виде контр-статьи. Чтобы можно было пользоваться, а не голословно.

Была такая идея, но все сильно завязано на нашу внутреннюю инфраструктуру на экспозицию которой никто добро не даст. Со временем попробую отделить мух от котлет.

То, о чем вы говорите, - это ортогональная вещь. Нативный код - это нативный код, и он обладает такими свойствами, которые не заменят никакие кодогенераторы. Есть отличный кодогенератор COG, который позволяет писать определения прямо в исходном коде. И в ряде случаев это действительно удобная и мощная штука.

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

Конечно, для одного небольшого проекта в год вариант описанный в статье закрывает почти все нужды, но для больших объемов, как показывает практика, что описанный мной подход, ИМХО конечно, оказался гораздо удобнее.

Замечание насчет нативного кода не ясно - код созданный на базе описателей является нативным и даже оптимизированным под конкретный МК или компилятор.