PCIe driver for Windows CE and Windows Desktop

Question

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?

Answer 1

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.