Jump to content

    

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

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

Edited by psyhologic

Share this post


Link to post
Share on other sites

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

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

Share this post


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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
14 часов назад, ViKo сказал:

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

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

Share this post


Link to post
Share on other sites
14 hours ago, ViKo said:

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

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

 

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

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

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

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

 

 

Share this post


Link to post
Share on other sites
1 час назад, AHTOXA сказал:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
47 minutes ago, ViKo said:

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

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

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

Share this post


Link to post
Share on other sites
1 hour ago, ViKo said:

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

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

 

Share this post


Link to post
Share on other sites
2 hours ago, ViKo said:

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

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

 

49 minutes ago, agregat said:

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

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

Share this post


Link to post
Share on other sites
11 minutes ago, Forger said:

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

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

Share this post


Link to post
Share on other sites

 

8 minutes ago, AlexandrY said:

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

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

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

 

8 minutes ago, AlexandrY said:

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

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

 

Share this post


Link to post
Share on other sites
5 minutes ago, Forger said:

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

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

Share this post


Link to post
Share on other sites

А я приведу. Несколько абстрактный пример, но 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. Я кстати современный С++ и рассматриваю только в плане улучшения "препроцессинга".

Share this post


Link to post
Share on other sites
8 minutes ago, AlexandrY said:

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

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now