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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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