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

[Serega Doc]

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

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

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

[Serega Doc]

Это глупый вопрос который обсуждали миллион раз?

[Mahagam]

нет. как-то це-крест-крест не сильно прижился у эмбеддеров.

[Dima_G]

нет. как-то це-крест-крест не сильно прижился у эмбеддеров.

Да нет, нормально прижился. Просто тут ИМХО вопросы не конкретно эмбеддерские, а уровня проектирования.
Я так понимаю, у вас стоит вопрос расширивания общего ресурса между несколькими потребителями?
Это обычно решается с помощью драйвера устройства.

[AHTOXA]

Где инициализировать SPI блок AT Mega 168 в классе работы с регистром или же глобально во всей программе.

Поскольку к SPI могут обращаться разные устройства, то объект класса SPI надо сделать глобальным. В конструкторы объектов dataflash, HC595, DAC, ADC, которые висят на SPI, в этом случае надо передавать ссылку на класс SPI.

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

Наследовать в этом случае нельзя, а то получится по экземпляру SPI в каждом из объектов.

[Serega Doc]

Спасибо все заработало. Что бы не плодить тем буду в будущем писать сюда по вопросам проектирования.
Жаль что мне самому не пришла идея использовать указатель на SPI.

[ReAl]

Ну оно "так и надо по теории". Сама флешка не есть вариантом интерфейса SPI или там контроллера SPI, она только пользуется SPI как транспортом, класс флешки есть пользователем класа SPI, поєтому должен получать его для использования.
Если теперь две одинаковых флешки будут висеть на разных контроллерах SPI (один аппаратный, другой программный или один из них на соответствующем режиме USART), то просто два экземпляра одного и того же класса флешки получат по каналу SPI (по указателю или ссылке) для работы.

[Ink]

Наследовать в этом случае нельзя, а то получится по экземпляру SPI в каждом из объектов.

А не покатит сделать то, что "глобальное", статическим членом класса? Тогда все унаследуется нормально, без лишних сущностей. Или не?

[Dima_G]

А не покатит сделать то, что "глобальное", статическим членом класса? Тогда все унаследуется нормально, без лишних сущностей. Или не?

Объекты от статических членов не будут дублироваться только в случае создавание объектов от одного класса. В случае создания объектов от разных классов, объект SPI будет продублирован.

[neiver]

У меня есть некоторые интересные наработки на Си плюс плюс под АВР.
Например, виртуальные порты. Можно объединить от одной до 16 произвольно взятых ножек в такой виртуальный порт и манипулировать им как одним целым.
Кому интересно спрашивайте, раскажу подробнее.

typedef PinList<Pa1, Pa2, Pa3, Pb3, Pb4, Pb5> pins;

int main()
{
pins::DirWrite(0xff);
pins::Write(0xff);
}

[demiurg_spb]

Приведите для интереса asm листинг того, во что это скомпилится:

typedef PinList<Pa1, Pa2, Pa3, Pb3, Pb4, Pb5> pins;
pins::Write(0xff);

Мысль сама по-себе очень удачная. Вы молодец!

[Dima_G]

У меня есть некоторые интересные наработки на Си плюс плюс под АВР.
Кому интересно спрашивайте, раскажу подробнее.

Интересно
Выложите пожалуйста реализацию

[neiver]

Для

Код

typedef PinList<Pa1, Pa2, Pa3, Pb3, Pb4, Pb5> pins;
pins::Write(0xff);

листинг не очень интересный - всё заоптимизировалось в доску поскольку все значеня известны на момент компиляции:

Код

in    r24, 0x1b; 27
ori    r24, 0x0E; 14
out    0x1b, r24; 27

in    r24, 0x18; 24
ori    r24, 0x38; 56
out    0x18, r24; 24

Гораздо интереснее вот так:

Код

typedef PinList<Pa1, Pa2, Pa3, Pb3, Pb4, Pb5> pins;
pins::Write(PORTC);

Вместо PORTC можно подставить любое выражение невычисляемое на этапе компиляции.

Код

in    r18, 0x15; 21

in    r25, 0x1b; 27
mov    r24, r18
add    r24, r24
andi    r24, 0x0E; 14
andi    r25, 0xF1; 241
or    r24, r25
out    0x1b, r24; 27

in    r24, 0x18; 24
andi    r18, 0x38; 56
andi    r24, 0xC7; 199
or    r18, r24
out    0x18, r18; 24

Как-то так. Если различных портов в списке будет больше и ножки в них не будут упорядочены, то листинг соответственно будет больше.

Пример 1
Пример побольше
Реализация

Всё это реализовано на основе списков типов и с помощью очень злой и черной шаблонной магии

[Ink]

Объекты от статических членов не будут дублироваться только в случае создавание объектов от одного класса. В случае создания объектов от разных классов, объект SPI будет продублирован.

Нифига не понял. Вот пример:

Код

#include <iostream>

class A
{
  public:
  static int X;
  void printx() {std::cout << X << std::endl;};
  void setx(int x) {X=x;};
};
int A::X=0;


class B : public A
{
  public:
  void printx() {std::cout << X << std::endl;};
  void setx(int x) {X=x;};
};

class C : public A
{
  public:
  void printx() {std::cout << X << std::endl;};
  void setx(int x) {X=x;};
};


int main()
{
  A a;
  B b;
  C c;

  a.setx(10);
  a.printx();
  b.printx();
  c.printx();

  b.setx(20);
  b.printx();
  a.printx();
  c.printx();

  return 0;
}

Одна статическая переменная в базовом классе. От базового наследуются 2 класса, каждый видит одну и ту же переменную, так же, как если бы она была глобальной. Как бывает еще?

Ответ проги:
10
10
10
20
20
20

[sergeeff]

Нифига не понял.

Если вы посмотрите на sizeof(A) и наследуемые классы, то увидите, что int Х в них нет. А если уберете static, то размер классов увеличится.

Вот об этом и разговор.

[Mahagam]

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

[MrYuran]

программисты на Си обсуждают и решают проблемы конкретных контроллеров, конкретного железа. це-крест-крест добавляет к этим проблемам ещё и проблемы собственно языка.

Всё зависит от сложности и размера проекта.
С определённого момента дополнительные возможности, которые даёт язык, перекрывают его "проблемы".

[Ink]

Если вы посмотрите на sizeof(A) и наследуемые классы, то увидите, что int Х в них нет. А если уберете static, то размер классов увеличится.

Вот об этом и разговор.

Естественно X там нет, он лежит отдельно от всего в единственном экземпляре. Но я не понимаю вот этого:

В случае создания объектов от разных классов, объект SPI будет продублирован.

Это как так может быть? С чего создастся два разных Х?

це-крест-крест добавляет к этим проблемам ещё и проблемы собственно языка.

Конечно. И ровно то же самое говорят упертые ассемблерщики в сторону цешников (и справедливо, если на все смотреть плоско!). Смотрите на мир шире, не зря эти языки были придуманы, не зря существуют методы проектирования ПО. Естественно, что для простого SPI не нужно городить классы, но когда у вас будет огромный проект, вы встряните и будете долго понимать, как же так получилось непонятно.

Думается мне, что это не "проблемы языка", а банально проблемы от незнания языка. Это не характеризует язык.

[Mahagam]

я и смотрю широко. война с конструкциями языка (и только с конструкциями языка) - удел програмеров це++

[sergeeff]

я и смотрю широко. война с конструкциями языка (и только с конструкциями языка) - удел програмеров це++

В 1981 году мы делали статистический анализатор кардиоинтервалов на К580ИК80. У меня (единственного программиста) не было абсолютно ничего кроме блокнотика с клетчатой бумагой, таблицы мнемоники команд и программатора УФ ПЗУ. Все это было сделано, работало и получило награду на выставке в Женеве. Но ...!!! После этого я зарекся заниматься таким программированием. Мне ночами снились квадратики с кодами. Думается это одна из причин появления языков высокого уровня. Вторая причина - переносимость. Третъя - документированность (имею в виду, что если с вами что-то случается, то вашу работу легче кому-то подхватить).

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

[Mahagam]

где вы ратование за ассемблер увидели????

[sergeeff]

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

Или я чего-то не так понял?

[Mahagam]

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

[neiver]

Вы, видимо мало на С++ программировали...

На С++ можно писать более эффективные программы (по размеру/памяти/скорости) чем на чистом Си (применительно к 8-ми битникам в частности). И Наследование, инкапсуляция и полиморфизм (как динамический так и (особенно) статический) в этом только помошники а не проблемы. Это всего лишь средства языка, которые быдучи примененными к месту дают положительный результат. Ну а при неумелом использовании... Всё зависит от программиста.

Сообщение отредактировал neiver - Aug 3 2010, 11:29

[sergeeff]

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

Да, витиевато пишите. Сейчас только ваша мысль прояснилась.

По поводу С++. Очень хорошо на форуме сказал автор scmRTOS: С++ ничего не добавляет, если вы сами этого не просите.

[Ink]

программеры на Си воюют только с железом и со своими алгоритмами.

Это тоже ошибочное мнение Программеры на си, которые воюют, они воюют и с си! Потому что не знают языка! А те, кто знает, те не воюют, точно так же как и с си++.

[Mahagam]

во налетели.
ещё раз. чисто наблюдения показывают, что вопросы касаемые конструкций и возможностей языка у программистов Си практически не обсуждаются. зато активно муссируются у плюсистов. выводы какие?

[sergeeff]

во налетели.
ещё раз. чисто наблюдения показывают, что вопросы касаемые конструкций и возможностей языка у программистов Си практически не обсуждаются. зато активно муссируются у плюсистов. выводы какие?

Учите матчасть!

[MrYuran]

во налетели.
ещё раз. чисто наблюдения показывают, что вопросы касаемые конструкций и возможностей языка у программистов Си практически не обсуждаются.

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

[Dima_G]

Это как так может быть? С чего создастся два разных Х?

Прошу прощения
Почему-то показалось, что вы хотите не наследоваться от базового класса, а создавать статические члены в "потребителях" SPI

[Mahagam]

Учите матчасть!

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

[ReAl]

ещё раз. чисто наблюдения показывают, что вопросы касаемые конструкций и возможностей языка у программистов Си практически не обсуждаются. зато активно муссируются у плюсистов. выводы какие?

Ещё раз. Чисто наблюдения показывают, точнее, показали лет 12-16 назад, что вопросы, касаемые конструкций языка, у программистов на асм практически не обсуждаются, зато активно муссируются у С-шников. Помнятся по SU.CROSSTOOLS да RU.EMBEDDED имено такие "болезни роста" и точно так же многие тогда говорили, что фигня это всё и ассемблерщики борятся с железом и задачей, а С-шники с языком и компилятором. И много приходилось спорить и доказывать, что борьба с компилятором - просто от незнания основ языка в духе правил приведения типов.
Но по мере увеличения числа знающих С эти вопросы отпали, место С во встроенных системах никто не оспаривает. Сейчас слово "асм" заменилось на "С", "С" на "С++" и наблюдаем второй виток. От тех, кто не видел первого?

[Mahagam]

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

[MrYuran]

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

Поэтому пора уже думать об С#

[ReAl]

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

В упомянутые времена разговоров про "С-шники воюют с компилятором" языку С тоже много лет было, стандарту C89 было много лет, С99 был на подходе.
Но в нише мелкоконтроллеров он был многим в новинку, болезни роста не от возраста языа зависят, а от времени его применения в нише, так как это болезни роста не языка как такового.
Многие из тех, кто много лет просидел в этой нише на ассемблере - просто не воспринимали С. Вопросы "рискнувших" (в смысле применения С) укрепляли их в вере в то, что "С-шники борятся ..." дале по тексту. Но "рискнувшие" прошли свою фазу освоения языка и все те вопросы остались, но они теперь ассоциируются не со всеми, применяющими С, а только с новичками. А "тогда" практически все новичками и были, С был уделом программистов на "достаточно больших машинах", а "в эмбеддед ему не место" (хотя я удивлялся — почему на "ДВК-2" с 56К озу на всё про всё вместе с ОС ему за десять лет до этого было место, а на 8051 с 16-20-32К ПЗУ для автономной программы — так не место).

[sergeeff]

Поэтому пора уже думать об С#

С его то идеологией уборки мусора?

[MrYuran]

С его то идеологией уборки мусора?

А что там с идеологией не так?
Стековый язык, с уборкой проблем быть не должно

[sergeeff]

А что там с идеологией не так?
Стековый язык, с уборкой проблем быть не должно

http://msdn.microsoft.com/en-us/library/ms...28VS.90%29.aspx :

In C#, garbage collection is handled by the common language runtime (CLR) with similar functionality to that of the JVM. The CLR garbage collector periodically checks the memory heap for any unreferenced objects, and releases the resources held by these objects.

[Savrik]

Управляеймый код, конечно, хорошо в своей области, но, как правило, во встраваимых системах программист привык быть уверенным в том, что и как делает программа. А если забывать за собой убирать - наверное, стоит сменить профиль
Оффтоп. Почему C# не такой популярный? потому, что его разрабатывал мужик без бороды.

[Mahagam]

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

[sergeeff]

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

"С войной покончили мы счеты —
Бери шинель, пошли домой!"

[Rst7]

(хотя я удивлялся — почему на "ДВК-2" с 56К озу на всё про всё вместе с ОС ему за десять лет до этого было место, а на 8051 с 16-20-32К ПЗУ для автономной программы — так не место).

Потому что на архитектуру PDP-11 ложится идеально. А на 51 - увольте

[Serega Doc]

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

И если можно ответить еще на один вопрос.
Можно ли каким либо образом сделать переход из одного метода класса в другой не вызовом его через Call а переходом через Jmp.
Вернее что бы компилировалось так. А то сейчас у меня два метода которые возвращают один и тот же тип WatcherState
Но при этом один просто выполняет проверки и возвращает значение
Второй же более длинный по времени выполнения выполняет расчет и так же возвращает WatcherState
Вот как я это пока написал

Код

if (Tvalue == TimerValue)
    {
        return Next();
    }
    else
    {
        return WAIT;
    }

Что можете посоветовать?

[Ink]

Можно ли каким либо образом сделать переход из одного метода класса в другой не вызовом его через Call а переходом через Jmp.

Может я ошибаюсь, но сдается мне, что никак так не сделать. Либо как-то в отдельно взятом компиляторе, но все равно сомневаюсь. Очень.
А инлайн не подходит?

[neiver]

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

[Serega Doc]

Спасибо за рекомендации.
inline я активно использую в header файле.
И для данной функции это бессмысленно из-за дублирования кода.

Я в принципе тоже так думал что нет такой возможности. Но надеялся что я чего-то не ведаю.
Еще раз спасибо.

[XVR]

ReAl
зайдите на любой форум программеров - война с языком идёт вечно. причём чуть ли не с базовыми конструкциями.

Заходил. Видел борьбу начинающих со своей безграмотностью, борьбы ПРОГРАММИСТОВ с С++ не видел

[alexvok]

Посоветуйте пажалуйста книгу
С++ с примерами для AVR

[demiurg_spb]

Посоветуйте пажалуйста книгу
С++ с примерами для AVR

Боюсь, что таковых не имеется...

[neiver]

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

[777777]

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

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

[MrYuran]

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

Да хоть какие угодно.
Порт, например, чем вам не класс?
УАРТ?
АЦП?
Таймеры?
Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.
Почему бы не соединить вместе?

Adc->Init();
Adc->StartConversion();
...
Uadc = Adc->GetResult();

[777777]

Да хоть какие угодно.
Порт, например, чем вам не класс?
УАРТ?
АЦП?
Таймеры?

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

Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.
Почему бы не соединить вместе?

Adc->Init();
Adc->StartConversion();
...
Uadc = Adc->GetResult();

Это лишь видимость С++, в реальности это ничем не лучше вызова обычных функций. А от объектно-ориентированного программирования польза будет только если пользоваться всеми его особенностями - инкапсуляцией, наследованием, полиморфизмом. А для этого нужно весь проект рассматривать как поле для взаимодействия объектов, а не просто переделать проект на С++ потому что это модная фича.

Сообщение отредактировал 777777 - Aug 20 2010, 11:18

[MrYuran]

Это лишь видимость С++, в реальности это ничем не лучше вызова обычных функций. А от объектно-ориентированного программирования польза будет только если пользоваться всеми его особенностями - инкапсуляцией, наследованием, полиморфизмом. А для этого нужно весь проект рассматривать как поле для взаимодействия объектов, а не просто переделать проект на С++ потому что это модная фича.

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

Нет, это не классы. Это объекты, существующие в одном экземпляре.

Ни разу не видел контроллер с одним портом
Вот немного выше был пример, как можно очень удобно представить разрозненные пины разных портов как один обычный порт.
Лучшего примера, я думаю, не найти.
Ну и в конце концов, чуть приподнявшись и отвязавшись от железа, имеем обычную абстрактную программу, в которой можно применять все тонкости и возможности с++.
Я для пробы делал класс цифровых фильтров - очень удобно.
В одном объекте сосредоточен буфер с дискретными отсчётами, методы и выходное значение.
Опять же, можно сделать несколько разных фильтров с разными параметрами и характеристиками.

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

[dxp]

Нет, это не классы. Это объекты, существующие в одном экземпляре.

То, что классы нужно заводить только при возникновении необходимости во множественном (> 1) использовании объектов, - распространенный стереотип-заблуждение. Классы - это просто типы, определяемые пользователем, и использовать их имеет смысл во всех случаях, когда описание программных сущностей удобно воспринимать в виде законченных объектов, даже если такой объект в программе всего один. Классы, как типы, определяемые пользователем, позволяют программисту провести близкие аналогии между объектами реального мира и сущностями программы, что значительно облегчает процесс разработки, т.к. выводит логику программы на более высокий уровень абстракции (от низкоуровневого железа). К тому же, это обстоятельство позволяет в значительной мере формализовать процесс проектирования программы - т.е. составить проект ("рыбу") будущей программы из кубиков структурной схемы еще до написания первой строки кода.

Кстати, на том же С очень удобно заводить в структуру объекты, относящиеся к одному и тому же (по смыслу) месту программы, даже если таких структур нужна всего одна.

[MrYuran]

Кстати, на том же С очень удобно заводить в структуру объекты, относящиеся к одному и тому же (по смыслу) месту программы, даже если таких структур нужна всего одна.

Да, структура - частный случай класса.

[ReAl]

Ну вот как раз сегодняшний пример.
ATmega48. Программа сравнительно древняя на С (и нет желания её переписывать начисто, но что-то новое даже такого объёма будет сразу писаться на С++).
Дописывается кусочек функционала, понадобилось при входе в некоторый режим сохранить состояние некоторых выходов, выключаемых в этом режиме, а при выходе из режима восстановить. Ну всё понятно, заводится флаг нахождения в этом режиме (в режим может быть повторный вход, который теперь отличается тем, что сохраняь уже отключенные ножки не нужно) и буферная переменная для сохранения состояния выходов. Т.е. появляются две глобальных переменных файловой области видимости и связь между функциями через них.
На С++ все эти функции изначально объединяются в класс-«драйвер режима» и потом хоть обдобавляйся в этом классе приватных полей.
Казалось бы, между

Код

SomeModeOn();
SomeModeOff();

Код

someMode.On();
someMode.Off();

разницы не видно, «а она есть»©

Кстати, классы, изначально предназначенные для того, чтобы иметь только один экземпляр - вполне нормальное явление.

[MrYuran]

С++ с примерами для AVR

Может, напишем сообща?

Я уже название придумал.
"С++ в микроконтроллерах. Почему бы и нет?"
Экспортный вариант:
"С++ for microcontrollers. Why no?"

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

Спор "плюсы против бесплюсов" считаю таким же контрпродуктивным, как "асм против си".
Си вобрал в себя основные на тот момент методики структурирования ассемблера.
Плюсы - также включают основные методики из сишного программирования. То, что на си пишется в виде отдельного модуля, на с++ можно поместить в класс. Закрытые члены - это аналог static-функций и переменных. В общем, всё то же самое, только проще, короче, быстрее и нагляднее.
Точно так же, есть надстройки над с, дающие дополнительную абстракцию, например, компонентно-ориентированный диалект Nes-C, на котором написана TinyOS

Сообщение отредактировал MrYuran - Aug 23 2010, 09:03

[neiver]

Идея интересная. Я статью по этой теме пишу - никак не допишу... Времени мало. А тут книгу...

[777777]

Кстати, классы, изначально предназначенные для того, чтобы иметь только один экземпляр - вполне нормальное явление.

Да это явление может и нормальное, я не спорю. Хуже когда этот класс в принципе не может иметь несколько экземпляров - это уже архитектурная проблема, говорящая о том, что классу тут делать нечего. Можно например написать класс CIdle, который будет инкапсулировать в себе бесконечный цикл, имеющийся в любом контроллере:

Код

class CIdle
{
CIdle()
    {
    sei();
    while(1)
        {}
    }
}

Применение

Код

main()
    {
    // инициализация периферии
    ...
    // дальше работают только прерывания
    CIdle idle;
    }

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

"С++ в микроконтроллерах. Почему бы и нет?"
Экспортный вариант:
"С++ for microcontrollers. Why no?"

По-английски это не звучит, надо по-французски: pourquoi pas?

У "плюсов" есть ещё один несомненный плюс. Прежде чем сломя голову что-то писать, надо сначала продумать структуру.
То есть, дополнительный организующий момент.

Да, это действительно полезно...

[Andron_]

по осени начал писать проект для сигнальника TI, решил на свой страх и риск использовать С++ и динамическое управление памятью в некоторых моментах.
поскольку продумать изначально удачную структуру умишка не хватило (в-смысле, не смог) структура программы получилась путанная местами и через чур замудренная. Сейчас дописываю... Естественно, что писалось полгода назад я уже наглухо забыл. В-принципе, мне нравится - с помощью Doxygen'овской документации весьма приятно дописывать.
Динамическое выделение пока также работает стабильно, я боялся худшего.

Немного неудобно использовать inline функции в классах - CCS 3.3 корявенько их разворачивает в редакторе во время отладки и по шагам ходит как-то неправильно местами.

[ReAl]

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

Во-первых, если я хорошо высплюсь, то я и "чисто-С-шных" маразмов в ответ смогу придумать как доказательство того, что С в микроконтроллрах делать нечего.
Во вторых, в этой теме уже говорили - и в С несколько переменных, относящихся к одной и той же логической сущности, имеет смысл объединить в структуру даже если эта структра используется в программе в принципе один единственный раз. Это будет "архитектурной проблемой" ? Лучше пусть будет несколько на вид независимых переменных?

[xelax]

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

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

Выскажу кромольную мысль:
На архитектуру язык программирования влияет лишь косвенно. Этап перехода с С на С++ уже давным давно закончился (если кто-то ещё не заметил). Все более или менее крупные и что немаловажно УСПЕШНЫЕ компании специализирующиеся на разработке софте (и эмбеддед в том числе) начинают с UML или подобного дизайна. Да собственно это и есть основной этап. А в получившейся на выходе архитектуре-софте любая команда индо-китайских тупокодеров добьёт код за пару месяцев.

[MrYuran]

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

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

[ReAl]

Я бы сказал так — по сравнению с С язык С++ более жёстко наказывает за непродуманность структуры.

[dxp]

Я бы сказал так — по сравнению с С язык С++ более жёстко наказывает за непродуманность структуры.

Скорее более явно показывает (подчеркивает) корявости в этом контексте.

[Waso]

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

Может, напишем сообща?

Я уже название придумал.
"С++ в микроконтроллерах. Почему бы и нет?"

Желающие читать такие статьи есть! Вот по крайней мере я, например! Так-что жду с нетерпением.
А как наберете с десяток статей - соедините их в книгу и будете барыши получать.

[sergeeff]

А как наберете с десяток статей - соедините их в книгу и будете барыши получать.

Наивность впечатляет...

[Waso]

В чем же она заключается, наивность-то?

[DRUID3]

Этап перехода с С на С++ уже давным давно закончился (если кто-то ещё не заметил).

Да... я заметил. Закончился. Как и жизнь C++. Мало того - когда о Cpp забудут на C еще будут писать целые системы.

Все более или менее крупные и что немаловажно УСПЕШНЫЕ компании специализирующиеся на разработке софте (и эмбеддед в том числе) начинают с UML или подобного дизайна.

... Эмбэддед буржуи часто называют JavaME. А "подобный дизайн"... Так все с него начинают. Даже строители зданий из железобетонных блоков.

Да собственно это и есть основной этап. А в получившейся на выходе архитектуре-софте любая команда индо-китайских тупокодеров добьёт код за пару месяцев.

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

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

ага... И к постоянному переструктурированию. Сколькими способами можно разбить белый лист на подчасти!? Не даром в том же C++ есть все что-бы нарушить инкапсуляцию "если очень надо"... Ну а полиморфизм - это ли не повод накидать в проект всего чего не лень? То, что при этом он, зачастую теряет не только обозримость, но и простую читабельность(х.з. какую там из реинкарнаций и где вызывают - и не все IDE такие же функциональные как мелкософтовская визуалстудия). Ну а уж если появилась иерархическая модель классов - это верный признак, что от первоначальной архитектуры отказались , но переписать все заново не представляется возможным ввиду отсутствия времени совместно с запутанностью и нечитабельностью уже написанного кода.


Хорошая статья что-бы задуматься - а туда ли в жизни направляешь стопы свои...

[MrYuran]

Хорошая статья что-бы задуматься - а туда ли в жизни направляешь стопы свои...

Это всё конечно хорошо, в теории.
А в реальности никто не даст 20 лет на вылизывание кода, как в случае с академическим миниксом.
Зачастую цикл жизни изделия составляет от 2 до 5 лет.
Да и не в каждой конторе работают гении уровня Таненбаума.
Так что, оставшимся остаётся довольствоваться прозой и использовать общепринятые методики и наработки.
Тем более что действительно, лучше сегодня выпустить актуальное, хоть и несколько сырое изделие, чем завтра сидеть с вылизанным, но никому не нужным...

[sigmaN]

Хорошая статья что-бы задуматься - а туда ли в жизни направляешь стопы свои...

А вы никогда не слышали как Торвальдс критикует микроядра?

[neiver]

А вы никогда не слышали как Торвальдс критикует микроядра?

Торвальдс и Си++ усиленно критикует.
Мне нравится, что Steven Dewhurst ему на это отвечает.

[halfdoom]

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

Вот большой проект: http://www.freebsd.org/cgi/cvsweb.cgi/src/. C++ есть только в библиотеках для C++. Ничего, не встряли. А NetBSD из той-же серии так вообще на тьму платформ портирована, и во многом благодаря здоровому консерватизму.

[Dima_G]

Вот большой проект: http://www.freebsd.org/cgi/cvsweb.cgi/src/. C++ есть только в библиотеках для C++. Ничего, не встряли. А NetBSD из той-же серии так вообще на тьму платформ портирована, и во многом благодаря здоровому консерватизму.

А в чем плюс то голого сишного подхода? Никто не спорит, что все, что пишется на С++, можно сделать и на Си.
Вопрос - какими средствами и какой надежностью.

[SasaVitebsk]

Мне кажется, всётаки, что сравнение переходов ASM->C и C->C++ некоректно. Так как первый решает главную задачу - убирает зависимость программиста от процессора (не от переферии). Эта задача глобальна для эмбеддера. И эта задача решается как академически так и практически. Соответственно повышается переносимость, возможность заимствований. Вроде бы переход C->C++ академически решает те же задачи. Но, на мой взгляд дальнейшие шаги в данной области целесообразны лишь при однотипных задачах.
Например, если программист непрерывно работает с графикой, то лучше потратить кучу времени написать и вылизать соответствующие классы работы с графикой. Но если он сегодня работает с ШД, а завтра с CAN, а послезавтра с графикой, то возникают нюансы.
Собственно эти нюансы просты. Написал я свои классы на тему конечных автоматов - потратил время. Вылизал - потратил время. А далее написал 10 проектов никакого отношения к этому не имеющещих. Через 2 года у меня появилась тема где, казалось бы можно применить наработки по конечным автоматам. И что будет? Я потрачу минимум неделю чтобы всё вспомнить и проникнуться высоким уровнем моих наработок, ещё неделю чтобы соотнести то решение с новым проектом. Естественно выяснится, что в чистом виде это чуть-чуть не подходит. И надо добавить пару новых свойств и чуть подправить реализацию. Причём лучше это сделать так, чтобы новый класс работал бы и со старым приложением. Надо честно признаться (хотя бы себе), что создавать новый класс, производный от старого, учитывая что старый писали тоже вы и, учитывая, что вы просто не учли вот этот вот нюанс, что вылез в новом проекте, вы не станете. Далее вам опять придётся проникнуться всеми нюансами разработки вашего класса, опять потребуется время для написания и отладки, чтобы через год-два вам мифически было бы проще всё это использовать.
Конечно, можно сказать что это произойдёт в случае низкого уровня программиста. А я вам возражу, что в случае низкого уровня программиста этот класс придётся переписать заново, а не чуть-чуть подправить.

По-моему, С++ это всётаки удел крупных контор с большим коллективом программистов, с чётким разделением задач, с проектами близкой направленности, с хорошей документированностью наработок и т.д и т.п. Пытаться одному программисту "охватить необъятное" (читай ... изучить и использовать все новейшие течения в области программирования) будет провальным. Из-за физической невозможности.

[one_man_show]

В своей практике стараюсь сделать примеры применения своего "творчества", чтобы легче передавалось по наследству и самому быстрее въезжать, что наваял лет пять тому назад. Времени и терпения писать документацию по своим наработкам в 99% случаев не хвататет, поэтому примеры применения с коментариями выручают. Какой язык программирования при таком подходе уже не имеет значения.

[Harvester]

В чем же она заключается, наивность-то?

А Вы давно покупали книги по электронике/программированию?

[halfdoom]

А в чем плюс то голого сишного подхода? Никто не спорит, что все, что пишется на С++, можно сделать и на Си.

Я же написал про портирование на множество платформ. На момент портирования NetBSD лишь для немногих из них был вменяемый компилятор С++. Соответственно и у нас имеется определенное количество наработок на голом С, причем многим из них уже за 10 лет. Смысла в переписывании нет.

Вопрос - какими средствами и какой надежностью.

Сисадмин говорит, что предыдущая инкарнация нашего сервера под FreeBSD имела аптайм 3.5 года и была обновлена из-за переезда на новое железо.

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

Ну и классика сравнения этих языков для встраиваемых систем: "есть два пути: можно грамотно использовать все возможности C либо ограниченный набор возможностей C++" - кто сказал это не помню, но сказано верно.

[MrYuran]

А Вы давно покупали книги по электронике/программированию?

Если я вижу стоющую книгу, я её покупаю не задумываясь, на конторские деньги либо на свои.

[DRUID3]

offtop

А вы никогда не слышали как Торвальдс критикует микроядра?

Торвальдс и Си++ усиленно критикует.

Авторитет Торвальдса все-таки сильно завышен. Нет, разумеется он молодец - написать свою до конца работоспособную ОС-ку еще в студенческие годы(когда вечно не хватает времени) и "раздать ее людям"... Но... Если задуматься - студенческую ОС без прикладного софта напарить можно разве что тем людям которые профинансировали "сапфировые носители" для украинской центральной библиотеки. Да и писать UNIX, пусть и самобытный, по книжке это не одно и то же, что придумать UNIX. Чувствуете разницу?

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

Я когда-то Вам, sigmaN, не ответил(не было времени на развернутый ответ) что-же быдлокодерского в Линуксе. В самом коде - качественно ничего. Но в архитектуре - это "в лоб" написаный UNIX переживший несколько конструктивных потрясений. Ну каГбЭ бульварный роман написанный на безупречном русском .

Кстати темные силы мировой закулисы не столь коварны(там точно нет русских или украинцев - иначе голову Столмена нашли бы под Белой Церковью, в лесу, делов то ) сколь дальновидны. Ни для кого не секрет, что дикие народности типО иранцев, украинцев, русских и китайцев беззастенчиво используют свободное ПО (которое писАли люди со всего мира) в том числе и в военной технике. Не повод ли задуматься - а стОит ли при этом "раздавать" самое лучшее ...

P.S.: да, я сторонник теории заговоров и не стыжусь этого ...

P.P.S.: "диким народностям" стоит задуматься, что не все "свободное ПО" одинаково полезно , и верные инвестиции сеодня(инвестиции интеллекта в том числе) завтра могут обернуться качественным(ключевым) преимуществом в целой отрасли. Это на просто на каждом углу кричать "о, свободное ПО... а-а-а-а...у-у-у-у... э-э-э-э... Покупайте наше свободное ПО" ...

P.P.P.S.: готов поспорить, что та же история и с т.н. "нейронными сетями" - как по мне, то это "каша из топора". Жаль, что это уж совсем-совсем оффтоп...

end_offtop

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

 linux_0.01.tar.gz ( 71.38 килобайт ) Кол-во скачиваний: 47

 

[sigmaN]

Блни, а зря оффтоп прикрыли.
Вот щас про Торвальдса потроллить бы, а))))

Сисадмин говорит, что предыдущая инкарнация нашего сервера под FreeBSD имела аптайм 3.5 года и была обновлена из-за переезда на новое железо.

Прям 3.5года без единого ребута??? Я в восторге!

Лично я абсолютно согласен с Торвальдсом, что такие вещи как ядро ОС на С++ лучше не писать.И аргументирует он своё мнение.
Один мой знакомый говорит что типа забивать гвозди можно и ноутбуком... Конечно, он на много круче, чем обычный молоток, но... улавливаете мысль, нам то гвоздь забивать надо и в деле забивания гвоздя - молоток зэ бэст.
А ещё Торвальдс правильно сказал как-то что-то типа: компиляторы, языки - всё это инструменты в наших руках и если мы будем идти на поводу у своих инструментов или не делаем чего-то, потому что нам не позволяют наши инструменты, то как-бы пора бы может быть нам сменить профессию или поменять инструменты. (как-то так, за достоверность не ручаюсь)
Но, конечно, тема вообще холливарная пошла....завязывать надо..

P.S. Без оффтопа жить тяжело. Чё, мож и вправду на шараге зарегиться......

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

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

Сравнение некорректно. Ноутбук изначально не предназначен для забивания гвоздей. Есть такие специальные пневматические молотки, для которых гвозди выпускаются в кассетах. Вот это больше похоже - можно с чувством, не спеша, накачивая мышцу забивать ручным молотком, а можно нажав кнопку загнать пневматическим. Плата - стоимость инструмента (читай - необходимость изучать С++) и несколько более высокая стоимость гвоздей в кассете по сравнению с гвоздями россыпью в ящике (читай - некоторые накладные расходы типа кода вызова конструкторов). Но если покупать гвозди не по одинаковому количеству, а, скажем, закупить количество гввоздей, которое можно забить за час одним и вторым инструментом, то выясняется, что это количество гвоздей в кассетах уже подходит под понятие "мелкий опт" и по мелкооптовым ценам гвоздь даже с дополнительной кассетой стоит дешевле, чем гвоздь без кассеты по розничным. Вот такое сравнение мне кажется более похожим на C/C++.

Ну или сравните лопату и экскаватор. Только лопату берите не с Джамшутом впридачу, а с профессиональным копателем. И посчитайте, сколько надо заплатить профессиональному оператору лопаты за рытье траншеи, скажем, м*м*км и сколько будет стоить та же работа, выполненная экскаватором с профессиональным оператором экскаватора за рычагами. И сравните затраченное в обоих случаях время.

[sigmaN]

Нет, точно пора завязывать, оффтоп же!

[halfdoom]

Прям 3.5года без единого ребута??? Я в восторге!

Поскольку он периодически хвастался растущим аптаймом, то на 3 году я решил поинтересоваться "а не зря ли мы его кормим" (имелся в виду сисадмин). Действительно, uptime был за тысячу с лишним дней, все порты были аккуратно обновлены и даже пересобраны некоторые системные библиотеки и демоны. Но ядро оставалось прежним и перезагрузок не требовалось.

[neiver]

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

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

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

 

[MrYuran]

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

Отличная статья!
И намного нагляднее, чем 6 страниц руками махать.
Рекомендую разместить в разделе статей.
Обсуждение здесь

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

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

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

Код

#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() ?

[WHALE]

Код

void LCDwrite4(uint8_t value)
{
    LDP &= ~(1<<LCD_D7|1<<LCD_D6|1<<LCD_D5|1<<LCD_D4); //clear data bus
    
    if(cmd & (1 << 0))
        LDP |= LCD_D4;
    if(cmd & (1 << 1))
        LDP |= LCD_D5;
    if(cmd & (1 << 2))
        LDP |= LCD_D6;
    if(cmd & (1 << 3))
        LDP |= LCD_D7;
}

В аргументе фукции value на cmd замените.
А вообще-то отличная статья,спасибо!

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

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

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

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

[ReAl]

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

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

[MrYuran]

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

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

[halfdoom]

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

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

[dxp]

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

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

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

[halfdoom]

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

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

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

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

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

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

[BSVi]

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

[neiver]

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

PS.
Если кто хочет опубликовать статью у себя - пожалуйса!
Ссылаться можно на мой Git репозиторий:
AvrCpp

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

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

 

[sigmaN]

Великолепная статья!
Самому очень понравилась!
Немного пропиарил ))
DI HALT'у тоже понравилась и теперь её можно лицезреть у него на сайте

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

И да, ВСЕХ С ДНЕМ ПРОГРАММИСТА!!!!
Чистого и безглючного кода нам всем