В данной статье рассмотрена установка и настройка среды Eclipse для работы с микроконтроллерами MDR1206FI, MDR1206AFI, построенными на базе процессорного RISC-V ядра BM-310S0.

Основное отличие между микросхемами MDR1206FI и MDR1206AFI заключается в контроллере FLASH-памяти и влечет за собой использование разных алгоритмов для работы с FLASH. Микросхемы MDR1206FI и MDR1206AFI могут быть различены программно с помощью поля CHIP_ID в регистре FLASH_CNTRL->CHIP_ID_CTRL - значение 215 соответствует MDR1206AFI, значение 217 соответствует MDR1206FI.

Исходные файлы проектов ("MDR32VF0xI_Template"/"MDR1206_Template"/"MDR1206FI_Template"/"MDR1206AFI_Template" и т.д.) доступны в составе Standard Peripherals Library на официальном сайте.

Статья содержит информацию о:
1) Установке IDE Eclipse и подготовке к работе с МК MDR1206(A)FI.
2) Подготовке отладчика для работы с OpenOCD.
3) Создании и настройке проекта.
4) Сборке проекта.
5) Создании и настройке конфигурации отладки.
6) Программировании загрузочной программы в микроконтроллер.
7) Дополнительных возможностях для работы с памятью при разработке ПО.

Вводные сведения о библиотеке MDR32VF0xI и организации проектов

Микросхемы MDR1206FI, MDR1206AFI являются усовершенствованной версией К1986ВК025 (MDR32F02) с некоторыми отличиями. Поскольку МК MDR1206(A)FI функционально близки к К1986ВК025, программная поддержка уровня CMSIS и SPL для микроконтроллеров К1986ВК025 (MDR32F02), MDR1206FI и MDR1206AFI реализована в общей библиотеке - MDR32VF0xI. Поэтому информация из данной статьи по большей части также применима для К1986ВК025 (MDR32F02).

В свою очередь шаблоны проектов (а также примеры) для микроконтроллеров реализованы как один общий для всех, так и раздельные индивидуально под МК. Помимо этого, для микроконтроллеров MDR1206FI и MDR1206AFI разработаны общие проекты MDR1206, поскольку функциональные отличия минимальны.

Для выбора конкретного МК необходимо задать соответствующий макрос USE_MDR... в файле MDR32VF0xI_config.h на уровне SPL или, если уровень SPL не используется и используется только уровень CMSIS, в файле system_MDR32VF0xI_config.h на уровне поддержки устройства (DeviceSupport) в CMSIS. После выбора конкретного МК с помощью макроса при сборке проекта необходимо также установить соответствующую микроконтроллеру конфигурацию сборки.

Примеры проектов с общим для микроконтроллеров MDR32F02, MDR1206FI, MDR1206AFI функционалом реализованы в едином для всех примере. Например, проект MDR32VF0xI_Template является общим для всех этих МК. Проекты для Eclipse реализованы как шаблоны со всеми необходимыми настройками, но без функционального кода конечной программы.

1. Установка и подготовка к работе IDE Eclipse

Далее рекомендуется обновить установленные пакеты: sudo apt update && sudo apt upgrade

Скачать IDE Eclipse (Eclipse IDE for Embedded C/C++ Developers) можно по следующей ссылке: https://projects.eclipse.org/projects/iot.embed-cdt/downloads.

Помимо самой среды Eclipse также понадобятся следующие программные средства:

1. GNU RISC-V Embedded GCC – набор программ (компилятор, ассемблер, компоновщик, библиотеки, отладчик GDB), которые необходимы для разработки ПО на устройствах с ядром RISC-V.
GNU RISC-V Embedded GCC доступен для скачивания по ссылке: https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases.

2. OpenOCD - ПО для программирования и отладки устройств. При использовании ОС Linux версию OpenOCD с поддержкой микросхем компании Миландр (требуется патч, доступный на официальном сайте компании Миландр) нужно собрать, например, по инструкции "[i] Компиляция OpenOCD из исходных данных".

При первом запуске среды Eclipse необходимо выбрать директорию, в которой будет создан workspace, рисунок 1, после чего нажать кнопку "Launch".

Рисунок 1 – Выбор директории в качестве workspace

Для подключения программных средств для работы с МК MDR1206FI, MDR1206AFI в среде Eclipse необходимо указать соответствующие пути. Для этого необходимо открыть окно "Window->Preferences" и перейти во вкладку "MCU".

Во вкладке "MCU->Global OpenOCD Path" необходимо прописать путь к папке с исполняемым файлом OpenOCD (xPack OpenOCD), рисунок 2. Данный путь используется в отладочных конфигурациях.

Рисунок 2 – Указание пути к OpenOCD

Во вкладке "MCU->Global RISC-V Toolchains Paths", необходимо выбрать toolchain по умолчанию "xPack GNU RISC-V Embedded GCC (riscv-none-elf-gcc)" и прописать путь к папке bin GNU RISC-V (xPack GNU RISC-V Embedded GCC), рисунок 3.

Рисунок 3 – Указание пути к GNU RISC-V Embedded GCC

После указания всех путей необходимо нажать кнопку "Apply and Close".

На этом подготовка среды Eclipse завершена.

2. Подготовка отладчика для работы с OpenOCD

МК MDR1206FI, MDR1206AFI поддерживают отладку только через интерфейс JTAG. Для отладки МК MDR1206FI, MDR1206AFI на плате отладочного комплекта для микросхем MDR1206FI ТСКЯ.468998.140 установлена микросхема FT2232HL компании FTDI, имеющая два независимых интерфейса. Интерфейс 0 позволяет выполнять отладку МК по интерфейсу JTAG. Интерфейс 1 позволяет выполнять обмен данными с МК по интерфейсу UART1 на выводах PB[1], PB[0]. Подключение микросхемы к ПК выполняется с помощью кабеля USB A-B, разъём USB на отладочной плате.

На отладочной плате также предусмотрено подключение внешнего отладчика через разъём JTAG. В качестве внешнего отладчика можно использовать J-Link. Выбор используемого отладчика задаётся с помощью перемычек на разъёме JTAG to USB:

• перемычки установлены (для отладочного комплекта MDR1206FI ТСКЯ.468998.140 - переключатель в положении ON) - используется встроенный отладчик, реализованный на базе микросхемы FT2232HL;
• перемычки сняты – используется внешний отладчик.

При работе в ОС Linux для корректной работы OpenOCD с программаторами необходимо разрешить работать USB-программаторам как доверенным источникам, как это описано в статье [i] Компиляция OpenOCD из исходных данных.

3. Создание и настройка проекта в IDE Eclipse

Для быстрого старта можно использовать один из шаблонов проектов "MDR32VF0xI_Template"/"MDR1206_Template"/"MDR1206FI_Template"/"MDR1206AFI_Template", в которых уже помимо готовых настроек проектов подключена библиотека SPL (проекты доступны в составе Standard Peripherals Library на официальном сайте).

Далее по статье для примера используются проект "MDR32VF0xI_Template" с кодом примера MDR32VF0xI_PORT_Led (в SPL расположен в папке Examples/MDR32VF0xI/common/PORT - при обновлениях SPL путь может меняться).

Чтобы добавить проект в Workspace, необходимо выполнить процедуру импорта проекта. Для этого требуется выбрать "File->Import". В открывшемся окне выбрать "General->Existing Projects into Workspace" и нажать "Next >", как показано на рисунке 4.

Рисунок 4 – Импорт "Existing Projects into Workspace"

В пункте "Select root directory" необходимо указать папку с проектом "MDR32VF0xI_Template". В поле "Projects" установить галочку напротив выбранного проекта, а также установить пункт "Copy projects into workspace", чтобы проект был скопирован в workspace, если проект расположен не в папке workspace. Далее следует нажать "Finish". При появлении окна "Overwrite '.settings' in folder ..." - нажать "Not To All".

Рисунок 5 – Импорт – выбор ранее созданного проекта

Чтобы отобразилось основное окно проекта, необходимо закрыть стартовое окно "Welcome". Слева в поле "Project Explorer" должен отобразиться добавленный проект, рисунок 6.

Рисунок 6 – Отображение проекта в "Project Explorer"

Добавленный проект можно переименовать. Для это следует нажать ПКМ на имя проекта и выбрать пункт "Rename" (или нажать F2). После переименования следует изменить папку ресурсов. Для этого необходимо перейти в свойства проекта (ПКМ на имя проекта -> Properties или нажать "Alt+Enter"). В открывшемся окне необходимо перейти в "C/C++ Build -> Refresh Policy" и удалить папку со старым названием проекта, как показано на рисунке 7. Следует учитывать, что переименование проекта вызовет необходимость изменения предварительно сохраненных конфигураций отладки (см. Использование предварительно сохраненных файлов отладочных конфигураций).

Рисунок 7 – Удаление папки со старым названием проекта

Теперь необходимо нажать "Add Resourse…" и выбрать папку с новым названием проекта, рисунок 8. Далее следует нажать "ОК" и "Apply and Close".

Рисунок 8 – Добавление папки с новым названием проекта

Добавление проекта в IDE Eclipse завершено.

3.1 Дополнительные особенности настройки проектов - включение расширений ядра для компилятора

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

Начиная с версии 2.1 системы команд RV32I инструкции FENCE.I и CSR-инструкции вынесены в отдельные расширения - Zifencei и Zicsr соответственно. В то же время ядро BM-310S0 реализует систему команд RV32I версии 2.0, когда данные инструкции являлись частью базовой системы команд. В связи с этим в настройках GNU RISC-V Embedded GCC проекта необходимо указать использование расширений Zicsr и Zifencei. Помимо этого, согласно п.11 "Система команд" спецификации, поддерживаются расширения команд для битовых манипуляций и для скалярной криптографии.

Настройка расширений осуществляется в настройках проекта (ПКМ по названию проект в Workspace -> Properties -> C/C++ Build -> Settings -> Tool Settings -> Target Processor), в поле "Other extensions" нужна записать "_zicsr_zifencei_zicntr_zba_zbb_zbc_zbs_zbkb_zbkc_zbkx_zknd_zkne_zknh_zksed_zksh" (рисунок 9).

Рисунок 9 – Настройка использования расширений

Инструкции работы с CSR-регистрами используются на уровне CMSIS. Без указания использования расширений Zifencei и Zicsr сборка проекта будет завершаться, например, с ошибками вида "Error: unrecognized opcode `csrr s10,mhartid'" и аналогичными ошибками.

4. Сборка проектов

Компиляция проекта под выбранную конфигурацию в GUI осуществляется с помощью кнопки в виде молотка на панели инструментов (выделен зеленым на рисунке 10). Нажав на стрелку рядом, можно выбрать конфигурацию сборки. Значок документа (выделен синим) компилирует активные конфигурации в каждом открытом проекте.


Рисунок 10 – Кнопки для сборки проекта


По умолчанию в проектах реализован набор разных видов сборки, которые отличаются настройками конфигурационного файла компоновщика (link_*.ld):

• "FLASH" - код расположен во Flash-памяти, данные - в ОЗУ на системной шине TCM;
• "RAM_TCM_Debug/_Release" - код и данные расположены в ОЗУ на системной шине TCM.

Отличия между Debug/Release конфигурациями для сборки под области RAM заключается в том, что для конфигурации Debug код изначально располагается сразу в ОЗУ (в связи с этим существует особенность с отладкой в части опции "Debug in RAM", описанная далее) и его загрузка в память возможна только отладчиком-программатором (при штатном запуске МК после сброса или подачи питания программа не будет исполняться, т.к. не записана в энергонезависимую память). В то же время в конфигурации Release код изначально располагается в Flash-памяти и копируется в ОЗУ с помощью startup-файла, в связи с чем исполнение загруженного ПО при штатном запуске МК возможно.

Для каждой конфигурации сборки используется свой конфигурационный файл компоновщика link_*.ld. Отличие данных link_*.ld файлов заключается в различном описании регионов памяти (блоки REGION_ALIAS для разных конфигураций).

Для частных проектов под конкретный МК неиспользуемые конфигурации сборки убраны - например, из MDR1206_Template удалены конфигурации сборки для MDR32F02 (К1986ВК025), а из MDR32F02_Template убраны конфигурации сборки для MDR1206FI и MDR1206AFI.

5. Создание и настройка конфигурации отладки

5.1. Создание новых конфигураций отладки

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

После сборки проекта для создания конфигурации отладки необходимо нажать на стрелку у значка "жука" и выбрать пункт "Debug Configurations…", рисунок 11.

Рисунок 11 – Расположение кнопки Debug Configurations

В открывшемся окне слева необходимо выбрать пункт "GDB OpenOCD Debugging" и нажать кнопку "New", как показано на рисунке 12.

Рисунок 12 – Настройки окна Debug Configurations

Во вкладке "Main" необходимо выбрать требуемый проект, при этом также можно изменить название отладочной конфигурации. Для выбора проекта необходимо нажать кнопку "Search Project" и выбрать соответствующий elf-файл (рисунок 13).

Рисунок 13 – Конфигурация отладки во вкладке Main

Во вкладке "Debugger" в поле "Config options" необходимо указать файлы конфигурации отладчика (рисунок 14):

	MDR1206AFI	MDR1206FI
On-board FTDI2232HL	-f interface/ftdi/mdr-ft2232hl.cfg -f target/MDR1206AFI.cfg	-f interface/ftdi/mdr-ft2232hl.cfg -f target/MDR1206FI.cfg
J-Link	-f interface/jlink.cfg -f target/MDR1206AFI.cfg	-f interface/jlink.cfg -f target/MDR1206FI.cfg

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

В случае необходимости прошивки загрузочной программы при запуске отладки в поле "Config options" можно дополнительно после подключения файла конфигурации прописать команду программирования BOOT загрузочной программой:
-c "program bootloader/MDR1206_Bootloader.hex preverify verify"

Данная команда запрограммирует образ типовой загрузочной программы MDR1206_Bootloader.hex (описание типовой загрузочной программы приведено в спецификации) в область BOOT.

В поле "Commands" необходимо указать следующие команды:

set mem inaccessible-by-default off
set arch riscv:rv32
set remotetimeout 250

Рисунок 14 – Конфигурация отладки во вкладке Debugger для MDR1206AFI и MDR1206FI

Во вкладке "Startup" необходимо убрать галочку с пункта "Enable Arm semihosting".

ВАЖНО!

Опция "Debug in RAM" указывает отладчику при каждом запуске отладки выполнять загрузку программы, а также принудительно устанавливать начальный адрес программы (функция _start из файла startup). Данную опцию необходимо устанавливать в двух случаях:

1. выполняется отладка программы, загруженной в память ОЗУ (конфигурации сборки "RAM_TCM_Debug");
2. используется микросхема без загрузочной программы (загрузочная программа не запрограммирована в область BOOT) и выполняется отладка программы, загруженной во Flash-память (конфигурация сборки "FLASH").

Когда галочка убрана с "Debug in RAM", то после загрузки программы отладчик установит точку останова на функцию main() и сбросит МК. МК стартует с загрузочной программы, которая передаёт управление во Flash-память (режим MODE[1:0] = 00 для стандартной загрузочной программы). Когда выполнение программы дойдёт до точки останова в main(), то МК остановится, а в окне отладки появится синяя стрелочка напротив main(), указывающая, что МК остановлен.

Рисунок 15 – Конфигурация отладки во вкладке Startup

Во вкладке "SVD Path" необходимо указать путь к SVD-файлу, описывающему периферию МК, рисунок 16. SVD-файл также расположен локально в приложенных проектах, в папке svd, выбирается в зависимости от микросхемы, MDR1206FI.svd или MDR1206AFI.svd.

Рисунок 16 – Конфигурация отладки во вкладке SVD Path на примере MDR1206AFI

5.2. Использование предварительно сохраненных файлов отладочных конфигураций

В приложенных проектах файлы отладочных конфигураций под все конфигурации сборок для отладки с помощью FTDI2232HL уже реализованы (рисунок 17). Отладочные конфигурации сохранены в проектах в папке launch_cfg и автоматически добавляются в список отладочных конфигураций в окне "Debug Configurations" после импорта проекта (изменять имя проекта при этом не рекомендуется - иначе руководствоваться примечанием ниже). При необходимости настройки могут быть скорректированы (например, при использовании другого отладчика и образа собранной программы для загрузки) согласно инструкциям, приведенным в пункте выше.

Дополнительно следует отметить, что в отладочных конфигурациях для FLASH-памяти в них прописана команда программирования образа загрузочной программы MDR1206_Bootloader.hex из папки bootloader. При каждом запуске отладки с командой программирования образа MDR1206_Bootloader.hex осуществляется проверка на наличие загрузочной программы в памяти и ее запись, если контрольная сумма не совпадает (загрузочная программа не запрограммирована или в памяти по этим адресам другие данные).

Рисунок 17 – Предварительно созданные отладочные конфигурации


Если проект был переименован, сохраненные отладочные конфигурации не будут работать, т.к. в их структуре содержится информация о названии проекта и собираемого elf-файла. Для того, чтобы они работали с переименованным проектом, необходимо каждый файл отладочной конфигурации .launch открыть как текстовый файл (ПКМ по файлу .launch, в контекстном меню "Open with" -> "Text Editor"), найти все старые названия проекта и заменить на новые. Также рекомендуется изменить названия проектов на новые в названии файлов .launch. Для упрощения в проектах в папке с отладочными конфигурациями добавлен файл rename-launch-configurations.bat для применения этих изменений.

5.3. Запуск отладки

Для запуска отладки необходимо включить питание отладочной платы, подключить кабель USB A-B от платы к ПК, после чего нажать кнопку "Debug" в окне "Debug Configuraions" при выбранной отладочной конфигурации.

После запуска отладки на отладочном комплекте для микросхем MLDR1206FI ТСКЯ.468998.140 будут мигать светодиоды LED4-LED1, подключенным к выводам PD[8:5] микроконтроллера.

5.3.1. Программное определение микросхем MDR1206FI/MDR1206AFI по полю CHIP_ID регистра FLASH_CNTRL->CHIP_ID_CTRL

Поле CHIP_ID для определения микросхемы MDR1206FI или MDR1206AFI может быть прочитано в режиме отладки с помощью файла периферии SVD в окне "Memory". Для этого достаточно запустить любую отладочную конфигурацию RAM_TCM_Debug - при отладке только в ОЗУ различия в алгоритме программирования не влияют на возможность запуска отладки, поскольку механизм доступа к памяти ОЗУ одинаков, и используемый SVD-файл также не влияет, поскольку регистр FLASH_CNTRL->CHIP_ID_CTRL расположен по одинаковым адресам в MDR1206FI и MDR1206AFI. После перехода в отладку через окно Memory необходимо открыть просмотр регистров блока RST_CLK и установить в "1" бит PCLK[3] – FLASH в регистре RST_CLK->PER2_CLOCK для дальнейшего доступа к регистрам блока FLASH_CNTRL. Затем открыть регистры FLASH_CNTRL. В регистре FLASH_CNTRL->CHIP_ID_CTRL поле CHIP_ID указывает на версию микросхемы - значение 215 соответствует MDR1206AFI, значение 217 соответствует MDR1206FI (рисунок 18).

Рисунок 18 – Определение номера версии микросхемы по полю CHIP_ID в режиме отладки из ОЗУ

6. Программирование загрузочной программы в область BOOT FLASH

Микросхемы MDR1206FI, MDR1206AFI поставляются запрограммированными загрузочной программой. Загрузочная программа в микроконтроллере расположена в области BOOT (информационной области Flash-памяти) и может быть стерта или перезаписана при использовании. Рекомендуется всегда использовать актуальную версию загрузочной программы с сайта.
Скомпилированный образ описанного в спецификации примера загрузочной программы доступен в составе приложенных проектов в папках bootloader - файл MDR1206_Bootloader.hex. Данный файл общий для MDR1206FI и MDR1206AFI.
Для программирования загрузочной программы в область BOOT можно скомпилировать любой из прилагаемых проектов, выбрать прилагаемую отладочную конфигурацию "FLASH with Bootloader FTDI2232HL" и запустить отладку (следует обратить внимание, что конфигурация настроена именно для использования микросхемы-отладчика FTDI2232HL). Загрузка образа типовой загрузочной программы перед загрузкой программы проекта осуществляется с помощью прописанной в настройках отладочной конфигурации команды '-c "program bootloader/MDR1206_Bootloader.hex preverify verify"' для OpenOCD.

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

7. Дополнительные возможности

При разработке программы имеется возможность использовать дополнительные настройки проекта, такие как размещение функций в ОЗУ, размещение данных в AHB RAM для контроллера DMA, использование функций для работы с динамической памятью. Подробнее об этом описано в пунктах ниже.

7.1 Размещение функций в ОЗУ

В конфигурационных ld-файлах компоновщика добавлен ряд секций памяти. Данные секции также прописаны в файле system_MDR32VF0xI_sections.h на уровне CMSIS (описание секций приведено в h-файле). Если требуется разместить функцию в ОЗУ (при исполнении startup они будут скопированы из Flash-памяти в TCM RAM), для этого нужно добавить в объявлении функции определение __RAM_TEXT или __RAM_TEXT_NOINLINE. Пример размещения функции foo() в ОЗУ приведён во фрагменте кода 1.

Фрагмент кода 1 - Размещение функции foo() в ОЗУ
__RAM_TEXT_NOINLINE void foo(void);
Необходимо обратить внимание, что точки останова, которые проставлены в функции, расположенной в ОЗУ, могут работать некорректно и вызывать исключение "illegal instruction". Это происходит из-за того, что отладчик в таких функциях ставит программные точки останова до их инициализации.

В результате возникает следующая ситуация. При запуске отладки МК сбрасывается. После сброса МК содержимое ОЗУ, в котором будет находится требуемая функция, неопределенно. Отладчик до копирования функции из Flash в ОЗУ ставит в ОЗУ, где, как он предполагает, уже размещена функция, программную точку останова. Программная точка останова предполагает перезапись инструкции специальной командой, при этом инструкция, расположенная на месте точки останова, запоминается отладчиком. Так как точка останова ставится до копирования функции из Flash в ОЗУ, то отладчик запоминает данные неиницализированной ОЗУ, т.е. "мусор". После остановки в функции main(), когда ОЗУ уже проинициализировано, отладчик восстанавливает инструкции на местах точек останова, тем самым записывая в ОЗУ сохранённый ранее "мусор". Реальная инструкция будет утрачена.

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

При работе с микроконтроллером может также потребоваться перенос функции в ОЗУ, например, из Flash-памяти не на этапе сборки проекта, а прямо по ходу исполнения программы. Что необходимо учитывать в таком случае?

При рассмотрении данного вопроса мы говорим о том, что функция, находящаяся во Flash-памяти, должна быть скопирована по адресам памяти ОЗУ с соблюдением следующих требований:

- Выравнивание функции, которая будет перенесена из Flash-памяти в память ОЗУ. На уровне объявления прототипа функции выравнивание достигается объявлением атрибута "__attribute__((aligned(4)))".
- Мы должны гарантировать, что при использовании функции memcpy() для копирования функции из Flash-памяти в память ОЗУ функция копируется целиком, то есть верно задан аргумент "size". Контрольная сверка должна выполняться по .map файлу собранного проекта.
- После выполнения операции копирования функции в память ОЗУ необходимо для надежности вызвать инструкции "fence" и "fence.i" (делается при помощи ассемблерных вставок: __asm__ volatile ("fence iorw, iorw" ::: "memory"); и __asm__ volatile ("fence.i");), дабы обеспечить барьерную синхронизацию данных и инструкций.
- Объявление функции, которая будет использоваться для запуска перенесенной функции, необходимо выравнивать аналогично п.1. Закономерно эта функция для осуществления вызова должна представлять из себя функцию-указатель на адрес, куда была перенесена исходная функция. Например, это можно сделать следующим образом:
__attribute__((aligned(4))) void (*ram_func_ptr)(void) = (void (*)(void))func_addr; , где ram_func_ptr является названием функции для дальнейшего вызова, а func_addr - адрес, куда была перенесена функция в память ОЗУ.
- Если переносимая функция внутри себя содержит подвызов других функций (для функций, которые в себе не содержат вызовов других функций, данный пункт может не рассматриваться), то из-за нарушения относительной адресации вызов этих функций необходимо реализовывать через "функции-трамплины". Например, переносимая функция моргает светодиодами и содержит в себе две функции: PORT_ToggleBit() и DELAY_WaitMs(). В таком случае для корректного вызова переносимая функция должна вызывать второстепенные функции, объявленные следующим образом:

static void (* volatile delay_wait_ms_ptr)(uint32_t) = DELAY_WaitMs;
static void (* volatile port_toggle_bit_ptr)(MDR_PORT_TypeDef*, uint32_t) = PORT_ToggleBit;

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

7.2 Размещение данных в памяти AHB RAM

МК MDR1206FI, MDR1206AFI имеют три области ОЗУ: TCMA RAM, TCMB RAM и AHB RAM. Ядро имеет доступ ко всем трём областям ОЗУ, контроллер DMA получает доступ к памяти TCM RAM по шине AHB-Lite (рисунок 19) через арбитр доступа к блокам памяти TCM в ядре.

Рисунок 19 – Доступ к областям ОЗУ со стороны процессорного ядра и контроллера DMA

Интенсивный обмен данными в TCM RAM с помощью DMA может значительно замедлить работу как программы, так и DMA, поскольку ядро и DMA будут работать по одной шине. Поэтому данные, используемые контроллером DMA, предпочтительней размещать в области памяти AHB RAM. Для этого добавлены секции, доступные через определения __RAM_AHB_DATA и __RAM_AHB_BSS, которые предназначены для размещения инициализированных и неинициализированных данных соответственно. В startup-файл добавлен код инициализации данных.

Пример размещения массивов данных в памяти AHB RAM приведён во фрагменте кода 2.

Фрагмент кода 2 - Размещение массивов данных в памяти AHB RAM
__RAM_AHB_BSS int array[100]; // Данные инициализируются нулями, при старте не хранятся в Flash-памяти.
__RAM_AHB_DATA char init_message[] = "Hello World from MDR1206FI!"; // Данные при старте заполняются из Flash в ОЗУ.

7.3 Использование функций для работы с динамической памятью

Функции для работы с динамической памятью (malloc(), calloc(), realloc(), free()) предоставляет библиотека newlib (реализация стандартной библиотеки C). Библиотека newlib поставляется в двух вариантах - обычная версия (newlib) и компактная версия (newlib-nano). Для использования newlib-nano в настройках проекта "C/C++ Build -> Settings -> GNU RISC-V Cross C++ Linker -> Miscellaneous", необходимо установить опцию "Use newlib-nano", рисунок 20.


Рисунок 20 – Использование библиотеки newlib-nano

Библиотека newlib взаимодействует с операционной системой (ОС) через системные вызовы. Реализация системных вызовов по умолчанию вызывает ОС с помощью исключения ecall. Если в проекте не используется ОС, то функции системных вызовов необходимо реализовать самостоятельно. Подробнее про реализацию функций системных вызовов написано на сайте newlib.

Для работы с функциями, которые используют динамическую память, необходимо реализовать функцию _sbrk(). Реализация данной функции представлена в файле "syscalls.c", который приложен к примерам проектов в "Standard Peripherals Library", например, по пути: "ExampleProjects\MDR32VF0xI\Eclipse".