[psyhologic 0]

С 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. 

Изменено 9 февраля, 2019 пользователем psyhologic

[ViKo 1]

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

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

[k155la3 26]

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);	// некритичная ошибка - принято больше байт, чем размер пакета, но пакет корректен
}

 

[ViKo 1]

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

[AHTOXA 14]

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

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

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

[Forger 17]

14 hours ago, ViKo said:

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

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

 

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

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

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

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

 

 

[ViKo 1]

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

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

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

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

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

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

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

[AlexandrY 3]

47 minutes ago, ViKo said:

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

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

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

[agregat 0]

1 hour ago, ViKo said:

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

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

 

[Forger 17]

2 hours ago, ViKo said:

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

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

 

49 minutes ago, agregat said:

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

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

[AlexandrY 3]

11 minutes ago, Forger said:

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

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

[Forger 17]

 

8 minutes ago, AlexandrY said:

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

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

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

 

8 minutes ago, AlexandrY said:

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

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

 

[AlexandrY 3]

5 minutes ago, Forger said:

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

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

[Nixon 3]

А я приведу. Несколько абстрактный пример, но 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);
}

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

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

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

[Forger 17]

8 minutes ago, AlexandrY said:

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

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

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