При кодировании с помощью 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
® |
| Тип контейнера для Simulink |
| Тип контейнера для типа данных, который был переопределен |
Один sfix24_En10 тип данных имеет длину слова 24, но фактически хранится в 32 битах во время моделирования. Для этого сигнала,
ssGetDataTypeStorageContainCat прибыль FXP_STORAGE_INT32.
ssGetDataTypeStorageContainerSize или sizeof( ) прибыль 4, который является размером контейнера хранения в байтах.
ssGetDataTypeFxpContainWordLen прибыль 32, которая является длиной слова контейнера хранения в битах.
ssGetDataTypeFxpWordLength прибыль 24, которая представляет собой длину слова типа данных в битах.
Контейнеры хранения, используемые этим API для генерации кода, не всегда совпадают с контейнерами, используемыми для моделирования. Во время создания кода всегда используется собственный тип данных C. Типы данных с плавающей запятой хранятся в C double или float. Типы данных с фиксированной точкой хранятся в подписанных и неподписанных С char, short, int, или long.
Поскольку он полезен для быстрого прототипирования и тестирования аппаратных средств в петле, при формировании кода поддерживается эмуляция сигналов меньшего размера внутри больших контейнеров. Например, 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'к char, short, int, или long в сгенерированном коде, в зависимости от того, что подходит для целевого компилятора.
Остальные функции TLC, перечисленные выше, возвращаются TRUE или FALSE в зависимости от того, используется ли конкретный стандартный тип данных C для хранения данного зарегистрированного API типа данных. Следует отметить, что эти функции не обязательно дают взаимоисключающие ответы для данного зарегистрированного типа данных из-за того, что типы данных C могут потенциально перекрываться по размеру. В C,
sizeof (char ) ≤ sizeof ( короткий) ≤ sizeof ( int ) ≤ sizeof (длинный).
Один или несколько из этих типов данных C могут иметь одинаковый размер.