Simulink Coder generates an rtwtypes.h file which defines various matlab/simulink types in terms of C types like char, short, int, long, .... This file uses the hardware platform specified in the C code generation options to determine these types.
This is fine except that the interpretation of "long" appears to differ between platforms, particularly between Windows and Linux/MacOS.
Ideally, these types should use the standard C int types such as int32_t which remove this ambiguity.
This also causes issues when trying to run these generated blocks from within S-blocks. Interestingly, it looks like the definition of long differs between matlabs internal rtwtypes.h file and the one it generates for linux (which has the same parameters as MacOS).
The fix for this is to scrub the rtwtype.h file and replace these type definitions with more generic ones.
/*=======================================================================*
* 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 long int64_T;
typedef unsigned long uint64_T;
typedef float real32_T;
typedef double real64_T;
The workaround to using in an S-function box is to include #define RTWTYPES_H //Matlab includes these defns already in the S-function header section before the actual header is included.
Simulink Coder generates an rtwtypes.h file which defines various matlab/simulink types in terms of C types like char, short, int, long, .... This file uses the hardware platform specified in the C code generation options to determine these types.
This is fine except that the interpretation of "long" appears to differ between platforms, particularly between Windows and Linux/MacOS.
Ideally, these types should use the standard C int types such as int32_t which remove this ambiguity.
This also causes issues when trying to run these generated blocks from within S-blocks. Interestingly, it looks like the definition of long differs between matlabs internal rtwtypes.h file and the one it generates for linux (which has the same parameters as MacOS).
The fix for this is to scrub the rtwtype.h file and replace these type definitions with more generic ones.