PCIe driver for Windows CE and Windows Desktop

I need a little advice for development of a custom PCIe driver. The driver must support b开发者_Go百科oth 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?

---

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.

---

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.