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