PCI-6503 RLP Mapping.

[Scotty2541]

Hello,

I have a PCI 6503, and I am developing a driver to run the card.  Everything, so far, is going fine.

The driver loads, I have the VID and PID for the device.  PNP finds the board and tells me all about it.  I have the doc ...  "PCI-6503 User Manual" (374938b.pdf) and was doing fine until the appendix B, page 14.

But now I have some concept questions.

The driver is enumerating the resources with memory (and an interrupt) not register ports. I was epxecting registers...

Specifically there are two memory windows,  Then the appendix starts talking about remapping memory.

First....  Isn't that a violation of the PCI PNP spec to redefine resource addresses?    Why would this even be an option?  It says the programmer has to keep track of what resource is being used...  so I have to go into the device manager and look at all the resources, and pick some that are not used?  Which is fine until the PNP manager reassigns some stuff.  Then the machine is dead in the water...

Next... The next page (B15) has a table of 'register' addresses.  But the PCI PNP enumeration didn't give any registers, only memory addresses.  Where do these come from?  (is it a misnomer?)

Then I just get even more lost...  The doc starts talking about BAR0 and BAR1.

Which of ther two memory windows is BAR0 and BAR1? Or are they not it at all?

It says to write to BAR0 + 0x10?  Which memory window is the BAR?

    (my card came up with fdfff000 and fdffe000, which oddly enough has the memory spaces backwards, not contigous)

Step 3 says write the address you want to use to config space "offset 0x14  (BAR1)".  This implies that BAR1 is BAR0 + 0x14.  But if they are those memory windows, than BAR1 is 4096 bytes away from BAR0, not a mere 20 bytes away.

How, if at all, does this translate to accessing through registers (outb...)   Or is access only ever done through memory alone?

Clearly, I am missing some fundemental concept here.  Up to this point, everthing had been fine.

(I have another simpler question on the interrupt...  it can be configured for PORT A or PORTB...  Is that only when they are configured as inputs?  And is that any specific bit in the port, or the entire 8 bit port?  Is that an 'interrupt on change' ? )

And advice is appreciated.

-Scotty

[kruiz17]

Hi Scotty2541,

I am not sure I understand the issue that you are having with the registers mentioned in Appendix B.  Those memory locations are the registers. You have to write the information in those memory locations (i.e. 0x1234 -memory location-, 0x7894 -data written to that location-) as shown in page B-27 of the manual. Additionally, you mentioned that you are developing a driver to run the card. Wouldn’t the NI-DAQmx driver be good for your application? You can use that driver with some text-based programming languages as well so I am just a little curious of why using the driver is not an option for your application. 

Regards, 

K. 

[Scotty2541]

To answer the second question first, I will be developing RLP drivers in the future, because the DAQmx  is inadequate.  Also, at this stage, I am using it as a learning tool for many other programming tasks.

As to the first question...

Okay, I now see that communication to the card is through memory, not ports.  The term 'register' crosses boundaries, as it does not mean 'memory' in the embedded areas I am used to, it means 'input or output port'.

However, I do not understand this MITE concept.  I did, however find this post from over a decade ago, but I still can't get it to work:

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

I posted a followup, but I don't know if the original poster is even monitoring it.

My goal at this stage is just to get PORTA outputs to toggle.

Here is what I am doing, and as far as I can tell is what I am supposed to do. I have filled the driver with kernel debug messages, and everything indicates it is doing what I tell it  (but not doing what I want)

Following the example code on that link, I obtain the base address register, which  is translated  (when I used the untranslated value, I got a BSOD,  doh! ).

I stored the address in my device extension structure so I can get to it later...

Using pages B5,  B19 and B20, I disable the interrupts and set everything as outputs:

    WRITE_REGISTER_UCHAR(block->baseAddress + 0x14, 0);      /* 'block' is in my device extension structure */
    WRITE_REGISTER_UCHAR(block->baseAddress + 0x15, 0);
    command = 0x80;                                        /*  ctrl =1,   mode = 00,  all ports are output  */
    WRITE_REGISTER_UCHAR(block->baseAddress + 0x03, command);

Then I have a program that opens the device and just toggles between FF and 00 to port A on a 1 second loop.  The IO code does this:

   WRITE_REGISTER_UCHAR(block->baseAddress, pWriteDataBuffer[0]);

Again, all kernel debug messages indicate that it is working (or doing what I tell it to do)

The voltages on the lines on the output terminal block do not change.  They are (mostly all) +5V, but never change.

So I have to conclude that the register I am writing to is not the correct memory address to change the PORTA output (or any  of the other ports for that matter).  but at least it is not giving me a bugcheck, so I know the driver owns that memory address..

So this is where I have stalled.  I suspect it goes back to my not underanding the MITE concept.  And as a result, do not have the correct base address.  And I can't find any description.

And further advice is appreciated.

-Scott.

[Scotty2541]

 kruiz17,

Two additonal things.

The MH DDK driver, which uses RLP, doesn't have any reference to the PCI 6503.  So I assume there is no support for it.

Second,
I have tried writing to the memory addresses that are returned during enumeration.  My kernel logging came up with these two memory windows:

          MEMORY Mapping: BAR0 00000000fdfff000 Length 1000
          BAR 0 MEMORY Mapping: Translated BAR0 b877b000

          MEMORY Mapping: BAR1 00000000fdfff000 Length 1000
          BAR 1 MEMORY Mapping: Translated BAR1 b87aa000

So I can see what the MmMapIoSpace is translating the address to.

However when I write to the registers, still nothing happens.

I tried  b877b003 = x80  followed by   b877b000 = xff and x00  to toggle PORTA,  (which should be BAR 0)

and  b87aa003 = x80  followed by   b87aa000 = xff and x00   (which should be BAR1)

I was tempted to just loop though the entire 4096 byte block, but that would probably just be a disaster  🙂

-Scott

[chaka1234]

Hello Scotty2541,

I think that since you are using MHDDK driver,  I recommend you to post your question in this forum: 

http://forums.ni.com/t5/Driver-Development-Kit-DDK/bd-p/90

You can exchange ideas with other register level programmers there. The forum is also monitored by National Instruments R&D engineers who can provide added insight when appropriate.

Regards,

Carmen

[Scotty2541]

I downloaded the DAQMX package, and it does not recognize the board.  In fact, none of the INF files contain a reference to the device "DEV_17D0".  So using NIMAX is not an option in any event.

The driver I wrote does recognize the board.  And PHP assigns resources, so I know to board functions.  Except it doesn't react to commands sent to it.

-Scott

[Dennis_Knutson]

Yes, there was a problem with the forum today.

DAQmx will most certainly recognize your device but you would first have to disable your custom driver since Windows will only recognize one.

I would second the reconnection to post to the ddk board for your questions on it.

[Scotty2541]

Thanks Dennis.

I would delete those post about the errors if I could.  I was really getting annoyed by 11:45pm, and that frustration was leaking into the posts...

I could not even find a 'email the moderator' link to tell anyone about the issue.

As for the original issue, I will go over to that other forum.

As an FYI, I found that it required some other version of DaqMX  (9.5.1).  I installed it, and can toggle digital outputs using that tool.  So the hardware is fine.  This is just something to do with how to initialize and send commands to the board inside kernel space.

Thanks.

Scott