OSSIE 常见问题

本页所列问题和答案在 OSSIE 讨论列表及其它相关地方里皆有表述。

安装

如果在 fourpalms 无法获得 omniORB source RPM 该如何办?

回答:fourpalms 网站常常会出现问题。如果这种情况发生的话,试图访问 http://opensource.nederland.net/omniORB/downloads/4.1.0/SRPMS/omniORB-4.1.0-1.src.rpm。然后如同是从 fourpalms 获取的文件一样对它进行处理。(0.6.2 用户手册于 4/11/08 被添加)

USRP

如何安装 USRP 驱动?

回答: 在如下网站获得 GNURadio:

对于稳定发行版或 3.1.* 的 tarballs 格式的源码,键入如下命令:
./configure --disable-all-components --enable-usrp
make

对于开发版版本的源码,键入如下命令:
./configure --disable-all-components \
--enable-usrp --enable-omnithread --enable-mblock --enable-pmt
make

其它页面的相关问题,可以到如下站点访问:

OWD

如何把设备添加到被定义的网络节点(node definition)?

试图在 OWD 上用 VMWare image 0.6.2 创建新的节点。如何把设备添加到被定义的节点?
回答: 右键点击在设备清单上的设备

OSSIE

有 Windows 版本吗?

回答:
没,没有用于 Windows 的版本,目前也没有计划在预知的未来制作 Windows 用的版本。
对此最好的解决方法是对于那些没有机器安装 Linux 的 Windows 用户下载 VMware player(虚拟机),在虚拟机上安装 linux 并使用 OSSIEVMs。这一切都可以在 下载专区 找到。

当运行 nodeBooter 时出现错误诸如 "Failed to resolve NameService?"

回答: 确保 omniNames 服务处于激活状态

启动 omniNames 服务后上面的错误仍旧存在

回答: 似乎 naming 服务还没有被激活。能把 omniNames.sh 发来吗? 做为替代 omniNames.sh 的另一种选择,键入如下命令:
killall omniNames
omniNames -start -logdir /home/<your user directory>/logs &

如果错误关联记录( log)文档,键入如下命令:
rm /home/<your user directory>/logs/omninames*

在运行 omniNames 之前(如下操作)

Follow-up:

在正在使用的命令行使用如下命令,(应当发现)设备可以被注册。
killall omniNames
omniNames -start -logdir /home/Oss/logs &

(在此)之前的 omniNames.sh 理应如下:
killall omniNames [omniEvents]
rm /home/Oss/logs/omninames*
omniNames -start -logdir /home/Oss/logs &

当[omniEvents]被清除, 脚本也能
正常运行.


OSSIE 组成部分遵循 SCA 应用部件的定义吗?它使用什么样的基本应用接口(Base Application Interfaces)?

OSSIE 组成部分和 OSSIE 核心应用(OSSIE CF::Applications) 都遵循 SCA 的精髓,但是其配置文件(Domain Profiles)用于明确其部件和应用的配置没用完全遵循其标准(SCA specification)。 因此商业工具同 OSSIE 的接口可能会招致问题(尽管 Zeligsoft 公司的工具支持 OSSIE 而且支持最新的 OSSIE 版本)。

OSSIE 使用全部的基本应用接口(Base Application Interfaces)来定义其部件和应用,问题仅仅是配置文件(Domain Profiles)的作用域而已。

OSSIE 设备部分遵循 SCA 系统部件的定义吗?它使用什么样的基本设备接口(Base Device Interfaces)?

OSSIE 也使用基本设备接口(Base Device Interfaces),其局限性仍就是其配置文件(Domain Profiles)的作用域。正如在 SCAv2.2.2 用于 CF::Devices 的扩展描述中所看到的,JTRS 对逻辑设备的概念同 OSSIE 对设备的用途是不同的。 对于 OSSIE 而言,设备接口的准确定义是,一个用于读取在 CF::Device 子类中被定义的确定设备的接口。 OSSIE 提供到 GPP 的设备接口(以 CF::ExecutableDevice 形式表现 ?),到 USRPv1.0 ( 以 CF::Resource 形式表现 ?),将很快也会提供接口到 FPGAs 和 DSPs。所没有提供的逻辑表现设备,只有 RS-232 或 以太网。

OSSIE 有方法生成定制设备(for custom hardware)吗,否则理应被理解为系统部件吧?

目前 OSSIE 的工具还不能(自动)产生设备代码。如果需要生成的设备代码的设备的数量不大的话,通过手动改动 GPP  例程便可很快生成设备(代码),因为它已经成为一个基本的代码框架(skeleton code。籍借脚本产生代码框架skeleton code是很简单的,每个文件只需 5 - 10 代码便可奏效,这包括 XML, CPP, H 和 makefile

试图把一个新设备纳入系统框架之中,必须对此特定设备生成设备代码并更新系统。实现它最好的方法是修改 GPP 设备文件。 把所有的 GPP.* 文件改名为
DEVICENAME.*,同时把文件内的所有关联做相应的修改。所需的需要定制的(对应特定的设备的)接口(诸如:配置、分配容量,等)须手动在相应的 DEVICENAME.cpp 编写。

直到 OSSIE 工具(能自动)支持这些步骤
为止,下面是目前手动操作这些的步骤:

设备文件(由 GPP 设备文件拷贝产生)已经存在,便需设备管理器同它相关联。这可以通过把设备文件添加到节点 DCD 文件(
node DCD file)来实现,同时把软件依附关系标标签(the dependency tag加到节点 SPD文件(the node SPD file)上来实现。

组成该设备的
部件需要同这个设备文件的依附关系相关联。 SPD 文件便需通过更新进而能够包含此特定设备文件所关联的依附关系标签(the dependency tag)和 UUID。

最后,想要运行已经部分包含或全部包含部件的设备的信号处理程序,程序需能够同该设备相关联。(为此)首先需把设备文件添加到 SAD 文件中,其次把设备和构建它的部件添加到 DAS 文件中。DAS 文件是由 OSSIE 产生的并被在目前充当布局样板的。

所列的所有关联工作的指导在下面的站点可以找到:
All of the instructions listed reference the work that is being done here:

(登录第一个站点需在 http://ossie.wireless.vt.edu/trac 注册并邮件你的用户 ID 来申请登录 ossie at vt dot edu 的权限)

以上篇幅概述的过程是用来产生并添加到信号处理程序的
Xilinx FPGA 设备用的。源码目录 …/ossiedev/trunk/ 下的如下内容也许会让你感兴趣:

components/TxDemo
platform/XilinxFPGA
nodes/default_ml403_node
waveforms/ml403_ossie_demo

目前这些内容还没有准备好被公开发布,也不想被问题、补丁修补诸如此类的事情所拖累。尽管如此,源码还是充当一个很好的在需产生一个新设备时所需添加的内容的典范(例程)。进而,产生和使用一个新设备的过程已经被言及,在
Matthew Carrick 文章中被更好而且详细的论述。这将在随后的一或两个月内面世。

如果 OSSIE 不能直接功能性地生成设备文件,为定制设备编写能够生成框架性的 C++ 代码、配置文件和 xml spd 和 scd 文件的脚本难吗?

编写能够生成代码框架(skeleton code)的脚本是极其简单的事情,每个文件仅需 5 - 10 代码即可,它包含XML, CPP, H and makefiles。

进而,安装定制设备到 OSSIE 环境从而使得它能够作为信号处理程序的一部分被用于 OEF 中难吗?

目前,传统的 OSSIE 信号处理开发者(OWD)允许生成新的节点或节点配置(每个节点包括被缺省在 /sdr/nodes/ 下目录。每个节点目录包含能够表述此节点有哪些设备的设备管理器的 XML 文件)。OWD 能被用来使用现有的设备(这也包括新开发的设备,一旦设备被生成,其二进制代码和 XML 文件便被安装在 /sdr/ 下相关的目录中)来产生节点。 Lab 7 (练习)提供机会练习生成和使用一个新的节点。 这个特征也被添加到 OEF。

OSSIE 在定义组成部件的端口的限制是什么? 能否定义一个多数据类型的端口,或 CF 类型的端口? 如何在 OSSIE 里生成一个 custom_ports 的部件? 生成一个可以由用户自由定义的订制端口类型的捷径如何?

OSSIE 目前支持多数据类型的端口定义的部件,其类型支持用于实现接口的任何数据类型。

为了构建一个新的接口,建议修改定制接口的 IDL 然后用 C++ 编写其构建代码。 不提倡添加代码到
OSSIE::standardInterfaces IDL 以便维护标准接口的一致性。

目前大多数使用如上描述的基本的方法来构建接口,它使用
metadata 有效地实现了多数据类型端口并用在 2007 的 smart radio challenge 活动中。使用它的同学们回想其过程相对地直接明了。 其相关部件使用客户端口"pushPacket"的方法(或类同的)来处理信号。在这届 smart radio challenge 所做的 standardInterfaces-MetaData 在下面网站可以找到:


最简洁的做法便是去如下网站浏览历来的修改版和源代码:
这需要先在  http://ossie.wireless.vt.edu/trac 注册并邮件你的用户 ID 来申请登录 ossie at vt dot edu 的权限.

OSSIE 的软件部件的端口和 OSSIE 的设备的接口是同一对象类型吗?如果不是,它们如何不同以及在构建客户端口时,尤其可能针对客户端口类型时,其难点如何?

部件和设备端口不是同一对象类型,但它们都支持相同的端口类型。如果想添加进现有的端口类型,必须先定义自己的 IDL。 不建议直接添加进 OSSIE::standardInterfaces IDL,其原因是这将玷污所谓“标准”的理念。OSSIE::standardInterfaces 定义了所有的最原始的类型的端口类型(诸如: int, double, char*, 等等。) 如果想扩展这些,不要使用这些原始类型,使用用户定制类型(user-defined)。如果要想使用这些原始类型,需要这些端口类型的一些额外功用,可以仿照前述的 OSSIE::standardInterfaces-metadata 类型处理方法相类似来对 OSSIE::standardInterfaces 进行扩展。

在 OSSIE 使用这些端口是 SCA 允许的子集,所有的部件类型也可以是端口类型。 OSSIE 支持这种诠释,但不提倡。原因是物理的区分端口和部件可以避免概念混淆。








注:OSSIEListFAQ(原文出处,翻译整理仅供参考!)