Michael Barr建议：尽可能地用专用硬件来处理实时任务 Michael, 硬件

作者：Steve Leibson, 赛灵思战略营销与业务规划总监

2009年，Michael Barr发表了一篇题为“5个简单步骤使嵌入式软件架构更健壮”的博文。Barr曾经是《嵌入式系统编程》杂志的主编，因此你应该把他当作是一个编写嵌入式代码的专家，我是这么认为的。

在这篇博文中，Barr写道：
“我收集到的大量的证据表明，大部分编程人员、技术经理或者团队都不能真正理解一个好的固件架构是什么样的，怎么去实现它，甚至是怎么去识别他们看的架构的好坏。这还包括了在团队中最有经验的开发人员。”
随后，Barr的博文给出了开发稳定的嵌入式固件架构的5个步骤程序。
1.        确定需求
2.        把架构从设计中区分出来
3.        管理CPU时间
4.        测试设计
5.        为改变做计划
整篇博文值得花时间去阅读，但在这里我想要聚焦在第3步：管理CPU时间，Barr写道：
“大部分产品都是把非实时、软件实时和硬件实时的需求混合到一起。软件的时间限制通常最具挑战性，要以一种明确的方式去定义、测试和实施。举个例子，在机顶盒设计中，偶尔丢掉一帧视频数据可能是可以接受的，但是不能连续丢掉超过两帧，并且不能丢掉任何音频数据，音频数据是包括在相同的数字输入数据流中，处理软件时间限制的最简单的方法是把它们作为硬件时间限制一样对待，必须满足。
一旦识别了时间限制，在体系结构上，第一步要做的是把尽可能多的有时间要求的需求从软件中分离出来，放到硬件中去处理。图1展示了实时功能的处理方式的优先级排序。如图所示，处理实时功能最理想的地方是在一片FPGA或者一个专用的CPU中（不考虑时间限制的长度）。只有当不可能这样做的时候，才会去选择中断服务程序（ISR），当一个ISR也不能使用的时候，就应该选择使用一个高优先级的任务。”


请注意，Barr建议使用专用的硬件来处理实时任务，比如一片FPGA，或者一个专用处理器，他解释了为什么要这么做：
“首先，因为这样简化了非实时软件的设计和实现，在架构上把有时间要求的需求从大量的软件中剥离出来，这样可以使用新手编写的代码，而不会影响到用户安全性。把实时功能放到一起的另一个好处是，可以简化关于验证所有的时间限制都能满足的分析过程。”

Barr是在2010年Xilinx公布Zynq SoC之前不到8个月时写下这些话的，但他也许应该写的更直接一些。Zynq SoC的可编程逻辑（PL）恰好就是你需要的这种资源，可以用来实现自定义的硬件，处理硬件实时需求，包括那些需要用到一些专用I/O的任务，就象Adam Taylor在今天发表的博文中描述的那样，” 亚当泰勒玩转MicroZed连载34：用MicroZed驱动Adafruit RGB NeoPixel LED阵列…”，在这个简单的例子中，使用Zynq SoC 中的PL硬件逻辑为Adafruit NeoPixel LED条实现了一个专用的串行驱动器。如果你需要做一些更复杂的事情，那么可以有多种途径来使用Zynq PL，你可以在Zynq 的PL中例化复杂的硬件模块，包括存储器控制器、以太网MAC、DSP模块以及很多其它类型的硬件模块，这些模块可以是商业IP，也可以是你自己用Verilog、VHDL开发的模块，或者是用Vivado HLS从C/C++代码综合转换而来的设计。

如果出于某些原因，你的系统在实时性方面需要做得异常复杂，那么可以考虑使用多核设计，多核Zynq SoC有两个ARM Cortex-A9 MPCore处理器，工作频率可以超过1GHz。如果需要，你可以使用其中一个ARM处理器内核来处理实时代码和实时操作系统（RTOS），另一个ARM处理器内核可以运行那些不需要或者不能够实时工作的代码（在这里阅读“Linux,” GUI, 和apps）。

再说一次，我建议你阅读Barr发表的整篇博文，然后，如果你喜欢这篇文章，为什么不注册参加6月3日由Barr组织的免费的网络研讨会：“Bug-Killing：最重要的10个编码标准规则“

原文链接：
http://forums.xilinx.com/t5/Xcell-Daily-Blog/Michael-Barr-suggests-you-p...
© Copyright 2014 Xilinx Inc.
如需转载，请注明出处