[ReAl 0]

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

+1

Нутром чуял, что что-то такое реально сделать, но всё страшно за Александреску взяться :-) Точнее, за глубокое влезание в шаблоны.

Увы, у меня С++ больше как «С с классами» идёт, хоть я и понимаю, что этого мало.

 

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

 

p.s[1] По поводу лицензии.

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

[halfdoom 0]

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.

 

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

[ReAl 0]

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

...

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

И Вам спасибо за иллюстрацию, или, по крайней мере, её фрагмент.

Зато пример автора полный, по которому можно учиться и которым можно пользоваться :-)

Если бы, чтобы уйти от упрёка в однобокости, в такой объём кто-то попытался бы втиснуть «чуть менее, чем все» возможности, то это было бы несколько страниц реферативного журнала, по которому можно было бы узнать о спектре идей, но ничему нельзя было бы научиться. Такое тоже полезно и это ждёт своего автора.

Каждая иллюстрация однобока, и только их множество создаст более-менее полную картину.

На то и фрум.

 

 

[MrYuran 17]

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

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

[halfdoom 0]

Если бы, чтобы уйти от упрёка в однобокости, в такой объём кто-то попытался бы втиснуть «чуть менее, чем все» возможности, то это было бы несколько страниц реферативного журнала

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

 

[dxp 38]

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

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

 

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

[halfdoom 0]

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

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

 

 

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

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

 

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

 

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

[BSVi 0]

Уже некоторое время пишу на плюсах в эмбеддед-проектах. Довольно удобно получается. Я бы не сказал, что плюсы не прощают архитектурные ошибки. Скорее, плюсы сужают область поиска правильной архитектуры - каждая сущность - класс. Кроме того, существует куча паттернов, о которых так много говорят программеры для "старших братьев". Собственно, сейчас изучением паттернов я и занят. После статьи я понял, что стоит почитать еще и Александреску.

[neiver 0]

Я исправил высказынные замечания и некоторые опечатки.

Вот исправленная версия.

 

PS.

Если кто хочет опубликовать статью у себя - пожалуйса!

Ссылаться можно на мой Git репозиторий:

AvrCpp

CppGpioForAvr.zip

[sigmaN 0]

Великолепная статья!

Самому очень понравилась!

Немного пропиарил ))

DI HALT'у тоже понравилась и теперь её можно лицезреть у него на сайте

 

P.S. аффтар жги ещё! это очень круто ;)

 

И да, ВСЕХ С ДНЕМ ПРОГРАММИСТА!!!!

Чистого и безглючного кода нам всем :cheers:

[drvlas 0]

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

 

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

Автору - успехов!

 

А то, что есть другие методы - дык! Флаг в руки! Покажите нам красиво :)

Изменено 13 сентября, 2010 пользователем drvlas

[Гость DL36]

Мне тоже понравилось, хотя на плюсах не пишу начал добавлять на вики сахары

[Sergey_B 0]

В функции UppendReadValue есть ошибка - portValue должно сдвигаться в противоположном направлении.

 

При использовании в IAR есть нюансы:

1. Для подавления довольно громоздких предупреждений компилятора подправить функции UppendValue и UppendReadValue подобным образом:

    if (IsSerial<Typelist<Head, Tail> >::value)
    {
       #pragma diag_suppress = Pe062
        if ...
        else ...
        #pragma diag_default = Pe062
     }
     else
     {
         ...
         return value | ....
      }

 

2. Для получения заявленной автором эффективности, в макросе MAKE_PORT заменить вызовы функций data(), dir() и pin() непосредственно соответствующими параметрами макроса, т.к. IAR не оптимизирует ссылки на порты.

 

3. Конструкции типа #ifdef PORTA в IAR не работают, т. к. PORTA не является макроопределением. Тут уж по собственному усмотрению, ну и конечно не забыть про include guard.

[neiver 0]

Спасибо за отзыв и найденную ошибку.

1. Переделаю вскоре, чтоб не было предупреждений, я уже знаю как.

2. Впринципе, data(), dir() и pin() это просто артефакт. В них реальной необходимости нет.

3. Я с этим сталкивался, но пока не знаю, что с этим делать.

Include guard есть - #pragma once. Или IAR такую форму не понимает?

[Sergey_B 0]

В IAR используется "классическая" конструкция в заголовочных файлах:

 

#ifndef FILENAME_H

#define FILENAME_H

...

...

...

#endif

 

 

> 3. Я с этим сталкивался, но пока не знаю, что с этим делать.

 

Я заменил их макроопределениями типа USE_PORTA, которые объявляю в файле подобном avr/io.h для нужных мне контроллеров.