Why is the preprocessor check #if ( UCHAR_MAX != (0xFFU) ) || ( SCHAR_MAX != (0x7F) ) being generated in private.h?

In the generated code for my model, I have noticed that the following code is generated in the "model_private.h" file:

#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

Why is this code being generated?

Answer 1

[MathWorks Support Team]

The above code is being generated because a signal or block with a fixed point data type is being used in your model. Please refer to the link for more details.

https://www.mathworks.com/help/releases/R2018a/dsp/fixed-point-data-types.html

[John]

This code construct is in error for 2 reasons and should be removed/updated from the templates.

1) The LONG and ULONG types are not used in the portable datatypes that the generator creates under the ERT. Where a long type is used, it is not considered to be a specific size.

/*=======================================================================*
 * Fixed width word size data types:                                     *
 *   int8_T, int16_T, int32_T     - signed 8, 16, or 32 bit integers     *
 *   uint8_T, uint16_T, uint32_T  - unsigned 8, 16, or 32 bit integers   *
 *   real32_T, real64_T           - 32 and 64 bit floating point numbers *
 *=======================================================================*/
typedef signed char int8_T;
typedef unsigned char uint8_T;
typedef short int16_T;
typedef unsigned short uint16_T;
typedef int int32_T;
typedef unsigned int uint32_T;
typedef float real32_T;
typedef double real64_T;

2) Why isn't the fixed size type variables used from <stdint.h> instead of Matlab recreating this? This section ensures that I cannot use the same generated code on separate machine architectures even though the source code is actually identical.

Answer 2

[Mayur Sathawane]

Change below porperty in model configuration,

'ERTFilePackagingFormat' to 'Modular', (Code Generation --> Code Placement --> Code Packaging)

This will include model_private.h in code instead.

Answer 3

[michael braverman]

Yeah, the question is though why sometimes I see this code and sometimes not, when in both cases the signals and data types are essentially similar?

Answer 4

[Vikrant]

I have investigated this error using two different hardware implementation one is Intel x86-64(linux64) and other one is ARM compatibale ARM coretex but got same error after auyo code Gen.

To resolve this error I've removed all fixdt and the hardcoded datatypes applied as output datatype of block.

ex: Having product block two inputs and data types are single and uint16 to input ports make sure that output data type should be inherite and not uint32 or somthing else.

[谷]

Can I avoid generating <limits.h> just through the configuration settings？