Перейти к содержанию

    

Как делить программу на объекты?

Нет иного программирования, кроме ООП, и С++ его пророк. Однако, не могу понять, как следовать этой вере.

Есть у меня Com-порт, по которому компьютер передает команды прибору и получает результаты их выполнения. В микроконтроллере делаю кольцевые буферы для приема и передачи. Чтобы писать и читать в них, имею по паре указателей. Чтобы контролировать, что указатели в пределах буферов, имею пару констант - границ. Принимаю и отправляю сообщения в прерываниях. Для разбора принятой команды - своя функция, для выполнения - несметная масса функций. Ответ опять же в буфере надо подготовить.

Вопрос - Какой класс объекта мне создать? Хочу Com_port, например. Но функции выполнения команд, логично, в нем быть не должны. Тогда и разбор команды - тоже? Тогда доступ к буферам должен быть снаружи класса. И прерывания - их же не спрячешь в класс?

В общем, как раньше не мог сообразить, так и сейчас. :to_become_senile:И терпеть нет мочи. Подскажите, что и как робить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

COM порт + прерывания + кольцевой буфер - в один объект (сам буфер можно сделать отдельным объектом и использовать как член класса, если хочется)

Разбор команды - другим объектом. Общаться между ними через метод типа 'взять строку' (ну или как они у вас там нарезаются)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот прерывания - в обработчике прерывания, получив символ, обращаться к функции записи в буфер, принадлежащей объекту Com_port? Как бы, лишние дёргания.

Я же не могу сам обработчик прерывания спрятать в класс? 

Теперь "взять строку" - не пересылать же строку из буфера порта в буфер, скажем, парсера? То есть, дать парсеру доступ в буфер порта? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В буфер складывает драйвер который обрабатывает прерывания. Он же выставляет флаг наличия новых данных. Т.е. по сути это одна функция.

А уж объект занимается чтением флага и если находит его установленным читает данные и парсит их.

На счёт передачи парсеру и доступа в буфер. Может быть по разному. Если жёсткая экономия времени то можно и указатель передать. Если не жёсткая то да складываем комманды в новый буфер и парсе их исполняет по мере сил и возможностей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
53 минуты назад, ViKo сказал:

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

м.б. небесполезен и третий указатель -- просмотр без изъятия

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 минуты назад, Vladivolt сказал:

м.б. небесполезен и третий указатель -- просмотр без изъятия

Так я и читаю без изъятия. Я же микроконтроллер программирую.

10 минут назад, MegaVolt сказал:

В буфер складывает драйвер который обрабатывает прерывания. Он же выставляет флаг наличия новых данных. Т.е. по сути это одна функция.

Т.е., обработчик прерывания? Тогда ему и буфер принадлежит? Я не хочу иметь глобальный буфер. Или Com_port и будет являться драйвером?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 минуты назад, ViKo сказал:

Так я и читаю без изъятия. Я же микроконтроллер программирую.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 минуту назад, Vladivolt сказал:

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

Нет, повторного чтения не нужно. Зачем? Раз прочитал, считайте, освободил. Если команда правильная - выполнил. Нет - ответил "Ошибочная команда".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
7 минут назад, ViKo сказал:

Если команда правильная - выполнил. Нет - ответил "Ошибочная команда".

Как определяется момент "пора анализировать и исполнять команду"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
17 минут назад, Vladivolt сказал:

Как определяется момент "пора анализировать и исполнять команду"?

По символу конца строки (нуля, то есть).

Вы меня вовлекаете в разговор, не относящийся к сути вопроса. Хотите иметь три указателя - пусть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

От него (packet) наследуется класс(ы) MyDevice_A_Protocol . . . . MyDevice_Z_Protocol  (форматирование данных в пакет для передачи, парсер для приема)

Например, на шине RS485 устр-ва, из которых считывается иформация, имеют различные форматы пакетов и/или алгоритмы подсчета CRC.

Я принял веру, пройдя по этому пути .... :)

 

ps

Я так не делал, но можно packet в свою очередь унаследовать от самого "низкоуровневого" класс вроде frame_IO (самые низкоуровневые данные и функции, аналог аппаратного узла сетевого контроллера или драйвера конкретного узла конкретного контроллера). 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
8 минут назад, k155la3 сказал:

Самое простое - для коммуникационного обмена - базовый класс "packet" (формирование заголовка пакета, просчет CRC. Передача пакета. Прием пакета.

Хорошо, так куда прерывание по приему символа впихнуть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 минуты назад, ViKo сказал:

По символу конца строки (нуля, то есть).

Вы меня вовлекаете в разговор, не относящийся к сути вопроса. Хотите иметь три указателя - пусть.

к сути вопроса - разделение ответственности...

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Обработчик складывает в буфер и проверяет на конец строки. Если конец - дает сигнал задаче разбора. Так было.

 

Еще вот что. Мне не нужно ничего наследовать. Я не пишу универсальных программ. Никаких базовых классов и т.п. Я просто хочу видеть свою программу более структурированной. Но не усложненной.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 minute ago, ViKo said:

Хорошо, так куда прерывание по приему символа впихнуть?

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

(если конечно, у Вас "пакетный" обмен данными а не "поточный"). Эти флаги - "отображать" на класс frame_IO.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти