Цели сгенерированного кода обычно включают компактность и скорость. С другой стороны, S-функции являются загружаемыми временем выполнения дополнительными модулями для добавления функциональности блочного уровня к Simulink®. По сути, интерфейс S-функции оптимизирован для гибкости в конфигурировании и использовании блоков в среде симуляции с возможностью позволить изменения во время выполнения в операции блока через параметры. Эти изменения обычно принимают форму выбора алгоритма и числовых констант для алгоритмов блока.
В то время как переключение алгоритмов является желательной функцией в стадии проектирования системы, когда время настает, чтобы сгенерировать код, этот тип гибкости часто пропускается в пользу оптимальной скорости вычисления и размера кода. Компилятор Выходного языка спроектирован, чтобы позволить генерацию кода, который компактен и быстр путем выборочной генерации только кода, в котором вы нуждаетесь для одного экземпляра набора параметров блока.
Вы можете решить не встроить S-функции MEX C, которые имеют:
Немногие или никакие числовые параметры.
Один алгоритм, который уже фиксируется в возможности. Например, это не имеет никаких дополнительных режимов или альтернативных алгоритмов.
Поддержка только одного типа данных.
Значительный или большой размер кода в mdlOutputs() функция.
Несколько экземпляров Блока s-function в ваших моделях.
Каждый раз, когда вы сталкиваетесь с этой ситуацией, усилие по встраиванию блока не может улучшить скорость выполнения и могло на самом деле увеличить размер сгенерированного кода. Компромисс находится в размере кода тела блока, сгенерированного для каждого экземпляра по сравнению с размером дочернего SimStruct, созданного для каждого экземпляра невстроенной S-функции в сгенерированном коде.
В качестве альтернативы можно использовать гибридный метод встраивания, известный, когда MEX C перенес S-функцию, где конечный файл блока просто генерирует вызов функции пользовательского кода, которую также вызывает сама S-функция. Этот подход может быть оптимальным решением для генерации кода в случае большой части существующего кода. Смотрите S-функцию Обертки Записи и Файлы TLC для процедуры и примера перенесенной S-функции.
Стратегия улучшения кода от блоков сосредотачивает при определении, какая часть операций блока активны и используются в сгенерированном коде и какие части могут быть предопределены или не учтены.
На практике это означает, что код TLC в конечном файле блока выберет алгоритм, который является подмножеством алгоритмов, содержавшихся в самой S-функции и затем выборочно твердом коде числовые параметры, которые не должны быть изменены во время выполнения. Это уменьшает емкость памяти кода и приводит к коду, который часто намного быстрее, чем его дубликат S-функции, когда выбор режима является значительной частью обработки S-функции. Кроме того, вызов функции наверху устраняется для встроенных S-функций, когда код сгенерирован непосредственно в теле кода, если нет явный вызов библиотечной функции в сгенерированном коде.
Выборы алгоритма и параметры для каждого блока выводятся в начальной фазе процесса генерации кода от зарегистрированного набора S-параметра-функции или mdlRTW() функция (если есть), которая приводит к записям в .rtw модели файл для того блока во время генерации кода. Файл, записанный на выходном языке для блока, затем называется, чтобы считать записи в model.rtw
Один особый случай для встроенных S-функций для случая блоков ввода-вывода и драйверов, таких как конвертеры A/D или коммуникационные порты. Для симуляции драйвер ввода-вывода обычно кодируется в S-функции как чистый источник, передача или чистый приемник. В сгенерированном коде, однако, фактический интерфейс к устройству ввода-вывода должен быть сделан, обычно посредством прямого кодирования с общим _in(), _out() функции, встроенный ассемблерный код или определенный набор библиотеки I/O вызывают уникальный для устройства и целевого окружения.
Компилятор Выходного языка использует выполняющий поисковый приказ, чтобы определить местоположение файлов TLC:
Текущая папка.
Местоположения заданы %addincludepath директивы. Компилятор оценивает несколько %addincludepath директивы с самого начала.
Местоположения заданы -I опции. Компилятор оценивает несколько -I опции справа налево.
Для встроенных файлов S-function TLC процесс сборки поддерживает следующие местоположения:
Папка, где исполняемый файл S-функции (MEX или MATLAB®) файл расположен.
Подпапка ./tlc_c папки S-функции (для C или целей языка C++).
Текущая папка, когда процесс сборки инициируется.
Примечание
Примечание: Размещение встроенного файла S-function TLC в другом месте не поддерживается, даже если местоположение находится в TLC, включают путь.
Первый конечный файл, с которым сталкиваются с необходимым именем, которое реализует заданный язык, используется в обработке S-функции model.rtw
Примечание
Компилятор не ищет путь MATLAB и не найдет файл, который доступен только на том пути. Компилятор ищет только местоположения, описанные выше.
S-функции могут быть написаны в языке MATLAB, Фортране, C, и C++. Встраивание TLC S-функций доступно, как обозначено в этой таблице.
Встройте поддержку TLC типом S-функции
| Тип S-функции | Поддерживаемое невстраивание | Поддерживаемое встраивание |
|---|---|---|
Язык MATLAB | Нет | Да |
MEX Фортрана | Нет | Да |
C | Да | Да |
C++ | Да | Да |