普遍认为开发多处理器系统软件的难度要大于单处理器系统。但实际情况并非总是如此。我们这个在 TRW 汽车公司下属的咨询部 TRW Conekt 工作的设计团队最近接管了一个项目,展示了如何根据手中的问题发挥硬件的功能,并通过使用许多个处理器开发出高效系统。
我们小组接到了一项任务,为一个名为“Foot-LITE”的项目开发车载嵌入式处理电子系统(该项目由MIRA 公司牵头,英国政府支持的技术战略委员会、交通部和工程物理科学研究所赞助)。该项目能够为驾驶员提供反馈信息,从安全和燃油经济性的角度让他们了解他们的驾驶习惯。
该系统通过两种方式为驾驶人员提供反馈。一是,由一个仪表盘式的智能电话显示系统(由布鲁塞尔大学设计,HW CommunicaTIons 公司开发)向驾驶员提供与需要立即关注的事件有关的实时通信。二是,该系统还能够连续采集行程数据,包括特别“事件”的视频流,然后将其上传到互联网服务器,供用户在闲暇时查看。根据我们的合作伙伴汽车高级驾驶协会 (InsTItute of Advance Motorists) 提出的驾驶建议,另一个合作伙伴英国里卡多有限公司 (Ricardo UK) 开发出了一种算法,能够决定哪些事件需要标出来提醒用户注意。
该项目将把这个系统安装到由30辆车组成的车队里。测试车手由项目合作方Hampshire县议会 (Hampshire County Council) 公开招募。
该项目将逐步纳入由12家行业、政府和学术合作伙伴协同研究的成果。这意味着我们需要非常灵活的解决方案来解决我们的处理问题。
起初,我们想提供单处理器系统。不过很快发现,专用处理器可以简化算法开发工作每次迭代所需的集成工作。
基本系统
我们已经有一种处理器系统,目前正在另一个项目中进行开发,主要用于图像处理(图2)。
该系统基于连接到 4 个独立的DDR存储块的单个Xilinx? Spartan?-3A XC3SD3400A器件。该架构可以让用户实现众多不同的处理器/逻辑配置。举例来说,可以把整个 FPGA 结构用作完全采用HDL定义的纯逻辑资源。另外,还可以使用更高级的工具,比如赛灵思EDK来实现 4 个(或者更多)的软核微处理器。每个软核微处理器都可以访问自己专用的DDR存储设备,保护数据免遭其它微处理器的干扰。对于其他的简单工作,可以使用内嵌的BRAM块来实现更多的处理器。
图 1 – Foot-LITE 系统
项目合作伙伴很早就决定采用USB接口,因为这样可以向系统添加各种外设。然而这需要一些形式的USB 协议栈——我们通过使用Petalinux版本的uclinux获得,以及一个配有USB主机设备的子卡。
使用 Linux 还为我们提供了一种管理SPI闪存设备的简单方法,该系统可提供 FPGA 比特流和应用代码存储。我们安装了一个简单的 JFFS2 文件系统,可以通过以太网(使用 FTP)或启动USB 记忆棒(包含一个脚本,用以将新代码上载到内部闪存上)来实现现场应用升级。在传统的嵌入式系统中,所有这些要求都需要软件小组编写底层应用代码。不过,在有了 Linux 之后,我们可以轻松地编写简单的 Bash 脚本来控制这些流程。
Foot-LITE 算法
Ricardo开发出了用于评估驾驶员行为的核心算法,并将其应用在自己的 rCube 快速原型设计系统上 (http://www.ricardo.com/en-gb/ Engineering-ConsulTIng/AutomoTIveExpertise/Controls--Electronics/ Embedded-Software/rCube/)。我们采用这种方法进行了初步的仿真器测试,并在三辆测试车辆上进行了试用。在测试车辆上,一个嵌入式视觉系统(基于现有的 TRW 产品——凑巧也有 FPGA)用于测量与前车之间的距离,并评估车辆在车道上的位置。测试车辆还可通过雷达系统提供距离信息。作为投产前的一个步骤,我们在更大规模的试验中取消了雷达系统,因为视觉系统已经能够为应用提供足够的信息。
我们在车辆上安装了前视摄像头和处理子系统,两者整合成一个小型设备,安装在后视镜的旁边。子系统中的嵌入式算法可通过视频图像处理来测量车身和车道边缘之间的距离。此外,并行算法还可检测到 Foot-LITE 车辆前面的车辆,并测量车头间距。该子系统使用汽车标准的控制器局域网(CAN) 总线将数据传输给Foot-LITE子系统单元。
我们在 Foot-LITE单元中集成了三轴加速计和横摆角速度传感系统,这可以给Foot-LITE算法提供在需要时访问高速率、低延时车辆动态信息的可能。
Foot-LITE 算法把所有的数据整合在一起,为驾驶员提供一系列与他的(或她的)驾驶风格相关的简洁信息。
算法实施
起初,我们想提供一种单处理器系统。不过很快发现,专用处理器可以简化算法开发工作每次迭代所需的集成工作。我们把主处理器和 Foot-LITE 算法处理器隔离开来,中间用MicroBlaze? Fast Simplex Link (FSL) 总线系统来实现通信。这样可以把两个处理器的存储完全隔离开来(与常见的共享存储的做法不同),可以大幅度简化集成工作,因为错误不会通过内存损坏而从一个处理器迁移到另一个处理器上。
此外,这样可以避免对处理器周期的竞相争用。这就意味着我们的合作伙伴可以放心,我们对主机应用所做的任何修改都不会影响他们的应用性能。
图 2 – 基于 Spartan 的处理模块
我们开发了一系列封装功能,允许我们访问Simulink? 编译器生成的 C 语言程序,而无需对接口进行大幅更改。我们可通过 I2C 总线提供少量非易失板上缓存空间,用于存储Foot-LITE 算法中的各种调节参数 (tune parameter)。这就需要一个简单的封装程序,以便算法在 Simulink 环境下实现轻松访问,从而在启动时读取该内存,并在关断时写回。
该系统需要测量加速度和横摆角速度,并通过CAN总线与车道和车辆检测系统通信。由于我们已经有了底层CAN 驱动程序,而且我们担心Linux应用在40毫秒的时间范围内测量车辆动态信息的及时性,我们决定在系统中再增加一个MicroBlaze。这样可以不必把 CAN 驱动程序导入Linux,而且可以通过另一个隔离的处理节点实现确定的性能。这对算法非常重要,因为算法使用的动态测量值。此外,这种方法还可以让我们把编写软件的工作拆开,进行并行开发。这里我们还是使用 FSL 作为动态处理器和Foot-LITE 算法处理器之间的接口。
视频捕获与压缩
系统的初步构想是把视觉系统的数据通过CAN 总线传输给 Foot-LITE 算法单元,为车道宽度和偏移量、与前方车辆之间的距离等提供简单的测量。项目合作伙伴决定强化其设置,将捕获到的视频帧传输到服务器,进行离线环境分析,以转译系统提供的信息的含义。鉴于这项要求只针对“互联网质量”的视频(频率为5 Hz 时,像素为 300x200),我们觉得我们可以再用一个 MicroBlaze,把视频流实时压缩成一系列 JPEG 图像。摄像头捕获的图像是宽VGA(频率为30Hz 时,像素为 720 x 480,)视频流。很明显,图像降采样工作应该交给硬件来做。
我们设计了一个简单的外设,通过交替去掉像素和行来进行降采样 *** 作,生成360 x 240的图像。该外设还每 5 帧去掉 4 帧,以获得所需的帧率。无需进行更复杂的处理就可以获得视觉上可以接受的结果,因为JPEG 处理会让走样的人为效果不可见。我们使用系统生成器来开发该外设,因为它可以直接导出到 EDK,而且我们已经有了使用系统生成器进行更加复杂的图像处理的经验。
进入连接到 JPEG 处理器的 SDRAM 的数据由降采样外设的总线负责控制,数据随即被逐帧压缩,送入循环缓冲区,直到Foot-LITE算法发出标志。JPEG处理器将压缩后的视频帧(也是通过 FSL)发送到主机 MicroBlaze。我们使用独立 JPEG 小组提供的代码库,而且发现基本不需要优化就可以工作在 5Hz 的条件下。
另外,通过隔离的处理器让另一位软件工程师(身处异地)在进行系统相同部分开发的时候,都可以并行不悖。
用蓝牙连接到智能电话和车载诊断系统
简便的安装是这个项目的关键因素。减少系统使用的线缆数量也是需要考虑的重要方面。
我们选用蓝牙做为连接到智能电话的接口。标准USB蓝牙连接器的驱动程序是ucLinux内核的标配,虽然我们不得不自己构建用户空间工具。以上这些工作跟其他代码有着许多关联性,而这些代码也都是经过Petlinux的工具包交叉编译并添加到ucLinux的 文件系统中。
我们选定蓝牙作为智能电话接口后,我们自然也选择蓝牙作为连接到板载诊断系统的接口。我们使用标准的现成蓝牙-车载诊断系统 (Bluetooth-OBD) 接口模块,这样从系统中省掉了又一个有线链接。
图 3 — 显示主要外部元件的FPGA框图
简便的调试
调试有多个并行执行线程的系统往往难度较大。不过把系统划分给多个处理器就可以使事情变得简单。我们不需要多线程调试器(比如在Linux环境中调试多个处理器时所需要的)。赛灵思调试器 (XMD) 可以连接到多个处理器上,而且通过使用TCL(XMD能理解的工具命令行语言),我们可以自动完成设置,并将待测的代码下载到多个处理器上。当然,也可以使用采用 printf 声明的常规嵌入式系统调试方法,因为每个处理器都有自己的串行端口。
在调试处理器间通信时具有重大价值的另一种工具是 ChipScope? Pro。该嵌入式逻辑分析器内建在 FPGA 结构中,让我们可以捕获通过FSL 链路的数据,把隐藏较深的缺陷的漏洞排查到发送方或者接收方,然后进行代码的逐行排查。
使用四个处理器实现的隔离的意义在于,当某个元件被调试过后,基本上不需要再调试。这样可以避免在把不同来源的代码集成到大型独立应用中,或者在单个处理器上运行多个进程时,因奇奇怪怪的相互作用而产生的诸多问题。
FPGA 实现
这个项目基本不涉及 HDL,只用高级封装程序把基于 EDK 的设计与一小段看门狗代码整合在一起,确保系统在驾驶人员熄火后关闭。 EDK生成了FPGA的主体部分(MHS 文件长度超过1,300 行!),而系统生成器负责生成视频降采样器。我们对四个微控制器都配置使用了高速缓存和浮点单元。在使用四个处理器、四个 DDR 存储接口以及一系列外设(包括以太网、SPI、IIC、CAN、UART、定时器和 GPIO)之后,器件约七成的查找表都被占用了(大约2.8万个查找表)。与基于微控制器的 FPGA 的通常情况一样,块存储器的使用率非常高,超过了 90%,或者119 个BRAM,但 DSP 模块使用率相对较低:只有每个处理器的浮点单元需要它们(每个处理器 8 个,总计 32 个)。
整合主微处理器从内部闪存引导 Linux 内核,然后加载内部文件系统。每个从处理器都有基于FSL的引导载入程序,可以接受标准的 S-record文件,对其进行解析并将其拷贝到本地存储中,然后执行。Linux 处理器把 S-record文件从文件系统中直接发送到 FSL 伪文件(使用内置的 dd 实用程序)。如上文所述,所有的处理器间通信都通过完全连接的 FSL 链路网格完成。FSL 链路网格的带宽为 32 位,运行频率为60MHz,能够提供大量的低时延通信带宽。虽然避免使用共享存储可能会带来限制,但这样做可以实现上文已经探讨过的隔离所带来的优势。硬件架构与应用要求的划分吻合良好,实现了直观的软件分区。
有需要时,Foot-LITE 算法微处理器会向 JPEG 压缩器发出触发信号,同时与智能电话显示器通信。Linux 处理器在蓝牙通信和系统其余部件之间充当媒介作用(如图3 所示)。除了向驾驶人员发出即时信号,它将有关车辆状态的连续信息流以及偶发的视频流通过智能电话上传到中央服务器。
在旅途结束,驾驶人员熄火时,主处理器会通知从处理器,随即从处理器启动各自的关闭流程(比如将更新的参数写入非易失调节存储器),然后告知主处理器它们已经可以安全地关闭了。此时,主处理器向电源发出信号,然后系统进入极低功耗睡眠模式,等待下一次发动。如果在熄火后两分钟软件还没有发出关闭信号(不过这种情况一般不太可能发生),FPGA 结构中的硬件定时器会切断电源,避免耗尽车辆的电池。
在项目收尾阶段,来自由纽卡斯尔大学和南安普顿大学两名学术界人士将分析在实际高速公路行驶状态下车辆输出数据,以评估该系统引导驾驶人员行为的效能。
FPGA 的优势
FPGA 提供了高度的灵活性,与固定硬件平台相比,能够更轻松地满足日新月异的项目需求。另一大优势是,FPGA 能够集成到定制化硬件中,满足密集型应用(比如视频)需求。在使用 Linux 的情况下,可以方便地对诸如以太网这样的外设进行高级访问,同时不会影响实时性能,这样就可以把这些关键性的工作交给它们各自的微处理器来处理。最终,如果是由一个大型的、位于不同地理位置的团队在开发该软件,使用与功能划分相匹配的硬件架构有助于开发和集成工作。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)