I’ve been investigating a sample driver in the Win2k DDK, and an
accompanying DLL, 1394API.DLL.
In the DDK docs for this sample DLL (and on the MSDN Website) it is stated
several times that “Detailed functionality of this API can be found in the
1394 DDI documentation”. At the risk of sounding stupid, where might I find
this elusive documentation?
Cheers
James
Did you look here:
http://www.1394ta.org/Technology/Specifications/specifications.htm ?
-----Original Message-----
From: James Wain [mailto:xxxxx@vutrix.com]
Sent: Friday, April 12, 2002 6:46 AM
To: NT Developers Interest List
Subject: [ntdev] FireWireI’ve been investigating a sample driver in the Win2k DDK, and
an accompanying DLL, 1394API.DLL.In the DDK docs for this sample DLL (and on the MSDN Website)
it is stated several times that “Detailed functionality of
this API can be found in the 1394 DDI documentation”. At the
risk of sounding stupid, where might I find this elusive
documentation?Cheers
James
You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%
If you look in one of the latest DDKs at ‘System Support for Buses’'IEEE
1394 Bus’\Reference you will find just about everything related to FireWire
that is documented for Windows platforms. Now if you are working with a
still image device like a scanner or camera WIA might be a better way to go
and you can search on that. If you are working with video look at the AV
stuff.
All in all the generic firewire documentation has quite a few large gaps in
it, and much of what is there is incorrect.
Also, that particular 1394 sample in the DDK has several issues. It doesn’t
handle many things correctly, and more importantly it doesn’t show how a
typical driver would handle most 1394 operations. As everything comes from
user mode in that sample, it is extremely hard to follow, and most
interesting values are hard coded in the app and as such provide no insight
to their use in the real world.
What are you trying to do, as in what type of device do you need to control,
perhaps a better answer is available to you.
–
Bill McKenzie
“James Wain” wrote in message news:xxxxx@ntdev…
>
> I’ve been investigating a sample driver in the Win2k DDK, and an
> accompanying DLL, 1394API.DLL.
>
> In the DDK docs for this sample DLL (and on the MSDN Website) it is stated
> several times that “Detailed functionality of this API can be found in the
> 1394 DDI documentation”. At the risk of sounding stupid, where might I
find
> this elusive documentation?
>
> Cheers
>
> James
>
>
>
> If you look in one of the latest DDKs at ‘System Support for Buses’'IEEE
1394 Bus’\Reference you will find just about everything related to FireWire
that is documented for Windows platforms.
Bill, have you solved the problem with AllocateAddressRange and response packet?
At least in early w2k and in Win98 Gold all was fine in this respect.
Max
It isn’t fine in this respect for me. If I use an MDL or a fifo list as
backing store, it works fine. But then I can’t see the node number of the
node that wrote the address range on 2000 and earlier. Not using either of
these as backing store allows me to get the request packet and see the node
number of the sender. But 2000 sends the response packet I create in this
case at the wrong speed, or at least it does on my test platform. I tested
this again with 2000 no SPs, same result.
Are you saying you did exactly this, and it worked fine for you? BTW, I
don’t get any errors anywhere, its just the packet is sent at the wrong
speed.
–
Bill McKenzie
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> > If you look in one of the latest DDKs at ‘System Support for
Buses’'IEEE
> > 1394 Bus’\Reference you will find just about everything related to
FireWire
> > that is documented for Windows platforms.
>
> Bill, have you solved the problem with AllocateAddressRange and response
packet?
> At least in early w2k and in Win98 Gold all was fine in this respect.
>
> Max
>
>
>
>
Do you have the bus analyzer at hand? Like Philips aka Vetana board - it connects to PC using a serial port and has MS-DOS
full-screen software to control it.
Max
----- Original Message -----
From: “Bill McKenzie”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Saturday, April 13, 2002 12:27 AM
Subject: [ntdev] Re: FireWire
> It isn’t fine in this respect for me. If I use an MDL or a fifo list as
> backing store, it works fine. But then I can’t see the node number of the
> node that wrote the address range on 2000 and earlier. Not using either of
> these as backing store allows me to get the request packet and see the node
> number of the sender. But 2000 sends the response packet I create in this
> case at the wrong speed, or at least it does on my test platform. I tested
> this again with 2000 no SPs, same result.
>
> Are you saying you did exactly this, and it worked fine for you? BTW, I
> don’t get any errors anywhere, its just the packet is sent at the wrong
> speed.
>
> –
> Bill McKenzie
>
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >
> > > If you look in one of the latest DDKs at ‘System Support for
> Buses’'IEEE
> > > 1394 Bus’\Reference you will find just about everything related to
> FireWire
> > > that is documented for Windows platforms.
> >
> > Bill, have you solved the problem with AllocateAddressRange and response
> packet?
> > At least in early w2k and in Win98 Gold all was fine in this respect.
> >
> > Max
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
I am using a 1394 connected analyzer from MindReady. Its a PCI card on my
host that just snoops the host controller on my target.
–
Bill McKenzie
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> Do you have the bus analyzer at hand? Like Philips aka Vetana board - it
connects to PC using a serial port and has MS-DOS
> full-screen software to control it.
>
> Max
>
> ----- Original Message -----
> From: “Bill McKenzie”
> Newsgroups: ntdev
> To: “NT Developers Interest List”
> Sent: Saturday, April 13, 2002 12:27 AM
> Subject: [ntdev] Re: FireWire
>
>
> > It isn’t fine in this respect for me. If I use an MDL or a fifo list as
> > backing store, it works fine. But then I can’t see the node number of
the
> > node that wrote the address range on 2000 and earlier. Not using either
of
> > these as backing store allows me to get the request packet and see the
node
> > number of the sender. But 2000 sends the response packet I create in
this
> > case at the wrong speed, or at least it does on my test platform. I
tested
> > this again with 2000 no SPs, same result.
> >
> > Are you saying you did exactly this, and it worked fine for you? BTW, I
> > don’t get any errors anywhere, its just the packet is sent at the wrong
> > speed.
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Maxim S. Shatskih” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > > If you look in one of the latest DDKs at ‘System Support for
> > Buses’'IEEE
> > > > 1394 Bus’\Reference you will find just about everything related to
> > FireWire
> > > > that is documented for Windows platforms.
> > >
> > > Bill, have you solved the problem with AllocateAddressRange and
response
> > packet?
> > > At least in early w2k and in Win98 Gold all was fine in this respect.
> > >
> > > Max
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> I am using a 1394 connected analyzer from MindReady. Its a PCI card on my
host that just snoops the host controller on my target.
Have you tried Win98 Gold and SE in terms of response packet speed?
Max
No, and I hadn’t planned on it. I know MS is not going to service pack
those platforms, so there is nothing that can be done there even if this is
indeed a 1394 stack issue.
–
Bill McKenzie
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> > I am using a 1394 connected analyzer from MindReady. Its a PCI card on
my
> > host that just snoops the host controller on my target.
>
> Have you tried Win98 Gold and SE in terms of response packet speed?
>
> Max
>
>
>
>
BTW, for any who were following this. I have confirmed with MS, that
there is indeed a problem here. If you use REQUEST_ALLOCATE_ADDRESS_RANGE
and provide no backing store, that is you do not use an MDL or the fifo
list of MDLs and go with ‘raw’ mode, then in the notification callback
that you must provide, when you create your response packet, you have to
set the speed. *It will not be set correctly automatically* The problem
is you MUST set the speed to that of the request packet, and there is no
documented way to get that speed. However, there is an undocumented way,
and if anyone needs this I suggest you contact MS. MS is aware of the
problem and they are planning on straightening this out in some fashion in
the future. I am not sure of when or what, MS can provide details.
Anyway, thought I would follow up on this. This works the same from
98-XP.
Bill M.
I am using a 1394 connected analyzer from MindReady. Its a PCI card on my
host that just snoops the host controller on my target.–
Bill McKenzie“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >
> > Do you have the bus analyzer at hand? Like Philips aka Vetana board - it
> connects to PC using a serial port and has MS-DOS
> > full-screen software to control it.
> >
> > Max
> >
> > ----- Original Message -----
> > From: “Bill McKenzie”
> > Newsgroups: ntdev
> > To: “NT Developers Interest List”
> > Sent: Saturday, April 13, 2002 12:27 AM
> > Subject: [ntdev] Re: FireWire
> >
> >
> > > It isn’t fine in this respect for me. If I use an MDL or a fifo list as
> > > backing store, it works fine. But then I can’t see the node number of
> the
> > > node that wrote the address range on 2000 and earlier. Not using either
> of
> > > these as backing store allows me to get the request packet and see the
> node
> > > number of the sender. But 2000 sends the response packet I create in
> this
> > > case at the wrong speed, or at least it does on my test platform. I
> tested
> > > this again with 2000 no SPs, same result.
> > >
> > > Are you saying you did exactly this, and it worked fine for you? BTW, I
> > > don’t get any errors anywhere, its just the packet is sent at the wrong
> > > speed.
> > >
> > > –
> > > Bill McKenzie
> > >
> > >
> > >
> > > “Maxim S. Shatskih” wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > > If you look in one of the latest DDKs at ‘System Support for
> > > Buses’'IEEE
> > > > > 1394 Bus’\Reference you will find just about everything related to
> > > FireWire
> > > > > that is documented for Windows platforms.
> > > >
> > > > Bill, have you solved the problem with AllocateAddressRange and
> response
> > > packet?
> > > > At least in early w2k and in Win98 Gold all was fine in this respect.
> > > >
> > > > Max
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> set the speed. *It will not be set correctly automatically* The problem
is you MUST set the speed to that of the request packet, and there is no
documented way to get that speed.
NOTIFICATION_INFO::RequestPacket points to ASYNC_PACKET describing the incoming packet. You can find the source node from there, and
query the speed by speed map.
BTW - the fact ASYNC_PACKET is not described in the documentation, though is declared in 1394.H, is very bad.
Max
The problem with the speed map is you would have to check it for each packet
that you receive as the speed isn’t guaranteed. The device’s speed could
get throttled at any point by a REQUEST_SET_DEVICE_XMIT_PROPERTIES call
which I don’t even know if that shows up in the speed map. Besides that
getting the speedmap properly across 98/Me/2000/XP is a pain.
If you control the device this probably isn’t an issue, but I was going peer
to peer and this could occur. Anyway, turns out that the bus is actually
using an OHCI_ASYNC_PACKET which is not documented or in any header and
overlays the ASYNC_PACKET structure. There is a way of getting the speed
from the received request packet, and you can set the speed in the response
packet IF you cast it to this OHCI_ASYNC_PACKET type. Well, obviously you
could anyway, but you wouldn’t know where the bits go. There is no way to
set the speed of the response packet just looking at the ASYNC_PACKET
structure, and I imagine anyone who has used this ‘raw’ mode has, to date,
had their response packets traveling at the wrong speed. The speed is
calculated from the request packet differently for different tcodes as well.
And there are issues if your data crosses packets and such. Its a pain, but
doable, but undocumented, but a bug has been filed.
–
Bill McKenzie
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> > set the speed. It will not be set correctly automatically The
problem
> > is you MUST set the speed to that of the request packet, and there is no
> > documented way to get that speed.
>
> NOTIFICATION_INFO::RequestPacket points to ASYNC_PACKET describing the
incoming packet. You can find the source node from there, and
> query the speed by speed map.
>
> BTW - the fact ASYNC_PACKET is not described in the documentation, though
is declared in 1394.H, is very bad.
>
> Max
>
>
>
>