随着32位多核处理器应用逐渐走热，设计者正面临着新的挑战， 业内专家指出面向角色（actor-oriented）的图形化方法是更适合嵌入式软件设计的工具。NI 的LabVIEW嵌入式开发模块是LabVIEW图形化编程环境的一款全新附加模块，通过这个软件和图形化系统设计的理念，原先无法利用到嵌入式编程的工程师们都可以进入32位微处理器的领域之中。通过LabVIEW中附加的状态图、控制图表、信号处理库函数等这一完整的工具来设计它们的应用，以解决各种问题。本文对该开发工具进行了介绍。
随着嵌入式系统变得越来越复杂，设计者正面临着新的挑战：随着基于32位微控制器(MCU)的嵌入式系统的成本向16位系统逐步接近，在许多高级应用中8位和16位微控制器正逐步让位给扩展性更佳，性能更好的32位片上系统（SoC）。此外，由于单纯通过CPU的性能提升来增加整个系统的性能已经不是一种持久的发展趋势了，所以主要的处理器制造商已经转向了多核心架构。从Dell在几个月前推出的多处理器核心的台式计算机，就可以看到这种趋势。从消费者和用户的观点上来看，处理性能的提升是一样的。但是，从一个嵌入式系统开发者的观点来看，设计将变得更加复杂，因为您必须了解如何在多处理器环境下开发和分割您的应用。根据十年前的估计，嵌入式系统的平均代码量为10万行。到2001年，这个数字实际已经超过了100万，而现在的数字估计为500万。
现在我们将视线转移到当前嵌入式系统的开发工具上来，随着复杂度的逐渐上升，现在传统工具很难降低编程工作的复杂度，嵌入式领域需要另一种方法来应对这些挑战。挑战不仅是工具方面的，还有解决问题的途径：基于文本编程的嵌入式应用开发在将来不可能解决这些问题。这已经是许多业内专家的共识；Edward Lee博士是加州大学伯克利分校嵌入式研究方面的领先者，他指出现在嵌入式系统的开发手段如基于文本编程和面向对象的工具都难以用来构建嵌入式实时系统，因为面向对象很难直观地表达时间和平行性（parallelism），而时间和平行性或并行（concurrency）在现在的嵌入式系统中是必不可少的。Lee博士提出面向角色（actor-oriented）的图形化方法是更适合嵌入式软件设计的工具。
虽然嵌入式系统的挑战越来越严峻，但是现在已经有了许多解决的方向。许多供应商采取了将底层工具的设计抽象出来的办法。这种方法每前进一步，都会吸引更多的用户。另一个方向是可以更彻底地解决面临的挑战，也就是向基于平台的工具转移，它能够更好地表达整个系统，而减少与特定硬件的相关性，这使得更多的软件设计容易理解并被重复使用，而从基于文本的工具向图形化工具的转移则可以直观地表达系统，并解决系统的挑战。图形化系统设计（Graphical System Design）的理念就是源于这些趋势。通过简化嵌入式编程的复杂性，它降低了对领域专家在嵌入式设计流程中各个步骤的要求；同时提供了从设计、原型到部署的一条捷径，使得工程师和科学家们可以更快速地进行重复设计。
尽管市场上的工具都在向图形化的方向转变，但由于它们是针对特定领域特定应用的工具，所以仍旧受到自身的限制，而这是不足以解决行业将要面临的挑战的。事实上，现在的嵌入式系统市场与八十年代早期的台式计算机市场有很多相似之处，其中的一个特点就是非常分散。现在市场所需的是一种完全的图形化编程语言，提供足够的灵活性和功能，以满足更广泛应用的需求。因此，图形化系统设计的关键因素是图形化编程。
将设计方法学直接应用于实现
自1986年诞生以来，LabVIEW图形化编程语言已经开始简化了系统的复杂性，并在同一个平台上提供采集、分析和显示等功能，在使用计算能力对处理过程自动化的同时，允许在研发原型，制造和测试过程中对软硬件的重用，弥补了原先因为原型、制造和测试三个步骤间因工具不同而造成的这一鸿沟。在所有涉及到数据采集和控制的领域里，LabVIEW图形化方式都已经成为标准的开发工具。从那时开始，我们就一直向这个编程环境添加功能上的改进，现在LabVIEW在已有的定时循环结构上新加了硬件定时功能，它是一种表示时间和并行的语义。现在，我们就可以通过点击来设置操作系统优先级，延时，循环速率等等；回想在文章前面所提到的向多处理器转移的趋势，现在我们可以憧憬使用可扩展的直观图形化编程，来开发应用，并将处理过程分配到不同的处理器上。
新的NI LabVIEW嵌入式开发模块（LabVIEW Embedded Development Module,）是LabVIEW图形化编程环境的一款全新附加模块，通过这个软件和图形化系统设计的理念，原先无法利用到嵌入式编程的工程师们都可以进入32位微处理器的领域之中。通过LabVIEW中附加的状态图、控制图表、信号处理库函数等这一完整的工具来设计它们的应用，以解决各种问题。
领域专家－在某个科学或工程领域的专家，但不一定是嵌入式的程序员－一般使用不同的模型或工具解决他们学术上或工程上的问题。例如，开发引擎控制单元(ECU)的工程师可能使用状态图来对引擎控制单元的功能进行图形化的描述。这位工程师可能是一个控制理论方面的专家，但是却可能没有任何嵌入式或C编程方面的经验。直到现在，嵌入式应用的实现仍然需要深入了解关于嵌入式编程工具，如C语言等方面的知识。因此，很多领域专家要实现他们的解决方案，甚至只是简单的验证一个概念仍然要依赖专门的嵌入式开发人员。这个存在于领域专家和嵌入式程序员之间的鸿沟，使得开发时间增加，而且容易在系统中引入错误。
LabVIEW嵌入式开发模块在设计和实现间的鸿沟之上架起了一座桥梁。领域的专家现在可以使用相同环境快速地设计算法，对定制的设计进行原型设计，将他们的解决方案在所选的目标上实现，并进行调试——所有这些过程都是通过图形化方式实现的。
开发与目标无关的代码
嵌入式目标本身要求程序员在编写代码之前对目标有深入的了解。程序需要知道板卡上各种关于内存映射和寄存器的信息，才能在板卡上执行他们的代码。另外，大部分代码是专为某一特定目标编写的。这样，在一块板卡上使用不同的微处理器或是不同的外围设备，可能就需要重新编写大部分已有的代码，或是完全从头开始。这意味着最终产品的扩展性方面是有缺陷的。
 |
|
图1：LabVIEW 开发界面 |
但是，使用LabVIEW嵌入式开发模块，工程师和科学家们不需了解最终的目标，就可以进行代码开发，因为软件生成的是LabVIEW应用的ANSI C代码，而不是针对某个特定目标的二进制代码。LabVIEW嵌入式方式是一个开放的框架，它可以整合任意的第三方工具链，将生成的C代码、LabVIEW实时库函数和板卡支持程序包（BSP）编译成为针对某一目标并能在这个目标上运行的二进制代码。BSP是一种作为C代码与板上外围硬件接口的底层代码。因此，如果板卡需要升级，工程师可以简单地将不同的BSP链接到LabVIEW中，在现有的图形化代码上作一小部分改动就可以完成。
与目标无关的代码开发意味着工程师和科学家不再需要等待硬件确定之后再开始设计算法。这样并行的工作和效率的提升，使开发周期和产品上市时间大大缩短。最后，所生成的LabVIEW代码不是针对某个特定平台的，所以您很容易升级到新的硬件。
使用LabVIEW嵌入式特性缩短开发时间
LabVIEW嵌入式开发模块构建在自LabVIEW诞生以来近20年的创新精神之上，帮助工程师和科学家们利用数百个内建的库函数，涵盖高等算法、文件I/O、逻辑和信号处理各个方面。通过LabVIEW嵌入式方式 ，工程师和科学家可以使用一种叫做内联C节点（Inline C Node）的新特性，整合现有的嵌入式代码，来保持LabVIEW的开放架构。
除了用于快速调试的内建图形化用户接口显示件、探针、断点和函数步进之外，LabVIEW嵌入式开发模块为代码调试提供了另外两种无缝的接口。在嵌入式目标平台上，工程师可以使用“仪器调试”（instrumented debugging），以便于通过TCP/IP、RS232,或CAN进行调试。使用内建的片上调试接口，工程师可以通过工业标准协议，如JTAG、BDI和Nexus等，进行调试，同时不影响程序性能。
LabVIEW嵌入式开发模块使领域专家可以使用现有的技术进行更多的应用，使用同一环境进行算法设计、原型，实现他们的解决方案，极大地缩短开发时间和产品上市时间。
 |
|
图2：NI嵌入式开发模块示意图 |
NI提供了各种硬件平台与LabVIEW集成，完成从设计、原型到部署的全过程。例如使用LabVIEW和NI 可重复配置I/O（RIO）设备或NI CompactRIO平台，他们可以快速而便捷地创建嵌入式系统的原型。NI现有的一个成功案例就是帮助汽车控制和数据采集解决方案的提供商--Drivven公司通过NI CompactRIO对基于FPGA的2004 Ya
