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

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

С MBED у меня опыта не много, а вот с ООП высокоуровневых языках предостаточно. Позвольте вставить свои 5 копеек.

 

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

CycleBuffer - класс / структура представляющая результаты чтения / записи. Можно вдохновиться здесь - http://nginx.org/en/docs/dev/development_guide.html#buffer

ProtocolParser - работает с SerialPort / CycleBuffer, реализует разбор и копирование данных на специализированные Packets. Прячет всю работу с SerialPort от остального приложения.

Packet и наследники Packet - фрейм вашего протокола разложенный на структуры / классы.

MyProtocol - логика разбора и обработки пакетов протокола. Содержит instance ProtocolParser. Может быть построен по разным шаблонам проектирования.

 

P.S. ViKo вы забыли упомянуть какую событийную модель использует ваше приложение. Request - Response / Publisher - Subscriber / etc. 

Изменено пользователем psyhologic

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


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

Я описывал. Запрос от компа (команда) - ответ от прибора. По крайней мере, так представляю сейчас. 

Внутри прибора тоже что-то типа конечного автомата. 

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


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

6 hours ago, ViKo said:

Я описывал. Запрос от компа (команда) - ответ от прибора. По крайней мере, так представляю сейчас. 

Если со стороны PC, то Вам не обязательно использовать кольцевой буфер и объект-класс порта.

Системные ф-ии API ReadFile() ReadFileEx() изначально работают "блочно", и их "байтовое" использование как-бы сомнительно.

Это старый "баян" на форуме.

// выдать в компорт запрос PC --> device 
// RET кол-во реально переданных байт
int CorrPC_Req::CorrPC_SendReq( void ) 
{	memset(RxPacketArr, 0x00, sizeof(RxPacketArr) );	// подготовка для чтения Rsp
	WriteFile(SerialPort, TxPacketArr, PacketTxSize, &real_write, NULL);
	return real_write;
}

int CorrPC_Req::CorrPC_GetResp( void )
{	real_read = 0;
	ReadFile(SerialPort, RxPacketArr, 50, &real_read, NULL);
	return real_read;
}

// проверка принятого пакета
// RET - наличие ошибок.
// (+1) - ошибок нет. (+2) - длина больше требуемой
// (0) - ничего не принято
// (-1)ошибки длины, (-2)шаблона, (-3)контр. суммы
int CorrPC_Req::CorrPC_TestResp( void )
{
	// -- 0 --
	if( real_read == 0 ) return( 0 ); // ничего не принято
	// -- 1 --
	if( real_read < PacketRxSize ) return(-1); // длина пакета недостаточна
	// -- 2 --
	for(int i=0; i<pktTemplateLen; i++)
	{	int testIndex = pktTemplate[i][0];
		if( RxPacketArr[testIndex] != pktTemplate[i][1] ) return(-2); // не соответствует шаблону
	}
	// -- 3 --
	int i_crc16 = fast_crc16( 0xFFFF, RxPacketArr, PacketRxSize); // (всего пакета, включая CRC)
	if( i_crc16 != 0x00 ) return(-3);	

	if( real_read == PacketRxSize )
		return(1);
	else
		return(2);	// некритичная ошибка - принято больше байт, чем размер пакета, но пакет корректен
}

 

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


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

Речь идет, естественно, о программе в микроконтроллере. И не о том, какие функции и буферы использовать, а какие создавать классы, и создавать ли. По словам некоторых опытных специалистов они в данном случае не нужны. Ок.

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


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

14 часов назад, ViKo сказал:

По словам некоторых опытных специалистов они в данном случае не нужны. Ок.

Почему-то я с самого начала топика не сомневался в таком выводе :)

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


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

14 hours ago, ViKo said:

 а какие создавать классы, и создавать ли.

Если вся эта затея только лишь ради наличия слова class в коде, то безусловно это ни к чему :don-t_mention:

 

зы. Потребность в слове class в коде возникает, когда возможностей struct уже не хватает.

Если не хватает class, то на помощь придет template

Если же и этого мало, то пришло время слезать из морально устаревшего C++03 на что-то посвежее.

Нынче подавляющее число стороннего кода требует компилятора от C++11 и выше.

 

 

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


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

1 час назад, AHTOXA сказал:

Почему-то я с самого начала топика не сомневался в таком выводе :)

Я знаю, вы в C++ собаку съели, и обратно деградировать не видите смысла. Я же, действительно, не понимаю, что мне дадут классы. С целью ограничить видимость переменных должны справляться namespace. А битами порта, к примеру, я и без шаблонов манипулирую легко. :prankster2:

56 минут назад, Forger сказал:

Если же и этого мало, то пришло время слезать из морально устаревшего C++03 на что-то посвежее.

Нынче подавляющее число стороннего кода требует компилятора от C++11 и выше.

Вот на C++11 и лезу. Воспользуюсь мелкими  интересными свойствами. Но без ООП.

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


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

47 minutes ago, ViKo said:

Я же, действительно, не понимаю, что мне дадут классы.

Классы, конечно, всего лишь синтаксис.
Чтобы разрабатывать аппаратный слой  надо видеть его место в стеке. 
Сам по себе слой UART порта не интересен. 
Вот когда он одинаково легко встраивается в сетевой стек под PPP или в коммуникационный по MODBUS или в Bluetooth под HCI, вот тогда он приобретает ценность и силу.
Но если порт используется на примитивном уровне, стеков нет, о RTOS только понаслышке, то тогда да, классы C++ и только они. :to_become_senile:    

Кстати сейчас в тренде ThreadX, так вот там никакого C++, просто жестко забанен.
Зато самая быстрая RTOS на рынке и сертифицирована под SIL4!

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


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

1 hour ago, ViKo said:

Вот на C++11 и лезу. Воспользуюсь мелкими  интересными свойствами. Но без ООП.

Да правильно Вы все понимаете. Нет никакого смысла разворачивать классы ради двух объектов. Тем более на микроконтроллере.

 

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


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

2 hours ago, ViKo said:

Вот на C++11 и лезу. Воспользуюсь мелкими  интересными свойствами. Но без ООП.

А смысл использовать плюсы без ООП? Все равно, что на С писать объекто-подобный код, используя структуры.

 

49 minutes ago, agregat said:

Тем более на микроконтроллере.

Вот только не надо опять раздувать старый холивар ;)

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


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

11 minutes ago, Forger said:

Вот только не надо опять раздувать старый холивар ;)

Эт не холивар, а честная конкуренция. Меряться тут никто не запрещал. :biggrin:
И мы по прежнему ждет демонстрацию ваших скилов в виде той эпической библиотеки на С++ способной конкурировать с чем-нибудь скромненьким типа Renesas SSP.
Докажите что с помощью C++ вы хоть на грамм эффективнее работаете чем "обычный" программист железа.  

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


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

 

8 minutes ago, AlexandrY said:

И мы по прежнему ждет 

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

Менять точку зрения этой персоны у меня желания нет. Поэтому предлагаю на этом закончить.

 

8 minutes ago, AlexandrY said:

Докажите что с помощью C++ вы хоть на грамм эффективнее работаете чем "обычный" программист железа.  

Вам я ничего доказывать не собираюсь.

 

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


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

5 minutes ago, Forger said:

Вам я ничего доказывать не собираюсь.

Ну так не надо тогда пенять на холивар.   

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


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

А я приведу. Несколько абстрактный пример, но sapienti sat

struct FOO {
    int A;
    int B;
};

struct BAR {
    const FOO* foo;
    const int  sum;
};

constexpr int sum (const FOO foo) {
    return foo.A + foo.B;
} 

constexpr FOO foo1 {1,2};
constexpr FOO foo2 {2,4};

const BAR bar1 {&foo1, sum(foo1)};
const BAR bar2 {&foo2, sum(foo2)};

void main ( void ) {
    
    int X = bar1.sum + bar2.sum;
        
    while(1);
}

Чтоб было понятнее - скриншотик

Снимок.JPG

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

P.S. Я кстати современный С++ и рассматриваю только в плане улучшения "препроцессинга".

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


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

8 minutes ago, AlexandrY said:

Ну так не надо тогда пенять на холивар.   

У вас, как я понял, панический страх перед наличием C++ кода с ООП внутри микроконтроллера. Этот страх - ваша проблема. Эта Ваша "проблема" не имеет отношения к этой теме.

Но вы правы - не буду мешать раздувать меха в старом махровый баяне в стиле "плюсы внутри МК" :)

 

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


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

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...