适用于 Windows CE 和 Windows 桌面的 PCIe 驱动程序

发布于 2024-12-04 16:36:09 字数 470 浏览 1 评论 0原文

我需要一些建议来开发自定义PCIE驱动程序。驱动程序必须支持Windows CE 6.0和Windows桌面(准备就绪时XP,7和8)。

我们有很多为Windows CE开发驱动程序的经验,但没有用于Windows桌面的驱动程序。我很确定我们可以开发出一个良好的固体Windows CE驱动程序,但是我认为,如果没有一些外部帮助,我们将无法为Windows桌面做同样的事情。我认为我们有两个选择:

1)使用现有的驱动程序框架,例如Jungo Windriver,这使我们可以开发一次驱动程序并将其编译为Mulitiple平台。这也具有一个优势:大多数开发都将在用户空间中,因此它应该使开发过程变得更加简单。

2)获得一些外部帮助,以设置一个良好的Windows桌面驱动程序,其中所有管道都完成了,我们只需要添加与我们的董事会通信并暴露相关的Iocontrols的代码。也许将代码尽可能多地移动到用户空间库中。

每种选项的好处和缺点是什么?您会推荐其他方法吗?

I need a little advice for development of a custom PCIe driver. The driver must support both Windows CE 6.0 and Windows Desktop (xp, 7, and 8 when ready).

We have a lot of experience developing drivers for Windows CE but none for Windows Desktop. I am pretty sure that we can develop a good, solid Windows CE driver, but I think we will not be able to do the same for Windows Desktop without some external help. I think that we have two options:

1) Use an existing driver framework such as Jungo WinDriver, which allows us to develop the driver once and compile to mulitiple platforms. This also has the advantage that most of the development will be in user space, so it should make the development process simpler.

2) Get some external help to setup a good Windows Desktop driver where all the plumbing is done and we simply need to add the code that communicates with our board and expose relevant IOControls. Perhaps move as much as possible of the code into a user space library.

What would be the benefits and downsides of each option? Would you recommend alternative approaches?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

暮年慕年 2024-12-11 16:36:09

按照不久前的要求,在我提出最初的问题一年多后,我将尝试分享我的经验。我们决定使用Windriver,但到目前为止我们只编写了Windows CE 6.0的驱动程序,所以我无法评论跨平台支持。

在Windows CE 6.0 上使用Windriver 有优点也有缺点。这意味着我们所有的驱动程序代码现在都在库中,因此更容易开发和调试(与需要 Platform Builder 的标准驱动程序相比)。所以从发展的角度来看,这很好。表现也一直不错。开始学习 Windriver API 以及如何使用它会产生一些开销,特别是 DMA 和中断,但我认为这并不比学习原始的 Windows CE 6.0 PCI API 更糟糕。

我能想到的唯一真正的缺点是“真正的”驱动程序比我们使用 Windriver 创建的库更容易在多个进程之间共享。在我们的应用程序(具有一个进程的嵌入式系统)中,这实际上并不是一个问题,但创建在主进程后面的硬件上运行的调试/开发实用程序比较困难。我们已经使用这种方法在其他平台上进行测试/调试,但在这里执行起来有点复杂。

总而言之,我认为我们做出了正确的选择,并且我很高兴我们能够在需要时轻松地将我们的“驱动程序”移植到 Windows 桌面(希望如此)。

As requested a little while ago, I will try to share my experience now more than one year after I asked the original question. We decided to use Windriver, but so far we have only written a driver for Windows CE 6.0, so I cannot comment on the cross-platform support.

Using Windriver on Windows CE 6.0 has both advantages and disadvantages. It means all our driver code is now in library, so it has been easier to develop and debug (compared to a standard driver that requires Platform Builder). So from a development point of view it has been nice. Performance has also been fine. There were some overhead in the beginning learning the Windriver API and how to use it, especially with DMA and interrupts, but I don't think it was worse than learning the raw Windows CE 6.0 PCI API.

The only real disadvantage I can think about is that a "real" driver is easier to share between multiple processes than the library we have created using Windriver. In our application (embedded system with one process) it is not really a problem, but it is harder to create debug/development utilities that operate on the hardware behind the back of the main process. We have used that approach for testing/debugging on other platforms but it is a bit more complicated to do here.

To sum everything up, I think we made the right choice and I am happy that we have the ability to port our "driver" to Windows Desktop with (hopefully) very little effort when we need it.

你又不是我 2024-12-11 16:36:09

使用Windriver开发Windows/Linux驱动程序后,我想回答这个问题。

如果使用驱动程序的应用程序也将由您编写,我更喜欢 Windriver。既然您提到您正在开发自定义驱动程序,我假设您也将自己编写该应用程序。在这种情况下,应用程序不需要在 Windows 和 Windows CE 之间进行太多更改,因为大多数驱动程序函数将由 Windriver 本身生成。这就像调用标准库函数而不是使用 IOCTL 等。

过去,我使用 windriver 生成基本的驱动程序接口代码,并开发使用 windriver 生成的代码的应用程序(主要是诊断应用程序)。只需很少的修改,我们就可以在 Windows 和 Linux 之间使用驱动程序和应用程序。我并不提倡使用Jungo,但它很容易使用。

由于问题是征求建议,很难提供准确答案,我只是分享我的反馈。

Having used Windriver to develop drivers for Windows/Linux, I want to answer this question.

I prefer Windriver, if the application which uses the driver is also going to be written by you. Since you mention that you are developing a custom driver, I assume that you are going to write the application also by yourself. In this case, the application need not change much between windows and windows CE, as most of the driver functions are going to be generated by Windriver itself. It is like calling standard library functions as opposed to use IOCTLs etc.

In the past, I have used windriver to generate basic driver interface code, and developed applications (Mostly diagnostic applications) which uses the windriver generated code. With little modifications, we were able to used the driver and application between windows and linux. I am not advocating to use Jungo, but it was easy to use.

Since the question is about asking for suggestions, It is difficult to provide exact answer, I am just sharing my feedback.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文