使用 .NET Micro Framework 进行编程的经验

Question

在我的敦促下，我咨询的一家公司正在寻求切换到由 .NET Micro Framework 提供支持的设备，以便我们能够更快地将设备推向市场。至少在理论上，这个想法是用 C# 而不是 C 或汇编进行编码会更快，更不容易出错。就像我说的，这都是理论，因为我从未编写过嵌入式设备。

我的问题如下：

1. .NET Micro Framework 能胜任这项任务吗？
2. .NET Micro Framework 不能做哪些事情？
3. 有哪些陷阱？
4. 插件设备是否存在可行的第三方市场？我在 Microsoft 的网站上没有看到很多内容。
5. 谁能指出使用 MF 框架开发的商业设备。

谢谢。

Answer 1

在不了解您的应用程序和嵌入式设备的当前功能的情况下，如果 .NET MF 能够胜任这项任务，我将很难给出明确的意见。如果嵌入式设备是具有 2K RAM 和 32K ROM 的低功耗 8 位 CPU，那么 .NET MF 将不适合该设计。

在很多情况下，迁移到 .NET MF 会涉及对许多供应商青睐的芯片组进行硬件更改，这些供应商通常以 ARM7 或 ARM9 内核为目标。这样做的主要原因是利用在移植 HAL 和将 PAL 和 TinyCLR 交叉编译到相关处理器的本机代码方面已经完成的工作。然后，如果您的应用程序适合 .NET MF 模型，您只需要开发托管代码。

development boards 的比较可能会帮助您为新设计选择平台。 GHI products 的优势在于您可以购买裸芯片组以及他们开发的固件以与您的硬件设计集成。

问题 1 的答案：.NET Micro Framework 能胜任这项任务吗？

抱歉，如果没有更多信息，我无法回答您的申请。

问题 2 的答案：.NET Micro Framework 不能做哪些事情？

微框架不像许多竞争产品那样是实时的。调度程序相当简单，并未针对需要确定性时序的系统进行优化。
TinyCLR 将下一个等待“线程”的 IL 解释 20 毫秒。线程可以通过调用Thread.Sleep(0) 来产生它们分配的时间片。只有在每个线程时间片之间，运行时解释器才会检查来自硬件的标志，并将事件分派到托管代码或唤醒线程（如果它们被阻塞等待硬件）。据我了解，线程无法从本机代码中断服务例程 (ISR) 中解除阻塞，也无法让较高优先级的线程先发制人地中断较低优先级的线程。

问题 3 的答案：有哪些陷阱？

一切似乎都在工作，您已经了解了运行时 interperter 循环的工作原理（线程调度和对硬件事件的反应），然后您就忘记了 GARBAGE COLLECTION！！
最好尽量减少内存抖动量（每次new 对象时都要仔细检查）。与其创建和销毁常用对象，不如考虑持有一个通常被 GC 处理的对象池，并在需要时回收它们。

问题 4 的答案：插件设备是否存在可行的第三方市场？

第三方参与主要是在硬件方面的开发板和参考设计。从软件的角度来看，这个code-share link 可能很有趣。另外，不要忘记大多数 VS2008 开发工具也适用于 .NET MF（例如 Resharper 和 VisualSVN）

抱歉，没有问题 5 的答案，因为我不关注这类事情。 Microsoft 上的 landing page for .NET MF 似乎确实有商业设备的图像，但我从未点击过链接。

Answer 2

与我使用过的许多其他嵌入式平台相比，.Net Micro Framework 使用起来非常简单。但它目前确实有一些缺点，例如缺乏实时支持。由于使用相同总线的所有附加设备的硬件争用，一些 SDK 套件也存在问题。如果你需要大量的设备挂在你的控制器上，我会考虑使用 Windows CE 平台。当前用于 Micro Framework 的硬件选择非常有限。

很棒的平台，对于小型项目来说，它会很棒。但是，当您尝试处理近乎实时的需求时，您可能会遇到困难。

就像这个行业的其他许多事情一样，这取决于。但事实上你可以得到发展 不到 100 美元的套件可能值得检查。

---

我使用了来自 DeviceSolutions.Net 的 Tahoe-II 以及 .Net Micro Framework 2.0/3.0 和 C#。线程非常简单，但框架目前非常有限。我必须创建自己的 HTTP 解析器并创建粗糙的 RESTful 网络服务。有一个设备 Web 服务模型，但我想要纯 HTTP。我还必须创建自己的 SNTP 和 SMTP 协议层。一个新版本 (4.0) 应该很快就会发布，它可能会填补其中的一些不足。