Целевая механика разработки работает с рядом типов папок и файлов. В следующих разделах приведены сведения для разработки пользовательских целевых объектов, настройки использования папок и использования пользовательских целевых объектов в процессе сборки.
Можно использовать одну папку для пользовательских целевых файлов, или, при желании, можно использовать подпапки, например, содержащие файлы, связанные с определенными средами разработки или инструментами.
Для пользовательской целевой реализации рекомендуемые соглашения об именовании папок и файлов:
Используйте только строчные имена папок, имена файлов и расширения.
Не встраивайте пространства в имена папок. Пространства в именах папок вызывают ошибки во многих сторонних средах разработки.
Включите требуемые папки в 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™ Semiconductor CodeWarrior® IDE.
Файлы Hook: Дополнительные программные файлы TLC и MATLAB, которые можно вызвать на четко определенных этапах процесса сборки. Файлы Hook позволяют вам настраивать процесс сборки и передавать информацию между различными фазами процесса.
Другие целевые файлы: Файлы, которые позволяют вам интегрировать вашу цель в окружение MATLAB. Для примера можно предоставить info.xml
файл, чтобы сделать целевые библиотеки блоков и примеры доступными из сеанса работы с MATLAB.
В следующих разделах представлены ключевые концепции и терминология, которые необходимо знать для разработки каждого компонента. Приводятся ссылки на более подробные источники информации.
Исполняемая программа, содержащая код, сгенерированный Simulink® модель состоит из ряда модулей кода и структур данных. Они делятся на две категории: компоненты приложения и файлы поддержки выполнения.
Компоненты приложения. Прикладными компонентами являются те, которые специфичны для конкретной модели; они реализуют функции, представленные блоками в модели. Компоненты приложения не относятся к целевому объекту. Компоненты приложения включают
Модули, сгенерированные из модели
Пользовательские блоки (S-функции)
Параметры модели, которые видны и могут быть сопряжены с внешним кодом
Файлы поддержки выполнения. За управление и поддержку выполнения сгенерированной программы отвечает ряд модулей кода и структур данных, именуемых совместно файлами поддержки выполнения. Модули файлов поддержки выполнения не генерируются автоматически. В зависимости от требований цели, необходимо реализовать определенные части файлов поддержки выполнения. Execution Support Files суммирует файлы поддержки выполнения.
Файлы поддержки выполнения
Вы обеспечиваете... | Генератор кода обеспечивает... |
---|---|
Настроенная основная программа | Типовая основная программа |
Обработчик прерывания таймера для запуска модели | Механизм выполнения и решатель интегрирования (вызывается обработчиком прерывания таймера) |
Другие обработчики прерывания | Пример обработчиков прерывания (блоки асинхронных прерываний) |
Драйверы устройств | Пример драйверов устройств |
Логгирование данных, настройка параметров, контроль сигналов и поддержка режима external mode | Логгирование данных, настройка параметров, контроль сигналов и API режима external mode |
Написанные пользователем файлы поддержки выполнения. Генератор кода обеспечивает большинство файлов поддержки выполнения. В зависимости от требований вашей цели, вы должны реализовать некоторые или все из следующих элементов:
Служебная стандартная программа прерывания таймера (ISR). Таймер запускается с базовой частотой дискретизации программы. ISR таймера отвечает за операции, которые должны быть завершены в течение одного такта, такие как вычисление текущей выходной выборки. ISR таймера обычно вызывает rt_OneStep
функция.
Если вы нацелены на операционную систему в реальном времени (RTOS), ваш сгенерированный код обычно выполняется под контролем механизмов управления временем и задачами, предоставляемых RTOS. В этом случае, возможно, вам не придется реализовывать ISR таймера.
Основная программа. Ваша основная программа инициализирует блоки в модели, устанавливает таймер ISR и выполняет фоновую задачу или цикл. Таймер периодически прерывает основной цикл. Если основная программа предназначена для выполнения в течение конечного количества времени, она также отвечает за операции очистки - такие как отмена выделения памяти и маскировка прерывания таймера - перед завершением программы.
Если вы нацелены на операционную систему в реальном времени (RTOS), ваша основная программа, скорее всего, порождает задачи (соответствующие частотам дискретизации, используемым в модели), выполнение которых определяется временем и управляется RTOS.
Ваша основная программа обычно основана на сгенерированной или статической основной программе. Для получения дополнительной информации о структуре файлов поддержки выполнения, выполнении кода и руководствах по настройке основных программ, смотрите Развертывание сгенерированных автономных исполняемых программ на целевом компьютере.
Драйверы устройств. Драйверы взаимодействуют с устройствами ввода-вывода на вашем целевом компьютере. В производственном коде драйверы устройств обычно реализуются как встроенные S-функции.
Другие обработчики прерывания. Если ваши модели должны поддерживать асинхронные события, такие как аппаратные прерывания и асинхронные операции чтения и записи, необходимо поставить обработчики прерываний. В библиотеке «Шаблоны прерывания» приведены примеры.
Логгирование данных, настройка параметров, контроль сигналов и поддержка режима external mode. Нетипично реализовать такие функции быстрого прототипирования, как поддержка режима external mode в целевом процессоре. Однако можно поддержать эти функции с помощью стандартных API генератора кода. Для получения дополнительной информации см. раздел Калибровка и измерение.
Процесс генерации и сборки кода направляется рядом файлов TLC и MATLAB, совместно называемых файлами управления. В этом разделе представлены и обобщены основные файлы управления.
Файл управления верхнего уровня (make_rtw). Процесс сборки инициируется при нажатии клавиши Ctrl+B. На данной точке процесс сборки анализирует поле Make command панели Code Generation диалогового окна Параметры Конфигурации, ожидая найти имя команды MATLAB, которая управляет процессом сборки (а также необязательные аргументы к этой команде). Команда по умолчанию make_rtw
, и файл управления верхнего уровня по умолчанию для процесса сборки make_rtw.m
.
Примечание
make_rtw
является внутренней командой MATLAB, используемой процессом сборки. Обычно целевым разработчикам не нужно детально знать, как make_rtw
работает. (Детали для целевых разработчиков описаны в Target Development и Build Process.) Вы не должны вызывать make_rtw
непосредственно из кода MATLAB, и вы не должны настраивать make_rtw.m
.
The make_rtw.m
файл содержит логику, необходимую для выполнения пользовательских файлов управления, в том числе ряд точек хук для выполнения пользовательского кода. make_rtw
делает следующее:
Передает необязательные аргументы в процесс сборки
Выполняет необходимую предварительную обработку перед генерацией кода
Выполняет системный целевой файл для генерации кода (и необязательная генерация HTML)
Обрабатывает TMF, чтобы сгенерировать make-файл
Вызывает утилиту make, чтобы выполнить make-файл и создать исполняемый файл
Выполняет необходимую постобработку (например, создание файлов калибровочных данных или загрузка сгенерированного исполняемого файла в целевой файл)
Системный целевой файл. Target Language Компилятора (TLC) генерирует специфичные для целевого объекта коды C or C++ из частичного описания вашей Диаграммы Simulink (
). Компилятор целевого языка читает model
.rtw
и выполняет программу, состоящую из нескольких целевых файлов (model
.rtw.tlc
файлы.) Системный целевой файл на верхнем уровне этой программы управляет процессом генерации кода. Выходом этого процесса является ряд исходных файлов, которые подаются в утилиту make вашей системы разработки.
Вам нужно создать настроенный системный целевой файл, чтобы задать параметры генерации кода для вашего целевого файла. Необходимо скопировать, переименовать и изменить стандартный системный целевой файл ERT (
).matlabroot
/ rtw/c/ert/ert.tlc
Подробная структура системного целевого файла описана в разделе Настройка системных целевых файлов.
Примечание
Системный целевой файл выбирает, поддерживает ли целевой объект подход набора инструментальных средств или подход с шаблоном make-файла для генерации кода. См. Раздел «Настройка системных целевых файлов»
Шаблон make-файла (TMF). TMF предоставляет информацию о вашей модели и вашей системе разработки. Процесс сборки использует эту информацию для создания make-файла (.mk
файл), который создает исполняемую программу.
Некоторые цели реализуют более одного TMF, в порядок для поддержки нескольких сред разработки (для примера, двух или более кросс-компиляторов) или нескольких режимов генерации кода (для примера, генерации бинарного исполняемого файла от генерации файла проекта для вашего компилятора).
Embedded Coder® программное обеспечение предоставляет большое количество TMF, подходящих для различных типов компьютера разработчика систем. Эти TMF расположены в
. Стандартные файлы TMF описаны в шаблонах make-файлов» и «Опции создания».matlabroot
/ toolbox/coder/compile/tmf
Подробная структура TMF описывается в разделе Настройка шаблонов make-файлов.
Примечание
Системный целевой файл выбирает, поддерживает ли целевой объект подход набора инструментальных средств или подход с шаблоном make-файла для генерации кода. См. Раздел «Настройка системных целевых файлов»
Файлы крючков. Процесс сборки позволяет вам поставить дополнительные файлы hook, которые выполняются в заданных точках генерации кода, и выполнить процесс. Можно использовать файлы hook для добавления специфичных для целевого объекта действий к процессу сборки.
Файлы крючков должны соответствовать четко определенным требованиям к наименованию и местоположению. Соглашения об именовании папок и файлов описывают эти требования.
Эта папка содержит ключевые подпапки для целевого объекта (см. Соглашения о именовании папок и файлов). Можно также найти различные файлы (такие как readme
файл) в целевой корневой папке. В следующих разделах описываются требуемые и необязательные подпапки и их содержимое.
Эта папка содержит файлы, которые являются центральными для целевого устройства, такие как системный целевой файл (STF) и файл make-файла шаблона (TMF). Ключевые файлы в целевой папке (mytarget/mytarget) результируют файлы, которые должны храниться в mytarget/mytarget
, и предоставляет указатели на подробную информацию об этих файлах.
Примечание
mytarget/mytarget
должен находиться в пути MATLAB.
Если ваш целевой объект включает драйверы устройств или другие блоки, найдите файлы реализации блоков в этой папке. mytarget/blocks
содержит
Скомпилированный блок файлов MEX
Исходный код для блоков
TLC-inlining файлов для блоков
Библиотечные модели для блоков (если вы предоставляете свои блоки в одной или нескольких библиотеках)
Примечание
mytarget/blocks
должен находиться в пути MATLAB.
Можно также хранить примеры моделей и вспомогательные файлы в mytarget/blocks
. Также можно создать mytarget/mytargetdemos
папка, которая также должна находиться в пути MATLAB.
Чтобы отобразить блоки в стандартном браузере Simulink Library Browser и/или интегрировать ваши примеры в сеанс работы с 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
, и т.д.). Обычно ваша цель поддерживает хотя бы одну такую среду разработки и вызывает ее компилятор, linker и другие утилиты в процессе сборки. mytarget/dev_tool1
включает файлы команды linker, код запуска, функции hook и другие файлы, необходимые для поддержки этого процесса.
Для каждой среды разработки необходимо предусмотреть отдельную папку.
Эта папка является необязательной. Если этого требует сложность вашей цели, можно использовать mytarget/src
для хранения общего исходного кода и строения (например, кода загрузки и кода запуска).
Целевая папка mytarget/mytarget
содержит ключевые файлы в целевой реализации. К ним относятся системный целевой файл, файл make-файла шаблона, основной программный модуль и необязательные файлы hook M и TLC, которые позволяют добавлять специфичные для целевого объекта действия к процессу сборки. В следующих разделах описываются ключевые файлы целевой папки.
mytarget.tlc
- системный целевой файл. Функции системного целевого файла включают
Обеспечение видимости цели в браузере системных целевых файлов
Определение опций генерации кода для цели (унаследованная и специфичная для цели)
Предоставление точки входа для управления верхнего уровня процесса генерации кода TLC
Вы должны основать свой системный целевой файл на ert.tlc
, системный целевой файл, предоставляемый программным обеспечением Embedded Coder.
Customize System Target Files дает подробную информацию о структуре системного целевого файла, а также дает инструкции о том, как настроить системный целевой файл
Отобразите свою цель в Системном браузере целевых файлов
Добавьте свои собственные целевые опции в диалоговое окно Параметров конфигурации
Адаптируйте генерацию кода и процесс сборки к требованиям вашей цели
mytarget.tmf
является шаблоном make-файла для создания исполняемого файла для вашего целевого компьютера.
Основные сведения о структуре и операции файлов make-файлов шаблонов см. в разделе Настройка файлов make-файлов шаблонов.
Этот файл является необязательным. mytarget_genfiles.tlc
используется как файл хранилища, из которого можно вызвать специфичные для целевого объекта файлы TLC, которые генерируют дополнительные файлы в рамках целевого процесса сборки. Например, ваш целевой объект может создать вспомогательные файлы make или файлы проекта для среды разработки или командные скрипты для отладчика, чтобы выполнить автоматическую загрузку. Для получения дополнительной информации см. раздел Использование mytarget_genfiles.tlc.
Основной программный модуль необходим для вашего целевого устройства. Чтобы предоставить основной модуль, вы можете либо
Измените rt_main.c
или rt_cppclass_main.cpp
модуль, предоставляемый программным обеспечением
Сгенерируйте mytarget_main.c
или .cpp
в процессе сборки
Описание операции основных программ см. в разделе Развертывание сгенерированных Независимый исполняемый файл программ на целевом компьютере. Раздел также содержит инструкции по генерации и изменению основного программного модуля.
является необязательным файлом hook, который можно использовать для вызова функций или исполняемых файлов конкретного целевого устройства в заданных точках процесса сборки. STF
_make_rtw_hook.m
реализует функцию, которая отправляет конкретное действие в зависимости от STF
_make_rtw_hook.mmethod
переданный в него аргумент.
Настройка процесса сборки с помощью STF_make_rtw_hook File описывает операцию
подробное описание файла крюка.STF
_make_rtw_hook.m
До выпуска 14 пользовательские целевые системы предоставляли специфическую для цели информацию с помощью файла hook (называемого
). The STF
_rtw_info_hook.m
заданные свойства, такие как размеры слов для целочисленных типов данных (для примера, STF
_rtw_info_hookchar
, short
, int
, и long
) и специфичные для реализации C свойства пользовательского целевого объекта.
The
механизм был заменен панелью Аппаратная реализация (Hardware Implementation) диалогового окна Параметры конфигурации (Configuration Parameters). Используя это диалоговое окно, можно задать свойства, которые ранее были заданы в вашем STF
_rtw_info_hook
файл.STF
_rtw_info_hook
Для обратной совместимости существующие
файлы все еще доступны. Однако необходимо преобразовать цель и модели в область Аппаратная реализация (Hardware Implementation). См. «Настройка опций окружения во время выполнения».STF
_rtw_info_hook
Этот файл предоставляет информацию программному обеспечению MATLAB, которая определяет, где отображать целевой тулбокс в среде сеанса работы с MATLAB. Для получения дополнительной информации см. раздел «Отображение пользовательской документации».
По соглашению, этот файл служит домашней страницей для целевых примеров.
The <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
.
Чтобы разработать целевой процессор, вам нужно глубокое понимание процесса сборки. Ваш целевой процессор использует процесс сборки и может потребовать изменения или настройки процесса. Общий обзор генерации кода и процесса сборки представлен в Code Generation and Build Process.
Этот раздел дополняет обзор описанием процесса сборки, настроенным программным обеспечением Embedded Coder. Основное внимание уделяется точкам в процессе, когда доступны крюки индивидуальной настройки, и передаче информации между различными фазами процесса.
В конце этого раздела описываются дополнительные методы передачи информации, описывающие различные советы и рекомендации для передачи информации в процессе сборки.
Важно понять, где (и когда) процесс сборки получает необходимую информацию. Источники информации включают
The
файл, который предоставляет информацию о генерирующей модели. Информация в model
.rtw
доступен для целевых файлов TLC.model
.rtw
Панели генерации кода диалогового окна Параметров конфигурации. Опции (как общие, так и специфичные для целевого объекта) предоставляются через флажки, меню и поля редактирования. Вы можете связать опции с переменными TLC в rtwoptions
структура данных. Используйте поле Configuration Parameters Code Generation > Custom Code > Additional build information > Defines для определения лексем make-файла.
Выбранный набор инструментальных средств (для подхода набора инструментальных средств) или выбранный шаблон make-файла .tmf
(для шаблонных сборок подхода make-файла); они генерируют make-файл конкретной модели.
Окружение переменные на хост-компьютер. Переменные окружения предоставляют дополнительную информацию об установленных инструментах разработки.
Другие файлы, относящиеся к целевому объекту, такие как файлы TLC, файлы команд linker или файлы проекта.
Также важно понять несколько фаз процесса сборки и способы передачи информации между фазами. Процесс сборки включает несколько высокоуровневых фаз:
Выполнение файла верхнего уровня (slbuild.m
) для последовательности через процесс сборки для целевого объекта
Преобразование модели в входной файл TLC (
)model
.rtw
Генерация целевого кода компилятором
Компиляция сгенерированного кода с make
или другие утилиты
Передача окончательного сгенерированного исполняемого файла на целевой компьютер с помощью утилиты отладчика или загрузки
Полезно рассматривать каждую фазу процесса как разное « окружение», которая поддерживает свои собственные данные. Эти окружения включают
Окружение выполнения кода MATLAB (MATLAB)
Simulink
Окружение выполнения компилятора целевого языка
makefile
Среды разработки, такие как и IDE или отладчик
В каждом окружении можно получить информацию из различных источников, упомянутых выше. Для примера во время фазы TLC может выполняться выполнение файла MATLAB, чтобы получить информацию от окружения MATLAB. Кроме того, данная фаза может генерировать информацию для последующей фазы.
Смотрите Ключевые файлы в целевой папке (mytarget/mytarget) для получения дополнительной информации о доступном файле MATLAB и крюках TLC для передачи информации с примерами кода.
В этом разделе описывается ряд полезных методов для передачи информации между различными фазами процесса сборки.
tlcvariable Field in rtwoptions Структура. Параметры на панелях генерации кода диалогового окна Параметров конфигурации могут быть связаны с переменной TLC и заданы в tlcvariable
поле значения опции в rtwoptions
структура. Это значение переменных передаётся в командной строке при вызове TLC. Это предоставляет способ сделать параметры генерации кода и их значения доступными в фазе TLC.
Для получения дополнительной информации смотрите System Target File Structure.
makevariable Field in rtwoptions Structure. Можно связать параметры генерации кода с шаблоном лексемы, который вы задаете в makevariable
поле значения опции в rtwoptions
структура. Если лексема с тем же именем, что и makevariable
имя существует в TMF, лексема обновляется значением опции при создании окончательного файла make. Если лексема не существует в TMF, makevariable
передается в командной строке при вызове make. Таким образом, в любом случае, makevariable
доступен для make-файла.
Для получения дополнительной информации смотрите System Target File Structure.
Доступ к переменным окружения хоста. Вы можете получить доступ к переменным окружения интерпретатора хоста в командной строке MATLAB, введя getenv
команда. Для примера:
getenv ('MSDEVDIR') ans = D:\Applications\Microsoft Visual Studio\Common\MSDev98
Для доступа к той же информации из TLC используйте FEVAL
директива для вызова getenv
.
%assign eVar = FEVAL("getenv","<varname>")
Предоставление информации о среде разработки в make-файл шаблона. Целевой процессор должен связать процесс сборки с целевыми инструментами разработки, установленными на хост-компьютер. Чтобы процесс make запустил эти инструменты, TMF должен иметь возможность определять имя инструментов, путь к компилятору, linker и другим утилитам, а также, возможно, параметры переменного окружения операционной системы хоста.
Потребовать от конечного пользователя изменения целевого TMF. Пользователь вводит информацию о пути (например, местоположение исполняемого файла компилятора), и, возможно, переменные окружения операционной системы хоста, как переменные make. Это позволяет адаптировать 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-файлу. The rtwmakecfg
механизм предоставляет метод для встроенных S-функций, таких как блоки драйверов, чтобы добавить информацию к make-файлу. Этот механизм описан в разделе Использование rtwmakecfg.m API для настройки сгенерированных make-файлов.