Дальнейшее рассчитано только на то, если ты адекватный человек и
желаешь учиться и поступать профессионально. Из-за отсутствия опыта
ты пока не знаешь более высокоуровневых "так не надо". Именно эти
вещи я тебе и хочу сообщить. Если тебя устраивает "ну а чо такова,
у меня всё работает" - скажи. Откуда взялся твой проект, в частности файл "stm32l1xx_conf.h"? Сгенерен? Даже если ты скажешь "нет, я его взял там-то и там-то" - не важно, в будущем при создании других проектов файл будет сгенерирован (скопирован) заново. Код порожденный STM32CubeMX, может быть свободно многократно перегенерен (обновлен) у одного и того же проекта, это типовая схема работы. Ты будешь его каждый раз поправлять? Пойдешь в ST CubeMX репозиторий и поправишь там?
В embedded средах довольно часто встречается полное копирование файлов всех библиотек в пользовательский проект. Однако это не правило, и могут быть скопированы лишь некоторые файлы, а основной массив файлов библиотек остаться в установочной директории, проект на них будет лишь ссылаться. Именно поэтому правка подобных вещей моветон, в теории не надо таким заниматься. Да, файл "stm32l1xx_conf.h" конфигурационный и он специально отдельно присутствует в каждом проекте. Но тут совпало лишь то что тебе повезло. Больший вопрос к странным ребятам из ST: что в конфигурационном файле с #define'ами делает библиотечный макрос assert_param, и именно только он??? Он там оказался по какой-то нелепой причине, в нормальных обстоятельствах его там быть не должно и рассчитывать на это - моветон.
Объясню почему если даже файлы всех библиотек полностью скопированы в проект, править их не стоит. (И делать так тоже не стоит, в проф. разработке никто так не делает, полагаются на неизменные библиотеки, лежащие как есть). Объясню на собственном примере. Не так давно, пару лет назад пришлось переносить заброшенный проект-недоделку с AT91 на STM32. Все либы скопированы в локальные директории. Я был несколько обескуражен, пока выяснил методом сравнения дерева файлов, что веселый чудырь взял да и поправил некоторые функции библиотек! И зачем-то туда же (в Atmel'овские файлы) поднаписал новых и поправил некоторые макро! К этому надо добавить второе недоразумение - мешанину, некоторые файлы локально были, но вот IAR ссылался на самом деле не на них, а на файлы в своих потрохах. Проблема? Проблема. Надо так делать? Не надо, крендель небось и думать никогда не думал что все его "художества" придется в итоге кому-то разбирать. А вот пришлось.
Не свой код не стоит менять, потому что может найтись кто-то, кто не будет подозревать о изменениях. И он возьмет новую версию либ, у него будет более свежая версия среды разработки, он перегенерит файлы, итд итп. Поэтому это делать нужно только в каком-то самом крайнем случае, неисправленный баг или еще что-то (записывая результаты своей деятельности в ПрочтиМеня!.txt )
Теперь перейдем на еще боле высокий уровень. А что именно у тебя не компилируется, что оказалось несовместимым с MISRA? Чужой код ST библиотеки HAL?
И ты решил что обеспечить ему (локально у себя) совместимость с MISRA - это хорошая идея? А ты прям все-все .c файлы от STM проверил? Все-все-все правила MISRA включил? Ну и что будешь делать, если первые же макро-определения в дефайнах "железа" stm32f***xx.h просто-напросто не проходят правила MISRA по длине идентификатора? Переименуешь их? Как быть с тем что в простейшем проекте с UART, который не включает все ST HAL/LL файлы уже высыпается 1655 проблем?
ST HAL/LL не совместимы с MISRA. Заявление в dm00105879-description-of-stm32f4-hal-and-ll-drivers-stmicroelectronics.pdf есть, но выражаясь политкорректно, оно "не соответствует действительности", а по-русски говоря, пиздёж.
Смысла править ST-шную либу, добиваясь ее совместимости с MISRA немного. Есть смысл только в том чтобы с MISRA был совместим именно твой код. Делается это так:
1. Опции проекта, включая конфиг MISRA (или настройки компилятора) - можно переписать поверх для каждого файла.
В IAR идем в окно workspace (вкладка project снизу) правой кнопкой на файле - выбрать меню options. Выставить "override inherited settings".
2. https://www.iar.com/support/tech-notes/compiler/disable-misra-c-for-include-files/
RxTx (25.09.2020 16:16, просмотров: 568) ответил teap0t на #1. (Повтор удалённого вопроса. Решил немного перекомпоновать
ветки, чтобы разделить темы). Как надо обходиться с проектом:
создавать локальную копию или пользоваться общим репозиторием IAR?
Я к тому, что есть понятие "говнокод", но может есть и понятие
"плохая практика". Ну, типа, хорошие мальчики не тащат всё к себе,
а учатся грамотно настраивать проект.