Целевая механика разработки работает со многой папкой и типами файлов. Следующие темы предоставляют информацию, чтобы разработать пользовательские цели, сконфигурировать использование папки и использовать пользовательские цели в процессе сборки.
Можно использовать одну папку для пользовательских конечных файлов, или при желании можно использовать подпапки, например, содержащие файлы, сопоставленные с определенными средами разработки или инструментами.
Для пользовательской целевой реализации рекомендуемая папка и соглашения о присвоении имен файла
Используйте только нижний регистр на имена папок, имена файлов и расширения.
Не встраивайте пробелы в имена папок. Пробелы на имена папок вызывают ошибки со многими сторонними средами разработки.
Включайте желаемые папки в путь MATLAB®
Не помещайте свою пользовательскую целевую папку никуда в дерево папки MATLAB (то есть, в или под
папка). Если вы помещаете свою папку под matlabroot
matlabroot
вы рискуете терять свою работу, если вы устанавливаете новую версию MATLAB (или переустанавливаете текущую версию).
Следующие разделы объясняют, как организовать ваши целевые папки и файлы и добавить их в ваш путь MATLAB. Они также предоставляют высокоуровневые описания файлов.
В этом документе, mytarget
имя заполнителя, которое представляет папки и файлы, которые используют имя цели. Имена dev_tool1
, dev_tool2
, и так далее представляйте подпапки, содержащие файлы, сопоставленные со средами разработки или инструментами. Этот документ описывает структуру в качестве примера где папка mytarget
содержит подпапки для mytarget
, blocks
, dev_tool1
, dev_tool2
. Папка mytarget
верхнего уровня целевая корневая папка.
Компоненты пользовательской цели являются файлами, расположенными в иерархии папок. Папка верхнего уровня в этой структуре называется целевой корневой папкой. Целевую корневую папку и ее содержимое называют, организуют и располагают на пути MATLAB согласно соглашениям, описанным в Соглашениях о присвоении имен Папки и Файла.
Компоненты пользовательской цели включают
Компоненты кода: C исходный код, который контролирует и поддерживает выполнение сгенерированного типового кодекса.
Файлы управления:
Системный конечный файл, чтобы управлять процессом генерации кода.
Файл (файлы), чтобы управлять созданием исполняемого файла от сгенерированного кода. В традиционном делают - базирующаяся среда, 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
делает следующее:
Дополнительные аргументы передач в к процессу сборки
Выполняет требуемую предварительную обработку перед генерацией кода
Выполняет системный конечный файл, чтобы выполнить генерацию кода (и дополнительная генерация отчета HTML)
Обрабатывает TMF, чтобы сгенерировать make-файл
Вызывает сделать утилиту, чтобы выполнить make-файл и создать исполняемый файл
Выполняет требуемую последующую обработку (такую как генерация калибровочных файлов данных или загрузка сгенерированного исполняемого файла к цели)
Системный Конечный файл. Компилятор выходного языка (TLC) генерирует целевой код C or C++ из частичного описания вашей Диаграммы Simulink (
). Компилятор Выходного языка читает model
.rtw
и выполняет программу, состоящую из нескольких конечных файлов (model
.rtw.tlc
файлы.) Системный конечный файл, в верхнем уровне этой программы, управляет процессом генерации кода. Выход этого процесса является многими исходными файлами, которые питаются вашу систему разработки, делают утилиту.
Необходимо создать индивидуально настраиваемый системный конечный файл, чтобы установить параметры генерации кода для цели. Необходимо скопировать, переименовать и изменить стандартный системный конечный файл ERT (
).matlabroot
/rtw/c/ert/ert.tlc
Подробная структура системного конечного файла описана в, Настраивают Системные Конечные файлы.
Примечание
Системный конечный файл выбирает, поддерживает ли цель подход набора инструментальных средств или подход make-файла шаблона для генерации кода. Смотрите Настраивают Системные Конечные файлы.
Обработайте Make-файл по шаблону (TMF). TMF предоставляет информацию о вашей модели и вашей системе разработки. Процесс сборки использует эту информацию, чтобы создать make-файл (.mk
файл), который создает исполняемую программу.
Некоторые цели реализуют больше чем один TMF, для того, чтобы поддержать несколько сред разработки (например, два или больше кросс-компилятора) или несколько режимов генерации кода (например, генерируя бинарный исполняемый файл по сравнению с генерацией файла проекта для вашего компилятора).
Программное обеспечение Embedded Coder® предлагает большое количество TMFs, подходящего для различных типов систем компьютера разработчика. Эти TMFs расположены в
. Стандартные TMFs описаны в Make-файлах Шаблона и Делают Опции.matlabroot
/toolbox/coder/compile/tmf
Подробная структура TMF описана в, Настраивают Make-файлы Шаблона.
Примечание
Системный конечный файл выбирает, поддерживает ли цель подход набора инструментальных средств или подход 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
системный конечный файл. Функции системного конечного файла включают
Создание цели, видимой в Системном Браузере Конечного файла
Определение опций генерации кода для цели (наследованный и целевой)
Обеспечение точки входа для управления верхнего уровня процесса генерации кода TLC
Необходимо основывать системный конечный файл на ert.tlc
, системный конечный файл обеспечивается программным обеспечением Embedded Coder.
Настройте Системные Конечные файлы, дает подробную информацию о структуре системного конечного файла, и также дает инструкции относительно того, как настроить системный конечный файл к
Отобразите свою цель в Системном Браузере Конечного файла
Добавьте свои собственные целевые опции в диалоговое окно Configuration Parameters
Адаптируйте генерацию кода и процесс сборки к требованиям вашей цели
mytarget.tmf
make-файл шаблона для создания исполняемого файла для вашей цели.
Для основной информации о структуре и операции make-файлов шаблона, смотрите, Настраивают Make-файлы Шаблона.
Этот файл является дополнительным. 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.mmethod
аргумент, который передается в него.
Настройте Процесс сборки с Файлом STF_make_rtw_hook, описывает операцию
сцепите файл подробно.STF
_make_rtw_hook.m
До Релиза 14 пользовательские цели предоставили целевую информацию с файлом рычага (называемый
). STF
_rtw_info_hook.m
заданные свойства, такие как размеры слова для целочисленных типов данных (например, STF
_rtw_info_hookchar
, short
, int
, и long
), и специфичные для реализации свойства C пользовательской цели.
механизм был заменен панелью Аппаратной реализации диалогового окна Configuration Parameters. Используя это диалоговое окно, можно задать свойства, которые были раньше заданы в STF
_rtw_info_hook
файл.STF
_rtw_info_hook
Для обратной совместимости, существующего
файлы все еще доступны. Однако необходимо преобразовать цель и модели, чтобы использовать панель Аппаратной реализации. Смотрите Конфигурируют Опции Среды выполнения.STF
_rtw_info_hook
Этот файл предоставляет информацию программному обеспечению 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
) к последовательности посредством процесса сборки для цели
Преобразование модели в файл входа 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. Данные приложения обеспечивают путь к приложениям, чтобы сохранить и получить данные, хранимые с графический интерфейсом пользователя. Этот метод позволяет вам создать то, что является по существу пользовательским свойством для объекта, и используйте это свойство хранить данные для использования в процессе сборки. Если вы незнакомы с этим методом для создания графических интерфейсов пользователя, смотрите, Хранят Данные как Данные приложения.
Следующие примеры кода иллюстрируют использование данных приложения, чтобы передать информацию 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-файлы.