xPC Target Custom Drivers

[Matthew]

I have a question, I am creating a custom board driver for xPC target and I am looking as some of the examples in the xPC Blocks directory. There are 2 different ways that the drivers are created. One uses xpcDevice and xpcGetPCIDevice the other, which is used in many of the examples, uses xpcimports.h and calls like rl32eGetPCIInfo. Are they the same, is the r132 calls obsolete or an old way to do it. The documentation seems to show using the first way?

Using the first way
xpcPCIDevice pciinfo;
void *Physical0, *Physical1, *Physical2;
volatile uint32_T *ioaddress0, *ioaddress1, *ioaddress2;

if(xpcGetPCIDeviceInfo(VENDOR_ID,DEVICE_ID,XPC_NO_SUB,XPC_NO_SUB,0,-1,&pciinfo))
{
printf("%s: board not present", devName);
return;
}
This finds the board and fills in the Base Addresses for BAR0, BAR1, and BAR2
Then this:
Physical0 = (void *)pciinfo.BaseAddress[BAR0];
pciinfo.VirtAddress[BAR0] = xpcReserveMemoryRegion(Physical0, 1024, XPC_RT_PG_USERREADWRITE);
ioaddress0 = (volatile uint32_T *)pciinfo.VirtAddress[BAR0];
ssSetIWorkValue(S, BAR0, (uint_T)ioaddress0);

Should set the virtual address up and place it in a IWork variable so it can be used in mdlOutputs. Would it be normal if the Virtual Address and Base Address are exactly the same if I use the command below after I have done the VirtAddress on each of the Physical Memory Spaces?
xpcShowPCIDeviceInfo(&pciinfo)

Thanks,
Matt

[Gordon Weast]

Matthew,

A few releases ago, we decided to rationalize all the names and clean
up the linkage. However we didn't go back and change all the old
drivers and risk breaking them. If we need to fix a driver that uses
the old method, we will often switch it over.

We recommend including xpctarget.h and using the functions that start
with xpc such as xpcGetPCIDevice. This function checks for both cases
of either 2 ids or 4 ids. Some boards don't use the subsystem vendor
and device ids, while for some that's the only way to tell board types
apart. At some point we may get rid of the older rl32... names.

With the current kernel, the virtual address will usually come back
as exactly the same as the physical address you pass in. I have seen
it return a different value, but that was a case of overlapping areas
which was a mistake.

You have to assume that the virtual address it returns may be different.
Always use the virtual address.

Gordon Weast
xPC Target Development
The MathWorks