файлов зависит от среды разработки, в данном случае рассматриваем среду разработки фирмы IAR. В ассемблерном модуле начального запуска определено, какие функции будут вызываться первыми после системного сброса (SystemInit и __iar_program_start), а также определена таблица адресов вызова обработчиков прерываний и исключительных ситуаций, в нем же инициализируется указатель главного стека (MSP). Как вы думаете, что находится в файлах core_cmInstr.h и core_cmFunc.h ?

1.2.2Описание библиотеки MDR32F9Qx_StdPeriph_Driver

Библиотека по своей структуре достаточна проста и разбита на модули соответствующие модулям МК. Например, работа с модулем аналого-цифрового преобразования (ADC) реализована в файлах MDR32F9Qx_adc.c(*.h) и т.д. для каждого модуля МК. Заголовочные файлы находятся в папке inc исходные тексты в папке src.

1.2.3Описание примеров работы с блоками МК

Примеры конфигурирования и использования всех блоков МК находятся в папке:

\_For_Students\MPSSAU\Milandr\Программное обеспечение\MDR_Library\Library\Examples\MDR32F9Q1_EVAL.

В фалах MDR32F9Qx_board.h, MDR32F9Qx_config.h содержится выбор отладочной платы и определение частот работы МК, некоторых констант и определений.

Далее в папках ADC, BKP, CAN... находятся примеры проектов работы с соответствующими блоками МК. В каждом примере есть файл main.c и может быть MDR32F9Qx_it.c (h) в котором реализован обработчик прерывания.

1.3Описание демонстрационного проекта MDR32F9Qx_Demo

Кроме описанного программного обеспечения мы также будем использовать демонстрационный проект, который, как правило, предоставляется вместе с отладочной (оценочной) платой, в нашем случае - это Evolution Board for MCU 1986VE91T rev.4 (см.

Или по адресу на сервере sv2 «\_For_Students\MPSSAU\Milandr\Программное обеспечение\MDR_Library\MDR32F9Qx_Demo».

Демонстрационный проект московской фирмы «Фитон» реализован достаточно профессионально и не плохо документирован (см. раздел Оформление и документирование), поэтому его можно взять за основу для подражания. Разберем состав проекта и правила разработки многомодульных проектов, когда весь программный код разбивается на отдельные, как правило, функционально различные и в тоже время взаимосвязанные участки кода.

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

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

Рисунок 2 — Внешний вид окна IDE с открытым проектом MDR32F9Qx_Demo

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

1HL_Appl — прикладные функции верхнего уровня проекта, соответствует группе Users.

2MCU_drv — драйвера устройств микроконтроллера, содержащие подгруппы:

2.1Config – где находятся файлы конфигурации проекта : *.icf —

конфигурация ликовщика, platform_config.h — привязка к конкретному железу, допустим содержащая строки #define LCD_PORT PORTA.

2.2 Interrupts – логично собрать все обработчики прерывания в одном месте. Подумайте почему ?