基于Windows的嵌入式软件原型设计与仿真

Question

我正在寻找工具和技术，用于在桌面Windows上对深度嵌入的C代码进行原型(虚拟原型)、模拟和测试，包括构建由按钮、LCD和LCD显示器(包括分段和图形)组成的逼真嵌入式前面板。

我特别感兴趣的是一种可能的低级方法，使用纯C代码和原始MFC，而不是Win32、.NET/C#、vxWidgets或Qt。我也喜欢使用免费的开发工具，比如带有Platform C++的Visual SDK Express和用于编辑资源的ResEdit。

我正在寻找代码示例来渲染图形LCD(从单色到24位颜色)，它具有高效的像素级界面、多段LCD以及响应“按下”和“释放”事件的所有者描述的按钮。

Answer 1

令我惊讶的是，我原来的问题引发了如此多的误解和负面评论。在一台机器(例如，PC)上开发深度嵌入的C代码，然后在另一台机器(嵌入式微控制器)上运行它的策略被称为“双目标”，实际上是相当常见的。例如，在PC上开发和测试深度嵌入的代码是James Grenning最近出版的“嵌入式C的测试驱动开发”一书的基石。

通过双目标避免目标硬件瓶颈

请注意，双重目标并不意味着嵌入式设备与PC有任何关系。这也不意味着仿真必须与嵌入式目标CPU的周期精确。

双重目标简单地说，从第一天起，您的嵌入式代码(通常是C语言)被设计为至少在两个平台上运行:最终目标硬件和您的PC。您真正需要的只是两个C编译器:一个用于PC，另一个用于嵌入式设备。

然而，双目标策略确实需要设计嵌入式软件的特定方式，使得任何目标硬件依赖性都通过通常称为板级支持包(BSP)的明确定义的接口来处理。该接口至少有两个实现:一个用于实际目标，另一个用于PC，例如运行Windows。有了这样的接口，大部分嵌入式代码可以完全不知道它链接到哪个BSP实现，因此它可以在PC上快速开发，但也可以在目标硬件上运行，而不需要任何更改。

虽然一些嵌入式程序员可能会将双重目标视为自己造成的负担，但更有经验的开发人员通常同意，关注软件和硬件之间的边界实际上是有益的，因为它导致更模块化、更可移植和更可维护的软件具有更长的使用寿命。在双重目标上的投资也会在大大加速的编译-运行-调试周期中立即得到回报，与速度慢得多、资源受限的深度嵌入目标相比，在功能强大的PC上，这要快得多，效率也更高，对运行代码的可见性有限。

前面板Win32图形用户界面工具包

在为具有重要用户界面的设备开发嵌入式代码时，经常会遇到在PC上将嵌入式前面板表示为GUI元素的问题。这个问题是如此普遍，以至于我真的很惊讶，这里没有人推荐一个现成的库或一个开源项目，它们将为基本元素提供一个简单的C-only接口，比如LCD、按钮和LED。这真的不是那么复杂，但似乎每个嵌入式开发人员都必须一次又一次地重新发明这个轮子。

因此，为了帮助有兴趣在Windows上构建嵌入式设备原型的嵌入式开发人员，我创建了一个“前面板GPL工具包”，并在Win32开源许可证下将其发布到网上(请参阅http://www.state-machine.com/win32)。该工具包仅依赖于C语言中的原始Win32应用编程接口，目前提供了以下元素：

1. 点阵显示器，用于高效、像素可寻址的显示器，例如图形LCD、OLED等，具有高达24位彩色
2. 分段显示器，用于分段显示，以及分段LED，具有用于LCD按钮的通用、自定义位图，具有自定义的“按下”和“释放”位图，并能够在按下和释放时生成单独的事件。

该工具包附带了一个示例和一个App Note (请参阅http://www.state-machine.com/win32/AN_Win32-GUI.pdf)，展示了如何处理来自所有者描述的按钮、常规按钮、键盘和鼠标的输入。您还可以在http://www.state-machine.com/win32/front_panel.html上观看动画演示。

关于“前面板SDK图形用户界面工具包”的大小和复杂性，上述图形用户界面元素的实现只需要大约250行C语言。具有所有输入源和大量注释的示例相当于大约300行C语言。该工具包已经使用免费的Visual C++ Express2010(带有速成版平台Win32 )和免费的ResEdit资源编辑器进行了测试。

享受吧！

Answer 2

你在对问题的评论澄清中提到的设备永远不会使用windows PC，因此在这种情况下不需要低级别的windows编程。事实上，我会说这是不可取的。原型是关于速度的。它是关于你能以多快的速度把一些东西组合在一起，向潜在的投资者或上层管理人员或其他决策者展示。

您不会想要花额外的时间在低级C和Win32应用程序接口上，直到项目需求被充分清除，您知道这是最终项目可交付件(可能是服务器/PC监控工具？)的绝对需求。在此之前，您需要的是开发速度。幸运的是，该行业拥有快速原型设计和开发硬件的工具，如您所描述的。

我更喜欢使用嵌入式开发进行原型开发

至于我作为一名开发人员的看法，我喜欢Microsoft微框架(.netmf)只是因为我已经是一名.net .Net开发人员，可以传授我的许多现有技能。因此，我在Visual C# Express2010下使用C#实现了FEZ微控制器的原型(按您的要求免费)。它快速，简单，你可以在几分钟内完成项目的核心。

如果您作为开发人员的经验不同，您可以寻找使用BASIC、Java或其他语言编程的微控制器，通过重用您的核心技能集来帮助提高开发速度。

回答你的问题，赏金评论

令人惊讶的是，大部分嵌入式软件可以在台式计算机上开发，而不是在深度嵌入的目标上开发。这种“目标系统瓶颈”的避免可以潜在地提高生产力，如果处理得当的话。但是，要在桌面上开发嵌入式软件，需要模拟UI组件，例如显示器(包括分段的和越来越图形化的)、LED、旋钮和按钮。我正在寻找这样的UI组件，用C编写的纯Windows，以便与要在桌面Win32上开发和测试的嵌入式代码轻松集成。

我全职从事嵌入式开发已经有4年多的时间了，在这段时间里我也做了很多年。虽然你上面所说的在某种程度上是正确的，但它不会节省你的时间和金钱，这就是为什么每个人都对这个策略的动机感到困惑。我们花了几年时间，试图为这家公司的硬件设备推出一款windows模拟器，理论上可以节省原型开发的时间。这一直是一件痛苦的事情，我们花了更多的时间来尝试模拟这种体验，而不是直接从草图UI绘图规范到真正的开发。仿真器落后于硬件开发，通常在硬件发布后6个月或更长时间才支持最新功能。这是一项额外的工作，但价值很小。

您将花费更多的时间开发不可重用的win32平台代码和硬件仿真组件，而不是实际为核心项目本身编写代码。这只对硬件供应商来说是有意义的，他们将这个仿真器作为一个‘增值’工具提供给潜在的第三方开发人员，但它对新硬件设计的原型没有意义。

像带有FEZ微控制器的Visual C# Express2010这样的现代开发环境可以编译、将项目输出推送到微控制器，然后开始调试，其速度甚至比用C语言编译和运行低级windows应用程序(模拟LCD或LED或开关等)的速度更快。因此，你的评论“提高生产力一个数量级”，对于现代工具来说已经不再正确了。(它可能早于过去10年左右。)

如果你真的真的想在PC上可视化地模拟嵌入式硬件，可以使用像adobe flash这样的东西来模拟UI。但是，当你正在制作原型的最终设备不会运行windows (也许会运行，但你并没有这么说)时，不要重复为windows编写代码。使用当今可用的最快、最可靠的原型工具，这无疑不是低级C和win32应用编程接口！

也许把StackExchange用在电子产品上？

因为这是一个面向开发的站点，所以关于特定嵌入式硬件的优点的讨论实际上并不重要。如果您决定将重点重新放在使用微控制器电子设备进行原型设计(Arduino、FEZ、Propeller、Basic Stamp、Pololu等)上，您可以在stackexchange for electronics上寻求电子硬件方面的建议。我要说的是，这些平台中的大多数都是为了方便您概述的LCD、LED、按钮和界面的原型而设计的。您通常可以在几分钟内组装一些预先构建的模块，并准备开始编写项目代码。在这里可以节省大量的时间。

Answer 3

你的要求太高了，你需要看看@ proteus。http://www.labcenter.com/products/vsm_overview.cfm