C++ и ООП для микроконтроллеров AVR Опции

[koluna]

Здравствуйте!

Что вы думаете по поводу ООП для микроконтроллеров AVR на языке C++?

Благодарю заранее!

[yanvasiij]

В С++ вы пишете в module.h:

Код

class Module { private: int data;};

И эта переменная у вас инициализирована не будет.

Ну я так понимаю на то конструкторы и есть. Мне вот только не совсем понятно: можно ли объявлять объект - не создавать его динамически. То есть в приведенном Вами примере создание объекта вот так:

Код

class Module { private: int data;};

Module myModule;

int main (void)
{
    myModule.data=100500;
    while(1)
...
}

Можно так:
...

Не совсем понял: Вы передали указатель на функцию обработчик прерывания в метод InitIsr?

[doom13]

Не совсем понял: Вы передали указатель на функцию обработчик прерывания в метод InitIsr?

Теперь для каждого объекта можно задать свой обработчик прерывания, Ваши предложения...
Моя практика показала, что если обработчик прерывания - член класса, то он должен быть статик, или не работает. Т.о. это выбрано для реализации возможности задать собственный обработчик прерывания для каждого объекта.

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

Ваши предложения...

Код

class driver
{
public:
    void isr_handler();
    ....
};

driver Device1;

ISR(XXXX_vect)
{
    Device1.isr_handler();
};

[doom13]

Код

class driver
{
public:
    void isr_handler();
    ....
};

driver Device1;

ISR(XXXX_vect)
{
    Device1.isr_handler();
};

В таком исполнении ISR() нельзя сделать членом какого-то класса.

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

В таком исполнении ISR() нельзя сделать членом какого-то класса.

А зачем ему быть членом класса? Оно даже логически слабо в класс просится. Членом класса является isr_handler(). Допустим у вас 4 UARTa: класс - один, объектов - 4, вектора прерываний для каждого объекта свои и каждый вектор вызывает один и тот же обработчик но для своего, конкретного объекта. С натяжкой можно было бы согласиться спрятать ISR внутрь класса для периферии, которая на кристалле одна. Но где гарантия, что завтра не придется переносить этот код на кристалл, у которого этой периферии две или три?

[doom13]

А зачем ему быть членом класса? Оно даже логически слабо в класс просится. Членом класса является isr_handler(). Допустим у вас 4 UARTa: класс - один, объектов - 4, вектора прерываний для каждого объекта свои и каждый вектор вызывает один и тот же обработчик но для своего, конкретного объекта. С натяжкой можно было бы согласиться спрятать ISR внутрь класса для периферии, которая на кристалле одна. Но где гарантия, что завтра не придется переносить этот код на кристалл, у которого этой периферии две или три?

Для каждого объекта, естественно, свой обработчик, его и задаём при помощи InitIsr (RegisterIsr если нравится).

Хорошо, но допустим есть какой-то класс Device, у него есть интерфейс управления (class Spi), интерфейс передачи данных (class Uart), системный счётчик (class Timer), для каждого необходимо задать обработчик прерывания. Ну а обработчик прерывания логически просится в класс Device, т.к. он непосредственно и выполняет операции необходимые для функционирования Device.

Допустим в системе пять таймеров, для каждого нужен свой обработчик. Логично всё "одинаковое" запихнуть внутрь класса, обработчик, который может отличаться для каждого таймера реализовать как callback-функцию.

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

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

Угу. И каждый имеет свой вектор прерывания ISR(Timer_XX_vect) Как все пять обработчиков сделать статическими членами класса timer? Или я чего-то не понял в вашей идеологии?

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

Угу, как callback или как виртуальную функцию. Или построить наследников на шаблонах используя Curiously recurring template pattern (я так думаю, сам не пробовал пока).

[doom13]

Угу. И каждый имеет свой вектор прерывания ISR(Timer_XX_vect) Как все пять обработчиков сделать статическими членами класса timer? Или я чего-то не понял в вашей идеологии?

Все пять обработчиков и не являются статическими членами класса Timer. У Timer есть только функция регистрации прерывания. Обработчик прерывания необходимо зарегистрировать после создания объекта.

Угу, как callback или как виртуальную функцию. Или построить наследников на шаблонах используя Curiously recurring template pattern (я так думаю, сам не пробовал пока).

Тут не понял иронию, что не так в моей реализации? Всё работает и , по-идее, нет никаких противоречий. Можно и унаследовать если есть желание.