juvf

немного офтопа.... т.е. функции отправки получают указатель на void char, и размер. внутри writeTxFIFO() знать не знает о структуре пакета, ну может быть в конец src[] прикрутит u32 crc. Тогда смысыл вот этого... Даже не смысл.... а... вот дали мне стуктуру struct FlexFrame { Header hdr; int length; u8 data[128]; // уговорили, путь будет 128. считай что для ПЛК u32 crc; }; //Передает вы её очевидно так void main() { struct FlexFrame frame; writeTxFIFO( (u8*)&frame, sizeof(frame)); } Так где "проще читать"? и " сходу въехать в порядок разложения этой порнографии на байтики в реальном проводе.". внутри writeTxFIFO() вообще фиолетого, там в провод по байтикам раскладывается тупо массив по указателю. А из "девственной" структуры видно, что сначало идет Header hdr; Смотрим описание Header - там стутура адрас, стурктура типа, структвра... в ней структура... и ещё структыра (гляньте какую нибудь стуктуру в девственном виде в ядре linux). Понятно, что по *.cpp/*.h класса разложить в уме всю верёвку битов в проводе не просто, но и по структуре изучать протокол... видеть что за чем в проводе... тоже какой-то зашквар. Передавать исходный код др. разработчику для изучения протокола - так себе затея. Я предпочитаю сделать класс-фрейм. Спрятать все в методы, в приваты... в виртуальный функции... отладить и забыть. И если отдам это другому, то вместе с этим описание протокола. Не должен разработчик смотреть, что там в проводе, ползая по хидерам стурктур. Вот например, описание протокола Movilink Создал протокол, написал библиотеку для работы с ним (классы или структуры, с или с++, или вообще жава/паскаль), и выдал как библиотеку. Хоть в src, хоть скомпилеиную как lib. А чтобы было видно что в проводе - вот pdf-ка. Я обычно описываю достаточно подробно свои протоколы, не так конечно наглядно... но есть куда стремится. ИМХО. ps а подскажите - это word? Или какойнить специальный редактор для вёрстки? pps Весна!

мне не надо. я для 10 байт выделю 10. Да, это просматривается. Просто ещё бывает, что разработали контроллер для одной задачи, а потом смогли его использовать в другой. а потом в 3-ей.... а потом в 100-ой. Обычно, при таком подходе нет издержек на разработку нового железа, нет издержек на расширение элементной базы...

памяти для ТЗ хватает. кому-то не хватает .... чего-то, поэтому кому-то приходится городить память 12.8 раз больше требуемой задачи.

вы вообще о чем говорите? какое внешнее ОЗУ SPI? Есть железо собранное. Есть задача - написать ПО для этого железа. Выделяйте для 10 байт - массив в 128 байт. По другому не умеете - делайте как умеете.

на всякий случай, я цифру 128 написал от балды, это лишь для примера было.

смотрю.... 12,5%. Это во первых, во вторых - А сколько будет в ОЗУ этих ваших RxPacketMemory? один? два? или 700 по 1024 байт?. В третих - дело не только в ОЗУ. Вот сейчас у меня задача регистрировать пакеты в флешь/фрам. Или я там сохраню мелких пакетов за год, или жирных за час? В третих... ну поставите вы вместо какого нить МК мелким ОЗУ пушку, с 1 Gb ОЗУ.... напишите код... а в этой системе есть датчик на мелком PIC. И? Для PIC будете новый код писать? и т.д. и т.п. Так вот этим и занимаемся.

а с какой цифры начинается много? лично для меня и 128 бит много. Нужно массив в 10 байт - выделяем 128. 👍 А потом почему-то памяти для какого нибудь регистратора не хватает или канал передачи в 1 Gb не прокачивает. 1024/128 = 8. +хидер, +кс, как итог максимально 7 пакетов в такой буфер влезет.

структура в с++ это уже костыльно. Зачем в с++ в этом случае структура? коль вы выехали из деревни, так и бросьте деревенские привычки переехали в с++, так и пишите на с++, пишите классы.

ну допустим, в основном, 90% пакетов - это 10...20 байт. Но есть пакеты до 128 байт. Т.е. максимальный размер 128. Как это поможет? В стандратном C++ нет прямой поддержки добавления переменных после fam в структуре. гибкий массив должен быть последним членом структуры. Но компиляторы могут поддерживать расширения, позволяющие размещать дополнительные члены после fam. Например, расширение GCC "Zero-Length Array" (ZLA) позволяет добавлять дополнительные члены после гибкого массива. struct FlexFrame { Header hdr; int length; u8 data[]; // <- гибкий массив, а значит дальше можно ставить только элементы с атрибутом "гибкого положения" u32 crc; // положение этого члена "гибкое", в зависимости от объема поля data при создании структуры }; использование таких расширений делает код нестандартным и не переносимым между различными компиляторами и платформами. Лучше избегать использования таких расширений и следовать стандарту C++.

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

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

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

плюсую #include <vector> struct TxRS485 { Header hdr; std::vector<u8> bytes; u32 crc; }; Использование TxRS485 tx; tx.bytes.push_back(0x01); // добавление элемента в вектор tx.bytes.push_back(0x02); // Размер вектора может быть изменен динамически tx.bytes.resize(10); // Получение доступа к элементам вектора tx.bytes[0] = 0x11; tx.bytes[1] = 0x22;

Потому что компилятор не сможет установить правильный тип для этих параметров при вызове функции. Если вы вызовете эту функцию с определенным типом A, компилятору не будет известен тип B, потому что он не указан явно в аргументах функции. И, следовательно, компилятор не сможет сгенерировать соответствующий код для типа B. Вы потом сделаете вызов int asd; func(asd); компилатор сгенерирует func(int). А какой тип будет В?

Моё цитирование говорит, что jcxz речь ведёт про электротранспорт. Весь мой пост - это обращение к ТС. Прочитайте весь мой пост, а не одну строчку. Замените слово "Вы" на "Вы, dimir,".