I want to get base address of PCI board

Hi all,
I have a simple PCI DAQ card. I want to access Base Address to controll this board directly.
Can anybody help me how to get PCI Base Address of this board under WinXP?
I have a dll (pcitst32.dll) what supplyed it, but it works on win98 only.
I found a VB file next to the dll and I found a FindPciDevice(PID, VID, Index, BusNum, DevAndFunc) and a ReadConfigurationDword(BusNum, DevAndFunc, PciCsBaseAddr0, lValue) functions.
The other VB file call this bas file with Index=0.
The ReadConfigurationDword called 5 times. Each time called with different PciCsBaseAddr value.

I look into dll binary code and I found it call HalGetBusData function. I have seen on the MSDN sites and say it function is obsolete. It say use IRP_MN_QUERY_INTERFACE instead HalGetBusData.
Can I (or anybody) make a dll what I can call from any application what it will supply Base Addresses of PCI board what identified VID and PID or help with instruction what must i'm do?
I hope so you understand what I want.

Thank you!

Best Regards,

Syrius

Even if you KNOW the base address of the board, you will need some sort of driver to access the board. Technically, you could use a small driver that just allows you to map the boards memory region into the user-mode application space, and do the rest from your user-mode application, but you still some basic driver functionality to get there.

--
Mats

You'll need to get comfortable and settle down to a nice long read of
http://www.microsoft.com/whdc/DevTools/ddk/default.mspx

What kind of DAQ card is it?

Usually the vender provides drivers and a programming API.

gg

Quote:

---

Originally Posted by Codeplug

What kind of DAQ card is it?

Usually the vender provides drivers and a programming API.

gg

---

This board is the MCC PCI-DAS1xxx boards. For example PCI-DAS1602/16.
I have driver set for these boards but my challenge is to write a test program in labview what never use the VB and InstaCal because it is not comfortable to access from an application and the LabVIEW test enviroment.
The details of original manufacturing test program in Visual Basic:

VendorId = &H1307
DeviceId = &H1
Index = 0
Call FindPciDevice(DeviceId, VendorId, Index, BusNum, DeviceAndFunc)
If DeviceAndFunc = 0 Then
Msg = "PCI Board Not Found!"
Style = vbExclamation + vbOKOnly
Title = "Detect PCI Board"
response = MsgBox(Msg, Style, Title)
End
End If

' Find the physical location of S5933 operation Registers in I/O space
PciCsBaseAddress0 = &H10
PciCsBaseAddress1 = &H14
PciCsBaseAddress2 = &H18
PciCsBaseAddress3 = &H1C
PciCsBaseAddress4 = &H20

ReadStat% = ReadConfigurationDword(BusNum, DeviceAndFunc, PciCsBaseAddress0, lValue&)
OpRegBaseAddress0& = (lValue& And &HFFFFFFFC) ' Mask 2 Lower Bits
.
.
.
and it read for four time too to read the rest of base address

I look again the PCITst32.dll and I fount a following string in binary: \\.\CBUL32
I have the WDM driver (CBUL32.SYS). Can I connect to driver with CreateFile function with this string?

When installed the driver for the PCI device and look in device manager what driver addigned to device, it displayed the cbulwdm.sys. I found this file in %systemroot%DrvStore\cbi95_... folder on XP. I also found the cbul32.sys next to wdm file.

Thanks,

Syrius

Yes, you should be able to access the device through a file opened with

Code:

---

\\.\CBUL32

---

. But you need to also understand how the driver expects you to communicate with the driver.

--
Mats

Quote:

---

Originally Posted by matsp

Yes, you should be able to access the device through a file opened with

Code:

---

\\.\CBUL32

---

. But you need to also understand how the driver expects you to communicate with the driver.

--
Mats

---

Thanks,

How to understand it? Have you option for this?
When I send this cbul32.sys driver or pcitst32.dll, can you help me for solving my problem?

Regars,

Syrius

I have no idea how the driver expects you to get the data out - well, I can have a guess, but not necessarily say for sure. You may also need some ioctl calls to set up the device, or write some specific information in some way.

You can most likely READ from the filehandle that you get back from open (and you probably can't use fopen, you'll need OpenFile() or whatever it's called).

--
Mats

If you want to run on XP, you'll have to use the vender's supplied programming library.

You can download the latest InstaCal here:
http://www.measurementcomputing.com/...CMCV6GKPU7484B

Their support forrum is here:
http://forums.mccdaq.com/lofiversion/index.php/

gg

Quote:

---

Originally Posted by Codeplug

If you want to run on XP, you'll have to use the vender's supplied programming library.

You can download the latest InstaCal here...

gg

---

I have this software but I wrote above, the target is: NEVER use the Instacal, because it not friendly for our LabView Test Enviroment.
I want to write a dll what I can call form LabView that supplied PCI Base Address of the daq board for register level access.
I want to programming the PCI board in register level communication but I'm very beginner in system programming. Therefore wrote onto this forum.

Yesterday found a string in pcitst32.dll: \\.\CBUL32
This dll supplied information what I want, but it working only on Windows98.
I tried connect to device driver by CreateFile(). The program successfully connected to it, but I don't know yet what IOCTL commands are expect this.

I look drivers (cbul32.sys and cbulwdm.sys) in DeviceTree tool. It reports following:
cbul32.sys supports following IRP function codes (have a flag for dthis driver: LEGACY_DRIVER; Service: CBUL32):
IRP_MJ_CREATE
IRP_MJ_CLOSE
IRP_MJ_DEVICE_CONTROL
IRP_MJ_CLEANUP

The cbulwdm supports following IRP function codes (Service: cbulwdm):
IRP_MJ_CREATE
IRP_MJ_CLOSE
IRP_MJ_DEVICE_CONTROL
IRP_MJ_CLEANUP
IRP_MJ_QUERY_POWER
IRP_MJ_SET_POWER

Accordingly I connected by \\.\CBUL32 to cbul32.sys?

Syrius

Unfortunately, that doesn't tell you what you are expected to do with the device - it just lists the IRP types that are supported, and for exampel IRP_DEVICE_CONTROL can have many different sub functions - that is what IOCTL calls eventually become in normal cases.

As I said earlier (but perhaps not as clearly), you need to have information from the producer of the driver how you are supposed to use the driver. The company probably does provide this if you ask nicely.

--
Mats

Why do you *need* register level access?
Does the InstaCal API's not support what you're trying to do?

>> ...but I'm very beginner in system programming
Your two most feasable options are:
1) Go back to Win98
2) Write your DLL using the InstaCal library - which knows how to communicate with the driver.

gg