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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

Для

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


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

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


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

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

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

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



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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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