Preferred approach for code generation with MATLAB embedded coder

We are using MATLAB Embedded coder to generate production intent code from our m - scripts. Unlike in the SIMULINK world where people rarely check how the autocode looks like, with code generated from M scripts it is essential to review the code as it might be possible to easily identify changes that could potentially made in M-script to get a more optimal C code. I believe this probably because of the interpreted nature of M-scripts. We usually generate code as batch with a script which generates code for all the M-scripts. However, with this approach the entire C Code needs to be regenerated even for a minor change in just one of the m-files. This makes review of the generated C code tedious. Is this the right approach? Or should each M-script be individually generated, tested and maintained in isolation so that only the m file which has changed need to be regenerated. Is this second approach possible itself ? Even if possible will there be complexities like common files , shared data etc which are usually managed with Data dictionary in SIMULINK world .

Answer 1

[Mark McBroom]

Why are you manually reviewing the generated C code? Many workflows require review of the MATLAB code and then test cases that test both the MATLAB code and the generated C code ( i.e. SIL testing). This approach confirms that the M code and C code are functionally equivalent and therefore review of the C code is not needed. If manual review is required, you can use coder.inline('never') to force each MATLAB function to be generated as a corresponding C function. This will isloate changes in C code only to those M Functions that changed.

https://www.mathworks.com/help/ecoder/ug/software-in-the-loop-sil-execution-using-the-project-interface.html

[Nitin Skandan]

Hi Mark,

Thank you for the reply.

The manual review is done to ensure that C code is optimal.

i.e. example an unnecessary local variable might introduce a memcpy in the C code and if the local variable is eliminated then C code could be improved. We have Hardware constraints so it is necessary to ensure that C code is as optimised as possible.