源代码可用性：Linux 支持者可能会说，由于缺乏源代码，CE 是一个糟糕的选择。我只能说，在使用 CE 的十多年中，其中一半花在为定制板进行定制内核和驱动程序工作上，我只需要不随 CE 一起提供的源代码（他们提供了大量的源代码）我也喜欢有源代码，但是微软提供了支持，所以在极少数情况下，您可能认为您需要该源代码，您可以让他们来解决问题（有一次我们需要源代码，微软提供了修复程序） ，并且免费 - 这是他们在 CE 下的模型。
这是否意味着CE每次都会获胜？ 不，我根本不会建议这样做。 如果您是一家 Linux 商店，并且拥有大量 Linux 经验和代码资产，那么您就跑去使用 CE 是愚蠢的。 然而，如果您从头开始，CE 通常具有较低的 TCO。 具有 Win32/C# 经验的开发人员更为普遍，因此成本也更低。 与大多数其他发行版相比，您还可以通过 CE 获得更多“内置”功能，这意味着如果您还没有在内部完成这些事情，则可以更快地进入市场。
I worked for several years at a company that provided both CE and Linux for all of their hardware, so I'm fairly familiar with both sides of this equation.
Tools: Windows CE tools certainly are better than those provided by Linux, though the linux tools are certainly getting better.
Performance: Windows CE is real-time. Linux is not. The linux kernel is not designed for determinism at all. There are extensions that you can add to get sort-of real time, but CE beats it.
Cost: This is an area of great misunderstanding. My general experience is that CE is lower cost out of the box ($1k for Platform Builder and as low as $3 per device for a shipping runtime. "What?" you ask? "Linux is free." Well, not really so much, especially in the embedded arena. Yes, there are free distributions like Debian. But there are plenty of pieces that you might need that aren't in that free category. UI frameworks like QT, Java runtimes and media codecs just as a start. Also, most Linux distributions with a commercially-backed support system (e.g. MontaVista) are far from free.
Source Availability: Linux proponents may like to say that CE is a bad choice due to lack of source code. All I can say is that in over a decade of working with CE, half of which spent doing custom kernel and driver work for custom boards, I've only ever had need for source that didn't ship with CE (they ship a vast majority of it) once. I like having source too, but Microsoft provides support, so in the rare case you might think you need that source, you can get them to fix the problem (the one time we needed source, Microsoft provided a fix, and for free - which is their model under CE.
Does this mean that CE wins every time? No. I wouldn't suggest that at all. If you are a Linux shop and you have lots of Linux experience and code assets, you'd be foolish to run out and go CE. However, if you're coming into it from scratch CE usually has a lower TCO. Developers with Win32/C# experience are more prevalent and consequently less expensive. You also get a lot more "in the box" with CE than most other distributions, meaning faster time to market if you don't already have these things done in-house already.
I'll speak for the Linux side, at least for the category of software I'm familiar with (which is RF data collection equipment). Or industrial apps vs. consumer apps.
Windows CE (and its associated tools) IMH fairly recent E) is strongly biased to creating a "Windows Experience" on a small screen. The user input mode emphasizes mouse-like actions. Logons, application selection, etc. all try to be as similar to standard Windows as possible.
If a user is driving a lift truck, or filling a picking cart, or moving material from one place to another, there's a problem.
And it's a moving target - particularly on the .NET side. The Compact .NET runtime is seriously handicapped, and important libraries (like networking, data handling, and UI) are incomplete and versions too often deprecate the previous version. . CE seems to be the stepchild in the Windows family (possibly because there's not a lot of active competition selling to the hardware integrators.)
A nice stable rows-and-columns Linux console is a pretty handy context for many (in my experience most) high-use apps on a dinky screen.
Not much good for games on your cell-phone or Zune, though.
NOTE:
I think ctacke probably speaks accurately for the hardware integrator's side. I'm more aligned with the players further down the pipe - software integrators and users.
嵌入式处理器变得越来越复杂。 仅仅让 CPU 运行已经不够了。 如果您考虑 TI 的 OMAP3 cpu 系列，那么您必须问以下问题：是否有可用于 3D 加速引擎的库，我是否可以在不承诺每年数百万台的情况下获得它们？ 是否支持 DSP 桥接器？ 这一切的代价是什么？ 在我最近参与的一个项目中，Atmel AT91SAM9260 的基本 WinCE BSP 成本为 7000 美元。 就开发人员时间而言，这并不算多，但您还必须考虑维护、升级到新版本操作系统等的持续成本。
应用程序开发
嵌入式 Linux 和 WinCE支持一系列应用程序库和编程语言。 C 和 C++ 得到了很好的支持。 在 WinCE 世界中，大多数业务类型应用程序正在转向 C#。 Linux 有 Mono，它为 .NET 技术提供了广泛的支持，并且在嵌入式 Linux 系统中运行得很好。 有许多可用于嵌入式 Linux 的 Java 开发环境。 您确实会遇到差异的一个领域是图形库。 一般来说，Microsoft 图形 API 在 Linux 上得不到很好的支持，因此，如果您有一个大型应用程序团队，都是顽固的 Windows GUI 程序员，那么也许 WinCE 是有意义的。 然而，GUI 工具包有很多选项可以在 Windows PC 和嵌入式 Linux 设备上运行。 一些示例包括 GTK+、Qt、wxWidgets 等。Gimp 是在 Windows 上运行的 GTK+ 应用程序的示例，此外还有许多其他应用程序。 它们是与 GTK+ 和 Qt 的 C# 绑定。 WinCE 领域的另一个强大功能是 Windows Communication Foundation (WCF)。 但同样，有一些项目可以将 WCF 引入 Mono，具体取决于您需要哪些部分。 嵌入式Linux对Python等脚本语言的支持非常好，Python在200MHz ARM处理器上运行得很好。
人们常常认为 WinCE 是实时的，而 Linux 不是。 Linux 实时支持在带有 PREEMPT 选项的库存内核中表现不错，并且通过添加相对较小的实时补丁，实时支持也非常出色。 使用 Linux 可以轻松实现亚毫秒级计时。 随着实时功能合并到现有内核中，这种情况在过去几年中发生了变化。
开发流程
在生产环境中，最先进的嵌入式应用程序是在 PC（而不是目标硬件）上开发和调试的。 即使在目标系统上的远程调试效果良好的设置中，在工作站上调试应用程序也效果更好。 因此，一种解决方案具有良好的目标调试功能，而另一种解决方案则没有，这一事实并不真正相关。 对于以数据为中心的系统，通常具有模拟模式，可以在不连接到真实 I/O 的情况下测试应用程序。 对于 Linux 和 WinCE 应用程序，嵌入式设备的应用程序编程类似于 PC 的编程。 嵌入式Linux 更进一步。 由于嵌入式Linux技术与桌面和服务器Linux技术相同，因此几乎所有为桌面/服务器开发的东西（包括系统软件）都可以免费用于嵌入式。 这意味着非常完整的驱动程序支持（请参阅上面的 USB 蜂窝调制解调器和打印机示例）、强大的文件系统支持、内存管理等。Linux 的选项范围令人震惊，但有些人可能认为这是一个缺点，并且更喜欢更丰富的选项。集成解决方案，如 Windows CE，一切都来自一个地方。 虽然会损失灵活性，但在某些情况下，这种权衡可能是值得的。 有关可以使用 Openembedded 为嵌入式 Linux 系统构建的软件包数量的示例，请参阅。
GUI 趋势
考虑由手机（iPhone、Palm Pre 等）驱动的带有小显示屏的嵌入式设备的趋势非常重要。 桌面系统中常见的标准 GUI 小部件（对话框、复选框、下拉列表等）不适用于现代嵌入式系统。 因此，考虑对 3D 效果的支持以及设计供触摸屏设备使用的小部件库非常重要。 Clutter 库就是此类支持的一个示例。
Choice is often made largely on perception and culture, rather than concrete data. And, making a choice based on concrete data is difficult when you consider the complexity of a modern OS, all the issues associated with porting it to custom hardware, and unknown future requirements. Even from an application perspective, things change over the life of a project. Requirements come and go. You find yourself doing things you never thought you would, especially if they are possible. The ubiquitous USB and network ports open a lot of possibilities -- for example adding Cell modem support or printer support. Flash based storage makes in-field software updates the standard mode of operation. And in the end, each solution has its strengths and weaknesses -- there is no magic bullet that is the best in all cases.
When considering Embedded Linux development, I often use the iceberg analogy; what you see going into a project is the part above the water. These are the pieces your application interacts with, drivers you need to customize, the part you understand. The other 90% is under water, and herein lies a great deal of variability. Quality issues with drivers or not being able to find a driver for something you may want to support in the future can easily swamp known parts of the project. There are very few people who have a lot of experience with both WinCE and Linux solutions, hence the tendency to go with what is comfortable (or what managers are comfortable with), or what we have experience with. Below are thoughts on a number of aspects to consider:
SYSTEM SOFTWARE DEVELOPMENT
Questions in this realm include CPU support, driver quality, in field software updates, filesystem support, driver availability, etc. One of the changes that has happened in the past two years, is CPU vendors are now porting Linux to their new chips as the first OS. Before, the OS porting was typically done by Linux software companies such as MontaVista, or community efforts. As a result, the Linux kernel now supports most mainstream embedded cpus with few additional patches. This is radically different than the situation 5 years ago. Because many people are using the same source code, issues get fixed, and often are contributed back to the mainstream source. With WinCE, the BSP/driver support tends to be more of a reference implementation, and then OEM/users take it, fix any issues, and that is where the fixes tend to stay.
From a system perspective, it is very important to consider flexibility for future needs. Just because it is not a requirement now does not mean it will not be a requirement in the future. Obtaining driver support for a peripheral may be nearly impossible, or be too large an effort to make it practical.
Most people give very little thought to the build system, or never look much beyond the thought that "if there is a nice gui wrapped around the tool, it must be easy". OpenEmbedded is very popular way to build embedded Linux products, and has recently been endorsed as the technology base of MontaVista's Linux 6 product, and is generally considered "hard to use" by new users. While WinCE build tools look simpler on the surface (the 10% above water), you still have the problem of what happens when I need to customize something, implement complex features such as software updates, etc. To build a production system with production grade features, you still need someone on your team who understands the OS and can work at the detail level of both the operating system, and the build system. With either WinCE or Embedded Linux, this generally means companies either need to have experienced developers in house, or hire experts to do portions of the system software development. System software development is not the same as application development, and is generally not something you want to take on with no experience unless you have a lot of time. It is quite common for companies to hire expert help for the first couple projects, and then do follow-on projects in-house. Another feature to consider is parallel build support. With quad core workstations becoming the standard, is it a big deal that a full build can be done in 1.2 hours versus 8? How flexible is the build system at pulling and building source code from various sources such as diverse revision control systems, etc.
Embedded processors are becoming increasingly complex. It is no longer good enough to just have the cpu running. If you consider the OMAP3 cpu family from TI, then you have to ask the following questions: are there libraries available for the 3D acceleration engine, and can I even get them without being committing to millions of units per year? Is there support for the DSP bridge? What is the cost of all this? On a recent project I was involved in, a basic WinCE BSP for the Atmel AT91SAM9260 cost $7000. In terms of developer time, this is not much, but you have to also consider the on-going costs of maintenance, upgrading to new versions of the operating system, etc.
APPLICATION DEVELOPMENT
Both Embedded Linux and WinCE support a range of application libraries and programming languages. C and C++ are well supported. Most business type applications are moving to C# in the WinCE world. Linux has Mono, which provides extensive support for .NET technologies and runs very well in embedded Linux systems. There are numerous Java development environments available for Embedded Linux. One area where you do run into differences is graphics libraries. Generally the Microsoft graphical APIs are not well supported on Linux, so if you have a large application team that are die-hard windows GUI programmers, then perhaps WinCE makes sense. However, there are many options for GUI toolkits that run on both Windows PCs and Embedded Linux devices. Some examples include GTK+, Qt, wxWidgets, etc. The Gimp is an example of a GTK+ application that runs on windows, plus there are many others. The are C# bindings to GTK+ and Qt. Another feature that seems to be coming on strong in the WinCE space is the Windows Communication Foundation (WCF). But again, there are projects to bring WCF to Mono, depending what portions you need. Embedded Linux support for scripting languages like Python is very good, and Python runs very well on 200MHz ARM processors.
There is often the perception that WinCE is realtime, and Linux is not. Linux realtime support is decent in the stock kernels with the PREEMPT option, and real-time support is excellent with the addition of a relatively small real-time patch. You can easily attain sub millisecond timing with Linux. This is something that has changed in the past couple years with the merging of real-time functionality into the stock kernel.
DEVELOPMENT FLOW
In a productive environment, most advanced embedded applications are developed and debugged on a PC, not the target hardware. Even in setups where remote debugging on a target system works well, debugging an application on workstation works better. So the fact that one solution has nice on-target debugging, where the other does not is not really relevant. For data centric systems, it is common to have simulation modes where the application can be tested without connection to real I/O. With both Linux and WinCE applications, application programing for an embedded device is similar to programming for a PC. Embedded Linux takes this a step further. Because embedded Linux technology is the same as desktop, and server Linux technology, almost everything developed for desktop/server (including system software) is available for embedded for free. This means very complete driver support (see USB cell modem and printer examples above), robust file system support, memory management, etc. The breadth of options for Linux is astounding, but some may consider this a negative point, and would prefer a more integrated solution like Windows CE where everything comes from one place. There is a loss of flexibility, but in some cases, the tradeoff might be worth it. For an example of the number of packages that can be build for Embedded Linux systems using Openembedded, see.
GUI TRENDS
It is important to consider trends for embedded devices with small displays being driven by Cell Phones (iPhone, Palm Pre, etc). Standard GUI widgets that are common in desktop systems (dialog boxes, check boxes, pull down lists, etc) do not cut it for modern embedded systems. So, it will be important to consider support for 3D effects, and widget libraries designed to be used by touch screen devices. The Clutter library is an example of this type of support.
REMOTE SUPPORT
Going back to the issue of debugging tools, most people stop at the scenario where the device is setting next to a workstation in the lab. But what about when you need to troubleshoot a device that is being beta-tested half-way around the world? That is where a command-line debugger like Gdb is an advantage, and not a disadvantage. And how do you connect to the device if you don't have support for cell modems in New Zealand, or an efficient connection mechanism like ssh for shell access and transferring files?
SUMMARY
Selecting any advanced technology is not a simple task, and is fairly difficult to do even with experience. So it is important to be asking the right questions, and looking at the decision from many angles. Hopefully this article can help in that.
我参与过涉及定制 OEM 板软件的项目，我不会说 Linux 更便宜。 购买开发板时还需要购买SDK。 即使是 Linux 版本，您仍然需要付费。 一些制造商为其主板提供 Windows CE 和 Linux 解决方案，并且价格没有差异。 对于 Windows CE，您还需要 Platform Builder 并支付许可证费用，但没有支持会更容易。
另一个重要问题是您是否正在构建用户界面或无头设备。 对于需要 LCD 屏幕和人机交互的设备，使用 Windows CE 会更容易。 另一方面，如果您正在构建无头设备，Linux 可能是一个更合理的选择 - 特别是在涉及网络协议的情况下。 我相信 Linux 实现更可靠并且更容易调整。
I have worked in projects that involved customizing the software of an OEM board and I wouldn't say that Linux is cheaper. When buying a board you also need to buy the SDK. You still need to pay even for the Linux version. Some manufacturers offer both Windows CE and Linux solutions for their boards and there isn't a price difference. For Windows CE you also need the Platform Builder and pay for the licenses, but it is easier to go without support.
Another important issue is if you are building a User Interface or a headless device. For devices that require an LCD screen and human interaction is much easier to go with Windows CE. If on the other hand you are building a headless device, Linux may be a sounder option - especially if network protocols are involved. I believe that Linux implementations are more reliable and easier to tweak.
With Linux you are never on you own and you are never dependent on one single entity to provide permissions. There are many support options and you have the freedom to choose your support options for any part of the system through many competing sources.
With Windows CE you must adhere to the license and restrictions as set forth in the complex license agreements that must be agreed to. Get a lawyer. With windows CE you have only one proprietary source for OS support and you will proceed only as they see fit to support and provide what you need. You may not agree with their position, but will not have any recourse but to bend to what they prescribe. The costs of incremental components, modules, development kits, licensing, and support tend to pile up with proprietary platforms. In the longer term, what happens when the vendor no longer desires to support the platform and you do not have the rights to support and distribute it yourself? What happens when the vendor moves to newer technology and wants you to move along with them even though you may not be ready to make the move? $$$
Our experience with Windows solutions in general is that they tend to become more expensive over time. What was originally considered lowest TCO gravitates quickly towards and solution that is encumbered and costly to maintain and support. Licenses have to be re-negotiated over time and the new technologies, often unneeded, are forced into the picture at the whim of the provider for the sake of THEIR business needs. On top of that, the license agreements are CONTINUALLY changing--get a lawyer.
With Linux you have the freedom to provide in-house support and expertise without being encumbered against distributing the solution as you need. You also have the freedom to continue to use and support technology that original providers no longer want to support. Having the source code and the RIGHTs to do with it what you want (GPL, LGPL) is a powerful attractor when it comes to business continuity and containing costs while providing access to the very latest technologies or technologies that fit your needs.
我开发了可以在 RT Linux（更具体地说，带有 RT 补丁的 Linux 抢占式内核）和 Windows CE 上运行的网络驱动程序。 我的经验是windows CE在实时响应方面更稳定。 帧计时还表明 Windows CE 的抖动较小。
在 RT Linux 上，我们遇到了各种各样的问题。 例如，当用户移动鼠标时； 我们的帧被延迟了。 你猜怎么着，x-windows 的某些变体禁用了中断。 您可能还觉得仅在控制台屏幕上更安全。 如果您启用了 VGA 帧缓冲区，您将再次陷入困境。 我们在使用 Windows CE 时再次遇到了一个抖动问题。 当 USB 控制器在 BIOS 中设置为不正确的模式并且 Windows CE 使用大量时间进行轮询时，就会出现此问题。
说实话，windows CE的支持更多。 在 Linux 上，你只能靠自己了。 您必须阅读所有可能的邮件列表，以了解您可能遇到的问题。
I have developed network drivers that work both on RT Linux (to be more specific, Linux preemptive kernel with RT patch) and Windows CE. My experience was windows CE was more stable in terms of real-time response. Frame timings also showed that windows CE had less jitter.
On RT Linux, we had all sorts of problems. For example, when user moved the mouse; our frames were being delayed. Guess what, certain variants of x-windows disable interrupts. You may also feel that you are safer on console screen only. If you have VGA frame buffers enabled, you are doomed again. We had only one problem with windows CE in terms of jitter again. The problem happened when the USB controller was set to an incorrect mode in the BIOS and windows CE was using lots of time for polling.
To be honest, windows CE had more support. On Linux, you are on your own. You have to read every possible mailing list to understand what problems you may hve.
Android is a good option for some embedded systems.(it's linux based)
You have many experts that are able to develop on this system.
You have access to many libraries in java or C.
but it uses lot of memory and energy.
What we often forget with paid / licenced software is that you have to deal with licenses. It takes time and energy! Then you have to track if you pay it correctly. It involves many different people with different skills and it costs in decision.
This cost is often not included in the studies that show that open-source/free is more expensive than paid software.
With "free software" it's way easier to deal with licenses and you spend less time on dealing with these issues. Personally I prefer to avoid unnecessary communications with your legal / financing team every time you change some pieces of the software.
发布评论
评论（8）
我在一家为所有硬件提供 CE 和 Linux 的公司工作了几年，所以我对这个等式的两边都相当熟悉。
这是否意味着CE每次都会获胜？ 不，我根本不会建议这样做。 如果您是一家 Linux 商店，并且拥有大量 Linux 经验和代码资产，那么您就跑去使用 CE 是愚蠢的。 然而，如果您从头开始，CE 通常具有较低的 TCO。 具有 Win32/C# 经验的开发人员更为普遍，因此成本也更低。 与大多数其他发行版相比，您还可以通过 CE 获得更多“内置”功能，这意味着如果您还没有在内部完成这些事情，则可以更快地进入市场。
I worked for several years at a company that provided both CE and Linux for all of their hardware, so I'm fairly familiar with both sides of this equation.
Does this mean that CE wins every time? No. I wouldn't suggest that at all. If you are a Linux shop and you have lots of Linux experience and code assets, you'd be foolish to run out and go CE. However, if you're coming into it from scratch CE usually has a lower TCO. Developers with Win32/C# experience are more prevalent and consequently less expensive. You also get a lot more "in the box" with CE than most other distributions, meaning faster time to market if you don't already have these things done in-house already.
我将代表 Linux 方面发言，至少代表我熟悉的软件类别（即 RF 数据采集设备）。 或者工业应用程序与消费者应用程序。
Windows CE（及其相关工具）IMH 最近的 E）强烈偏向于在小屏幕上创建“Windows 体验”。 用户输入模式强调类似鼠标的操作。 登录、应用程序选择等都尽量与标准 Windows 相似。
如果用户正在驾驶叉车、装满拣选车或将物料从一个地方移动到另一个地方，就会出现问题。
这是一个不断变化的目标——尤其是在 .NET 方面。 Compact .NET 运行时存在严重缺陷，重要的库（如网络、数据处理和 UI）不完整，而且版本经常会弃用以前的版本。 。 CE 似乎是 Windows 家族中的继子（可能是因为没有太多积极的竞争向硬件集成商出售产品。）
一个良好稳定的行列 Linux 控制台对于许多人来说是一个非常方便的环境（根据我的经验，大多数）小屏幕上的高使用率应用程序。
不过，这对于手机或 Zune 上的游戏来说并没有多大好处。
注意：
我认为 ctacke 可能准确地代表了硬件集成商方面。 我更倾向于与下游的参与者——软件集成商和用户保持一致。
I'll speak for the Linux side, at least for the category of software I'm familiar with (which is RF data collection equipment). Or industrial apps vs. consumer apps.
Windows CE (and its associated tools) IMH fairly recent E) is strongly biased to creating a "Windows Experience" on a small screen. The user input mode emphasizes mouse-like actions. Logons, application selection, etc. all try to be as similar to standard Windows as possible.
If a user is driving a lift truck, or filling a picking cart, or moving material from one place to another, there's a problem.
And it's a moving target - particularly on the .NET side. The Compact .NET runtime is seriously handicapped, and important libraries (like networking, data handling, and UI) are incomplete and versions too often deprecate the previous version. . CE seems to be the stepchild in the Windows family (possibly because there's not a lot of active competition selling to the hardware integrators.)
A nice stable rows-and-columns Linux console is a pretty handy context for many (in my experience most) high-use apps on a dinky screen.
Not much good for games on your cell-phone or Zune, though.
NOTE:
I think ctacke probably speaks accurately for the hardware integrator's side. I'm more aligned with the players further down the pipe - software integrators and users.
选择通常主要取决于感知和文化，而不是具体数据。 而且，当您考虑现代操作系统的复杂性、与将其移植到定制硬件相关的所有问题以及未知的未来需求时，根据具体数据做出选择是很困难的。 即使从应用程序的角度来看，事情也会在项目的生命周期中发生变化。 需求来来去去。 你发现自己正在做一些你从未想过会做的事情，尤其是如果它们是可能的。 无处不在的 USB 和网络端口带来了很多可能性——例如添加 Cell 调制解调器支持或打印机支持。 基于闪存的存储使现场软件更新成为标准操作模式。 最后，每种解决方案都有其优点和缺点——没有一种灵丹妙药在所有情况下都是最好的。
在考虑嵌入式 Linux 开发时，我经常使用冰山比喻； 你在项目中看到的是水面以上的部分。 这些是您的应用程序与之交互的部分、您需要自定义的驱动程序、您理解的部分。 其余 90% 都在水下，这里存在很大的变化。 驱动程序的质量问题或无法找到您将来可能想要支持的内容的驱动程序很容易淹没项目的已知部分。 很少有人对 WinCE 和 Linux 解决方案都拥有丰富的经验，因此倾向于选择舒适的（或经理们熟悉的）或我们有经验的。 以下是需要考虑的多个方面的想法：
系统软件开发
此领域的问题包括 CPU 支持、驱动程序质量、现场软件更新、文件系统支持、驱动程序可用性等。过去两年发生的事情是，CPU 供应商现在将 Linux 作为第一个操作系统移植到他们的新芯片上。 此前，操作系统移植通常由 MontaVista 等 Linux 软件公司或社区共同完成。 因此，Linux 内核现在只需很少的额外补丁即可支持大多数主流嵌入式 cpu。 这与5年前的情况截然不同。 因为许多人使用相同的源代码，所以问题会得到解决，并且通常会被贡献回主流源。 对于 WinCE，BSP/驱动程序支持往往更多地是参考实现，然后 OEM/用户接受它，修复任何问题，这就是修复往往停留的地方。
从系统角度来看，考虑未来需求的灵活性非常重要。 现在不是要求并不意味着将来也不会是要求。 获得外围设备的驱动程序支持可能几乎是不可能的，或者需要付出巨大的努力才能使其实用。
大多数人很少考虑构建系统，或者从来不考虑“如果工具周围有一个漂亮的 GUI，那么它一定很容易”。 OpenEmbedded 是构建嵌入式 Linux 产品的非常流行的方式，最近被认可为 MontaVista Linux 6 产品的技术基础，但新用户普遍认为“难以使用”。 虽然 WinCE 构建工具表面上看起来更简单（水面以上 10%），但您仍然会遇到这样的问题：当我需要自定义某些内容、实现软件更新等复杂功能时会发生什么。构建具有生产级的生产系统功能，您仍然需要团队中有人了解操作系统并且可以在操作系统和构建系统的详细级别上工作。 对于 WinCE 或嵌入式 Linux，这通常意味着公司要么需要内部有经验丰富的开发人员，要么聘请专家来完成部分系统软件开发。 系统软件开发与应用程序开发不同，通常情况下，您不想在没有经验的情况下进行开发，除非您有很多时间。 对于公司来说，为前几个项目聘请专家帮助，然后在内部进行后续项目是很常见的。 另一个需要考虑的功能是并行构建支持。 随着四核工作站成为标准，完整的构建可以在 1.2 小时内完成，而不是 8 小时，这有什么大不了的吗？ 构建系统从各种来源（例如不同的版本控制系统等）提取和构建源代码的灵活性如何。
嵌入式处理器变得越来越复杂。 仅仅让 CPU 运行已经不够了。 如果您考虑 TI 的 OMAP3 cpu 系列，那么您必须问以下问题：是否有可用于 3D 加速引擎的库，我是否可以在不承诺每年数百万台的情况下获得它们？ 是否支持 DSP 桥接器？ 这一切的代价是什么？ 在我最近参与的一个项目中，Atmel AT91SAM9260 的基本 WinCE BSP 成本为 7000 美元。 就开发人员时间而言，这并不算多，但您还必须考虑维护、升级到新版本操作系统等的持续成本。
应用程序开发
嵌入式 Linux 和 WinCE支持一系列应用程序库和编程语言。 C 和 C++ 得到了很好的支持。 在 WinCE 世界中，大多数业务类型应用程序正在转向 C#。 Linux 有 Mono，它为 .NET 技术提供了广泛的支持，并且在嵌入式 Linux 系统中运行得很好。 有许多可用于嵌入式 Linux 的 Java 开发环境。 您确实会遇到差异的一个领域是图形库。 一般来说，Microsoft 图形 API 在 Linux 上得不到很好的支持，因此，如果您有一个大型应用程序团队，都是顽固的 Windows GUI 程序员，那么也许 WinCE 是有意义的。 然而，GUI 工具包有很多选项可以在 Windows PC 和嵌入式 Linux 设备上运行。 一些示例包括 GTK+、Qt、wxWidgets 等。Gimp 是在 Windows 上运行的 GTK+ 应用程序的示例，此外还有许多其他应用程序。 它们是与 GTK+ 和 Qt 的 C# 绑定。 WinCE 领域的另一个强大功能是 Windows Communication Foundation (WCF)。 但同样，有一些项目可以将 WCF 引入 Mono，具体取决于您需要哪些部分。 嵌入式Linux对Python等脚本语言的支持非常好，Python在200MHz ARM处理器上运行得很好。
人们常常认为 WinCE 是实时的，而 Linux 不是。 Linux 实时支持在带有 PREEMPT 选项的库存内核中表现不错，并且通过添加相对较小的实时补丁，实时支持也非常出色。 使用 Linux 可以轻松实现亚毫秒级计时。 随着实时功能合并到现有内核中，这种情况在过去几年中发生了变化。
开发流程
在生产环境中，最先进的嵌入式应用程序是在 PC（而不是目标硬件）上开发和调试的。 即使在目标系统上的远程调试效果良好的设置中，在工作站上调试应用程序也效果更好。 因此，一种解决方案具有良好的目标调试功能，而另一种解决方案则没有，这一事实并不真正相关。 对于以数据为中心的系统，通常具有模拟模式，可以在不连接到真实 I/O 的情况下测试应用程序。 对于 Linux 和 WinCE 应用程序，嵌入式设备的应用程序编程类似于 PC 的编程。 嵌入式Linux 更进一步。 由于嵌入式Linux技术与桌面和服务器Linux技术相同，因此几乎所有为桌面/服务器开发的东西（包括系统软件）都可以免费用于嵌入式。 这意味着非常完整的驱动程序支持（请参阅上面的 USB 蜂窝调制解调器和打印机示例）、强大的文件系统支持、内存管理等。Linux 的选项范围令人震惊，但有些人可能认为这是一个缺点，并且更喜欢更丰富的选项。集成解决方案，如 Windows CE，一切都来自一个地方。 虽然会损失灵活性，但在某些情况下，这种权衡可能是值得的。 有关可以使用 Openembedded 为嵌入式 Linux 系统构建的软件包数量的示例，请参阅。
GUI 趋势
考虑由手机（iPhone、Palm Pre 等）驱动的带有小显示屏的嵌入式设备的趋势非常重要。 桌面系统中常见的标准 GUI 小部件（对话框、复选框、下拉列表等）不适用于现代嵌入式系统。 因此，考虑对 3D 效果的支持以及设计供触摸屏设备使用的小部件库非常重要。 Clutter 库就是此类支持的一个示例。
远程支持
回到调试工具的问题，大多数人都会停留在设备设置在实验室工作站旁边的场景上。 但是，当您需要对正在世界各地进行 Beta 测试的设备进行故障排除时该怎么办？ 这就是像 Gdb 这样的命令行调试器的优点，而不是缺点。 如果您在新西兰不支持手机调制解调器，或者不支持 ssh 等用于 shell 访问和传输文件的高效连接机制，那么如何连接到设备？
摘要
选择任何先进技术都不是一件简单的任务，即使有经验也相当困难。 因此，提出正确的问题并从多个角度看待决策非常重要。 希望这篇文章能对此有所帮助。
Choice is often made largely on perception and culture, rather than concrete data. And, making a choice based on concrete data is difficult when you consider the complexity of a modern OS, all the issues associated with porting it to custom hardware, and unknown future requirements. Even from an application perspective, things change over the life of a project. Requirements come and go. You find yourself doing things you never thought you would, especially if they are possible. The ubiquitous USB and network ports open a lot of possibilities -- for example adding Cell modem support or printer support. Flash based storage makes in-field software updates the standard mode of operation. And in the end, each solution has its strengths and weaknesses -- there is no magic bullet that is the best in all cases.
When considering Embedded Linux development, I often use the iceberg analogy; what you see going into a project is the part above the water. These are the pieces your application interacts with, drivers you need to customize, the part you understand. The other 90% is under water, and herein lies a great deal of variability. Quality issues with drivers or not being able to find a driver for something you may want to support in the future can easily swamp known parts of the project. There are very few people who have a lot of experience with both WinCE and Linux solutions, hence the tendency to go with what is comfortable (or what managers are comfortable with), or what we have experience with. Below are thoughts on a number of aspects to consider:
SYSTEM SOFTWARE DEVELOPMENT
Questions in this realm include CPU support, driver quality, in field software updates, filesystem support, driver availability, etc. One of the changes that has happened in the past two years, is CPU vendors are now porting Linux to their new chips as the first OS. Before, the OS porting was typically done by Linux software companies such as MontaVista, or community efforts. As a result, the Linux kernel now supports most mainstream embedded cpus with few additional patches. This is radically different than the situation 5 years ago. Because many people are using the same source code, issues get fixed, and often are contributed back to the mainstream source. With WinCE, the BSP/driver support tends to be more of a reference implementation, and then OEM/users take it, fix any issues, and that is where the fixes tend to stay.
From a system perspective, it is very important to consider flexibility for future needs. Just because it is not a requirement now does not mean it will not be a requirement in the future. Obtaining driver support for a peripheral may be nearly impossible, or be too large an effort to make it practical.
Most people give very little thought to the build system, or never look much beyond the thought that "if there is a nice gui wrapped around the tool, it must be easy". OpenEmbedded is very popular way to build embedded Linux products, and has recently been endorsed as the technology base of MontaVista's Linux 6 product, and is generally considered "hard to use" by new users. While WinCE build tools look simpler on the surface (the 10% above water), you still have the problem of what happens when I need to customize something, implement complex features such as software updates, etc. To build a production system with production grade features, you still need someone on your team who understands the OS and can work at the detail level of both the operating system, and the build system. With either WinCE or Embedded Linux, this generally means companies either need to have experienced developers in house, or hire experts to do portions of the system software development. System software development is not the same as application development, and is generally not something you want to take on with no experience unless you have a lot of time. It is quite common for companies to hire expert help for the first couple projects, and then do follow-on projects in-house. Another feature to consider is parallel build support. With quad core workstations becoming the standard, is it a big deal that a full build can be done in 1.2 hours versus 8? How flexible is the build system at pulling and building source code from various sources such as diverse revision control systems, etc.
Embedded processors are becoming increasingly complex. It is no longer good enough to just have the cpu running. If you consider the OMAP3 cpu family from TI, then you have to ask the following questions: are there libraries available for the 3D acceleration engine, and can I even get them without being committing to millions of units per year? Is there support for the DSP bridge? What is the cost of all this? On a recent project I was involved in, a basic WinCE BSP for the Atmel AT91SAM9260 cost $7000. In terms of developer time, this is not much, but you have to also consider the on-going costs of maintenance, upgrading to new versions of the operating system, etc.
APPLICATION DEVELOPMENT
Both Embedded Linux and WinCE support a range of application libraries and programming languages. C and C++ are well supported. Most business type applications are moving to C# in the WinCE world. Linux has Mono, which provides extensive support for .NET technologies and runs very well in embedded Linux systems. There are numerous Java development environments available for Embedded Linux. One area where you do run into differences is graphics libraries. Generally the Microsoft graphical APIs are not well supported on Linux, so if you have a large application team that are die-hard windows GUI programmers, then perhaps WinCE makes sense. However, there are many options for GUI toolkits that run on both Windows PCs and Embedded Linux devices. Some examples include GTK+, Qt, wxWidgets, etc. The Gimp is an example of a GTK+ application that runs on windows, plus there are many others. The are C# bindings to GTK+ and Qt. Another feature that seems to be coming on strong in the WinCE space is the Windows Communication Foundation (WCF). But again, there are projects to bring WCF to Mono, depending what portions you need. Embedded Linux support for scripting languages like Python is very good, and Python runs very well on 200MHz ARM processors.
There is often the perception that WinCE is realtime, and Linux is not. Linux realtime support is decent in the stock kernels with the PREEMPT option, and real-time support is excellent with the addition of a relatively small real-time patch. You can easily attain sub millisecond timing with Linux. This is something that has changed in the past couple years with the merging of real-time functionality into the stock kernel.
DEVELOPMENT FLOW
In a productive environment, most advanced embedded applications are developed and debugged on a PC, not the target hardware. Even in setups where remote debugging on a target system works well, debugging an application on workstation works better. So the fact that one solution has nice on-target debugging, where the other does not is not really relevant. For data centric systems, it is common to have simulation modes where the application can be tested without connection to real I/O. With both Linux and WinCE applications, application programing for an embedded device is similar to programming for a PC. Embedded Linux takes this a step further. Because embedded Linux technology is the same as desktop, and server Linux technology, almost everything developed for desktop/server (including system software) is available for embedded for free. This means very complete driver support (see USB cell modem and printer examples above), robust file system support, memory management, etc. The breadth of options for Linux is astounding, but some may consider this a negative point, and would prefer a more integrated solution like Windows CE where everything comes from one place. There is a loss of flexibility, but in some cases, the tradeoff might be worth it. For an example of the number of packages that can be build for Embedded Linux systems using Openembedded, see.
GUI TRENDS
It is important to consider trends for embedded devices with small displays being driven by Cell Phones (iPhone, Palm Pre, etc). Standard GUI widgets that are common in desktop systems (dialog boxes, check boxes, pull down lists, etc) do not cut it for modern embedded systems. So, it will be important to consider support for 3D effects, and widget libraries designed to be used by touch screen devices. The Clutter library is an example of this type of support.
REMOTE SUPPORT
Going back to the issue of debugging tools, most people stop at the scenario where the device is setting next to a workstation in the lab. But what about when you need to troubleshoot a device that is being beta-tested half-way around the world? That is where a command-line debugger like Gdb is an advantage, and not a disadvantage. And how do you connect to the device if you don't have support for cell modems in New Zealand, or an efficient connection mechanism like ssh for shell access and transferring files?
SUMMARY
Selecting any advanced technology is not a simple task, and is fairly difficult to do even with experience. So it is important to be asking the right questions, and looking at the decision from many angles. Hopefully this article can help in that.
我参与过涉及定制 OEM 板软件的项目，我不会说 Linux 更便宜。 购买开发板时还需要购买SDK。 即使是 Linux 版本，您仍然需要付费。 一些制造商为其主板提供 Windows CE 和 Linux 解决方案，并且价格没有差异。 对于 Windows CE，您还需要 Platform Builder 并支付许可证费用，但没有支持会更容易。
另一个重要问题是您是否正在构建用户界面或无头设备。 对于需要 LCD 屏幕和人机交互的设备，使用 Windows CE 会更容易。 另一方面，如果您正在构建无头设备，Linux 可能是一个更合理的选择 - 特别是在涉及网络协议的情况下。 我相信 Linux 实现更可靠并且更容易调整。
I have worked in projects that involved customizing the software of an OEM board and I wouldn't say that Linux is cheaper. When buying a board you also need to buy the SDK. You still need to pay even for the Linux version. Some manufacturers offer both Windows CE and Linux solutions for their boards and there isn't a price difference. For Windows CE you also need the Platform Builder and pay for the licenses, but it is easier to go without support.
Another important issue is if you are building a User Interface or a headless device. For devices that require an LCD screen and human interaction is much easier to go with Windows CE. If on the other hand you are building a headless device, Linux may be a sounder option - especially if network protocols are involved. I believe that Linux implementations are more reliable and easier to tweak.
使用 Linux，您永远不会独善其身，也永远不会依赖于一个实体来提供权限。 有许多支持选项，您可以通过许多竞争来源自由地为系统的任何部分选择支持选项。
使用 Windows CE，您必须遵守必须同意的复杂许可协议中规定的许可和限制。 找个律师。 对于 Windows CE，您只有一种专有的操作系统支持来源，并且您只能在他们认为合适的情况下继续支持并提供您所需的内容。 你可以不同意他们的立场，但除了屈服于他们的规定之外别无选择。 增量组件、模块、开发套件、许可和支持的成本往往会随着专有平台的增加而增加。 从长远来看，当供应商不再希望支持该平台并且您无权自行支持和分发时会发生什么？ 当供应商转向更新的技术并希望您与他们一起前进时，即使您可能还没有准备好采取行动，会发生什么？ $$$
我们对 Windows 解决方案的总体经验是，随着时间的推移，它们往往会变得更加昂贵。 最初被认为是最低 TCO 的解决方案很快就转向了维护和支持起来很麻烦且成本高昂的解决方案。 随着时间的推移，许可证必须重新协商，而新技术（通常是不需要的）是出于提供商的业务需求而被迫加入的。 最重要的是，许可协议不断变化——请律师。
借助 Linux，您可以自由地提供内部支持和专业知识，而无需根据需要分发解决方案。 您还可以自由地继续使用和支持原始提供商不再愿意支持的技术。 当涉及到业务连续性和控制成本，同时提供对最新技术或满足您需求的技术的访问时，拥有源代码和使用它做您想做的事情的权利（GPL、LGPL）是一个强大的吸引力。
With Linux you are never on you own and you are never dependent on one single entity to provide permissions. There are many support options and you have the freedom to choose your support options for any part of the system through many competing sources.
With Windows CE you must adhere to the license and restrictions as set forth in the complex license agreements that must be agreed to. Get a lawyer. With windows CE you have only one proprietary source for OS support and you will proceed only as they see fit to support and provide what you need. You may not agree with their position, but will not have any recourse but to bend to what they prescribe. The costs of incremental components, modules, development kits, licensing, and support tend to pile up with proprietary platforms. In the longer term, what happens when the vendor no longer desires to support the platform and you do not have the rights to support and distribute it yourself? What happens when the vendor moves to newer technology and wants you to move along with them even though you may not be ready to make the move? $$$
Our experience with Windows solutions in general is that they tend to become more expensive over time. What was originally considered lowest TCO gravitates quickly towards and solution that is encumbered and costly to maintain and support. Licenses have to be re-negotiated over time and the new technologies, often unneeded, are forced into the picture at the whim of the provider for the sake of THEIR business needs. On top of that, the license agreements are CONTINUALLY changing--get a lawyer.
With Linux you have the freedom to provide in-house support and expertise without being encumbered against distributing the solution as you need. You also have the freedom to continue to use and support technology that original providers no longer want to support. Having the source code and the RIGHTs to do with it what you want (GPL, LGPL) is a powerful attractor when it comes to business continuity and containing costs while providing access to the very latest technologies or technologies that fit your needs.
我开发了可以在 RT Linux（更具体地说，带有 RT 补丁的 Linux 抢占式内核）和 Windows CE 上运行的网络驱动程序。 我的经验是windows CE在实时响应方面更稳定。 帧计时还表明 Windows CE 的抖动较小。
在 RT Linux 上，我们遇到了各种各样的问题。 例如，当用户移动鼠标时； 我们的帧被延迟了。 你猜怎么着，x-windows 的某些变体禁用了中断。 您可能还觉得仅在控制台屏幕上更安全。 如果您启用了 VGA 帧缓冲区，您将再次陷入困境。 我们在使用 Windows CE 时再次遇到了一个抖动问题。 当 USB 控制器在 BIOS 中设置为不正确的模式并且 Windows CE 使用大量时间进行轮询时，就会出现此问题。
说实话，windows CE的支持更多。 在 Linux 上，你只能靠自己了。 您必须阅读所有可能的邮件列表，以了解您可能遇到的问题。
I have developed network drivers that work both on RT Linux (to be more specific, Linux preemptive kernel with RT patch) and Windows CE. My experience was windows CE was more stable in terms of real-time response. Frame timings also showed that windows CE had less jitter.
On RT Linux, we had all sorts of problems. For example, when user moved the mouse; our frames were being delayed. Guess what, certain variants of x-windows disable interrupts. You may also feel that you are safer on console screen only. If you have VGA frame buffers enabled, you are doomed again. We had only one problem with windows CE in terms of jitter again. The problem happened when the USB controller was set to an incorrect mode in the BIOS and windows CE was using lots of time for polling.
To be honest, windows CE had more support. On Linux, you are on your own. You have to read every possible mailing list to understand what problems you may hve.
如果操作系统是开源的（并且您拥有专业知识），则
Is much easier to achieve if the OS is open source (and you have the expertise).
对于某些嵌入式系统来说，Android 是一个不错的选择。（它是基于 Linux 的）
你们有很多专家可以在这个系统上进行开发。
您可以访问 java 或 C 中的许多库。
但它会占用大量内存和能量。
对于付费/许可软件，我们经常忘记的是您必须处理许可证。 这需要时间和精力！ 然后你必须跟踪你是否正确付款。 它涉及许多具有不同技能的不同人，并且决策成本很高。
这项成本通常不包括在表明开源/免费软件比付费软件更昂贵的研究中。
使用“自由软件”，可以更轻松地处理许可证，并且您可以花更少的时间来处理这些问题。 就我个人而言，我更愿意避免每次更改软件的某些部分时与法律/财务团队进行不必要的沟通。
Android is a good option for some embedded systems.(it's linux based)
You have many experts that are able to develop on this system.
You have access to many libraries in java or C.
but it uses lot of memory and energy.
What we often forget with paid / licenced software is that you have to deal with licenses. It takes time and energy! Then you have to track if you pay it correctly. It involves many different people with different skills and it costs in decision.
This cost is often not included in the studies that show that open-source/free is more expensive than paid software.
With "free software" it's way easier to deal with licenses and you spend less time on dealing with these issues. Personally I prefer to avoid unnecessary communications with your legal / financing team every time you change some pieces of the software.