Why does Stateflow operator 'falling' generate c code with conversion to float64?

I am generating code from a Stateflow logic that contains edge detetction.

I use the built-in 'falling' operator. All inputs and outputs of the chart are of int8 datatype.

The generated code calls the edge detection function 'rt_zcfcn' with conversion to float.

Why is the conversion to float there and is there a setting that changes this behavior so that the generated code does not contain double-precision floating-point operations? It would be ideal if there wasn't even a separate function in a separate .c file for this simple check.

  resultZC0 = (((sint32)rt_ZCFcn(FALLING_ZERO_CROSSING,
    &rtARID_DEF_CtApDriverRequestEval.previousZC,
    ((float64)((sint32)(((sint32)HCULeverPosition) - ((sint32)PrmReleasePosLimit))))))
               != 0);

Answer 1

[Aabha]

Hi @Szkupien Bence,

When generating code from a Stateflow chart that uses edge detection, such as the “falling” operator, the generated code often involves floating-point operations due to the underlying implementation of the function “rt_zcfcn” that implements zero-crossing detection. This is because the zero-crossing detection logic is implemented to handle a wide range of signal types and transitions, including those that involve floating-point values. Using floating-point arithmetic in this context can provide better precision for detecting transitions, especially in complex systems where the signal may not be strictly integer-based.

Please refer to the following documentation link for more information about Zero-Crossing Detection:

https://www.mathworks.com/help/releases/r2024b/simulink/ug/zero-crossing-detection.html

There isn’t a direct setting in Stateflow that disables the conversion of such variables to float. However, the following workaround can be tried to achieve this:

Instead of using the built-in “falling” operator, a custom implementation can be created using a combination of state variables and comparisons. This function can be implemented using a MATLAB function block, within the Stateflow chart. This approach can be designed to use only integer comparisons, avoiding any floating-point operations. Using this approach, the generated code will treat the required variables as integers.

I hope this helps.

[Szkupien Bence]

Hi @Aabha

Thanks for your answer,

I guess these operators are not so useful then for embedded code generation...

I had a similar problem with generating code from Stateflow logic with temporal operators like 'duration', and I had to find out that the generated code is not controllable there as well:

https://www.mathworks.com/matlabcentral/answers/892377-why-does-c-code-generated-from-stateflow-logic-with-duration-operator-have-conversion-to-real_t-d?s_tid=prof_contriblnk

I also found out that having multiple 'after' operators in charts that are not executed paralelly generates one shared temporal counter variable which makes debugging the c code really hard, and this can't be changed in codegen settings, so I have to create the respecive counter variables manually.

Of course I can do it myself using a state variable, but isn't the reason behind the existence of these operators not having to do it manually? I would expect the generated code to look like if I do it manually: one local variable for the previous value with the same daty type.