Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

Writing a PCI6503 Device Driver

Hello,

I am trying to write my own PCI6503 driver.  The short versoin is simply that I am changing to mode 00, setting the ports as outputs, and toggling the output lines.  But its failing.  The lines do not change.  There is no error occurring anywhere, just no results.

 

Additional info:

I sudied the appendix of the doc   "PCI-6503 User Manual" (374938b.pdf) for how to do the MITE remap...  (a concept not familiar to me)

 

The PHP is giving me raw and translated addresses, which are the same. (and match what the system properties box tells me was assigned to the VEN/DEV of the board ).   And these must be run through MmMapIoSpace.

 

I have liberally placed kernel debug messages all over the driver, and can see that it is doing the things I want it to do.  but the outputs lines do not change.

 

I consulted this post:

http://forums.ni.com/t5/Driver-Development-Kit-DDK/MITE-init-in-Windows-driver-stumped/m-p/2950901#M...

And assume his error was that

           "  WRITE_REGISTER_ULONG(translatedAddressMITE + 0xc0,   (physicalAddressBAR1 & 0xffffff00L) | 0x80);"

where translatedAddressMITE  + 0xc0 LONGS became translatedAddressMITE  + 0x300  UCHARS

 

So I fixed it accordingly, and see that the address is now correctly incremented to MITE + 0x30 UCHARS  (bytes)

(If this correct, that it should be 0x30 bytes, not 0x30 longs? )

 

The code on the link lets the physical BAR1 go out of scope...  Isn't is supposed to be transtated with MmMapIoSpace, and that is the address to be used?  (accessing the physical BAR1 obviously gives me a BSOD)

 

I have also tried writing to the memory registers without perfoming the MITE remapping, since that is how the NIRLP devices driver handles it's BAR0 abd BAR1, as I have examined that code as well.  (Is that the way it should be done ? Why does it not do the MITE remap, while the doc says it is required?)

Page B 19 of the doc says to just write 0x80 to base+3, to set it to all outputs, then start writing values to base, base+1, base+2  to see the results out ports A, B, and C  Am I reading that correctly?  Becuase it's not functioning.

 

So... nothing is happening on the output lines.  All I want to do at this stage is set the ports to outputs, and write some pattern to the port which I can then confirm with a DVM.  So far, no luck.

 

After struggling for weeks, I installed DAQMX 9.5.1, tested it, and the output respond.  So I know the hardware is good.

 

And anyone offer any advice?   Or any comments to my questions placed above?

 

-Scott

0 Kudos
Message 1 of 2
(6,746 Views)

As a follow up, I found a doc on the MITE inerface.  From Vienna.  And it was version 0.1 

http://web.student.tuwien.ac.at/~e0307201/ni_pcimio_6221/ni_mite_register_level_programmer_manual__d...

 

It would be nice if NI made a current doc available.

 

The original link in my above post from  'Thorsten' doesn't tell you which addresses to use.

It is correct, but I need to offer some clarification.

 

The first memory block that the enumeration finds is Base Address 0, although most docs about device drivers that I read say you should not trust that... But moving on...

Next is Base Address 1.  So, get and keep the raw address as BAR1.  Also get and keep the MmMapIoSpace() for both Base Address 0 and  Base Address 1.  This is where the link in my firs post falls short, since it does not describe that.

 

These are abbreivated BAR0 and BAR1.

 

So, you write the physical base address 1 back to the MITE chip, basically to open up that address block. This is defined in the PIO card manual and the MITE doc.  But in windows, the Hardware Access Layer (HAL) translates them.

So, you write the origiinal BAR1 physical address back to the MITE chip, at location BAR0 + 0xc0 (offset in chars, which is not the same as offsetting them in longs).  But you need to use the MmMapIoSpace() translated address to write to the card.  Because the HAL will convert any addresses.

 

By the way, when the address is a pointer to longs, it is not the same as a pointer to chars.  So offset 0xc0 is in chars, so if your pointer is to longs, you divied it by 4, to get the correct offset.

 

in other words I changed, the link to the post above:

    WRITE_REGISTER_ULONG(translatedAddressMITE + 0xc0, (physicalAddressBAR1 & 0xffffff00L) | 0x80);

to this:

     WRITE_REGISTER_ULONG(translatedAddressMITE + 0x30, (physicalAddressBAR1 & 0xffffff00L) | 0x80);

to account for the correct offset location.

 

And while I wrote the physical address back to the MITE, I had to write to the TRANSLATED base address 1to talk to the card.  And it is seems to be working now.

 

-Scotty

 

 

 

0 Kudos
Message 2 of 2
(6,713 Views)