razrab83

ps вообще не понятно, почему в разделе программирование предлагают решить вопрос заменой железа? Это же ПРОГРАМИРОВАНИЕ, а не проектирование. Кто-то разработал железку, кто-то закупил РЭК, кто-то собрал - Прошли годы.... попало это всё на стол программисту. За частую, железо разработано и собрано ещё до того, как программиста приняли на работу. Начал прогер ваять - столкнулся с проблемой по ПРОГРАММИРОВАНИЮ, не по ТЗ, не по выбору элементной базы, а по программированию. "Как создать тип данных для структуры с переменным размером?", приходит "советчик" и советует учит по мощнее процессор поставить или внешнее ОЗУ на SPI. 🥱

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

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

На сколько я понял, не стоит вопрос "помогите разработать новый протокол и формат пакета". Вопрос стоит "подскажите, как переехать в с++, и красиво оформить существующий протокол"? 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) { //пакет валидный } в конце пакета )))

допустимо, при явном указании типа. например template<class A, class B> void func(A a) { B b; ... } void main() { func<MyClass, YourClass>(2);//так норм func(2); //ошибка }

он будет по %f (или по %k) принимать float

Нет. Я же говорю Придется пока смериться с double, а в дальнейшем возможно писать свой sprintf или использовать сторонний. Их уже навелосипедили не мало.

с -Wformat предупреждения в gcc нет. Вы сами попробуйте.

включены, оба сразу. предупреждений нет.

ни чего не понял..... при чем тут суффикс f? Суфикс f в строке "float pi = ..." абсолютно ни как не влияет и не должен влиять на строку со sprintf(). все правильно. я записал "3.14" - считай что (double)(3.14). И что? Далее... я записал float pi = (double)(3.14); - в данной строке произошло неявное преобразование из double во float. Далее pi везде есть float. После, как инициализировалась pi - не важно. пусть будет так float pi = reinterpret_cast<float>(getMyFloat()); float pi = 3.14; float pi = (float)atof("3.14"); float pi = 3.14f; float pi = sinf(1); Выбери любой инит по душе. При чем тут вообще неявное преобразование в строке "float pi = 3.14;"? Мне на эту строку компилятор не дает ворнинг. да и если бы давал - да и черт с ним. Меня интересует ворнинг на sprintf. От способа инициализации pi результат sprintf не зависит. Ворнинг на sprintf в 9.4 будет, а в 8.5 и в gcc не будет. смотрел. там в 100500 окошках куча галочек. отличий не нашел. НО.... скомпилировал в 9,4 и в 8,5 один и тот же файл и сравнил опции компилятора - опции одинаковые iccarm.exe file.cpp -D USE_HAL_DRIVER -D STM32F429xx -D HSE_VALUE=((uint32_t)16000000) -D ewarm --preprocess=s <path>\ewarm-cm3\Debug\List -o <path>\ewarm-cm3\Debug\Obj --no_cse --no_unroll --no_inline --no_code_motion --no_tbaa --no_clustering --no_scheduling --debug --endian=little --cpu=Cortex-M4 -e --fpu=VFPv4_sp --dlib_config <path>\arm\inc\c\DLib_Config_Normal.h -On --c++ --no_exceptions но в 9.4 есть ворнинг на sprintf, а в 8.5 нет. Может в IAR 9-ке добавили этот ворнинг? В gcc версии arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10.3-2021.08) 10.3.1 20210621 (rel ease) тоже нет ворнинга.

в IAR - это лотерея. Ну не научился он это делать. Бывает, иногда сделает переход и даже попадет куда нужно. Но за частую не переходит. У вас какой-то месадж выдал. У меня молча закрывается контекстное меню и я остаюсь на том же месте, без каких либо сообщений. 2024 год на дворе, а IAR какие-то базовые операции навигации не умеет. Используйте внешний редактор внешнюю IDE: Eclipse, VS Code, .... для редактирования. Для отладки - IAR.

а кто сказал что у меня нет такой привычки? написал для ПРИМЕРА. Изначально был такой пример float pi; sprintf(str, "%f", pi); Но подумал: щя найдется учитель, который будет учить инициализировать переменные перед использованием. Или спросит "а что такое str?". Немного доработал пример... но всё равно "занавеска" кому-то не угодила )). можно ещё и про snprintf(str, 100, ...) вспомнить для str[100]. По делу, вопрос остался: почему в IAR 8,5 нет предупреждения, а в 9.4 есть в одном проекте есть предупреждение, в другом нет? Почему в iccarm есть предупреждение, а в gcc нет?

//*.cpp float pi = 3.14; char str[100]; sprintf(str, "%f", pi); На sprintf() получаю предупреждение Warning[Pa205]: implicit conversion from float to double До этого работал в IAR 8.5. всегда в %f подсовывал float, ни каких предупреждений. В кубеИде с gcc тоже нет такого предупреждения. В IAR 9.4 - это мой первый проект и вот такое получил. ну во первых, не хочу этот ворнинг, его конечно можно заглушить декертивами или настройками, или явным приведением типа к double. Но что-то не очень нравиться работать с double, т.к. МК имеет FPU single precision.

поставить галку Tools->Options...->Editor->File Encoding->Auto-detect Из вопроса я понял, что проблема в том, что файл уже написан с русскими буквами, но вместо них отображается что-то другое.Закрываем файл , ставим Auto-detect, открываем файл. Другая проблема, что иар не то что не может отобразить русские, но он не может редактировать русские буквы, вместо них "????". для IAR 8.5: По умолчанию Tools->Options...->Editor->File Encoding->Default character encoding: System при этом снята галка Tools->Options...->Editor->File Encoding->Auto-detect создаю новый фаил в иаре - вместо русских вопросики. удаляю или закрываю этот файл. Меняю кодировку на Russian Tools->Options...->Editor->File Encoding->Default character encoding: Russian (акказываицо существует кодировка и/или набор символов Russian) создаю новый фаил в иаре - русские буквы как положено печатаются. Открываю созданный файл в notepad - русские буквы нормально, кодировка автоматом определилась как ANSI. Можно и в UTF-8, и в 1251, но включить авто-детект и далее как сказал Евгений 1 Это работает, если галка Tools->Options...->Editor->File Encoding->Auto-detect установлена. Даже UTF-8 иар сможет нормально открыть и показать в этой кодировке.

Локализовал проблему. Память под хип выделена, но во внешней SDRAM, которая инитится в main. Всем спасибо.