Embedded Coder Portable Word Sizes Issue (Code was generated for compiler with different sized X)

69 次查看（过去 30 天）
Dana Schwanke
Dana Schwanke 2024-3-4
评论： Dana Schwanke 2024-9-6
I am working on a Simulink Coder project where we have a number of export function model references being built by a single top-level export function model, porting the resulting code over to an external application we are developing. We are then running the full codebase through Polyspace Access to verify MISRA compliance. When we get to the compilation step in Polyspace Access, it is failing on a single file; one of the MODEL_private.h files among the dozens generated for the code has a block of precompiler checks, and ALL of the #errors are being flagged, despite all of the defined constants in our GNU version's limits.h file matching the checks below:
/*
* File: MODEL_private.h
*
* Code generated for Simulink model 'MODEL'.
*
* Model version : 3.307
* Simulink Coder version : 9.5 (R2021a) 14-Nov-2020
*
* Target selection: ert.tlc
* Embedded hardware selection: ARM Compatible->ARM Cortex
* Code generation objectives:
* 1. MISRA C:2012 guidelines
* 2. Execution efficiency
* 3. Debugging
* Validation result: Not run
*/
#ifndef RTW_HEADER_MODEL_private_h_
#define RTW_HEADER_MODEL_private_h_
#include "rtwtypes.h"
#ifndef PORTABLE_WORDSIZES
#ifndef UCHAR_MAX
#include <limits.h>
#endif
#if ( UCHAR_MAX != (0xFFU) ) || ( SCHAR_MAX != (0x7F) )
#error Code was generated for compiler with different sized uchar/char. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif
#if ( USHRT_MAX != (0xFFFFU) ) || ( SHRT_MAX != (0x7FFF) )
#error Code was generated for compiler with different sized ushort/short. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif
#if ( UINT_MAX != (0xFFFFFFFFU) ) || ( INT_MAX != (0x7FFFFFFF) )
#error Code was generated for compiler with different sized uint/int. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif
#if ( ULONG_MAX != (0xFFFFFFFFU) ) || ( LONG_MAX != (0x7FFFFFFF) )
#error Code was generated for compiler with different sized ulong/long. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif
#endif
We have the same configuration being used as a configuration reference for all of the models in our project, and the configuration has Portable Word Sizes enabled. Does anyone know why this block of checks is being generated for only a single file? Why would these checks fail if my limits.h file values match the 3defines in this block?

请先登录，再回答此问题。

回答（1 个）

samil
samil 2024-7-30
I had the same problem when I copied code generated on Windows 64 to Linux 64. On 64-bit Windows, the long type is typically 32 bits, which causes the LONG_MAX to be 0x7FFFFFFF. On 64-bit Linux systems, the long type is typically 64 bits, i.e. LONG_MAX is 0x7FFFFFFFFFFFFFFF. When you use code generated with the Windows 64 setting and use that on a Linux 64 OS, the check in <model name>_private.h will fail. The solution is to use the Linux 64 setting for Simulink Configuration Parameters - Hardware Implementation - Device type which removes the LONG_MAX check from header file.
  1 个评论
Dana Schwanke
Dana Schwanke 2024-9-6
Unfortunately, this is not the case for us. We are doing embedded code development and the code base is not being copied across platforms or projects. We are using a custom Device type based on the embedded chip the code is being designed for.

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Deployment, Integration, and Supported Hardware 的更多信息

标签

产品


版本

R2021a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by