Как вы организуете код во встроенных проектах?

Question

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

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

Однако я пытался организовать свой код соответствующим образом:

1. аппаратное обеспечение (драйверы, инициализация)
2. для конкретного приложения (маловероятно, что оно будет использовано повторно)
3. многоразовый, аппаратно-независимый

Для каждого модуля я стараюсь придерживаться цели одного из этих трех типов.

Из-за ограниченного размера встраиваемых проектов и акцента на производительность, это часто удерживает эту организацию.

Для некоторого контекста мой текущий проект - ограниченное приложение DSP на MSP430 с флэш-памятью 8 КБ и оперативной памятью 256 байтов.

Answer 1

Я написал и поддерживал несколько встроенных продуктов (30+ и считая) для различных целевых микро, включая MSP430. Эмпирические правила, с которыми я наиболее успешно справляюсь:

• Постарайтесь максимально упростить модульные понятия (например, отделить код драйвера от кода приложения). - Это облегчает обслуживание и повторное использование / перенос проекта в другое целевое микро в будущем.
• НЕ начинайте с заботы об оптимизированном коде в самом начале. Попробуйте сначала решить проблему домена, а затем оптимизировать. - Ваш целевой микро может справиться с гораздо большим количеством «вещей», чем вы могли ожидать.
• Работа по обеспечению читабельности. Хотя большинство встроенных проектов, кажется, имеют короткие циклы разработки, проекты часто живут дольше, чем вы ожидаете, и другому разработчику, несомненно, придется работать с вашим кодом.

Answer 2

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

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

С учетом вышесказанного довольно типично следующее:

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

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

Администратор / приложение, вероятно, поддерживается как отдельный модуль. Весь аппаратный код должен быть скрыт в халате (как упомянуто выше).

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

---

Исключительные обстоятельства, которые могут быть наложены необычными ограничениями компилятора. например. Я встречал некоторые компиляторы, которые ожидают, что все подпрограммы обработки прерываний будут скомпилированы в одном объектном файле.

Answer 3

Я пытаюсь организовать его так, как если бы у меня было неограниченное количество ОЗУ и ПЗУ, и оно обычно работает нормально. Как уже упоминалось в другом месте, не пытайтесь оптимизировать его, пока вам это не понадобится.

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

Answer 4

Я работал над 8-разрядными процессорами PIC с аналогичными ограничениями.

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

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

Answer 5

Хотя это немного болезненно, один из методов организации, который в некоторой степени распространен для встроенных библиотек C, состоит в том, чтобы разделить каждую функцию и переменную в отдельный исходный файл C, а затем объединить полученную коллекцию файлов O в файл библиотеки.

Мотивация для этого заключается в том, что для большинства обычных компоновщиков единица связи является объектом, для каждого объекта вы либо получаете весь объект, либо ни одного из них. Поскольку между файлами C и объектными файлами существует соотношение 1-1, размещение каждого символа в своем собственном файле C дает каждому свой объект. Это, в свою очередь, позволяет компоновщику использовать только то подмножество функций и переменных, которые действительно используются.

Эта игра вообще не помогает, поскольку заголовки можно с радостью оставить в виде отдельных файлов.

Answer 6

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

Очевидно, это не означает, что caos начнется, но, например, попытайтесь взглянуть на организацию tinyOS исходного кода и приложений, это идея того, что я пытаюсь сказать.