Exponenta Banner

Управляйте файлами процесса сборки

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

  • Открытый интерфейс к образцовым точкам входа

  • Перечислимые типы, соответствующие встроенным типам данных

  • Структуры данных, которые описывают образцовые сигналы, состояния и параметры

Генератор кода создает файлы model.* во время генерации кода и процесса сборки. Можно настроить имена файлов для сгенерированного заголовка, источника и файлов данных. Для получения дополнительной информации смотрите, Настраивают Сгенерированные Имена файлов (Embedded Coder). Генератор кода создает дополнительные папки и файлы зависимости, чтобы поддержать совместно использованные утилиты и модели - ссылки. Для получения дополнительной информации о папках, которые создает процесс сборки, смотрите, Управляют Папками Процесса сборки. Для примера, который показывает, как использовать проект управлять папками процесса сборки, смотрите, Генерируют Код и Моделируют Модели в Проекте.

В зависимости от архитектур модели и опций генерации кода, процесс сборки для основанного на GRT системного конечного файла может произвести файлы, которые процесс сборки не генерирует для основанного на ERT системного конечного файла. Кроме того, для основанных на ERT системных конечных файлов пакеты процесса сборки сгенерировали файлы по-другому, чем для основанных на GRT системных конечных файлов. Смотрите Справляются с Упаковкой Файла Модулей Сгенерированного кода (Embedded Coder).

Примечание

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

Таблица описывает сгенерированные файлы принципала. В сгенерированных именах файлов, показанных в таблице, model представляет имя модели, для которой вы генерируете код. subsystem представляет имя подсистемы в модели. Когда вы выбираете параметр Create code generation report, генератор кода производит набор файлов HTML. Существует один файл HTML для каждого исходного файла плюс индексный файл _contents.html model в подпапке html в вашей папке сборки. Исходные и заголовочные файлы в таблице имеют отношения зависимости. Для описаний других зависимостей от файла смотрите, Управляют Зависимостями от Файла Процесса сборки и Добавляют Зависимости от Процесса сборки.

ФайлОписание

builtin_typeid_types.h

Задает перечислимый тип, соответствующий встроенным типам данных.

Сборка модели генерирует этот файл, когда один или несколько из этих условий применяется:

  • Ваша модель содержит диаграмму Stateflow, которая использует сообщения.

  • Ваша настройка модели включает MAT-file logging.

  • Ваша настройка модели включает опции API C в Code Generation> Interface.

modelsources.txt

Перечисляет дополнительные источники, чтобы включать в компиляцию.

model.bat

Содержит команды пакетного файла Windows®, которые устанавливают среду компилятора и вызывают утилиту make.

Для получения дополнительной информации об использовании этого файла см. model.bat.

model.c

model.cpp

Соответствует образцовому файлу.

Компилятор Выходного языка генерирует этот C или файл исходного кода C++. Файл содержит:

  • Включайте файлы model.h и model_private.h

  • Данные, кроме данных, помещенных в model_data.c

  • Образцово-специфичный код планировщика

  • Образцово-специфичный код решателя

  • Образцовый регистрационный код

  • Код алгоритма

  • Дополнительные функции обертки GRT

model.exe (платформа Windows)

model (UNIX® и платформы Macintosh)

Файл исполняемой программы.

Сборка модели генерирует этот файл, если вы явным образом не указываете, что генератор кода производит код только. Сборка генерирует исполняемый файл в текущей папке (не папка сборки) под управлением утилиты make вашей системы разработки.

model.h

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

Подсистема .c или файлы .cpp в модели включает model.h. Этот файл включает:

  • Экспортируемые символы данных Simulink®

  • Экспортируемая машина Stateflow® породила данные

  • Структуры данных модели, включая rtM

  • Образцовые функции точки входа

Для получения дополнительной информации см. model.h.

model.mk

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

Если вы устанавливаете переменную окружения MAKEFLAGS, не выбирайте опции с этой переменной, которые конфликтуют с текущей утилитой make, используемой процессом сборки.

model.rtw

Представляет скомпилированную модель.

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

model_capi.h

model_capi.c

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

Для получения дополнительной информации смотрите, обмениваются Данными Между Сгенерированным и Внешним Кодом Используя API C.

model_data.c

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

Сборка модели генерирует этот файл, когда модель использует эти структуры данных. Объявления extern для структур появляются в model.h. Когда существующий, этот файл содержит:

  • Постоянные параметры блока I/O

  • Включайте файлы model.h и model_private.h

  • Определения для нулевых представлений для пользовательских типов данных структуры, которые использует модель

  • Постоянные параметры

model_dt.h

(дополнительный файл), Объявляет структуры, которые содержат информацию о переходе типа данных и типа данных для сгенерированных структур данных модели для поддержки режима external mode.

model_private.h

Содержит локальные константы define и локальные данные для модели и подсистем.

Сгенерированные исходные файлы от сборки модели включают этот файл. Когда вы соединяете интерфейсом с внешним кодом со сгенерированным кодом из модели, включаете model_private.h. Файл содержит:

  • Импортированные символы данных Simulink

  • Импортированная машина Stateflow породила данные

  • Точки входа Stateflow

  • Детали Simulink Coder™ (различные макросы, enum s, и т.д, которые являются частными к коду),

Для получения дополнительной информации смотрите, Управляют Зависимостями от Файла Процесса сборки.

model_reference_types.h

Содержит определения типа для синхронизации мостов.

Сборка модели генерирует этот файл для модели, на которую ссылаются, или модели, содержащей блоки модели - ссылки.

model_targ_data_map.m

(дополнительный файл) команды языка Contains MATLAB®, что использование режима external mode, чтобы инициализировать связь режима external mode.

model_types.h

Предоставляет предописания для структуры данных модели реального времени и структуры данных параметров.

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

multiword_types.h

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

Сборка модели генерирует этот файл, когда один или несколько из этих условий применяется:

  • Ваша модель использует типы данных многословные.

  • Ваша настройка модели включает MAT-file logging.

  • Ваша настройка модели включает Code Generation> Interface> External mode.

rtGetInf.c

rtGetInf.h

rtGetNaN.c

rtGetNaN.h

rt_nonfinite.c

rt_nonfinite.h

Объявляет и инициализирует глобальные неличные значения для inf, минус inf и nan. Обеспечивает неличные функции сравнения.

Сборка модели генерирует эти файлы, когда один или несколько из этих условий применяется:

  • Модель содержит S-функции.

  • Сгенерированный код из модели требует неличных чисел.

  • Ваша настройка модели включает MAT-file logging.

  • Ваша настройка модели выбирает grt.tlc как System target file и включает Classic call interface.

rtmodel.h

Содержит директивы #include, требуемые статическими основными программными модулями, такими как rt_main.c.

Процесс сборки не создает эти модули во время генерации кода. Модули включают rtmodel.h, чтобы получить доступ к образцово-специфичным структурам данных и точкам входа. Если вы создаете свой собственный основной программный модуль, убедитесь, что включали rtmodel.h.

rtwtypes.h

Предоставляет существенные определения типа, операторы #define и перечисления.

Для основанных на GRT системных конечных файлов rtwtypes.h включает simstruc_types.h, который, в свою очередь, включает tmwtypes.h.

Для основанных на ERT системных конечных файлов, которые не генерируют интерфейс GRT и не иметь невстроенных S-функций, rtwtypes.h не включает simstruc_types.h.

Для получения дополнительной информации см. rtwtypes.h и Управляйте Зависимостями от Файла Процесса сборки.

rtw_proj.tmw

sl_proj.tmw

Файлы маркера.

Процесс сборки генерирует эти файлы, чтобы помочь утилите make определить, когда перекомпилировать и соединить сгенерированный код.

rt_defines.h

Содержит определения типа для специальных математических констант (таких как π и e) и задает макрос UNUSED_PARAMETER.

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

rt_sfcn_helper.h

rt_sfcn_helper.c

(дополнительные файлы), Обеспечивают функции, которые невстроенные S-функции используют в модели.

Невстроенные S-функции используют функции rt_CallSys, rt_enableSys и rt_DisableSys, чтобы вызвать нисходящие подсистемы вызова функций.

subsystem.c

(дополнительный файл), Содержит исходный код C для каждой невстроенной невиртуальной подсистемы, или скопируйте код, когда подсистема сконфигурирована, чтобы поместить код в отдельный файл.

subsystem.h

(дополнительный файл), Содержит экспортируемые символы для невстроенных невиртуальных подсистем.

model .bat

Этот файл содержит команды пакетного файла Windows, которые устанавливают среду компилятора и вызывают утилиту make.

Если вы используете подход набора инструментальных средств для процесса сборки, также можно использовать этот пакетный файл, чтобы извлечь информацию от сгенерированного make-файла, model.mk. Информация включает макроопределения и значения, которые появляются в make-файле, таком как CFLAGS (Флаги компилятора C) и CPP_FLAGS (флаги компилятора C++). С папкой, содержащей model.bat, выбранный как текущая рабочая папка, в Командном окне, введите:

>> system('model.bat info')

На UNIX и платформах Macintosh, генератор кода не создает файл model.bat. Чтобы извлечь информацию для сборок подхода набора инструментальных средств от сгенерированного make-файла в этих системах, в Командном окне, введите:

>> system('gmake -f model.mk info')

model.h

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

  • Экспортируемые глобальные сигналы

    extern int32_T INPUT;    /* '<Root>/In' */

  • Глобальные определения структуры

    /* Block parameters (auto storage) */
extern Parameters_mymodel mymodel_P;

  • Макроопределения модели реального времени (RTM)

    #ifndef rtmGetSampleTime
# define rtmGetSampleTime(rtm, idx) 
((rtm)->Timing.sampleTimes[idx])
#endif

  • Образцовые функции точки входа (пример ERT)

    extern void mymodel_initialize(void);
extern void mymodel_step(void);
extern void mymodel_terminate(void);

main.c (или .cpp) файл включает model.h. Если сборка модели генерирует main.c (или .cpp) файл из скрипта TLC, источник TLC может включать model.h.

#include "%<CompiledModel.Name>.h"

Если main.c является статическим исходным файлом, можно использовать фиксированное имя заголовочного файла rtmodel.h. Этот файл включает заголовочный файл model.h:

#include "model.h"     /* If main.c is generated */

или

#include "rtmodel.h"   /* If static main.c is used */

Другие внешние исходные файлы могут потребовать, чтобы включать model.h, чтобы взаимодействовать через интерфейс к данным модели, например, экспортировал глобальные параметры или сигналы. Сам файл model.h может иметь дополнительные зависимости от заголовка из-за требований сгенерированного кода. Смотрите Системные Заголовочные файлы и Заголовочные файлы Генератора кода.

Чтобы уменьшать зависимости и сократить количество включенных заголовочных файлов, смотрите, Управляют Зависимостями от Файла Процесса сборки.

rtwtypes.h

Заголовочный файл rtwtypes.h задает типы данных, структуры и макросы, требуемые сгенерированным кодом. Вы включаете rtwtypes.h для GRT и системных конечных файлов ERT вместо включения tmwtypes.h или simstruc_types.h.

Часто, сгенерированный код требует что переполнение целочисленных операций или потеря значимости в определенных значениях. Например, когда код ожидает 16-битное целое число, код не принимает 8-битное или 32-битный целочисленный тип. Язык C не устанавливает норму для количества битов в типах, таких как char, int и другие. Так, нет никакого универсально принятого типа данных в C, чтобы использовать для размерных целых чисел.

Чтобы разместить эту функцию языка C, сгенерированный код использует измеренные целочисленные типы, такие как int8_T, uint32_T и другие, которые не являются стандартными типами C. В rtwtypes.h сгенерированный код сопоставляет эти размерные целочисленные типы с соответствующим базовым типом ключевого слова C с помощью информации в панели Hardware Implementation параметров конфигурации.

Генератор кода производит оптимизированную версию rtwtypes.h для основанных на ERT системных конечных файлов, когда эти условия применяются:

  • Configuration Parameters> Code Generation> Interface> Advanced parameters> Classic call interface не выбран.

  • Модель не содержит невстроенные S-функции.

Включайте rtwtypes.h. Если вы включаете его для системных конечных файлов GRT, например, легче использовать ваш код с основанными на ERT системными конечными файлами.

Для GRT и системных конечных файлов ERT, местоположение rtwtypes.h зависит от того, использует ли процесс сборки разделяемое сервисное местоположение. Если это использует общий ресурс, генератор кода помещает rtwtypes.h в slprj/target/_sharedutils; в противном случае это помещает rtwtypes.h в папку сборки (model_target_rtw). Смотрите Задают Интерфейсы Сгенерированного кода.

Исходные файлы включают заголовочный файл rtwtypes.h, когда исходные файлы используют имена типов генератора кода или другие определения генератора кода. Типичный пример для файлов, которые объявляют переменные при помощи типа данных генератора кода, например, uint32_T myvar.

Исходный файл, что генератор кода и использование S-функции могут использовать макрос препроцессора MATLAB_MEX_FILE. Макроопределение прибывает из функции mex:

#ifdef  MATLAB_MEX_FILE
#include "tmwtypes.h"
#else
#include "rtwtypes.h"
#endif

Исходный файл для генератора кода main.c (или .cpp) файл включает rtwtypes.h без проверок препроцессора.

#include "rtwtypes.h"

Пользовательские исходные файлы, которые генерирует Компилятор Выходного языка, могут также испустить эти операторы include в свой сгенерированный файл.

Смотрите Размещение Управления rtwtypes.h для Разделяемого Служебного Кода.

Похожие темы

Документация Simulink Coder
Поддержка