[Arlleex 131]

5 минут назад, x893 сказал:

Хорошо что ИМХО. У меня примерно как Forger написал. Работает всё прекрасно. Данные по указателю. И с динамическими и со статическими данными.

Работает все прекрасно и у меня. И 15 лет назад тоже все работало.

Меня интересовало, додумалось ли C++ сообщество до чего-то более удобоваримого в этом плане.

P.S. Какие указатели в протоколе передачи данных??? Вы о чем? Вроде понятно, что данные снабжаются КС и уже улетают в провод.
 

3 минуты назад, juvf сказал:

Использование

В дизасм смотреть или даже не пытаться?🙂

P.S. Я с МК тоже отправляю, так что способ ищу легковесный.

Если нет - мне проще (как всегда, собственно) написать свой небольшой класс.

[x893 40]

12 minutes ago, Arlleex said:

Меня интересовало, додумалось ли C++ сообщество до чего-то более удобоваримого в этом плане.

Каждый сам додумывается, что ему удобоваримо.

[juvf 10]

В 15.04.2024 в 12:27, Arlleex сказал:

Работает всё прекрасно. Данные по указателю.

 

В 15.04.2024 в 12:27, Arlleex сказал:

Какие указатели в протоколе передачи данных???

ни каких указателей в протоколе передачи данных нет. Данные по указателю улетают. Не указатели, а данные.

Мне кажется задача действительно тривиальная. Свой класс-обёртка к указателю данных (без std::*). Легковесно и тривиально. 

[x893 40]

39 minutes ago, juvf said:

задача действительно тривиальная

Полностью согласен

[Forger 17]

2 hours ago, Arlleex said:

ИМХО, ужасное решение🙂 Потому что у меня десятки разных управляющих структур бегают, с разным содержимым и длиной. Контрольную сумму логично располагать где-то в одном конкретном месте для всех структур

так я ж о чем и пишу - ДО начала данных, а не как у вас - в конце

у меня было всегда примерно в таком порядке: заголовок, код команды, длина поля данных, КС (всего кадра или только данных), сами данные и финальный заголовок (если нужен), как например это сделано в CAN

можно КС размещать и после данных, но для этого ОБЯЗАТЕЛЬНО нужно в кадре указывать сколько их (поле длины), иначе как понять где искать эту самую КС?

можно КС разместить в самом начале, сразу после заголовка, если он конечно одинаковый для всех кадров,

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

 

в особо тяжелых случаях можно использовать составной кадр - управляющая часть со своей КС, это кадр строго фиксированного размера и кадр с данными, там своя КС

в этом случае в кадре данных действительно достаточно разместить в их начале заголовок, потом данные и потом КС, но даже в таком случае в управляющем кадре все равно есть поле длины кадра с данными

был у меня такой проект и в нем были команды с кадрами данных и без

 

 

 

 

 

[AHTOXA 14]

В 15.04.2024 в 11:47, Arlleex сказал:

Можно ли в C++ как-то красиво описать структуру с гибким положением последнего элемента?

Допустим, есть структура

struct TxRS485 {
  Header hdr;
  u8     byte[N];
  u32    crc;
}

N должно будет стать известно в рантайме, поэтому шаблоны тут вряд ли помогут.

Можно crc засунуть в Header, раз уж он у всех пакетов есть. Насколько я понимаю, и N будет там же, в Header. А в конце будет byte[maxLen].

В 15.04.2024 в 12:27, Arlleex сказал:

Если нет - мне проще (как всегда, собственно) написать свой небольшой класс.

Ну а почему бы и не написать, если небольшой? 🙂

[razrab83 17]

23 часа назад, Forger сказал:

можно КС разместить в самом начале

На сколько я понял, не стоит вопрос "помогите разработать новый протокол и формат пакета". Вопрос стоит "подскажите, как переехать в с++, и красиво оформить существующий протокол"?
 

class TxRS485 
{
	public:
		TxRS485(u8* frame);

	//api 
	struct Header getHeader() const;
	u8 getSize() const; //размер данных, который N
	const u8 *getData() const; //вовращает указатель на данные, на "u8 byte[N]"
	const u8 *getFrame() const; //возвращает указатель на весь пакет, на "Header hdr"

private:
	u8 *frame; //сырые нераспарсеные данные всего пакета, включая заголовок, данные, КС.
};

в конструкторе можно динамически выделять память и копировать туда весь пакет, а можно просто указатель TxRS485::frame инициализировать аргументом конструктора frame.  Отправка в провод по указателю

TxRS485 command(rxBuf);
//обработка command
Uart::send(command.getFrame(), command.getSize());

 

 

ps

КС CRC удобней размещать в конце пакета, даже если пакеты разной длинны. Многие CRC имеют свойства, при котором расчет нового CRC для пакета из "данных+CRC" даёт 0. Удобно проверять
 

if(calcCrc(frame, size) == 0)// где size = sizeof(Header) + sizeof(data) + sizeof(crc)
{
	//пакет валидный
}

 

В 15.04.2024 в 14:10, Forger сказал:

иначе как понять где искать эту самую КС?

в конце пакета )))

[Forger 17]

7 minutes ago, razrab83 said:

CRC удобней размещать в конце пакета, даже если пакеты разной длинны.

известный факт, но это если длина пакета заранее известна, тогда конечно кс можно размещать где угодно

весь нюанс в том, чтобы понять где именно в пакете эта КС после данных, если заранее не известна длина этого поля данных до того, как они все пришли

 

11 minutes ago, razrab83 said:

в конструкторе можно динамически выделять память

т.е. использовать кучу,

если это не пугает, то тогда уж проще сразу уходить на std::vector, коли сели на плюсы

[razrab83 17]

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

весь нюанс в том, чтобы понять где именно в пакете эта КС после данных, если заранее не известна длина этого поля данных до того, как они все пришли

не очень понятно... зачем знать где конец данных, ДО того как они все пришли? Пришел пакет - вот длинна, получи и распишись. Не весь пришел пакет - жди когда прийдет весь.

 

В бинарных протоколах всегда обычно известен размер пакета. Даже если размера нет в самом пакете.

[_pv 53]

On 4/15/2024 at 8:47 AM, Arlleex said:

Допустим, есть структура

struct TxRS485 {
  Header hdr;
  u8     byte[N];
  u32    crc;
}

там что-то в последние плюсовые стандарты добавляли из С про стуктуры и VLA, может и это уже научились.

 

для месье понимающих толк, С вроде как умеет вот так:

int get_data_size(){ return 0xF + (rand() & 0xF);}

int main(){
  struct { uint8_t hdr[8]; uint8_t byte[get_data_size()]; uint32_t crc; } *pkt = (void*)data;
  pkt->crc = 42;
...

удачи с выравниванием, упаковкой (переносимой между компиляторами) и валидацией значений, возвращаемых get_data_size

[juvf 10]

В 16.04.2024 в 14:51, _pv сказал:

удачи с выравниванием, упаковкой....

а так же с Little Endian и Big Endian

[Forger 17]

22 minutes ago, razrab83 said:

Пришел пакет - вот длинна, получи и распишись.

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

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

24 minutes ago, razrab83 said:

В бинарных протоколах всегда обычно известен размер пакета.

в изначальном посте не было ни слова про некие "бинарные" протоколы

[razrab83 17]

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

как вы предлагаете понять где они закончились не зная заранее их объем?

о каком протоколе говорим? Длинннна пакетов в бинарных протоколах известна ещё на этапе карандаша и черновика. Вы не сможете реализовать обмен данными, тем более защищать что-то там избыточным кодом, какие-то объемы данных, не зная размер этих объёмов. Допустим модбас: в каких-то пакетах есть размер данных, в каких-то нет. Но размеры всех всех пакетов известны на этапе проектирования. Пакет запрос чтения группы регистров - фиксированной длинннны. В пакете ответ чтения группы регистров - размер в пакете. Пакет теста - другой размер фиксированной длиннны. Все пакеты разной длинннны, но всё это можно посчитать в рантайме и без всяких пауз. Можете сунуть 100 пакетов в один приёмный буфер и он легко разгребается на отдельные пакеты и легко определяется длиннна каждого и соответственно вычисляется CRC.

[juvf 10]

Цитата

При корректной реализации CRC, когда исходные данные и CRC возвращают нулевое значение CRC, это означает, что нет ошибок в данных, так как контрольная сумма успешно проверена.

Вся вишенка CRC. Если CRC не в конце, то .....

 

В 16.04.2024 в 14:58, Forger сказал:

в изначальном посте не было ни слова про некие "бинарные" протоколы

Так это понятно из структуры TxRS485. А вы о каких протоколах говорите? О текстовых?

[Forger 17]

10 minutes ago, razrab83 said:

о каком протоколе говорим?

ни а каком, речь про то, что было изначально в посте - указана только структура кадра, но нет ни слова как определяется его конец в потоке данных

2 minutes ago, juvf said:

А вы о каких протоколах говорите?

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

вопрос был лишь к crc, выше расписал, что к чему повторяться не хочу