Контейнеры устройства хранения данных

Введение

При кодировании с API для написанных пользователем S-функций фиксированной точки важно иметь в виду различие между размером контейнера устройства хранения данных, размером слова контейнера устройства хранения данных, и сигнализировать о размере слова. Разделы, которые следуют, обсуждают контейнеры, используемые API, чтобы сохранить сигналы в симуляции и генерации кода.

Контейнеры устройства хранения данных в симуляции

В симуляции сигналы хранятся в одном из нескольких типов контейнеров определенного размера.

Категории контейнера устройства хранения данных

В процессе моделирования сигналы фиксированной точки сохранены в одном из типов контейнеров устройства хранения данных, как показано в следующей таблице. Во многих случаях сигналы представлены в контейнерах с большим количеством битов, чем их заданный размер слова.

Контейнеры устройства хранения данных фиксированной точки

Контейнерная категория	Сигнал Размер слова	Контейнерный размер слова	Контейнерный размер
`FXP_STORAGE_INT8` (со знаком) `FXP_STORAGE_UINT8` (без знака)	1 - 8 битов	8 битов	1 байт
`FXP_STORAGE_INT16` (со знаком) `FXP_STORAGE_UINT16` (без знака)	9 - 16 битов	16 битов	2 байта
`FXP_STORAGE_INT32` (со знаком) `FXP_STORAGE_UINT32` (без знака)	17 - 32 бита	32 бита	4 байта
`FXP_STORAGE_OTHER_SINGLE_WORD`	33 к размеру слова `long` тип данных	Длина `long` тип данных	Длина `long` тип данных
`FXP_STORAGE_MULTIWORD`	Больше, чем размер слова `long` тип данных к 128 битам	Множители длины `long` тип данных к 128 битам	Множители длины `long` тип данных к 128 битам

Когда количество битов в размере слова сигнала меньше размера контейнера, биты размера слова всегда хранятся в наименее значимых битах контейнера. Остающиеся контейнерные биты должны быть расширенным знаком:

Если тип данных без знака, биты расширения знака должны быть очищены, чтобы обнулить.
Если тип данных подписывается, биты расширения знака должны быть установлены в один для строго отрицательных чисел и очищены, чтобы обнулить в противном случае.

Например, сигнал типа данных sfix6_En4 сохранен в FXP_STORAGE_INT8 контейнер. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита обнуляются, когда сигнал положителен или нуль, и к тому, когда это отрицательно.

Сигнал типа данных ufix6_En4 сохранен в FXP_STORAGE_UINT8 контейнер. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита всегда очищаются, чтобы обнулить.

Сигнал и размеры слова контейнера устройства хранения данных возвращены ssGetDataTypeFxpWordLength и ssGetDataTypeFxpContainWordLen функции, соответственно. Размер контейнера устройства хранения данных возвращен ssGetDataTypeStorageContainerSize функция. Контейнерная категория возвращена ssGetDataTypeStorageContainCat функция, который в дополнение к тем в приведенной выше таблице, может также возвратить следующие значения.

Другие контейнеры устройства хранения данных

Контейнерная категория	Описание
`FXP_STORAGE_UNKNOWN`	Возвращенный, если категория контейнера устройства хранения данных неизвестна
`FXP_STORAGE_SINGLE`	Контейнерный тип для Simulink^® `single`
`FXP_STORAGE_DOUBLE`	Контейнерный тип для `double` Simulink
`FXP_STORAGE_SCALEDDOUBLE`	Контейнерный тип для типа данных, который был заменен с `Scaled double`

Контейнеры устройства хранения данных в примере симуляции

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

Поскольку отображение контейнеров устройства хранения данных в симуляции к контейнерам устройства хранения данных в генерации кода не является непосредственным, функции Компилятора выходного языка (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 может быть, и очень часто, тот же размер.

Документация