Arlleex 178 15 апреля Опубликовано 15 апреля · Жалоба 5 минут назад, x893 сказал: Хорошо что ИМХО. У меня примерно как Forger написал. Работает всё прекрасно. Данные по указателю. И с динамическими и со статическими данными. Работает все прекрасно и у меня. И 15 лет назад тоже все работало. Меня интересовало, додумалось ли C++ сообщество до чего-то более удобоваримого в этом плане. P.S. Какие указатели в протоколе передачи данных??? Вы о чем? Вроде понятно, что данные снабжаются КС и уже улетают в провод. 3 минуты назад, juvf сказал: Использование В дизасм смотреть или даже не пытаться?🙂 P.S. Я с МК тоже отправляю, так что способ ищу легковесный. Если нет - мне проще (как всегда, собственно) написать свой небольшой класс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 55 15 апреля Опубликовано 15 апреля · Жалоба 12 minutes ago, Arlleex said: Меня интересовало, додумалось ли C++ сообщество до чего-то более удобоваримого в этом плане. Каждый сам додумывается, что ему удобоваримо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 15 апреля Опубликовано 15 апреля · Жалоба В 15.04.2024 в 12:27, Arlleex сказал: Работает всё прекрасно. Данные по указателю. В 15.04.2024 в 12:27, Arlleex сказал: Какие указатели в протоколе передачи данных??? ни каких указателей в протоколе передачи данных нет. Данные по указателю улетают. Не указатели, а данные. Мне кажется задача действительно тривиальная. Свой класс-обёртка к указателю данных (без std::*). Легковесно и тривиально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 55 15 апреля Опубликовано 15 апреля · Жалоба 39 minutes ago, juvf said: задача действительно тривиальная Полностью согласен Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 апреля Опубликовано 15 апреля · Жалоба 2 hours ago, Arlleex said: ИМХО, ужасное решение🙂 Потому что у меня десятки разных управляющих структур бегают, с разным содержимым и длиной. Контрольную сумму логично располагать где-то в одном конкретном месте для всех структур так я ж о чем и пишу - ДО начала данных, а не как у вас - в конце у меня было всегда примерно в таком порядке: заголовок, код команды, длина поля данных, КС (всего кадра или только данных), сами данные и финальный заголовок (если нужен), как например это сделано в CAN можно КС размещать и после данных, но для этого ОБЯЗАТЕЛЬНО нужно в кадре указывать сколько их (поле длины), иначе как понять где искать эту самую КС? можно КС разместить в самом начале, сразу после заголовка, если он конечно одинаковый для всех кадров, может быть у вас окончание кадра определяется по межсимвольному таймауту, и между кадрами время тоже ограничено минимальным значением, то тогда да, можно отказаться от поля длины данных в особо тяжелых случаях можно использовать составной кадр - управляющая часть со своей КС, это кадр строго фиксированного размера и кадр с данными, там своя КС в этом случае в кадре данных действительно достаточно разместить в их начале заголовок, потом данные и потом КС, но даже в таком случае в управляющем кадре все равно есть поле длины кадра с данными был у меня такой проект и в нем были команды с кадрами данных и без Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 16 апреля Опубликовано 16 апреля · Жалоба В 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 21 16 апреля Опубликовано 16 апреля · Жалоба 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 26 16 апреля Опубликовано 16 апреля · Жалоба 7 minutes ago, razrab83 said: CRC удобней размещать в конце пакета, даже если пакеты разной длинны. известный факт, но это если длина пакета заранее известна, тогда конечно кс можно размещать где угодно весь нюанс в том, чтобы понять где именно в пакете эта КС после данных, если заранее не известна длина этого поля данных до того, как они все пришли 11 minutes ago, razrab83 said: в конструкторе можно динамически выделять память т.е. использовать кучу, если это не пугает, то тогда уж проще сразу уходить на std::vector, коли сели на плюсы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 16 апреля Опубликовано 16 апреля · Жалоба 1 минуту назад, Forger сказал: весь нюанс в том, чтобы понять где именно в пакете эта КС после данных, если заранее не известна длина этого поля данных до того, как они все пришли не очень понятно... зачем знать где конец данных, ДО того как они все пришли? Пришел пакет - вот длинна, получи и распишись. Не весь пришел пакет - жди когда прийдет весь. В бинарных протоколах всегда обычно известен размер пакета. Даже если размера нет в самом пакете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 75 16 апреля Опубликовано 16 апреля · Жалоба 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 17 16 апреля Опубликовано 16 апреля · Жалоба В 16.04.2024 в 14:51, _pv сказал: удачи с выравниванием, упаковкой.... а так же с Little Endian и Big Endian Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 16 апреля Опубликовано 16 апреля · Жалоба 22 minutes ago, razrab83 said: Пришел пакет - вот длинна, получи и распишись. Во первых - длиНа, во-вторых, как понять что пакет пришел? байт стаффинг с уникальных завершающим символом или межкадровый таймаут? если нет ничего из этого, а данные идут потоком, то как вы предлагаете понять где они закончились не зная заранее их ожидаемый объем? 24 minutes ago, razrab83 said: В бинарных протоколах всегда обычно известен размер пакета. в изначальном посте не было ни слова про некие "бинарные" протоколы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 16 апреля Опубликовано 16 апреля · Жалоба 1 минуту назад, Forger сказал: как вы предлагаете понять где они закончились не зная заранее их объем? о каком протоколе говорим? Длинннна пакетов в бинарных протоколах известна ещё на этапе карандаша и черновика. Вы не сможете реализовать обмен данными, тем более защищать что-то там избыточным кодом, какие-то объемы данных, не зная размер этих объёмов. Допустим модбас: в каких-то пакетах есть размер данных, в каких-то нет. Но размеры всех всех пакетов известны на этапе проектирования. Пакет запрос чтения группы регистров - фиксированной длинннны. В пакете ответ чтения группы регистров - размер в пакете. Пакет теста - другой размер фиксированной длиннны. Все пакеты разной длинннны, но всё это можно посчитать в рантайме и без всяких пауз. Можете сунуть 100 пакетов в один приёмный буфер и он легко разгребается на отдельные пакеты и легко определяется длиннна каждого и соответственно вычисляется CRC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 16 апреля Опубликовано 16 апреля · Жалоба Цитата При корректной реализации CRC, когда исходные данные и CRC возвращают нулевое значение CRC, это означает, что нет ошибок в данных, так как контрольная сумма успешно проверена. Вся вишенка CRC. Если CRC не в конце, то ..... В 16.04.2024 в 14:58, Forger сказал: в изначальном посте не было ни слова про некие "бинарные" протоколы Так это понятно из структуры TxRS485. А вы о каких протоколах говорите? О текстовых? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 16 апреля Опубликовано 16 апреля · Жалоба 10 minutes ago, razrab83 said: о каком протоколе говорим? ни а каком, речь про то, что было изначально в посте - указана только структура кадра, но нет ни слова как определяется его конец в потоке данных 2 minutes ago, juvf said: А вы о каких протоколах говорите? я - ни о каких, вижу тут просто поток байтов, из которых каким-то образом вычленяется заголовок и остальные данные, вопрос был лишь к crc, выше расписал, что к чему повторяться не хочу Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться