关于1394 destinationoffset问题

各位大虾：
我现在使用的ti的tsb12lv01b作为我的控制层控制器。

根据datasheet:
发送异步模式的数据包的时候，要求指定：destinationOffsetHight,和destinationOffsetLow.

1394体系结构中讲得这是指的node内部的space address.

我不清楚应该怎样去指定？
这些字段指定之后是给谁用的呢？

请牛人点拨

这要看1394协议了吧？

是不是每个节点内部的register空间啊，
不是每个地址都有真正的单元对应吧？

小弟这两天读了读OHCI

有一点体会，发出来请大家指正：

1394规范定义了一个节点内部48bits的内部空间。但是很多空间没有定义怎样使用。OHCI定义了一套适合于1394的寄存器，并且给出了具体的操作办法。如果各个节点都是遵守ohci1394规范的，那么它们可以通过互相访问（read write lock ）对方的寄存器来达到通信的目的。

因为微软是支持OHCI的，我的设想是调用ddk中1394的例子驱动程序1394diag.sys.给我的1394设备（通过6针电缆连接到pc的数据采集卡）安装这个驱动程序。然后调用例子中提供的1394api.dll来实现和他的通信。 请牛人看看这样是否可行。

因为调用的是微软编的驱动例子，所以我觉得我需要按照OHCI规范来配置自己的设备节点。现在我有几个问题和设想，请大家看看：
我的email是liu_roc@hotmail.com 欢迎指导


1：首先，我想知道48bit地址的节点空间中那些已经被std 1394和ohci定义了，那些我还可以自己定义？


2：1394api.dll里面有一个函数是GetDeviceList()
  
GetDeviceList
DWORD
WINAPI
GetDeviceList(
   PDEVICE_DATA    DeviceData
  );

typedef struct _DEVICE_LIST {
    CHAR    DeviceName[255];
} DEVICE_LIST, *PDEVICE_LIST;

typedef struct _DEVICE_DATA {
    ULONG        numDevices;
    DEVICE_LIST    deviceList[10];
} DEVICE_DATA, *PDEVICE_DATA;
 
This API is called with the DeviceData struct. 1394API.DLL supports a maximum of 10 1394 devices on one PC. This is an arbitrary limit and can be increased. The number of 1394 devices available is returned in numDevices and the symbolic link names of available 1394 devices are stored in DeviceName.


我不知道这个函数会对杰在1394总线上的设备发出什么样的包，
我的设备有应该怎样响应这个包呢？！！！！

有两个问题：

1。 OHCI是不是和PCI有关系啊？ OHCI在外设上同样可以使用吗？
    最初给我的感觉是OHCI用于PCI卡的1394接口。所以一直没有看
    该协议。要是象roc999兄的意思，看来我也要研究一下啦

2。你的附件在我电脑上打开时会提示有看不到的内码？

就是ddK里面的1394API的介绍

好像不是专门和pci有关的。
我理解是针对通用的节点。
只要你符合这个规范
就可以通过互相读写相应的寄存器来通信


你是怎样理解的呢？

我觉得ohci还是根pci有关的，我看ti的链路层芯片凡是支持ohci的都和pci有接口，另外我觉得节点和主机还是有趣别的，比如电对电是，好像用不到ohci吧。

一点看法，仅供参考

暂时比较支持ARRON

又看了一下ohci，有以下想法：
  1。主机和节点是不同的
  2。支持ohci的芯片和pci都有接口，是因为pci比较通用
  3。但只要是符合一定的寄存器规范，能当总线管理器，提供dma支持等等的节点，也是可能当主机的，即也支持ohci。
  所以说，ohci并不是针对pci的，外设也可能做到这一点，只不过这时这个node的controller功能应该比较强大。
 
不知道我得想法对不对

如果无特殊要求，指定为0就可以了。那个偏移地址是总线驱动程序用来分配空间的起始地址。

比较糊涂
能讲清楚一点吗？

大家好，小弟毕业设计作这个。算初步了解。
1。GetDeviceList作用
通过GUID来搜索设备接口。当找到设备时，将设备添加到DeviceData全局变量中。当发现有设备时，启动BusResetThread线程
2。BusResetThread作用
BusReset线程创建异步事件，导致驱动程序生成Pending的Irp.这样
当硬件事件发生时，完成这个Irp.此刻控制权回到应用程序。BusRestThread苏醒，简单的给注册了的应用程序发送自定义消息。使用参数hwnd的SendMessage。

如果硬件事件没有发生，而应用程序关闭，就需要清除Irp.需要在
驱动程序中有一个队列纪录Pending的Irp,清除时挨个调用IoCompleRequest,使用参数STATUS_CACELLED。

这种机制类似于Win32的消息，不过这个消息是驱动送给应用程序的
告诉他硬件事件发生。


由于我是自己用这个驱动，并变写应用程序控制1394卡，不喜欢dll
所以将其删去。在Win32 Ap中自己改的