Как вы структурируете большие встроенные проекты? [закрыто]

Фон :

Младший инженер-электронщик R & D ( единственный EE в компании ) - аппаратное обеспечение и кодирование не проблема. Моя самая большая проблема - получить правильный обзор проекта и с чего начать.

До сих пор я занимался только небольшими программными проектами (менее 500 строк кода), но я не могу представить себе, что я делаю большие проекты, не теряя обзора функциональности или отсутствия функциональности.

Как вы лучше всего структурируете / какие инструменты вы используете для структурирования больших встроенных программных систем?

Что я сейчас делаю :

Я обычно начинаю с набросков функциональности проекта. Это может быть многоуровневая блок-схема или связанные схемы (блок-схемы и т. Д.) И некоторые исследования компонентов / микросхем. Затем я сразу перехожу к кодированию (я думаю, что это быстро проваливается), ссылаясь на таблицы данных / Интернет, кодируя по одной функциональности за раз и проверяя их с помощью фиктивных данных или аналогичного теста. Это может быть запись данных в микросхему MEM, а затем, если это сработает, это может быть драйвер SPI между основным чипом и микросхемой MEM.

Какой ответ я ищу :

Ничего действительно. Я разберусь, что я считаю разумным. Это может быть книга, статья, личный опыт, рекомендации и т. Д.

Мне очень интересно знать, как пожилые люди справляются с этим.

редактировать

Прежде всего, спасибо, что поделились своим многолетним опытом! Все ответы очень ценятся. Мой вывод из этого есть;

• Создайте четкий и точный документ спецификации.
• Создать документ о разработке программного обеспечения. (Кое-что я сейчас добавлю) Дизайн шаблонов документов
• Подумайте в модулях, насколько это может показаться излишним. (Что-то, на чем мне нужно больше сосредоточиться)
• Следуйте стандарту кодирования для структурирования заголовочных / исходных файлов. (Никогда этого не делал) Barr Group C стандарт
• Сосредоточьтесь на создании низкоуровневых реализаций в первую очередь. (Общение и т. Д.)
• Реализуйте шаблоны проектирования там, где это возможно / разумно. Шаблоны проектирования
• Настроить что-нибудь для контроля версий (Github и т. Д. - никогда не использовал это много)
• Исследования непрерывной интеграции / непрерывного развертывания (что-то новое, на что я наткнулся) Основы CI и CD

Есть несколько аспектов, влияющих на степень детализации структурирования потребностей проекта. Для меня один из главных факторов - это то, что я единственный кодирую (что кажется вам правильным, когда вы пишете, что вы единственный EE), или есть другие. Тогда возникает вопрос, что на самом деле означает «большой». Обычно я делю процесс проектирования на следующие шаги:

Определение требования Если вы получили правильную спецификацию программного обеспечения для работы с большим количеством планирования уже сделано. Если вы просто получаете расплывчатые требования, первое, что вам нужно сделать, это разобраться, что на самом деле хочет клиент (иногда они вообще не знают). Я знаю, что заманчиво просто перейти прямо к кодированию, но это рискует упустить важную функцию, которая может быть неочевидна с самого начала и не может быть просто втиснута в ваш код где-то в середине разработки.

Системные границы и ремонтопригодность Во встроенных системах у вас часто есть некоторые системные интерфейсы, некоторые снаружи (оператор), но также и внутри. Определите их правильно и постарайтесь поддерживать зависимости как можно ниже, это упростит непрерывное проектирование и ремонтопригодность. Также комментируйте / кодируйте документ там, где это необходимо, вы никогда не знаете, кому еще придется работать с ним, он (а) будет рад, если ему не придется копать дюжину слоев кода, прежде чем он на самом деле узнает, что делает функция.

Определите проверяемые задачи. Особенно, если другие разработчики работают над одной и той же кодовой базой, неизбежно необходимо определить четкие задачи (функции) и необходимые интерфейсы между ними. Когда бы ни было возможно, отдельные функции должны быть проверены / проверены независимо от других, вот где вам нужны хорошо определенные интерфейсы, чтобы вы могли определить свои тестовые случаи.

Одна особенность за другой Людям нравится прогресс, поэтому, если у вас есть множество задач, они обычно работают над тем, что обещает наибольший прогресс. Обычно я пытаюсь завершить задачу и привести ее в проверенное и протестированное состояние, прежде чем начать со следующей. Это позволяет вашему коду быть проверенным другими, и вы не забудете ничего.

Контроль версий В течение жизни проекта вам иногда требуются более старые версии, например, для выявления ошибки, появившейся в каком-то новом выпуске, или просто для создания устройства, которое ведет себя точно так же, как и то, которое вы выпустили 3 года назад. Убедитесь, что в вашем коде есть четкие версии сборки и теги. Git определенно твой друг здесь.

Humpawumpa написал отличный ответ ! Я просто хочу дополнить некоторые из его пунктов, но так как это слишком долго, чтобы быть комментарием, я напишу отдельный ответ.

Когда-то я был в должности ОП - не единственного, но единственного, кто занимался разработкой MCU в небольшой компании.

Я не могу подчеркнуть важность модульности , даже если вы единственный разработчик. Это единственный способ оставаться в здравом уме по мере роста проекта. Вы должны быть строгими в написании модулей, каждый из которых обрабатывает только одну функциональную концепцию, и поддерживать их внешние интерфейсы как можно более минимальными. Модули высокого уровня будут соответствовать функциональным требованиям, а модули низкого уровня будут тесно связаны с аппаратными ресурсами (т. Е. Драйверами устройств).

Я потратил много времени на поддержание подробной диаграммы потока данных ¹ , которая показала, как различные модули обмениваются информацией. Некоторые функции будут иметь очень разные требования с точки зрения производительности в реальном времени; убедитесь, что вы знаете, как обмен информацией влияет на это. На диаграмме были нарисованы границы, отделяющие код без прерываний от различных управляемых прерываниями доменов.

¹ Очень отличается от блок-схемы, которая ориентирована на управление потоком.

Для любого крупного проекта я планирую его так, как будто в нем участвуют несколько разработчиков, даже если я собираюсь сделать все самому.

Причины просты:

1 Сложность. Большой проект всегда будет включать в себя сложности. Планирование проекта так, как если бы было задействовано несколько команд, означает, что сложность была рассмотрена и задокументирована . Количество раз, когда я сталкивался с большими проектами, сталкивалось с проблемами, и обычно потому, что что-то «проскальзывало». Не забывайте, что необходимо учитывать механическую сборку, а не просто размер коробки - будут ли нужны радиаторы? Должна ли коробка быть заземлена в целях безопасности? В этой категории много вопросов.

2 Требования. Предполагая участие нескольких человек, это означает, что требования высшего уровня (которые я часто оспариваю, поскольку они могут привести к ненужной сложности и стоимости) должны быть разбиты на различные меньшие требуемые и достижимые задачи (которые могут быть переданы другой команде в более крупной организации). ), а не просто смотреть на один шарик.

3 Разделение. Существует два основных типа разбиения; аппаратная функциональность и аппаратное / программное обеспечение. Первый тип - определить, какие отдельные (но сообщающиеся) функциональные блоки должны присутствовать. Второй - это компромисс между более простым (иногда) аппаратным и программным обеспечением, но имейте в виду, что простое перемещение большего количества вещей в программное обеспечение не обязательно решит аппаратную проблему. Переход к большему количеству программного обеспечения может в некоторых случаях значительно увеличить сложность аппаратного обеспечения (большая вычислительная мощность, более сложные интерфейсы и т. Д.).

4 интерфейса. Процесс разделения поможет определить внутренние интерфейсы; внешние интерфейсы обычно являются частью общих требований (хотя и не всегда). Существует много способов взаимодействия различных частей системы, которые могут быть сложным протоколом связи или просто хорошей / плохой сигнализацией.

5 Проверка. Это смесь низкоуровневого тестирования (для оборудования и драйверов) и системного уровня. Выполнение проекта в четко определенных блоках позволяет провести надежную проверку (которая может быть проведена с помощью анализа или фактического теста и, как правило, представляет собой смесь двух; при обновлении проектов могут использоваться аргументы сходства).

6 Стандартов. Я использую стандарты кодирования и рисования, как если бы это была большая команда. Я использую стандарты кодирования группы Barr, так как они не слишком обременительны, но предотвращают появление множества классов ошибок в коде. Что касается документации по выводу на печатную плату, я следую IPC-D-326 (который вызывает IPC-D-325), поскольку это проверенный метод передачи моих намерений производителям и сборщикам печатных плат. Это может показаться странным, но наличие дисциплины, соответствующей нескольким стандартам, означает, что качество стабильно.

7 Контроль версий. Я использую контроль версий для всех частей проекта (система, оборудование, программное обеспечение. Механика, требования к испытаниям - все). Инструменты CAD, которые я использую, поддерживают такие версии, как и все программное обеспечение и инструменты сборки FPGA.

Я работал над многими встроенными проектами (как и многие опытные люди здесь), и размеры команды варьировались от 1 (меня) до десятков (или сотен в конкретном наборе проектов), распределенных по нескольким дисциплинам, а иногда и другим географически удаленным места. Использование одного и того же подхода (который известен как работающий) означает, что я могу выбрать конкретную задачу в относительной изоляции, выполнить ее и полностью протестировать как отдельную часть более крупного проекта. Это также означает, что я могу при необходимости передать некоторые вещи.

Выполнение всего этого добавляет немного времени, но в конечном итоге это более быстрый маршрут для сложных встроенных систем.

Другие ответы дают много хороших советов. Вот два из них, которые я нашел наиболее важными в моей карьере встраиваемых разработчиков:

1. Сделайте как можно больше кода в отдельных, четко определенных модулях.
2. Сделайте модули автоматически тестируемыми на ПК.

Это то, что вам нужно для разработки стиля «непрерывной интеграции» на встраиваемых системах. Всегда будет некоторый объем кода, который слишком тесно связан с оборудованием для автоматического тестирования, но постарайтесь свести его к минимуму. Вы можете продвинуться далеко вперед, используя смоделированные данные или сбор данных с реального оборудования, которые вы затем вводите в тестовую систему.

Добавить к существующим ответам ...

Я всегда начинаю снизу вверх. Из вашего аппаратного дизайна вы знаете, что такое ваш ввод / вывод. Начните с создания модулей драйверов, которые инкапсулируют этот ввод-вывод, чтобы ваш высокоуровневый код не слишком много знал о низкоуровневых компонентах.

Когда вы создаете низкоуровневые интерфейсы, вам, конечно, нужен тестовый комплект. Если вы спроектировали это для подключения к ПК с самого начала (возможно, с портом RS-232, возможно, USB, возможно, через telnet через Ethernet), то вы можете сохранить этот интерфейс тестового жгута на месте при создании приложения. По мере того, как приложение принимает форму, вы можете продолжать добавлять дополнительные тестовые зацепки, и это позволит вам регрессивно тестировать свой код по мере продвижения.

Я склонен думать на четыре вопроса. Первые два относятся к началу системного проекта, два - к концу.

1. Они действительно хотят систему? Решит ли система проблему клиентов, с учетом времени и затрат, которые они примут? Распространенной проблемой является создание систем, которые клиент не будет использовать.

2. Можем ли мы на самом деле построить эту систему? Будет ли возможно обеспечить необходимую производительность, точность, энергопотребление, ...?

Создание ранних прототипов - хороший способ ответить на эти два первых вопроса. Снижение риска чрезвычайно важно на ранних этапах.

Следующие два вопроса больше ориентированы на более поздние фазы проекта:

3. мы на самом деле закончили? Все разработано, закодировано, проверено, доставлено

4. Они действительно используют систему?