嵌入式自学可能吗_自动生成的代码支持的硬件平台的简介

小嵌

嵌入式自学可能吗_自动生成的代码支持的硬件平台的简介,   

你们自动生成的代码都支持哪些MCU？

这是这几年最经常被问到的几个问题之一了，我向来的回答是：

代码生成工具生成的是标准C代码，支持所有的MCU或者DSP。

既然答案如此明确，干嘛还要来写这篇文章？

回答问题前，我们先看看为什么会有这么多人提及这个问题。

M曾经的Target Support Package

我敢说很多人提到这个问题是因为MATLAB曾经有一个的工具箱，叫做Target Support Package，简称TSP，这个产品从MATLAB R2011a开始不再单独销售。不过，对于习惯了汽车行业这种嵌入式软件开发的工程师，这些支持包，可能只能用作过家家了，因为汽车行业的软件是下面这个样子的：

  

即便是我们不使用AUTOSAR架构，差别也主要在于是否有RTE上，其他的部分该有的都会有的。

我们再来看一下TSP这个工具包有什么功能，下面这幅图是MATLAB R2012b里面TI C2000的TSP模块库：

  

这个模块库里有AD、有数字IO，有PWM输出，有比较寄存器，还有各类通信端口的收发模块等等，我们可以假想有这样一个模型：

  

模型中，AD模块有了，在生成的代码中，有读取AD转换数据的C接口函数，AD转换得到的数据经过Algorithm部分的运算，获得期望的PWM输出信号的占空比，后面的PWM模块会根据这个占空比的数值产生PWM信号。

看起来好像非常不错的样子，不过我们想，就AD转换或者PWM输出这类底层驱动软件，对于一个做单片机的工程师来讲，这点工作量并不大，并且，对于同一款单片机，最底层的驱动软件通常非常稳定，不会像应用层软件那样需要频繁变更。

也就是说，TSP给我们节省的时间非常有限。

时间上不能节省太多倒还不是最大的问题。最大的问题是，这部分软件在Simulink环境下没法仿真，如果架构设计不好，这会直接导致整个模型的可验证性变差。

如果为了节省那么一点微不足道的时间，而导致整个模型的可验证性变差，得不偿失。

另外，还有不少客户试图自己开发TSP，这往往连节省微不足道的时间的好处都没了，因为开发TSP也算得上对Simulink做深度定制了，通常需要用户熟悉TLC编程，熟悉S-Function，并且，无论是TLC还是S-Function都没有便利的调试环境，这对于开发以及后期维护TSP都带来了非常大的困难。

所以，我对Simulink模型设计的建议是：

能在Simulink环境下仿真的部分，可以通过Simulink实现，对于单片机底层这类没法在Simulink下仿真的软件，不应该打包到Simulink环境下。

MTSP是否一无是处？

前面我们说过，这个工具从2011年开始已经不再单独销售，但并未寿终正寝。最新版的MATLAB的标准产品中已经看不到这个产品，不过，如果你一定要找，还是可以通过添加硬件支持包的方式找到各式各样的硬件支持包，并且相对以前的TSP，硬件支持包不仅提供了很多MCU的驱动模块，而且还提供了很多热门硬件的支持，比如Arduino，Raspberry Pi等，如下图示：

  

对于完全没有嵌入式软件开发经验的大、中学生或者工程师，如果想做嵌入式系统上实现某些算法，而又没有精力去学习嵌入式系统，的确可以借助TSP，通过Simulink实现算法，并最快的做目标处理器上验证这些算法，这也是不错的选择。

但是对于产品开发，TSP在很多行业是行不通的。

M不该有的误解

或许因为TSP的存在，让很多人产生如下误解：

MATLAB没提供TSP的单片机就等于MATLAB代码生成不支持这款单片机

基于模型的嵌入式软件设计一定要有TSP作为支持，没有TSP支持，就没法进行基于模型的嵌入式软件设计

这两种误解是没有道理的，我们应该参照AUTOSAR架构，做应用层软件开发或者策略实现部分的模型开发中使用模型。

如果我们仔细观察一下AUTOSAR的软件架构，我们发现，基础软件部分，除了MCAL层之外，还有ECU 抽象层、协议栈、操作系统等基础软件，并且这部分软件远比MCAL复杂，如果使用TSP，基础软件中除了MCAL之外的软件怎么实现？这是一个问题，不需要答案，只为更加明确TSP做汽车电子产品软件开发中没有价值。