ООП подход в программировании AVR на С++ (не Си!) Опции

[Дуглас Шеппард]

Народ!
подскажите, дайте ссылку, или кто знает просто расскажите
как правильно писать на С++ для AVR-ов, с учетом всех тонкостей
контроллеров, например функции обработчиков прерываний,
может ли обработчик быть мембером класса,
или как правильно создать прог. инт-фейс для перефирийного устройства
например УАРТа или др.
какие нибуть примеры, личный опыт....
но только С++, не Си! непутать объектное со структурным.....

[IgorKossak]

alexander55, оба Ваших последних "зачем" можно добавить третьим - "зачем ООП?".
Дело в том, что и обработчик прерывания и любой внутренний ресурс можно безболезненно сделать статическим членом класса. Я это делаю постоянно и мне лично это кажется удобным.
Смысл?
Да всё тот же, что и в ООП как таковом: инкапсуляция, сокрытие, и т. д., и т. п.

[alexander55]

alexander55, оба Ваших последних "зачем" можно добавить третьим - "зачем ООП?".

Игорь, про третье "зачем ООП" у меня вопросов нет. Я сам стою горой за ООП.

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

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

[IgorKossak]

-в чем Вы видите удобство использования обработчика прерывания, как члена класса (а не функции, в него входящей);

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

-чем хуже макроопределение ресурса, чем определение его, как члена класса.

Да ни чем не хуже.
Всё зависит от конкретного случая и личных предпочтений.
Вопрос ведь был: "Можно ли?". Ответ: "Да, можно".
Я в своё время пробовал по всякому, и продолжаю решать вопросы разными методами.
Например, если порт целиком используется для одной цели - управления LCD, то его целиком мне было удобно определить в классе, назначив пинам или группе пинов нужные функции.
В другом проекте, где исходя из удобства трассировки, линии управления LCD оказались принадлежащими разным портам, я работал через макроопределения.

[alexander55]

Спасибо, я понял мысль.

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

Я для LCD поступал аналогично (так удобнее).

Спасибо dxp за пояснение.