通常使用simulink,是借助MATLAB强大的数据展示及分析能力,做仿真开发,或者用MBD的方式生成C代码使用。
以MBD为例,构建一个研发闭环,往往是“搭建模型-->模型仿真-->生成代码-->集成与部署-->实体运行-->数据采集-->数据回放-->数据分析-->优化迭代”,之所以叫做闭环,是因为最后一步的“优化迭代”和第一步的“搭建模型”实际上都是在做模型开发,在这里形成了闭环,这一套下来是以MATLAB&&Simulink为绝对主体的工具链。
在MBD开发的实践中,有时候需要引入C代码,原因可能是已有成熟的C代码可复用、或者C库中有更合适的实现方式、再或者MATLAB&&Simulink内建的方法效率低下(矩阵计算开销大);这种混合编程的方式还是很方便的,既支持纯仿真,也支持生成代码,极大地拓展了MBD的应用范围和应用能力。
最近突然冒出一个想法,在纯C环境下,一般来说,如果想对程序做仿真验证的话,尤其是偏重算法、数据的程序,对大量数据的处理、可视化的展现是不够方便的,至少比起MATLAB&&Simulink来是差了一大截。
那么既然可以在MBD中引用C代码,是不是也可以顺着这条思路,直接对纯C程序用Simulink做数据仿真呢?答案是肯定的。
举个例子:
我们有个C程序如下:
int MyAddFunc(int a1, int a2)
{
return a1 + a2;
}
一个很简单的例子,就是个加法,我们可以把它想象成很复杂的功能,我们需要对这个功能做仿真,造了一些输入数据(其实就是测试用例),也准备了期望的输出,借助Simulink仿真我们来看看这个功能的表现。
首先,在Simulink中对这个C代码的调用是这样的:
function result = TestMyFunc(a1, a2)
result = coder.ceval('MyAddFunc', coder.rref(a1), coder.rref(a2));
% ref可读可写,rref只读,wref只写
这是在matlab function里写的,就是这样的语法;只是个示例,coder.rref()在这里是不应该写的,因为在前面的C代码中没有对a1、a2做const限定,所以在matlab function里直接写a1、a2就行,要和C代码中的定义方式匹配。
在Simulink中搭模型是像下图这样的,上面的代码就写在叫做TestMyFunc的matlab function模块中。
对a1、a2给定一些数据后,执行仿真,就可以在Simulink Data Inspector(SDI)中查看结果了,操作区如下图所示。
SDI如下图所示,可移动、缩放、看多个曲线、多曲线叠加对比,极其方便。
这种方法的优点在于:
- 强大的数据展示、分析能力;
- 快速的仿真,直接调用C,不用再按照C的思路专门为仿真目的搭个模型;
- 借助simulink harness可以快速生成测试用例。
只不过,受限也是明显的:
- C程序需要有明确的输入输出;
- 无法看到中间过程。