При кодировании с 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 может быть, и очень часто, тот же размер.
