Это продолжение открытого проекта платы контроллера сервоприводов. В предыдущей статье был проведён анализ возможностей и выбор микроконтроллера, изучена и освоена среда разработки. Теперь подошла собранная плата.
Сразу подключаем питание. Дыма нет, ток потребления в норме. Это внушает уверенность. Схема сделана так, чтобы контроллер с пустой прошивкой не вызывал никаких побочных эффектов на плате.
Программируем на языке C. Дело в том что 90% наших исходников неминуемо будут на С. Так уж устроено большинство генераторов исходников и библиотек софта под микроконтроллеры, будь то CubeMX, MCUXpresso, ModusToolbox или в нашем случае Renesas Software Package. Ничего не остаётся, как продолжать традицию.
Шаг 1. Проверяем SWD
Проверяем работу SWD интерфейса и наличие соединения SWD адаптера J-Link с ядром микроконтроллера на максимальной скорости. Работоспособность SWD в нашем проекте критически важна. С его помощью можно находить баги в операциях с периферией и тонко исследовать особенности периферии не отражённые в документации с минимальными потерями времени на модификацию исходников. Через SWD работает движок ITM (ядро ARM Cortex-M4 c Arm® CoreSight™). С использованием ITM трассируются события практически не нагружая ядро процессора вспомогательными драйверами. Важно то что вызовы ITM можно оставлять в релизных версиях и в случае необходимости изучать трассировку событий не меняя прошивку. При настройке трассировки с J-Link нужно знать частоту тактирования CoreSight. Может ввести в заблуждение параметр в отладчике называемый частотой ядра. На самом деле там нужно вводить частоту CoreSight иначе трассировка не заработает.
Шаг 2. Настраиваем IDE
Про IDE e2 studio, входящую в пакет SSP, уже упоминалось.
IDE e2 studio была использована при создании схемы платы, поскольку нужно было распределить функции на пинах микроконтроллера. Теперь настало время сконфигурировать систему тактирования на чипе.
Но сначала настроим в e2 studio тулчейн. Устанавливаем использование IAR for ARM 9.30.1 в качестве тулчейна. У IAR есть очень удобный отладчик C-SPY и он может работать внутри IDE на базе Eclipse.
Шаг 3. Конфигурируем тактирование микроконтроллера
Конфигурирование проводим в e2 studio в режиме Eclipse-перспективы под названием Synergy Configuration.
Схема тактирования довольно проста для такого типа микроконтроллеров и выглядит так:
Как видно из диаграммы в чипе есть пять генераторов тактирующих частот:
Main clock oscillator (MOSC) 8 to 24 MHz. С внешним кварцем.
High-speed on-chip oscillator (HOCO) 16, 18, 20 MHz
Low-speed on-chip oscillator (LOCO) 32.768 kHz
Middle-speed on-chip oscillator(MOCO) 8 MHz
Sub-clock oscillator (SOSC) 32.768 kHz. С внешним кварцем
Мы используем только MOSC для тактирования ядра и периферии и SOSC для тактирования часов реального времени. Остальные генераторы могут оставаться выключенными.
От MOSC мы получаем частоту 240 МГц с помощью PLL, которую потом делим на ряд периферийных частот:
System clock (ICLK) 120 МГц. Тактирует CPU, DTC, DMAC, Flash, SRAM
Peripheral module clock A (PCLKA) 120 МГц. Тактирует ETHERC, EDMAC, USBHS, QSPI, SPI, SCI, SCE7, GLCDC, SDHI, CRC, JPEG engine, DRW, IrDA, GPT bus-clock
Peripheral module clock B (PCLKB) 60 МГц. Тактирует IIC, SSIE, SRC, DOC, CAC, CAN, DAC12, POEG, CTSU, AGT, Standby SRAM, ELC, I/O ports, RTC, WDT, IWDT, ADC12, KINT, USBFS, ACMPHS, TSN, PDC
Peripheral module clock C (PCLKC) 60 Мгц. Тактирует АЦП
External bus clock (BCLK) 120 МГц. Тактирует внешнюю шину памяти.
Peripheral module clock D (PCLKD) 120 МГц. Тактирует таймера
USB clock (UCLK) 48 МГц. Тактирует USB
Flash interface clock (FCLK) 60 МГц. Тактирует внутреннюю Flash память
SDCLK pin output (SDCLK) 120 МГц. Тактирует внешний SDIO интерфейс
В дальнейшем надо будет часто обращаться к этому списку. Чтобы вспомнить, какую частоту получает каждый из периферийных модулей микроконтроллера.
Шаг 3. Конфигурирование HAL (hardware abstraction layer)
Кто программирует микроконтроллеры достаточно регулярно, тот знает про HAL. Это такой компромисс между желанием производителя микроконтроллеров одной кодовой базой покрыть потребности целого семейства микроконтроллеров и при этом сохранить специализацию для каждого отдельного типономинала в семействе. На первых порах учитывая недостаточную полноту и ясность документации без HAL обойтись нельзя. В e2 studio визуально собираются все необходимые элементы HAL. Новичку сразу однозначно понять какие элементы HAL нужны, а какие нет практически невозможно. Поэтому в IDE при первом включении нужно сразу выбрать построение проекта на основе демонстрационного примера Blinky. Мы сразу, чтобы не тратить время, выбираем как базу проект ThreadX Blinky. Тогда проект будет включать RTOS. А RTOS нам однозначно понадобится.
В результате на вкладке Threads будет такая картина:
Здесь создано два потока в операционной системе - HAL/Common и Blinky Thread.
Поток HAL/Common получит управление первым и инициализирует драйвера включенные в него, после чего запустит поток Blinky Thread. Если быть точнее, то HAL/Common не является потоком RTOS. Он выполняется до того как будет инициализирована RTOS. Поток HAL/Common сам инициализирует RTOS и создает поток Blinky Thread, в который передает управление, этим же прекращает свое собственное выполнение. Это не означает что драйвера созданные в HAL/Common станут недоступны. Управляющие структуры этих драйверов вместе со ссылками на API объявлены как глобальные и всегда доступны всем потокам.
Состав драйверов в потоке HAL/Common:
g_elc ELC Driver on r_erc - это драйвер контроллера управления и маршрутизации сигналов событий в микроконтроллере. Сигналы событий исходят от разных периферийных модулей и напоминают прерываний, но отправляются не контроллеру прерываний, а другим периферийным модулям. Этот драйвер нужен всегда поскольку заодно занимается и прерываниями.
g_ioport I/O Port Driver - это драйвер управляющий внешними пинами. Драйвера коммуникационных портов всегда используют этот драйвер для настройки пинов.
g_fmi FMI Driver - нечто секретное и недокументированное. К счастью с этим дело иметь не придется. Из исходников можно узнать что модуль FMI используется для получения информации о составе периферии и адресов периферийных модулей в чипе. Странное решение, учитывая то, что с SSP поставляются хедеры полностью описывающие структуру периферию и адреса. Однако HAL во всех драйверах использует адреса не из хедеров, а от FMI.
g_cgc CGC Driver - это драйвер занимающийся инициализацией системы тактирования на чипе. Он всегда нужен.
Шаг 4. Конфигурирование RTOS
RTOS здесь называется ThreadX. ThreadX входит как составная часть в проект Azure RTOS.
При генерации проекта сначала возникает пустое окно задачи ThreadX Blinky. Но добавив в него компонент ThreadX Source получаем возможность сконфигурировать RTOS по своему желанию. Здесь можно включать и выключать разные дополнительные проверки, статистики, управлять возможностями отладочной трассировки (трассировка выполняется сторонним тулсом), и прочее. Самое важное правильно указать размеры стеков. Для потоков не использующих форматированный ввод-вывод (printf, sprintf, scanf …) обычно устанавливается 1024 байта на стек. Если будет использоваться форматированный ввод-вывод, то устанавливается не менее 2048 байт на стек. Если GuiX, то 4096 байт.
Шаг 5. Реализация мигания светодиода и генерация исходников
Первым делом начнем мигать светодиодом. Это сразу нам даст уверенность, что: программа стартует штатно, пины инициализированы правильно (во всяком случае на светодиоды), частота ядра правильная, такты у RTOS тоже правильные и сама RTOS запускается.
Для этого в файле /MC50/src/blinky_thread_entry.c объявим такие переменные:
const ioport_port_pin_t led_pins[] =
{
IOPORT_PORT_05_PIN_04,
IOPORT_PORT_05_PIN_08,
};
const bsp_leds_t g_bsp_leds =
{
2,
led_pins
};
В самом теле потока Blinky Thread уже будет код, который используя эту конфигурацию начнет попеременно включать и выключать светодиоды.
Остается нажать кнопку в верхнем правом углу Generate Project Content. Контент будет сгенерирован практически мгновенно. Созданное дерево исходников сразу содержит под тысячу файлов. Это базовый минимальный софт. Дальше количество файлов увеличится в несколько раз.
Шаг 6. Загрузка прошивки и настройка отладчика
Eclipse славен тем, что в нем можно поменять что угодно на что угодно. Можно поменять компилятор, можно поменять движок сборки, можно поменять отладчик и т.д. и т.п.
В начале мы успешно подставили в роли компилятора IAR. Для отладки используем адаптер J-Link. С этим адаптером возможны два варианта отладчиков в Eclipse: первый - это через GDB, а второй - через IAR C-SPY. C-SPY удобнее и быстрее работает.
Но настраиваем оба варианта чтобы все же сравнить. Тут ожидало много разочарований. В случае GDB не удалось никак увидеть панель с состояниями внутренностей RTOS. Не работала трассировка, хотя J-Link Ultra ее поддерживает. В случае C-SPY не удалось даже стартовать программу. На первом же такте возникал Hard Fault exception. Но программу все же загрузить удалось через GDB и получили вот такую картину:
Очевидно среда разработки от Renesas не так уж и удобна для разработки.
Шаг 7. Переход на IDE IAR (опционально)
Как было сказано выше, e2 studio тоже как-то работает. Но если хочется меньше проблем, то есть альтернатива - IAR. Поскольку SSP способна генерировать исходники адаптированные к компилятору IAR с использованием его проприетарных возможностей. Теперь о том как перейти на IAR.
Создаем или копируем файлы какой-нибудь предыдущего проекта IAR в корневую директорию нашего целевого проекта. Даем файлам имена MC50.ewp и MC50.eww. И запускаем утилиту Populate_MC50 ewp.py. Эта утилита отредактирует файл MC50.ewp для включения в него нужных файлов и директорий из дерева проекта начиная от корня. Я уже сделал все необходимые манипуляции и в директории проекта уже находится файл рабочего пространства для IAR под названием MC50.eww. Загрузив его в IAR получим точно тот же проект, что и в e2 studio. Но он будет быстрее компилироваться, загружаться и без проблем отлаживаться. Код в репозитории.
Отказ от работы в e2 studio не означает что эту IDE можно сразу же снести. Она будет требоваться в дальнейшем для генерации по необходимости остальных драйверов и промежуточного программного обеспечения.
Шаг 8. Разворачивание промежуточного софта.
Но об этом в следующей части.