•Хорошая разводка зависит от размещения компонентов: если вы новичок в этой задаче, помните, что все начинается с размещения компонентов на конечной плате. Каждую плату можно логически и физически разделить на подмодули: силовая часть, микроконтроллер и цифровая часть, аналоговая часть и т. д. Не начинайте трассировку сигналов, пока не разместите все компоненты на окончательной плате. Более того, хорошее разделение на подмодули позволяет повторно использовать дизайн для разных плат.

•Выполняйте следующие действия при разводке микроконтроллера STM32:

−Начинайте с размещения микроконтроллера;

−если вашей плате требуются внешние источники тактового сигнала, поместите их непосредственно рядом с выводами микроконтроллера;

−затем разместите все необходимые развязывающие конденсаторы;

−подключите источники питания к соответствующим линиям питания или плоскостям питания, если это позволяет система разводки слоев (layer stackup);

−никогда не забывайте при необходимости подтягивать к заземле вывод BOOT0 и развязывать вывод NRST;

−если вашему проекту требуется внешнее SRAM или быстрая Flash-память, начните с их размещения и первой трассируйте дифференциальную пару;

−трассируйте все высокочастотные сигналы;

−трассируйте оставшиеся сигналы;

−избегайте использования слишком большого количества переходных отверстий во время трассировки сигналов и используйте CubeMX в поисках лучших альтернатив (то есть используйте другие эквивалентные сигнальные I/O, если это возможно).

27.2. Разработка программного обеспечения

После того, как вы закончили проектирование оборудования, вы можете приступить к части разработки микропрограммы. Если вы использовали CubeMX для разработки секции микроконтроллера своей пользовательской платы, то сможете очень быстро начать написание кода микропрограммы. Если проект CubeMX точно соответствует фактическому дизайну платы, вы можете просто сгенерировать проект, как мы это делали для отладочной платы Nucleo, затем вы можете импортировать его в новый проект Eclipse и начать работу над своим приложением. Ничего не отличается от того, что описано в Главе 4.

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

•Создайте новый проект CubeMX как для вашей отладочной платы (например, Nucleo-F030), включая необходимые периферийные устройства, так и для собственной платы, которую вы спроектировали.

•Проведите сравнение между процедурами инициализации для используемых периферийных устройств: если они отличаются, начните заменять их одну за другой в проекте, созданном для отладочной платы, и выполните полную компиляцию проекта, прежде чем переходить к следующему периферийному

устройству. Это позволит вам контролировать изменения в вашей микропрограмме.

•Чтобы упростить процесс переноса, никогда не изменяйте код инициализации периферийного устройства, созданный CubeMX, а используйте CubeMX для изменения настроек периферийного устройства.

•Попробуйте использовать макросы для оборачивания периферийных обработчиков. После того, как вы их измените, вам нужно только переопределить макросы (например, если ваша микропрограмма, разработанная с помощью Nucleo, использует периферийное устройство USART2, определите глобальный макрос следующим образом: #define USART_PERIPHERAL huart2 и основывайте свой код на этом макросе; если в вашем новом проекте используется USART1, тогда вам нужно переопределить только этот макрос соответственно).

Помните, что CubeMX, по сути, генерирует 5 или 6 файлов. Если вы уменьшите количество изменений в этих файлах до минимума, будет легко переорганизовать код.

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

27.2.1. Генерация бинарного образа для производства

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

С точки зрения Eclipse/GCC создание бинарного образа в режиме release – это не что иное, как соответствующая настройка проекта. Возможно, вы уже заметили, что каждый новый проект Eclipse поставляется с двумя конфигурациями сборки (перейдите в меню Project → Build Configurations → Manage, если вы никогда раньше не использовали эту функцию): одна с именем Debug, а другая – с Release. Конфигурация сборки (build configuration) – это не что иное, как конфигурация проекта, и вы можете иметь в одном проекте столько отдельных конфигураций, сколько хотите.

На рисунке 11 показано диалоговое окно настроек проекта (перейдите в меню

Project → Properties, чтобы открыть его). Панель C/C++ Build → Settings позволяет настроить параметры сборки. Более того, как вы можете видеть на рисунке 11, вы можете быстро перейти к другой конфигурации сборки, используя поле с выпадающим списком Configuration. В разделе Optimization мы можем настроить уровни оптимизации GCC. GCC предоставляет 5 уровней оптимизации. Рассмотрим их вкратце.

Рисунок 11: Диалоговое окно настроек проекта Eclipse позволяет легко переключаться на другую конфигурацию сборки

•-O0: соответствует уровню без оптимизации (no optimization). Он генерирует неоптимизированный код, но обычно имеет самое быстрое время компиляции. Обратите внимание, что другие компиляторы проводят довольно обширную оптимизацию, даже если задано no optimization. В GCC очень необычно использовать -O0 для производства, если время выполнения имеет какое-либо значение, поскольку -O0 действительно не означает никакой оптимизации. Это различие между GCC и другими компиляторами следует учитывать при сравнении производительности.

•-O1: соответствует умеренной оптимизации (moderate optimization). Он достаточно хорошо оптимизирует, но не сильно снижает время компиляции.

•-O2: соответствует полной оптимизации (full optimization). Он генерирует высокооптимизированный код и имеет самое медленное время компиляции.

•-O3: также соответствует полной оптимизации, как в «-O2», но также использует более агрессивное автоматическое встраивание подпрограмм внутри модуля и пытается векторизовать циклы.

•-Os: соответствует оптимизации для экономии пространства (optimization for space).

Он оптимизирует использование пространства (как кода, так и данных) конечной программы.

•-Og: соответствует оптимизации для отладки (optimization for debug). Он обеспечивает оптимизацию, не мешающую отладке. Он должен быть уровнем оптимизации для стандартного цикла «редактирование-компиляция-отладка», предлагающий разумный уровень оптимизации при сохранении быстрой компиляции и хорошего опыта отладки.

По умолчанию уровень оптимизации GCC для конфигурации Release – -Os. Более высокие уровни оптимизации выполняют более глобальные преобразования в программе и применяют более дорогие алгоритмы анализа для создания более быстрого и компактного кода. Однако при программировании встраиваемых систем обычно предлагается начинать разработку с уровня без оптимизации (-O0). Это потому, что более агрессивная оптимизация приводит к другому поведению ограниченных по времени процедур. Как правило, свою микропрограмму разрабатывают с уровнями -O0 или -Og и начинают увеличивать его, пока не проверят все ее функции. Иногда также случается, что микропрограмма, прекрасно работающая при компиляции с уровнем -O0, вообще перестает работать при выборе более агрессивной оптимизации. Это часто случается: мы неправильно объявили разделяемые и глобальные переменные как volatile, и они были оптимизированы компиляторами, что приводит к неправильному поведению процедур ISR или различных потоков, если мы используем ОСРВ.

Другой важный параметр для конфигурации Release связан с уровнем отладки Debug level. Эта функция настраивается в представлении отладки Debugging, и GCC предлагает четыре возрастающих уровня: None, -g1, -g (по умолчанию в конфигурации Release) и -g3. Если вы хотите сгенерировать бинарный образ без отладочной информации, выберите уровень None.