DM6467 Technology

PCI driver: wdm

If choose wdm, we need to set:

set BROWSER_INFO=1

before the build.

then do:
build -B -W

• Use the DDK build env
• if XP x86, use Windows XP x86 Checked Build Env  
• 1)  From a WIN DDK Checked or Free Build Environment command prompt, change to the directory containing the source code. 
• 2)  Type "BUILD -cZgk."    
  
• If got the following errors:
  

  “fatal error U1087: cannot have : and :: dependents for same target”

  Please make sure that the directory you are building in contains no spaces.

http://www.codeproject.com/KB/system/wdf_kmdf_basic.aspx

WDF vs WDM

Background

For those of you who don't know what WDF is: it is the best invention since sliced bread. Until recently, if you needed a device driver, you had to use the Windows Driver Model (WDM). WDM provides a low level framework for creating device drivers. Using this framework, your driver had to accept PNP, Power management, and IO requests, and figure out what to do with them, based on the state of your driver.
There are a couple of simple state diagrams describing the transitions between the different PNP states, and between the different power states, along with the events that cause the different state transitions. On the surface, this seems simple enough. There are only 6 PNP states, and 6 system power states, so it shouldn't be that hard, right?
As soon as you start writing your driver, you realize that the more you learn about WDM, the more confused you are. Implementing PNP is doable, with the understanding that you can use someone else's cancel-safe IRP queues. Otherwise, you have to write them yourself. The real horror sets in when you try to implement power management. Typically, your device driver has to manage both the system power state policy, and the device policy IRPs. This is quite complex, and according to the documentation, you must never perform any blocking activities while handling those IRPs. This means that you have to build a complex state machine that is hooked together with the completion routines.
There is no system level synchronization between the IO, PNP, and power IRPs, so it is possible for your driver to receive both a PNP and a power IRP while it is still doing some other IO activities. The complexity this introduces is so enormous that writing this code yourself is nearly impossible if you are not an experienced, professional driver writer.
To be honest, power management was where I bailed out. My OSR USB-FX2 learning kit disappeared in a drawer, and I couldn't spend months of my free time getting the driver to work properly.
Then, WDF was released. It looked very promising. Suddenly, the prospect to write a kernel mode device driver looked exciting again. When I wrote my first device driver, there were very few articles on KMDF. The only source of information I could find were two articles at OSR Online. That's when I thought it would be a good idea to write such an article for beginners in WDF driver programming like myself.

http://focus.ti.com/lit/ug/spruer2b/spruer2b.pdf


Diff between DM642 PCI and DM6467 PCI:

The DM642 and DM6467 feature an integrated peripheral that is compatible with the industry standard
peripheral component interconnect (PCI) interface. The PCI interfaces on these two devices are similar in
function and pinout; however, the DM642 PCI interface complies with version 2.2 of the PCI specification
and the DM6467 PCI complies with version 2.3 of the PCI specification. Also, the DM642 PCI runs at a
maximum of 66 MHz and the DM6467 PCI runs at a maximum of 33 MHz. Accordingly, use of these two
peripherals is different, therefore, migrating an application from a DM642 to a DM6467 requires software
and hardware interconnection changes.

http://focus.ti.com.cn/cn/lit/an/spraaz4/spraaz4.pdf