Настройте make-файлы шаблона

Чтобы сконфигурировать или настроить make-файл шаблона (TMF), необходимо быть знакомы с как make команда работает и как она обрабатывает make-файл (.mk файл). Необходимо также изучить правила сборки make-файла. Для получения информации об этих темах обратитесь к документации, обеспеченной сделать утилитой, которую вы используете.

Обработайте по шаблону make-файлы и лексемы

Make-файл шаблона содержит лексемы. Процесс сборки расширяет лексемы и создает make-файлы:

  • model.mk – Компиляции и код ссылок сгенерированы от компонентов модели.

  • rtwshared.mk – Компиляции сгенерировали совместно использованный служебный код.

Make-файлы (model_or_sharedutils.mk) используйте команды, которые характерны для вашего компьютера разработчика.

Обработайте лексемы make-файла по шаблону

make_rtw команда (или различная команда, которой предоставляют некоторые цели), направляют процесс генерации model_or_sharedutils.mk. make_rtw команда обрабатывает TMF, заданный на панели Code Generation диалогового окна Configuration Parameters. make_rtw копирует TMF, линию за линией, расширяя каждую лексему, с которой сталкиваются. Обработайте по шаблону Лексемы Make-файла, Расширенные списками make_rtw лексемы и их расширения.

Эти лексемы используются несколькими способами расширенным make-файлом:

  • Управлять условным поведением в make-файле. Условные выражения используются, чтобы управлять списками исходных файлов, именами библиотеки, цель, которая будет создана, и другая связанная со сборкой информация.

  • Обеспечить макроопределения для компиляции файлов, например, -DINTEGER_CODE=1.

Обработайте по шаблону Лексемы Make-файла, Расширенные make_rtw

ЛексемаРасширение
Общая цель

|>ADDITIONAL_LDFLAGS<|

Компоновщик отмечает автоматически добавленный блоками.

|>ALT_MATLAB_BIN<|

Чередуйте полный путь для MATLAB® исполняемый файл; значение отличается, чем значение для MATLAB_BIN лексема, когда полный путь содержит пробелы.

|>ALT_MATLAB_ROOT<|

Чередуйте полный путь для установки MATLAB; значение отличается, чем значение для MATLAB_ROOT лексема, когда полный путь содержит пробелы.

|>BUILDARGS<|

Опции передали make_rtw. Эта лексема обеспечивается так, чтобы содержимое вашего model_or_sharedutils.mk изменение файла, когда вы изменяете аргументы сборки, таким образом обеспечивая обновление модулей, когда ваши опции сборки изменяются.

|>COMBINE_OUTPUT_UPDATE_FCNS<|

True (1), когда вы выбираете параметр конфигурации модели Single output/update function, в противном случае Ложный (0). Используемый для макроопределения -DONESTEPFCN=1.

|>COMPILE_FLAGS_OTHER<|

Компилятор отмечает в группе кроме 'OPTS', 'OPT_OPTS', и 'OPTIMIZATION_FLAGS'. Процесс сборки производит предупреждение если |>COMPILE_FLAGS_OTHER<| отсутствует, и эти условия применяются:

  • Информация о сборке содержит флаг компилятора, который не находится в 'OPTS', 'OPT_OPTS', или 'OPTIMIZATION_FLAGS'.

  • Флаг компилятора не находится в make-файле шаблона.

|>COMPUTER<|

Тип компьютера. Смотрите computer MATLAB команда.

|>DEFINES_OTHER<|

Макроопределения препроцессора в группе кроме 'OPTS', 'OPT_OPTS', 'OPTIMIZATION_FLAGS', и 'Custom'.

Макроопределение препроцессора в 'OPTS', 'OPT_OPTS', 'OPTIMIZATION_FLAGS', или 'Custom' это имеет соответствующую переменную/маркерную пару в make-файле шаблона, не расширен в DEFINES_OTHER. Это поведение помогает избежать условия дублирующихся макроопределений препроцессора.

Например, некоторые make-файлы шаблона содержат эти операторы:

...
NUMST = |>NUMST<|
...
CPP_REQ_DEFINES1 = ... -DNUMST=$(NUMST) ...
Если make-файл шаблона содержит переменный/маркерный парный NUMST = |>NUMST<| и NUMST макроопределение препроцессора в buildInfo, затем процесс сборки не расширяет его в DEFINES_OTHER.

Процесс сборки производит предупреждение если |>DEFINES_OTHER<| отсутствует, и эти условия применяются:

  • Информация о сборке содержит макроопределение препроцессора, которое не находится в 'OPTS', 'OPT_OPTS', 'OPTIMIZATION_FLAGS', или 'Custom'.

  • Макроопределение препроцессора, например, NUMST, не находится в make-файле шаблона.

|>EXPAND_LIBRARY_LOCATION<|

Местоположение предварительно скомпилированного файла библиотеки. TargetPreCompLibLocation параметр конфигурации может заменить эту установку. Для примеров смотрите Местоположение Библиотеки Управления и Называющий Во время Сборки.

|>EXPAND_LIBRARY_NAME<|

Имя библиотеки. Для примеров смотрите Местоположение Библиотеки Управления и Называющий Во время Сборки и Измените Make-файл Шаблона для rtwmakecfg.

|>EXPAND_LIBRARY_SUFFIX<|

Суффикс библиотеки. TargetLibSuffix параметр конфигурации может заменить эту установку. Для примеров смотрите Местоположение Библиотеки Управления и Называющий Во время Сборки.

|>EXT_MODE<| (Не требуемый для R2018a и позже если make-файл шаблона задает TOOLCHAIN_NAME)

True (1), чтобы включить генерацию режима external mode поддерживает код, в противном случае Ложный (0).

|>EXTMODE_TRANSPORT<| (Не требуемый для R2018a и позже если make-файл шаблона задает TOOLCHAIN_NAME)

Индекс транспортного механизма (например, tcpipпоследовательный) для режима external mode.

|>EXTMODE_STATIC<| (Не требуемый для R2018a и позже если make-файл шаблона задает TOOLCHAIN_NAME)

True (1), если выделение статического ЗУ выбрано для режима external mode. Ложь (0), если динамическое выделение памяти выбрано.

|>EXTMODE_STATIC_SIZE<| (Не требуемый для R2018a и позже если make-файл шаблона задает TOOLCHAIN_NAME)

Размер выделения статического ЗУ буферизует для режима external mode.

|>GENERATE_ERT_S_FUNCTION<|

True (1), когда параметр конфигурации модели Create block установлен в SIL, в противном случае Ложный (0). Используемый для управления цели make-файла сборки.

|>INCLUDE_MDL_TERMINATE_FCN<|

True (1), когда параметр конфигурации модели Terminate function required выбран, в противном случае Ложный (0). Используемый для макроопределения -DTERMFCN==1.

|>INTEGER_CODE<|

True (1), когда параметр конфигурации модели Support floating-point numbers очищен, в противном случае Ложный (0). INTEGER_CODE необходимое макроопределение при компиляции исходного кода и используется, когда выбор предварительно скомпилировал библиотеки, чтобы соединиться против.

|>MAKEFILE_NAME<|

model_or_sharedutils.mk — Имя make-файла, который был создан из TMF.

|>MAT_FILE<|

True (1), когда параметр конфигурации модели MAT-file logging выбран, в противном случае Ложный (0). MAT_FILE необходимое макроопределение при компиляции исходного кода и также используется, чтобы включать код логгирования в процесс сборки.

|>MATLAB_BIN<|

Местоположение исполняемой программы MATLAB.

|>MATLAB_ROOT<|

Путь туда, где MATLAB установлен.

|>MEM_ALLOC<|

RT_MALLOC или RT_STATIC. Указывает, как память должна быть выделена.

|>MEXEXT<|

Расширение файла MEX. Смотрите mexext MATLAB команда.

|>MODEL_MODULES<|

Дополнительные сгенерированные исходные модули. Например, можно разделить большую модель в два файла, modelC и model1.c. В этом случае эта лексема расширяется до model1.c.

|>MODEL_MODULES_OBJ<|

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

|>MODEL_NAME<|

Имя Simulink® блок-схема, в настоящее время создаваемая.

|>MULTITASKING<|

True (1), если режим решателя является многозадачностью, в противном случае Ложной (0).

|>NCSTATES<|

Количество непрерывных состояний.

|>NUMST<|

Количество шагов расчета в модели.

|>RELEASE_VERSION<|

Версия выпуска MATLAB.

|>S_FUNCTIONS_LIB<|

Список библиотек S-функции, доступных для соединения.

|>SOLVER<|

Исходное имя файла решателя, например, ode3.c.

|>SOLVER_OBJ<|

Объект Solver (.obj) имя файла, например, ode3.obj.

|>TARGET_LANG_EXT<|

c когда параметр конфигурации модели Language установлен в C, cpp когда Language установлен в C++. Используемый в make-файле, чтобы управлять расширением на сгенерированных исходных файлах.

|>TID01EQ<|

True (1), если частоты дискретизации непрерывной задачи и первой дискретной задачи равны, в противном случае Ложные (0).

S-функция и информационная поддержка сборки

Примечание

Для примеров лексем в этом разделе смотрите, Изменяют Make-файл Шаблона для rtwmakecfg.

|>START_EXPAND_INCLUDES<|
|>EXPAND_DIR_NAME<|
|>END_EXPAND_INCLUDES<|

Список имен папок, чтобы добавить к включать пути. Кроме того, ADD_INCLUDES макрос должен быть добавлен к INCLUDES строка.

|>START_EXPAND_LIBRARIES<|
|>EXPAND_LIBRARY_NAME<|
|>END_EXPAND_LIBRARIES<|

Список имен библиотеки.

|>START_EXPAND_MODULES<|
|>EXPAND_MODULE_NAME<|
|>END_EXPAND_MODULES<|

Имена модуля библиотеки в |>START_EXPAND_LIBRARIES<| и |>START_PRECOMP_LIBRARIES<| списки библиотек.

|>START_EXPAND_RULES<|
|>EXPAND_DIR_NAME<|
|>END_EXPAND_RULES<|

Правила make-файла.

|>START_PRECOMP_LIBRARIES<|
|>EXPAND_LIBRARY_NAME<|
|>END_PRECOMP_LIBRARIES<|

Список предварительно скомпилированных имен библиотеки.

Поддержка модели - ссылки

Примечание

Для примеров лексем в этом разделе см., что Модель Оказания Ссылается на Поддержку в TMF.

|>MASTER_ANCHOR_DIR<|

Для параллельных сборок, текущая папка работы (pwd) в то время запущенная сборка.

|>MODELLIB<|

Имя файла библиотеки сгенерировано для текущей модели.

|>MODELREFS<|

На список моделей ссылается топ-модель.

|>MODELREF_LINK_LIBS<|

Список библиотек модели, на которые ссылаются, против которых соединяется топ-модель.

|>MODELREF_LINK_RSPFILE_NAME<|

Имя файла ответа, против которого соединяется топ-модель. Эта лексема допустима только для сред сборки, которые поддерживают файлы ответа компоновщика. Для примера его использования смотрите matlabroot/toolbox/coder/compile/tmf/grt_vcx64.tmf.

|>MODELREF_TARGET_TYPE<|

Тип цели создается. Возможные значения

  • NONE: Автономная или топ-модель модели, ссылающаяся на другие модели

  • RTW: Сборка цели модели-ссылки

  • SIM: Симуляция модели - ссылки предназначается для сборки

|>RELATIVE_PATH_TO_ANCHOR<|

Относительный путь, от местоположения сгенерированного make-файла, к MATLAB рабочая папка.

|>START_DIR<|

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

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

NUMST = |>NUMST<|

расширяется до:

NUMST = 2

В дополнение к вышеупомянутому, make_rtw расширяет лексемы из других источников:

  • Целевые лексемы заданы в целевых опциях диалогового окна Configuration Parameters

  • Структуры в rtwoptions раздел системного конечного файла. Структуры в rtwoptions массив структур, которые содержат поле makevariable расширены.

Следующий пример извлечен из matlabroot/rtw/c/grt/grt.tlc. Раздел начиная с BEGIN_RTW_OPTIONS содержит код MATLAB, который настраивает rtwoptions. Следующая директива вызывает |>EXT_MODE<| лексема, которая будет расширена до 1 (на) или 0 (прочь), в зависимости от того, как вы устанавливаете опции режима external mode.

rtwoptions(2).makevariable = 'EXT_MODE'

Вызовите сделать Утилиту

сделайте Команду

После создания model_or_sharedutils.mk от вашего TMF процесс сборки вызывает make команда. Вызвать make, процесс сборки дает эту команду.

makecommand -f model_or_sharedutils.mk

makecommand задан MAKECMD макрос в вашем системном конечном файле TMF (см. Структуру Make-файла Шаблона). Можно задать дополнительные опции к make при помощи параметра конфигурации модели Делают команду. (См., что разделы Задают Сделать Make-файлы Команды и Шаблона и Делают Опции.)

Например, определение OPT_OPTS=-O2 в Сделать команде поле вызывает make_rtw сгенерировать следующий make команда.

makecommand -f model_or_sharedutils.mk OPT_OPTS=-O2

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

сделайте Версии программы

Сделать утилита позволяет вам управлять почти каждым аспектом создания вашей программы в реальном времени. Существует несколько различных версий make доступный. Генератор кода обеспечивает GNU Фонда свободного программного обеспечения® make для обоих UNIX®[1] и платформы PC в специфичных для платформы подпапках под

matlabroot/bin

Возможно использовать другие версии make с генератором кода, несмотря на то, что GNU Делают, рекомендуется. Чтобы быть совместимыми с генератором кода, проверьте что ваша версия make поддерживает следующий формат команды.

makecommand -f model_or_sharedutils.mk

Структура make-файла шаблона

TMF имеет несколько разделов, включая следующее:

  • Abstract — Описывает то, для чего предназначается make-файл. Вот представительный краткий обзор от ERT TMFs в matlabroot/toolbox/coder/compile/tmf:

    # Abstract:
    #       Template makefile for building a Windows-based stand-alone embedded
    #       real-time version of Simulink model using generated C code and the
    #          Microsoft Visual C/C++ compiler for x64.
    #
    #       Note that this template is automatically customized by the build 
    #       procedure to create "<model>.mk"
    #
    #       The following defines can be used to modify the behavior of the
    #       build:
    #         OPT_OPTS       - Optimization option. See DEFAULT_OPT_OPTS in
    #                          vctools.mak for default.
    #         OPTS           - User specific options.
    #         CPP_OPTS       - C++ compiler options.
    #         USER_SRCS      - Additional user sources, such as files needed by
    #                          S-functions.
    #         USER_INCLUDES  - Additional include paths
    #                          (i.e. USER_INCLUDES="-Iwhere-ever -Iwhere-ever2")
    #
    #       To enable debugging:
    #         set DEBUG_BUILD = 1, which will trigger OPTS=-Zi (may vary with
    #                               compiler version, see compiler doc) 
    #
    #       This template makefile is designed to be used with a system target
    #       file that contains 'rtwgensettings.BuildDirSuffix' see ert.tlc
  • Macros read by make_rtw раздел — Задает макросы, которые говорят make_rtw как обработать TMF. Вот представительный Macros read by make_rtw разделите от GRT TMFs в matlabroot/toolbox/coder/compile/tmf:

    #------------------------ Macros read by make_rtw -----------------------------
    #
    # The following macros are read by the build procedure:
    #
    #  MAKECMD         - This is the command used to invoke the make utility
    #  HOST            - What platform this template makefile is targeted for
    #                    (i.e. PC or UNIX)
    #  BUILD           - Invoke make from the build procedure (yes/no)?
    #  SYS_TARGET_FILE - Name of system target file.
    
    MAKECMD         = nmake
    HOST            = PC
    BUILD           = yes
    SYS_TARGET_FILE = any
    BUILD_SUCCESS	= ^#^#^# Created
    
    # Opt in to simplified format by specifying compatible Toolchain
    TOOLCHAIN_NAME = [\
        "Microsoft Visual C++ 2019 v16.0 | nmake (64-bit Windows)", \
        "Microsoft Visual C++ 2017 v15.0 | nmake (64-bit Windows)", \
        "Microsoft Visual C++ 2015 v14.0 | nmake (64-bit Windows)"]
    

    Макросы в этом разделе могут включать:

    • MAKECMD — Указывает, что команда раньше вызывала сделать утилиту. Например, если MAKECMD = mymake, затем make вызванная команда

      mymake -f model_or_sharedutils.mk

    • HOST — Задает платформу, предназначенную этим TMF. Это может быть PCUnix, computer_name (см. computer MATLAB команда), или ANY.

    • BUILD — Сообщает make_rtw должно ли это вызвать make из процедуры сборки. Задайте yes или no.

    • SYS_TARGET_FILE — Задает имя системного конечного файла или значения any. Это используется для непротиворечивости, проверяющей make_rtw проверять системный конечный файл, заданный в панели Target selection панели Code Generation диалогового окна Configuration Parameters. Если вы задаете any, можно использовать TMF с любым системным конечным файлом.

    • BUILD_SUCCESS — Когда make-файл создает статическую библиотеку, он производит BUILD_SUCCESS строка, как задано, например, этим правилом в ert_vcx64.tmf:

      $(PRODUCT) : $(OBJS) $(LIBS) $(MODELREF_LINK_LIBS)
      	@cmd /C "echo ### Linking ..."
      	$(LD) $(LDFLAGS) $(LIBS) \
          @$(CMD_FILE) @$(MODELREF_LINK_RSPFILE) -dll -def:$(MODEL).def -out:$@
      	@cmd /C "echo $(BUILD_SUCCESS) dynamically linked library  $(PRODUCT)"
      

      Когда процесс сборки находит BUILD_SUCCESS представьте в виде строки, это опрашивает относительно существования обновленного статического файла библиотеки. Процесс сборки не соединяет файл библиотеки с исполняемым файлом, пока процесс сборки не может подтвердить присутствие файла библиотеки, с обновленной меткой времени, в файловой системе.

      Если процесс сборки не находит BUILD_SUCCESS в журнале компиляции затем процесс сборки принимает, что обновленный архив библиотеки доступен в файловой системе. При необходимости процесс сборки соединяет библиотеку с исполняемым файлом.

  • Tokens expanded by make_rtw раздел — Задает лексемы что make_rtw расширяется. Вот краткая выборка от представительного Tokens expanded by make_rtw разделите от ERT TMFs в matlabroot/toolbox/coder/compile/tmf/:

    #---------------------- Tokens expanded by make_rtw ----------------------------
    #
    # The following tokens, when wrapped with "|>" and "<|" are expanded by the
    # build procedure.
    #
    #  MODEL_NAME          - Name of the Simulink block diagram
    #  MODEL_MODULES       - Any additional generated source modules
    #  MAKEFILE_NAME       - Name of makefile created from template makefile <model>.mk
    #  MATLAB_ROOT         - Path to where MATLAB is installed.
    ...
    
    MODEL                   = |>MODEL_NAME<|
    MODULES                 = |>MODEL_MODULES<|
    PRODUCT                 = |>PRODUCT<|
    MAKEFILE                = |>MAKEFILE_NAME<|
    MATLAB_ROOT             = |>MATLAB_ROOT<|
    ...

    Для получения дополнительной информации о лексемах TMF, смотрите Лексемы Make-файла Шаблона, Расширенные make_rtw.

  • Последующие разделы варьируются на основе компилятора, хоста и цели. Некоторые общие разделы включают Model and reference models, External mode, Tool Specifications или Tool Definitions'includepath' , C Flags, Additional Libraries, и Source Files.

  • Rules раздел — Содержит сделать правила, использованные в создании исполняемого файла из сгенерированного исходного кода. Правила сборки обычно характерны для вашей версии, делают. Rules разделите может сопровождаться связанными разделами, такими как Dependencies.

Настройте и создайте make-файлы шаблона

Введение

В этом разделе описываются механику подготовки пользовательского make-файла шаблона (TMF) и слияния его в процесс сборки. Это также обсуждает методы для изменения TMF и механизмов файла MATLAB, сопоставленных с TMF.

Прежде, чем создать пользовательский TMF, необходимо считать Соглашения о присвоении имен Папки и Файла изучить структуру папок и требования пути MATLAB для пользовательских целей.

Подготовка make-файла шаблона

Чтобы настроить или создать новый TMF, скопируйте существующий GRT или ERT TMF от matlabroot/toolbox/coder/compile/tmf.

Поместите копию в ту же папку как связанный системный конечный файл. Обычно, это - mytarget/mytarget папка в целевой структуре папок. Затем переименуйте свой TMF (например, mytarget.tmf) и измените его.

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

TMF: mytarget.tmf

Используя выражения макросов и сопоставления с образцом в make-файле шаблона

Этот раздел показывает через пример, как использовать макросы и выражения сопоставления с образцом файла в TMF, чтобы сгенерировать команды в model_or_sharedutils.mk.

Сделать служебные процессы model_or_sharedutils.mk и генерирует набор команд, основанных на правилах зависимости, заданных в model_or_sharedutils.mk. После make генерирует набор команд для создания или восстановления test, make выполняет их.

Например, чтобы создать программу под названием test, make должен соединить объектные файлы. Однако, если объектные файлы не существуют или устарели, make должен скомпилировать исходный код. Таким образом между исходными и объектными файлами существует зависимость.

Каждая версия make отличается немного по его функциям и как заданы правила. Например, рассмотрите программу под названием test это создается из двух источников, file1.c и file2.c. Используя большинство версий make, правила зависимости были бы

test: file1.o file2.o
        cc -o test file1.o file2.o

file1.o: file1.c
        cc -c file1.c

file2.o: file2.c
        cc -c file2.c

В этом примере, UNIX[2] среда принята. В среде PC расширения файла и компиляция и команды ссылки отличаются.

В обработке первого правила

test: file1.o file2.o

make видит это, чтобы создать test, это должно создать file1.o и file2.o. Создавать file1.o, make обрабатывает правило

file1.o: file1.c

Если file1.o не существует, или если file1.o является более старым, чем file1.c, make компиляции file1.c.

Формат TMFs следует вышеупомянутому примеру. Наши TMFs используют дополнительные функции make такой как макросы и выражения сопоставления с образцом файла. В большинстве версий make, макрос задан с

MACRO_NAME = value

Ссылки на макросы сделаны с $(MACRO_NAME). Когда make видит эту форму выражения, она заменяет value для $(MACRO_NAME).

Можно использовать выражения сопоставления с образцом, чтобы сделать правила зависимости более общими. Например, использование GNU[3] Сделайте, вы могли заменить два “file1.o: file1.c” и “file2.o: file2.c” правила с одним правилом

%.o : %.c
        cc -c $<

Обратите внимание на то, что $< в предыдущем примере специальный макрос, который приравнивается к файлу зависимости (то есть, file1.c или file2.c). Таким образом, с помощью макросов и "%"символ сопоставления с образцом, предыдущий пример может уменьшаться до

SRCS = file1.c file2.c
OBJS = $(SRCS:.c=.o)

test: $(OBJS)
        cc -o $@ $(OBJS)

%.o : %.c
        cc -c $<

Обратите внимание на то, что $@ макрос выше является другим специальным макросом, который приравнивается к имени текущей цели зависимости в этом случае test.

Этот пример генерирует список объектов (OBJS) из списка источников (SRCS) при помощи текста замена показывают для макрорасширения. Это заменяет расширение исходного файла (например, .c) с расширением объектного файла (.o). Этот пример также обобщил правило сборки для программы, test, использовать специальный "$@"макрос.

Настройка Сгенерированных Make-файлов с rtwmakecfg

TMFs обеспечивают лексемы, которые позволяют вам добавить следующие элементы в сгенерированные make-файлы:

  • Исходные папки

  • Включайте папки

  • Имена библиотеки времени выполнения

  • Объекты модуля этапа выполнения

S-функции могут добавить эту информацию в make-файл при помощи rtwmakecfg.m функция файла. Эта функция особенно полезна при создавании модели, которая содержит один или несколько Блоков s-function, такой как блоки драйвера устройства.

Добавить информацию, имеющую отношение к S-функции к make-файлу,

  1. Создайте функцию rtwmakecfg в файле rtwmakecfg.m. Генератор кода сопоставляет этот файл с вашей S-функцией на основе ее местоположения папки.

  2. Измените TMF своей цели, таким образом, что он поддерживает макрорасширение для получения информации, возвращенной rtwmakecfg функции.

После фазы TLC процесса сборки, при генерации make-файла от TMF, процесс сборки ищет rtwmakecfg.m файл в папке, которая содержит компонент S-функции. Если это находит файл, процесс сборки вызывает rtwmakecfg функция. Для получения дополнительной информации смотрите Использование rtwmakecfg.m API, чтобы Настроить Сгенерированные Make-файлы.

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

Если вы хотите, чтобы ваша пользовательская основанная на ERT цель поддержала непрерывное время, необходимо обновить make-файл шаблона (TMF) и статический основной программный модуль (например, mytarget_main.c) для вашей цели.

Обработайте модификации make-файла по шаблону.  Добавьте NCSTATES маркерное расширение после NUMST маркерное расширение, можно следующим образом:

NUMST = |>NUMST<|
NCSTATES = |>NCSTATES<|

Кроме того, добавьте NCSTATES к CPP_REQ_DEFINES макрос, как в следующем примере:

CPP_REQ_DEFINES = -DMODEL=$(MODEL) -DNUMST=$(NUMST) -DNCSTATES=$(NCSTATES) \
-DMAT_FILE=$(MAT_FILE)
-DINTEGER_CODE=$(INTEGER_CODE) \
-DONESTEPFCN=$(ONESTEPFCN) -DTERMFCN=$(TERMFCN) \
-DHAVESTDIO
-DMULTI_INSTANCE_CODE=$(MULTI_INSTANCE_CODE) \

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

Когда модель имеет непрерывное время и флаг TID01EQ истинное, и непрерывное время и самое быстрое дискретное время, обработаны как один уровень в сгенерированном коде. Код, сопоставленный с самым быстрым дискретным уровнем, охраняет основная проверка временного шага. Когда модель имеет только два уровня и TID01EQ верно, сгенерированный код имеет односкоростной интерфейс вызова.

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

  1. Перед NUMST ссылается в файле, добавьте следующий код:

    #if defined(TID01EQ) && TID01EQ == 1 && NCSTATES == 0
    #define DISC_NUMST (NUMST - 1)
    #else
    #define DISC_NUMST NUMST
    #endif
  2. Замените экземпляры NUMST в файле DISC_NUMST.

Факторы модели - ссылки

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

Примечание

Если вы используете TMF без переменной MODELREFS, файл может использоваться с предыдущим релизом программного обеспечения Simulink. Если вы хотите свой TMF к ссылке модели поддержки, добавьте MODELREFS к make-файлу.

Ошибка из-за тайм-аута, когда создание разделяемый служебный код с пользовательским make-файлом шаблона

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

  • Параметр конфигурации GenCodeOnly 'off'.

  • BUILD_SUCCESS сообщение выводится во время make вызовите к rtwshared.mk.

  • make вызовите к rtwshared.mk не обновляет конечный продукт (обычно rtwshared.lib).

Чтобы избежать ошибки, обновите пользовательский make-файл шаблона так, чтобы make вызов генерирует BUILD_SUCCESS обменивайтесь сообщениями только, когда конечный продукт будет сгенерирован (как идентифицировано make переменная PRODUCT). В качестве альтернативы, если процесс сборки не использует сгенерированный make-файл, отключите генерацию make-файла путем установки параметра конфигурации GenerateMakefile к 'off'.

Похожие темы


[1] UNIX является зарегистрированной торговой маркой Open Group в Соединенных Штатах и других странах.

[2] UNIX является зарегистрированной торговой маркой Open Group в Соединенных Штатах и других странах.

[3] GNU является зарегистрированной торговой маркой Фонда свободного программного обеспечения.

Для просмотра документации необходимо авторизоваться на сайте