соображения, которые следует учитывать при написании прошивок для больших проектов
Возможно, моя проблема выглядит настолько общей, но мне действительно нужна ваша помощь. Я новичок в разработке программного обеспечения для встраиваемых программ и выполнил несколько небольших проектов с использованием микроконтроллера TI DSC и STM с языками программирования C и C ++. но теперь я собираюсь начать писать прошивку для большого проекта и ищу способ смоделировать мою прошивку перед ее реализацией. На самом деле у меня есть два вопроса:
1. Я хочу знать, чем занимается профессиональный инженер по встроенному программному обеспечению перед тем, как приступить к написанию прошивки? (Для моделирования прошивки используется рациональная роза или корпоративная архитектура, подходящая для прошивки, я думаю, что эти два подходят для приложений ИТ и программного обеспечения не прошивка)
2. Какие важные правила я должен соблюдать при написании прошивки?
например я рассмотрел о:
Никогда не помещайте много кода в процедуру обработки прерывания.
б. Никогда не занимайся ожиданием с хитрыми петлями
Что еще я должен был рассмотреть?
Решение
Подобные вопросы не относятся к SO, но я все равно отвечу, поскольку нигде не существует форума для этих очень важных соображений. Обычно это выглядит так:
Напишите спецификацию и требования. Потратьте некоторое время на это и сосредоточьтесь на продукте, а не на технических деталях. «Варианты использования» UML могут быть полезны, но здравый смысл тоже работает. Убедитесь, что спецификация является живым документом, который может быть изменен при необходимости.
Затем сделайте дизайн программы с помощью ОО-модели (назовите ее классами / модулями кода / единицами перевода или как хотите). Запишите, какие модули кода нужны программе, убедитесь, что они соответствуют спецификациям — в идеале каждое требование ведет к конкретному коду (что в дальнейшем приводит к конкретному тестированию этого кода). Затем сфокусируйтесь на зависимостях между различными модулями: это должно быть дерево зависимостей «сверху вниз», в котором драйверы не зависят от HAL, которые не зависят от вызывающих и т. Д. Составьте это дерево с ручкой и бумагой. Необычный UML в порядке, но не обязателен.
Вы должны рассмотреть переносимость на ранней стадии. Должен ли код переноситься между проектами? (очень часто) Между компиляторами? (довольно часто) Между платформами? В зависимости от того, какой уровень переносимости необходим, вы можете изменить схему и пропустить некоторые HAL. Однако почти всегда неплохо отделять драйверы от приложения.
Что касается «важных правил», то они не имеют ничего общего со стадией разработки программы. Скорее, они должны быть в вашем стандартном документе кодирования. Предпочтительно стандарт компании, который используется для каждого проекта. Следует сосредоточиться на запрете всех видов плохой практики и, кроме того, содержать руководство по стилю. Для встраиваемых систем я настоятельно рекомендую основать этот документ на MISRA-C, затем добавить пользовательские правила, если вы хотите (например, «сохранить код ISR минимальным»), а затем добавить руководство по стилю поверх этого. Обратите внимание, что написание этого стандарта кодирования является собственным проектом.
Другие решения
Других решений пока нет …