Целевая механика разработки работает со многой папкой и типами файлов. Следующие темы предоставляют информацию, чтобы разработать пользовательские цели, сконфигурировать использование папки и использовать пользовательские цели в процессе сборки.
Можно использовать одну папку для пользовательских конечных файлов, или при желании можно использовать подпапки, например, содержащие файлы, сопоставленные с определенными средами разработки или инструментами.
Для пользовательской целевой реализации рекомендуемая папка и соглашения о присвоении имен файла
Используйте только нижний регистр на имена папок, имена файлов и расширения.
Не встраивайте пробелы в имена папок. Пробелы на имена папок вызывают ошибки со многими сторонними средами разработки.
Включайте желаемые папки в путь MATLAB®
Не помещайте свою пользовательскую целевую папку никуда в дерево папки MATLAB (то есть, в или под папкой
). Если вы помещаете свою папку под matlabroot
matlabroot
, вы рискуете терять свою работу, если вы устанавливаете новую версию MATLAB (или переустанавливаете текущую версию).
Следующие разделы объясняют, как организовать ваши целевые папки и файлы и добавить их в ваш путь MATLAB. Они также предоставляют высокоуровневые описания файлов.
В этом документе mytarget
является именем заполнителя, которое представляет папки и файлы, которые используют имя цели. Имена dev_tool1
, dev_tool2
, и так далее представляют подпапки, содержащие файлы, сопоставленные со средами разработки или инструментами. Этот документ описывает структуру в качестве примера, где папка mytarget
содержит подпапки для mytarget
, blocks
, dev_tool1
, dev_tool2
. Папка mytarget
верхнего уровня является целевой корневой папкой.
Компоненты пользовательской цели являются файлами, расположенными в иерархии папок. Папка верхнего уровня в этой структуре называется целевой корневой папкой. Целевую корневую папку и ее содержимое называют, организуют и располагают на пути MATLAB согласно соглашениям, описанным в Соглашениях о присвоении имен Папки и Файла.
Компоненты пользовательской цели включают
Компоненты кода: C исходный код, который контролирует и поддерживает выполнение сгенерированного типового кодекса.
Файлы управления:
Системный конечный файл (STF), чтобы управлять процессом генерации кода.
Файл (файлы), чтобы управлять созданием исполняемого файла от сгенерированного кода. В традиционном делают - базирующаяся среда, make-файл шаблона (TMF) генерирует make-файл с этой целью. Другой подход должен сгенерировать файлы проекта в поддержку современной интегрированной среды разработки (IDE), такие как Полупроводник Freescale™ CodeWarrior® IDE.
Рычаг регистрирует: Дополнительный TLC и файлы программы MATLAB, которые могут быть вызваны на четко определенных этапах процесса сборки. Сцепитесь файлы позволяют вам настроить процесс сборки и передать информацию между различными фазами процесса.
Другие конечные файлы: Файлы, которые позволяют вам интегрировать свою цель в среду MATLAB. Например, можно обеспечить файл info.xml
, чтобы сделать целевые библиотеки блоков и примеры доступными от сеанса работы с MATLAB.
Следующие разделы вводят ключевые концепции и терминологию, которую необходимо знать, чтобы разработать каждый компонент. Ссылки на источники более подробной информации обеспечиваются.
Исполняемая программа, содержащая код, сгенерированный из модели Simulink®, состоит из многих модулей кода и структур данных. Они попадают в две категории: компоненты приложения и файлы поддержки выполнения.
Компоненты приложения. Компоненты приложения - те, которые характерны для конкретной модели; они реализуют функции, представленные блоками в модели. Компоненты приложения не характерны для цели. Компоненты приложения включают
Модули сгенерированы из модели
Написанные пользователем блоки (S-функции)
Параметры модели, которые видимы, и могут быть соединены интерфейсом к, внешний код
Файлы поддержки выполнения. Много модулей кода и структур данных, упомянутых коллективно как файлы поддержки выполнения, ответственны за управление и поддержку осуществления сгенерированной программы. Модули файлов поддержки выполнения автоматически не сгенерированы. В зависимости от требований вашей цели необходимо реализовать определенные части файлов поддержки выполнения. Файлы поддержки выполнения обобщают файлы поддержки выполнения.
Файлы поддержки выполнения
Вы обеспечиваете... | Генератор кода обеспечивает... |
---|---|
Индивидуально настраиваемая основная программа | Типичная основная программа |
Обработчик прерывания по таймеру, чтобы запустить модель | Механизм выполнения и решатель интегрирования (вызванный обработчиком прерывания по таймеру) |
Другие обработчики прерываний | Обработчики прерываний в качестве примера (Асинхронные блоки Прерывания) |
Драйверы устройств | Драйверы устройств в качестве примера |
Регистрация данных, настройка параметра, контроль сигнала и поддержка режима external mode | Регистрация данных, настройка параметра, контроль сигнала и API режима external mode |
Написанные пользователем Файлы поддержки Выполнения. Генератор кода обеспечивает большинство файлов поддержки выполнения. В зависимости от требований вашей цели необходимо реализовать некоторых или все следующие элементы:
Служебная программа прерывания по таймеру (ISR). Таймер запускается на уровне основной частоты дискретизации программы. ISR таймера ответственен за операции, которые должны быть завершены в один период часов, такой как вычисление выборки текущей производительности. ISR таймера обычно вызывает функцию rt_OneStep
.
Если вы предназначаетесь для операционной системы реального времени (RTOS), ваш сгенерированный код обычно выполняется под управлением механизмов синхронизации и управления задачами, обеспеченных RTOS. В этом случае вам не, вероятно, придется реализовать ISR таймера.
Основная программа. Ваша основная программа инициализирует блоки в модели, устанавливает ISR таймера и выполняет фоновую задачу или цикл. Таймер периодически прерывает основной цикл. Если основная программа разработана, чтобы запуститься для конечного количества времени, это также ответственно за операции очистки — такие как освобождение памяти и маскирование прерывания по таймеру — прежде, чем отключить программу.
Если вы предназначаетесь для операционной системы реального времени (RTOS), ваша основная программа, скорее всего, порождает задачи (соответствующий частотам дискретизации, используемым в модели), чье выполнение синхронизирует и управляет RTOS.
Ваша основная программа обычно основана на сгенерированной или статической основной программе. Для получения дополнительной информации на структуре файлов поддержки выполнения, выполнение кода и инструкции для настройки основных программ, видят, Развертывают Сгенерированные Программы Независимого исполняемого файла На Целевом компьютере (Embedded Coder).
Драйверы устройств. Драйверы связываются с устройствами ввода-вывода на вашем целевом компьютере. В производственном коде драйверы устройств обычно реализуются как встроенные S-функции.
Другие обработчики прерываний. Если ваши модели должны поддержать асинхронные события, такие как оборудование сгенерировал прерывания и асинхронные операции чтения и операции записи, необходимо предоставить обработчиков прерываний. Библиотека Interrupt Templates обеспечивает примеры.
Регистрация данных, настройка параметра, контроль сигнала и поддержка режима external mode. Это нетипично, чтобы реализовать опции быстрого прототипирования, такие как поддержка режима external mode в целевом процессоре. Однако возможно поддерживать эти функции при помощи стандартных API генератора кода. Смотрите Интерфейсы Обмена данными для деталей.
Генерация кода и процесс сборки направлены многими TLC, и файлы MATLAB коллективно вызвали файлы управления. Этот раздел вводит и обобщает основные файлы управления.
Файл Управления верхнего уровня (make_rtw). Процесс сборки инициируется, когда вы нажимаете Ctrl+B. На данном этапе процесс сборки анализирует Сделать поле команды панели Code Generation диалогового окна Configuration Parameters, ожидая находить имя команды MATLAB, которая управляет процессом сборки (а также дополнительные аргументы к той команде). Командой по умолчанию является make_rtw
, и файлом управления верхнего уровня по умолчанию для процесса сборки является make_rtw.m
.
make_rtw
является внутренняя команда MATLAB, используемая процессом сборки. Обычно, целевым разработчикам не нужно детальное знание того, как make_rtw
работает. (Детали для целевых разработчиков описаны в Целевой Разработке и Процессе сборки.) Вы не должны вызывать make_rtw
непосредственно из кода MATLAB, и вы не должны настраивать make_rtw.m
.
Файл make_rtw.m
содержит логику, требуемую выполнить ваши целевые файлы управления, включая многие точки рычага для выполнения вашего пользовательского кода. make_rtw
делает следующее:
Дополнительные аргументы передач в к процессу сборки
Выполняет требуемую предварительную обработку перед генерацией кода
Выполняет STF, чтобы выполнить генерацию кода (и дополнительная генерация отчета HTML)
Обрабатывает TMF, чтобы сгенерировать make-файл
Вызывает сделать утилиту, чтобы выполнить make-файл и создать исполняемый файл
Выполняет требуемую последующую обработку (такую как генерация калибровочных файлов данных или загрузка сгенерированного исполняемого файла к цели)
Системный конечный файл (STF). Компилятор выходного языка (TLC) генерирует целевой C или Код С++ из частичного описания вашей Диаграммы Simulink (
). Компилятор Выходного языка читает model.rtw
и выполняет программу, состоящую из нескольких конечных файлов (файлы model.rtw
.tlc
.) STF, в верхнем уровне этой программы, управляет процессом генерации кода. Вывод этого процесса является многими исходными файлами, которые питаются вашу систему разработки, делают утилиту.
Необходимо создать индивидуально настраиваемый STF, чтобы установить параметры генерации кода для цели. Необходимо скопировать, переименовать и изменить стандартный системный конечный файл ERT (
).matlabroot/rtw/c/ert/ert.tlc
Подробная структура STF описана в, Настраивают Системные Конечные файлы.
STF выбирает, поддерживает ли цель подход набора инструментальных средств или подход make-файла шаблона для генерации кода. Смотрите Настраивают Системные Конечные файлы.
Обработайте Make-файл по шаблону (TMF). TMF предоставляет информацию о вашей модели и вашей системе разработки. Процесс сборки использует эту информацию, чтобы создать make-файл (файл .mk
), который создает исполняемую программу.
Некоторые цели реализуют больше чем один TMF, в порядке поддержать несколько сред разработки (например, два или больше кросс-компилятора) или несколько режимов генерации кода (например, генерируя бинарный исполняемый файл по сравнению с генерацией файла проекта для вашего компилятора).
Программное обеспечение Embedded Coder® предлагает большое количество TMFs, подходящего для различных типов систем компьютера разработчика. Эти TMFs расположены в (открытом)
. Стандартные TMFs описаны в Make-файлах Шаблона и Делают Опции.matlabroot/rtw/c/ert
Подробная структура TMF описана в, Настраивают Make-файлы Шаблона.
STF выбирает, поддерживает ли цель подход набора инструментальных средств или подход make-файла шаблона для генерации кода. Смотрите Настраивают Системные Конечные файлы.
Сцепите Файлы. Процесс сборки позволяет вам предоставлять дополнительные файлы рычага, которые выполняются в заданных точках в генерации кода и делают процесс. Можно использовать файлы рычага, чтобы добавить целевые действия в процесс сборки.
Файлы рычага должны следовать за четко определенным именованием и требованиями местоположения. Соглашения о присвоении имен папки и Файла описывают эти требования.
Эта папка содержит ключевые подпапки для цели (см. Соглашения о присвоении имен Папки и Файла). Можно также определить местоположение разных файлов (таких как файл readme
) в целевой корневой папке. Следующие разделы описывают требуемые и дополнительные подпапки и их содержимое.
Эта папка содержит файлы, которые являются центральными к цели, такими как системный конечный файл (STF) и обрабатывают make-файл по шаблону (TMF). Файлы ключей в Целевой Папке (mytarget/mytarget) обобщают файлы, которые должны храниться в mytarget/mytarget
и обеспечивают указатели на подробную информацию об этих файлах.
mytarget/mytarget
должен быть на пути MATLAB.
Если ваша цель включает драйверы устройств или другие блоки, найдите файлы реализации блока в этой папке. mytarget/blocks
содержит
Скомпилированные файлы MEX блока
Исходный код для блоков
TLC встраивание файлов для блоков
Модели библиотеки для блоков (если вы обеспечиваете свои блоки в одной или нескольких библиотеках),
mytarget/blocks
должен быть на пути MATLAB.
Можно также сохранить модели в качестве примера и вспомогательные файлы в mytarget/blocks
. Также можно создать папку mytarget/mytargetdemos
, которая должна также быть на пути MATLAB.
Чтобы отобразить ваши блоки в стандартном Браузере Библиотеки Simulink и/или интегрировать ваши модели в качестве примера в среду сеанса работы с MATLAB, можно создать файлы, описанные ниже, и сохранить их в mytarget/blocks
.
mytarget/blocks/slblocks.m. Этот файл позволяет группе блоков быть интегрированной в Браузер Библиотеки Simulink и Библиотеки Simulink.
function blkStruct = slblocks % Information for "Blocksets and Toolboxes" subsystem blkStruct.Name = sprintf('Embedded Target\n for MYTARGET'); blkStruct.OpenFcn = 'mytargetlib'; blkStruct.MaskDisplay = 'disp(''MYTARGET'')'; % Information for Simulink Library Browser Browser(1).Library = 'mytargetlib'; Browser(1).Name = 'Embedded Target for MYTARGET'; Browser(1).IsFlat = 1;% Is this library "flat" (i.e. no subsystems)? blkStruct.Browser = Browser;
mytarget/blocks/demos.xml. Этот файл предоставляет информацию о компонентах, организации и местоположении моделей в качестве примера. Программное обеспечение MATLAB использует эту информацию, чтобы поместить пример в среду сеанса работы с MATLAB.
<?xml version="1.0" encoding="utf-8"?> <demos> <name>Embedded Target for MYTARGET</name> <type>simulink</type> <icon>$toolbox/matlab/icons/boardicon.gif</icon> <description source = "file">mytarget_overview.html</description> <demosection> <label>Multirate model</label> <demoitem> <label>MYTARGET demo</label> <file>mytarget_overview.html</file> <callback>mytarget_model</callback> </demoitem> </demosection> </demos>
Эти папки содержат файлы, сопоставленные с определенными средами разработки или инструментами (dev_tool1
, dev_tool2
, и т.д.). Обычно, ваша цель поддерживает по крайней мере одну такую среду разработки и вызывает ее компилятор, компоновщика и другие утилиты во время процесса сборки. mytarget/dev_tool1
включает командные файлы компоновщика, код запуска, функции рычага и другие файлы, требуемые поддерживать этот процесс.
Для каждой среды разработки необходимо обеспечить отдельную папку.
Эта папка является дополнительной. Если сложность вашей цели требует его, можно использовать mytarget/src
, чтобы сохранить код общего источника и код настройки (такой как начальная загрузка и код запуска).
Целевая папка mytarget/mytarget
содержит файлы ключей в вашей целевой реализации. Они включают системный конечный файл, обрабатывают по шаблону make-файл, основной программный модуль, и дополнительный M и файлы рычага TLC, которые позволяют вам добавить целевые действия в процесс сборки. Следующие разделы описывают файлы папки главной цели.
mytarget.tlc
является системным конечным файлом (STF). Функции STF включают
Создание цели, видимой в Системном Браузере Конечного файла
Определение опций генерации кода для цели (наследованный и целевой)
Обеспечение точки входа для управления верхнего уровня процесса генерации кода TLC
Необходимо основывать STF на ert.tlc
, STF, обеспеченный программным обеспечением Embedded Coder.
Настройте Системные Конечные файлы, дает подробную информацию о структуре STF, и также дает инструкции относительно того, как настроить STF к
Отобразите свою цель в Системном Браузере Конечного файла
Добавьте свои собственные целевые опции в диалоговое окно Configuration Parameters
Адаптируйте генерацию кода и процесс сборки к требованиям вашей цели
mytarget.tmf
является make-файлом шаблона для создания исполняемого файла для вашей цели.
Для основной информации о структуре и операции make-файлов шаблона, смотрите, Настраивают Make-файлы Шаблона.
Если ваша целевая среда разработки требует, чтобы автоматизация современной интегрированной среды разработки (IDE), а не использование традиционного сделала утилиту, видела Интерфейс к Средствам разработки.
Этот файл является дополнительным. mytarget_genfiles.tlc
полезен как центральный файл, из которого можно вызвать целевые файлы TLC, которые генерируют дополнительные файлы как часть вашего целевого процесса сборки. Например, ваша цель может создать подmake-файлы или файлы проекта для среды разработки или командные сценарии для отладчика, чтобы сделать автоматические загрузки. Смотрите Используя mytarget_genfiles.tlc для деталей.
Основной программный модуль требуется для вашей цели. Чтобы обеспечить основной модуль, вы можете также
Измените rt_main.c
или модуль rt_cppclass_main.cpp
, обеспеченный программным обеспечением
Сгенерируйте mytarget_main.c
или .cpp
во время процесса сборки
Для описания операции основных программ смотрите, Развертывают Сгенерированные Программы Независимого исполняемого файла На Целевом компьютере (Embedded Coder). Раздел также содержит инструкции для генерации и изменения основного программного модуля.
является дополнительным файлом рычага, который можно использовать, чтобы вызвать целевые функции или исполняемые файлы в заданных точках в процессе сборки. STF_make_rtw_hook.m
реализует функцию, которая отправляет определенному действию в зависимости от аргумента STF_make_rtw_hook.m
method
, который передается в него.
Настройте Процесс сборки с Файлом STF_make_rtw_hook, описывает операцию файла рычага
подробно.STF_make_rtw_hook.m
До Релиза 14 пользовательские цели предоставили целевую информацию с файлом рычага (называемый
). STF_rtw_info_hook.m
задал свойства, такие как размеры слова для целочисленных типов данных (например, STF_rtw_info_hook
char
, short
, int
и long
), и специфичные для реализации свойства C пользовательской цели.
Механизм
был заменен панелью Аппаратной реализации диалогового окна Configuration Parameters. Используя это диалоговое окно, можно задать свойства, которые были раньше заданы в STF_rtw_info_hook
файле
.STF_rtw_info_hook
Для обратной совместимости существующие файлы
все еще доступны. Однако необходимо преобразовать цель и модели, чтобы использовать панель Аппаратной реализации. Смотрите Конфигурируют Опции Среды выполнения.STF_rtw_info_hook
Этот файл предоставляет информацию программному обеспечению MATLAB, которое задает, где отобразить целевой тулбокс в среде сеанса работы с MATLAB. Для получения дополнительной информации см. Отображение пользовательской документации (MATLAB).
Условно, этот файл служит домашней страницей для целевых примеров.
Поле <description>
в demos.xml
должно указать на mytarget_overview.html
(см. mytarget/blocks/demos.xml).
Пример файл mytarget_overview.html
<html> <head><title>Embedded Target for MYTARGET</title></head><body> <p style="color:#990000; font-weight:bold; font-size:x-large">Embedded Target for MYTARGET Example Model</p> <p>This example provides a simple model that allows you to generate an executable for a supported target board. You can then download and run the executable and set breakpoints to study and monitor the execution behavior.</p> </body> </html>
Если вы разрабатываете целевой процессор, который не установлен в дерево MATLAB, необходимо предоставить целевой скрипт настройки и целевую документацию в mytarget/mytarget
для удобства пользователей. Следующие разделы описывают необходимые материалы и куда разместить их.
Этот скрипт файла добавляет пути для вашей цели к пути MATLAB. Ваша документация должна дать пользователям команду запускать скрипт при установке цели.
Необходимо включать вызов функции MATLAB savepath
в скрипте mytarget_setup.m
. Эта функция сохраняет добавленные пути, таким образом, пользователи должны запустить mytarget_setup.m
только однажды.
Следующий код является примером файл mytarget_setup.m
.
function mytarget_setup() curpath = pwd; tgtpath = curpath(1:end-length('\mytarget')); addpath(fullfile(tgtpath, 'mytarget')); addpath(fullfile(tgtpath, 'dev_tool1')); addpath(fullfile(tgtpath, 'blocks')); addpath(fullfile(tgtpath, 'mytargetdemos')); savepath; disp('MYTARGET Target Path Setup Complete.');
Необходимо поместить документацию, связанную с целью в папке mytarget/mytarget/doc
.
Чтобы разработать целевой процессор, вам нужно полное понимание процесса сборки. Ваш целевой процессор использует процесс сборки и может потребовать, чтобы вы изменили или настроили процесс. Общий обзор генерации кода и процесса сборки дан в Генерации кода и Процессе сборки.
Этот раздел дополнения, что обзор с описанием процесса сборки, как настроено программным обеспечением Embedded Coder. Акцент находится на точках в процессе, где рычаги индивидуальной настройки доступны и на передающей информации между различными фазами процесса.
Этот раздел завершает Методами Передачи Дополнительной информации, описывая различные советы и приемы для передающей информации во время процесса сборки.
Важно понять, где (и когда) процесс сборки получает запрошенную информацию. Источники информации включают
Файл
, который предоставляет информацию о генерирующейся модели. Информация в model.rtw
доступна, чтобы предназначаться для файлов TLC.model.rtw
Панели генерации кода диалогового окна Configuration Parameters. Возможности (и общий и целевой) предоставляются через флажки, меню и поля редактирования. Можно сопоставить опции с переменными TLC в структуре данных rtwoptions
. Используйте поле Configuration Parameters> Code Generation> Custom Code> Additional build information> Defines, чтобы задать лексемы make-файла.
Выбранный набор инструментальных средств (для набора инструментальных средств приближаются к сборкам), или выбранный make-файл шаблона .tmf
(для сборок подхода make-файла шаблона); они генерируют образцово-специфичный make-файл.
Переменные окружения на хосте - компьютере. Переменные окружения предоставляют дополнительную информацию об установленных средствах разработки.
Другие целевые файлы, такие как связанные с целью файлы TLC, командные файлы компоновщика или файлы проекта.
Также важно понять несколько фаз процесса сборки и как передать информацию между фазами. Процесс сборки включает несколько высокоуровневых фаз:
Выполнение файла верхнего уровня (slbuild.m
или rtwbuild.m
) к последовательности посредством процесса сборки для цели
Преобразование модели в файл входа TLC (
)model.rtw
Генерация целевого кода компилятором TLC
Компиляция сгенерированного кода с make
или другими утилитами
Передача финала сгенерировала исполняемый файл к целевому компьютеру с утилитой загрузки или отладчиком
Полезно думать о каждой фазе о процессе как различная “среда”, которая поддерживает ее собственные данные. Эти среды включают
Среда выполнения кода MATLAB (MATLAB)
Simulink
Среда выполнения Компилятора Выходного языка
make-файл
Среды разработки такой как и IDE или отладчик
В каждой среде вы можете получить информацию из различных упомянутых выше источников. Например, во время фазы TLC, выполнитесь, файл MATLAB может выполниться, чтобы получить информацию из среды MATLAB. Кроме того, данная фаза может сгенерировать информацию для последующей фазы.
Смотрите Файлы ключей в Целевой Папке (mytarget/mytarget) для получения дополнительной информации о доступном файле MATLAB и рычагах TLC для информационной передачи с примерами кода.
В этом разделе описываются много полезных методов для передающей информации среди различных фаз процесса сборки.
tlcvariable Поле в rtwoptions Структуре. Параметры на панелях генерации кода диалогового окна Configuration Parameters могут быть сопоставлены с переменной TLC и заданы в поле tlcvariable
записи опции в структуре rtwoptions
. Значение переменных передается командной строке, когда TLC вызывается. Это обеспечивает способ сделать параметры генерации кода и их значения доступными в фазе TLC.
Смотрите Системную Структуру Конечного файла для получения дополнительной информации.
makevariable Поле в rtwoptions Структуре. Можно сопоставить параметры генерации кода с лексемой make-файла шаблона, которую вы задаете в поле makevariable
записи опции в структуре rtwoptions
. Если лексема того же имени как имя makevariable
существует в TMF, лексема обновляется со значением опции, когда итоговый make-файл создается. Если лексема не существует в TMF, makevariable
передается в на командной строке, когда делают, вызывается. Таким образом, в любом случае, makevariable
доступен make-файлу.
Смотрите Системную Структуру Конечного файла для получения дополнительной информации.
Доступ к Переменным Серверной среды. Можно получить доступ к переменным среды оболочки хоста в командной строке MATLAB путем ввода команды getenv
. Например:
getenv ('MSDEVDIR') ans = D:\Applications\Microsoft Visual Studio\Common\MSDev98
Чтобы получить доступ к той же информации от TLC, используйте директиву FEVAL
, чтобы вызвать getenv
.
%assign eVar = FEVAL("getenv","<varname>")
Предоставление информации Среды разработки к Make-файлу Шаблона. Целевой процессор должен связать процесс сборки с целевыми средствами разработки, установленными на хосте - компьютере. Для сделать процесса, чтобы запустить эти инструменты, TMF должен смочь определить имя инструментов, пути к компилятору, компоновщику, и другим утилитам, и возможно настройкам переменной окружения хостовой операционной системы.
Потребуйте, чтобы конечный пользователь изменил целевой TMF. Пользователь вводит информацию о пути (такую как местоположение исполняемого файла компилятора), и возможно переменные окружения хостовой операционной системы, как делают переменные. Это позволяет TMF быть адаптированным в соответствии с определенными потребностями.
Используя Данные о приложении MATLAB. Данные приложения обеспечивают путь к приложениям, чтобы сохранить и получить данные, хранимые с графический интерфейсом пользователя. Этот метод позволяет вам создать то, что является по существу пользовательским свойством для объекта, и используйте это свойство хранить данные для использования в процессе сборки. Если вы незнакомы с этим методом для создания графических интерфейсов пользователя, смотрите, Хранят Данные как Данные приложения (MATLAB).
Следующие примеры кода иллюстрируют использование данных приложения, чтобы передать информацию TLC.
Этот файл, tlc2appdata.m
, хранит data
, переданный в как данные приложения под именем переданный в (appDataName
).
function k = tlc2appdata(appDataName,data) disp([mfilename,': ',appDataName,' ', data]); setappdata(0,appDataName,data); k = 0; % TLC expects a return value for FEVAL.
Следующий демонстрационный файл TLC использует директиву FEVAL
, чтобы вызвать tlc2appdata.m
, чтобы сохранить произвольные данные приложения, под именем z80
.
%% test.tlc %% %assign myApp = "z80" %assign myData = "314159" %assign dummy = FEVAL("tlc2appdata",myApp,myData)
Протестировать этот метод:
Создайте файл tlc2appdata.m
как показано. Проверяйте, что tlc2appdata.m
хранится в папке на пути MATLAB.
Создайте файл TLC как показано. Сохраните его как test.tlc
.
Введите следующую команду в посдказке MATLAB, чтобы выполнить файл TLC:
tlc test.tlc
Получите данные приложения в посдказке MATLAB:
k = getappdata(0,'z80')
Функция возвращает значение 314159.
Введите следующую команду.
who
Обратите внимание на то, что данные приложения не хранятся в рабочем пространстве MATLAB. Также заметьте, что z80 данные не видимы. Используя данные приложения таким образом имеет преимущество, что это не создает помехи рабочему пространству MATLAB. Кроме того, это помогает предотвратить вас от случайного удаления ваших данных, поскольку это не хранится непосредственно в вашей рабочей области.
Реальное использование данных приложения может быть должно собрать информацию из файла
и сохранить его для использования позже в процессе сборки.model.rtw
Добавление Специфичной для блока информации к Make-файлу. Механизм rtwmakecfg
предоставляет метод для встроенных S-функций, таких как блоки драйверов, чтобы добавить информацию в make-файл. Этот механизм описан в Использовании rtwmakecfg.m API, чтобы Настроить Сгенерированные Make-файлы.