При кодировании с API для написанных пользователем S-функций фиксированной точки важно иметь в виду различие между размером контейнера устройства хранения данных, размером слова контейнера устройства хранения данных, и сигнализировать о размере слова. Разделы, которые следуют, обсуждают контейнеры, используемые API, чтобы сохранить сигналы в симуляции и генерации кода.
В симуляции сигналы хранятся в одном из нескольких типов контейнеров определенного размера.
Во время симуляции сигналы фиксированной точки сохранены в одном из типов контейнеров устройства хранения данных, как показано в следующей таблице. Во многих случаях сигналы представлены в контейнерах с большим количеством битов, чем их заданный размер слова.
Контейнеры устройства хранения данных фиксированной точки
Контейнерная категория | Сигнал | Контейнерный размер слова | Контейнерный размер |
|---|---|---|---|
| 1 - 8 битов | 8 битов | 1 байт |
| 9 - 16 битов | 16 битов | 2 байта |
| 17 - 32 бита | 32 бита | 4 байта |
| 33 к размеру слова типа данных | Длина типа данных | Длина типа данных |
| Больше, чем размер слова типа данных | Множители длины типа данных | Множители длины типа данных |
Когда количество битов в размере слова сигнала является меньше, чем размер контейнера, биты размера слова всегда хранятся в наименее значимых битах контейнера. Остающиеся контейнерные биты должны быть расширенным знаком:
Если тип данных без знака, биты расширения знака должны быть очищены, чтобы обнулить.
Если тип данных подписывается, биты расширения знака должны быть установлены в один для строго отрицательных чисел и очищены, чтобы обнулить в противном случае.
Например, сигнал типа данных sfix6_En4 сохранен в контейнере FXP_STORAGE_INT8. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита обнуляются, когда сигнал положителен или нуль, и к тому, когда это отрицательно.
Сигнал типа данных ufix6_En4 сохранен в контейнере FXP_STORAGE_UINT8. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита всегда очищаются, чтобы обнулить.
Сигнал и размеры слова контейнера устройства хранения данных возвращены ssGetDataTypeFxpWordLength и функциями ssGetDataTypeFxpContainWordLen, соответственно. Размер контейнера устройства хранения данных возвращен функцией ssGetDataTypeStorageContainerSize. Контейнерная категория возвращена функцией ssGetDataTypeStorageContainCat, которая в дополнение к тем в приведенной выше таблице, может также возвратить следующие значения.
Другие контейнеры устройства хранения данных
Контейнерная категория | Описание |
|---|---|
| Возвращенный, если категория контейнера устройства хранения данных неизвестна |
| Контейнерный тип для Simulink® |
| Контейнерный тип для |
| Контейнерный тип для типа данных, который был заменен с |
Тип данных sfix24_En10 перебрасывается парой слов длина 24, но на самом деле хранится в 32 битах во время симуляции. Для этого сигнала,
ssGetDataTypeStorageContainCat возвращает FXP_STORAGE_INT32.
ssGetDataTypeStorageContainerSize или sizeof( ) возвращают 4, который является размером контейнера устройства хранения данных в байтах.
ssGetDataTypeFxpContainWordLen возвращает 32, который является размером слова контейнера устройства хранения данных в битах.
ssGetDataTypeFxpWordLength возвращает 24, который является размером слова типа данных в битах.
Контейнеры устройства хранения данных, используемые этим API для генерации кода, являются не всегда тем же самым как используемыми для симуляции. Во время генерации кода всегда используется нативный тип данных C. Типы данных с плавающей точкой сохранены в double C или float. Типы данных с фиксированной точкой считаются в C подписанным и char без знака, short, int или long.
Поскольку это ценно для быстрого прототипирования и HIL-тестирования, эмуляция меньших сигналов в больших контейнерах поддерживается в генерации кода. Например, 29-битный сигнал поддерживается в генерации кода, если существует тип данных C, доступный, который имеет по крайней мере 32 бита. Правила для размещения меньшего сигнала в больший контейнер, и для контакта с дополнительными контейнерными битами, являются тем же самым в генерации кода что касается симуляции.
Если меньший сигнал эмулирован в большем контейнере устройства хранения данных в симуляции, он не обязательно эмулирован в генерации кода. Например, 24-битный сигнал эмулирован в 32-битном контейнере устройства хранения данных в симуляции. Однако некоторые микросхемы DSP имеют нативную поддержку 24-битных количеств. На такой цели компилятор C может задать int или long, чтобы быть точно 24 бита. В этом случае 24-битный сигнал сохранен в 32-битном контейнере в симуляции, и в 24-битном контейнере в генерации кода.
С другой стороны сигнал, который не был эмулирован в симуляции, может должен быть быть эмулирован в генерации кода. Например, некоторые микросхемы DSP имеют минимальную поддержку целых чисел. На таких микросхемах char, short, int и long могут все быть заданы к 32 битам. В этом случае необходимо эмулировать 8-и 16-битные типы данных с фиксированной точкой в генерации кода.
Поскольку отображение контейнеров устройства хранения данных в симуляции к контейнерам устройства хранения данных в генерации кода не является непосредственным, функции Компилятора выходного языка (TLC) для контейнеров устройства хранения данных отличаются от тех в симуляции:
FixPt_DataTypeNativeType
FixPt_DataTypeStorageDouble
FixPt_DataTypeStorageSingle
FixPt_DataTypeStorageScaledDouble
FixPt_DataTypeStorageSInt
FixPt_DataTypeStorageUInt
FixPt_DataTypeStorageSLong
FixPt_DataTypeStorageULong
FixPt_DataTypeStorageSShort
FixPt_DataTypeStorageUShort
FixPt_DataTypeStorageMultiword
Первой из этих функций TLC, FixPt_DataTypeNativeType, является самый близкий аналог ssGetDataTypeStorageContainCat в симуляции. FixPt_DataTypeNativeType возвращает строку TLC, которая задает тип контейнера устройства хранения данных, и продукт Simulink Coder™ автоматически вставляет typedef, который сопоставляет строку с нативным типом данных C в сгенерированном коде.
Например, рассмотрите фиксированный тип данных, который сохранен в FXP_STORAGE_INT8 в симуляции. FixPt_DataTypeNativeType возвратит int8_T. int8_T будет typdef 'd к char, short, int или long в сгенерированном коде, в зависимости от того, что подходит для целевого компилятора.
Остающиеся упомянутые выше функции TLC возвращают TRUE или FALSE в зависимости от того, используется ли конкретный стандартный тип данных C, чтобы содержать данный указанный в API тип данных. Обратите внимание на то, что эти функции не обязательно дают взаимоисключающие ответы для данного указанного типа данных, вследствие того, что типы данных C могут потенциально наложиться в размере. В C,
sizeof (char) ≤ sizeof (короткий) ≤ sizeof (int) ≤ sizeof (долго).
Один или несколько из этих типов данных C может быть, и очень часто, тот же размер.
