Thanks for the helpful reply.
I guess the following best describes what I have:
quoted from Microsoft WHDC :
"Problem Design 2: Single Base Address Register for Multiple Functions
A device of this type has a single configuration space with a unique device
ID, but the configuration space is overloaded to the point that a single
base address register represents resources for more than one functional
unit, each unit using a portion of the resource range represented by that
BAR.
Writing a driver to compensate for this design is highly complex, because
support differs for each version of the Windows operating system. It would
require a bus driver that can correctly handle its own device relations,
manage power, and coordinate resource use among its children. Developing
such a driver usually results in large, long-term support and development
costs for the vendor, and is not recommended. "
In retrospect it would have been better to design the hardware correctly
(According to PCI multifunction standard), to have independent resources for
all functions etc… The resources are however shared between all functions.
The device has the following functions: 5 * RS232/485, 4 * ARINC429 TX and
RX, 1 * ARINC717, Some Discrete I/O etc. As far as I understand mf.sys is
not going to work with these overlapped resources.
Now most of this is not a problem to me as I just use IOCTRLs (on the main
function driver for the PCI card) and write a user mode DLL to provide an
API to control these functions. The problem is with the serial ports which
must appear as standard ports. I must be able to open them from
HyperTerminal or other applications, so I cannot write my own interface to
them. My thinking was to do all the processing, reading, writing etc to the
ports in the main function driver, but to load a serial driver (Modified DDK
example) to look like a serial port and just pass the messages through to
the actual function driver which would control the actual hardware interface
(kind of like a virtual serial port but with actual hardware underneath it).
What I’m struggling with is to enumerate these serial devices manually from
the main function driver. From what you said it sounds as if I’m sort of on
the right track, although using mf.sys is actually the right way to go, if
the card could support it (i.e. multifunction standard) ?
“Mark Roddy” wrote in message news:xxxxx@ntdev…
> ‘Functions’ in PCI terminology refer to distinct addressable components on
a
> PCI bus that have a PCI config space region defined for them. PCI
addresses
> are bus/device/function tuples. A PCI-compliant multifunction device is a
> descrete PCI component, for example a PCI card, that has one PCI
bus/device
> address and more than one PCI function address. I cannot tell from your
post
> if your hardware is a multifunction PCI device or a non-compliant PCI
> device that has several ‘logical functions’ combined into one or more
> addressable PCI functions.
>
> Given that you claim to have 10 functions, and that the maximum number of
> PCI addresable functions per PCI device is 8, I think you have some
> combination of logical and addressable PCI functions. Each addressable PCI
> function should be implemented with a standard PCI PnP Function Driver. If
a
> PCI function contains more than one logical function then it should be
> implemented by providing PnP Bus Driver functionality for the
corresponding
> PCI Function Driver. You have two choices here: write your own bus driver,
> or use the existing semi-documented Microsoft supplied MultiFunction
Driver
> (mf.sys). Given the complexities of writing a bus driver from scratch, I
> strongly urge you to consider using mf.sys instead. Search this list and
the
> usenet groups for more information about mf.sys, as we have discussed the
> pros and cons of this issue several times here.
>
> I know from personal experience that using mf.sys to support logical
serial
> port functions on a PCI device works just fine, with the coding effort
> reduced to one rather cryptic inf file and the usual testing.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Vis
> > Sent: Sunday, July 04, 2004 7:18 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] PCI Serial Driver - need help
> >
> > I’ve been trying to get a driver running for a PCI serial
> > card for quite some time now, with no success. I’m getting
> > the feeling that the route I’ve chosen might not be the right
> > one, maybe somebody here can point me in the right direction.
> >
> > The PCI device is FPGA based and contains 5 non-standard
> > UARTS, ARINC 429 etc. What I’m trying to do is create a
> > driver for each of the functions, i.e. serial ports, ARINC
> > 429 etc. all of which are linked as children to my parent
> > PCI driver. I must also emphasize that this is not for a
> > commercial product, it is what we use for testing, and there
> > are only 5 of these cards thus we cannot afford to spend much
> > time or money on the driver.
> >
> > Now the route I’ve chosen is to write a PCI driver (which
> > works fine) and create child devices for the serial ports (as
> > per Walter Oney’s mulfunc
> > example) (which doesn’t work at all). I then removed the
> > card and just tried to to get the mulfunc example running and
> > creating one child as a serial port (using WINXPDDK
> > serial.sys example). Once again no luck.
> >
> > I don’t think I’m stupid but this seems a lot more difficult
> > than it ought to be. Does anybody have any ideas where to
> > start and what direction to take.
> >
> > The PCI card has 10 functions so I must enumerate them
> > manually, that’s why I think child devices are the way to go.
> > I can see the serial driver creating the port in the
> > registry, creating symbolic link etc. But when I open it it
> > says the device cannot be opened. I don’t get a create IRP
> > in either parent or child device when this happens.
> >
> > Any help will be greatly appreciated.
> >
> > Vis
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
>