Question

我在Linaro上制作了一个设备驱动程序，用于控制Linux上的交换机和LED。

它们安装为/ proc / zedLeds和/ proc / zedSwitches

当从C生成的程序迭代地读取和写入各个驱动程序时，几乎没有延迟。当翻转开关时，相关的LED立即点亮。

我构建了GNU Radio模块（交换机源和led sink）来从GNU Radio做同样的事情。它们通过32k样品油门连接。运行此设计时，运行的时间越长，切换延迟变得越长 - ＆gt;照明。

我的方法与使用C方法基本相同，因此我不确定极端延迟的来源。无论有没有油门，我都试过了。

使用GNU是否只是占用了太多滞后于运营的资源？

这是包含所有项目文件的github。

https://github.com/minersrevolt/zedboard_gnuradio

结构：

├── gr-zedboard                   # gnu radio blocks 
    ├── lib                       # GRC Block source code
        ├──led_sink_impl.cc       # source code for LED Sink block
        ├──switces_source_impl.cc # source code for Switch Source block            
├── switch_led_drivers            # dev drivers for switch and leds
    ├── BOOT                      # files for BOOT partition of SD Card
    ├── led_driver                # contains LED device driver
    ├── switch_driver             # contains Switch device driver
    ├── testLED_SWITCH_DRIVERS.c  # C code showing functionality of dev drivers
├── switch_led_test               # example GNU Radio Companion build

Answer 1

像往常一样，打开文件一次，将文件句柄保存为块impl的私有成员，然后使用它。我们在您提出的每个问题中都讨论过这个我真的不明白你为什么还要这样做。我认为这将是我回答的最后一个与GR有关的问题，包括你遵循这种模式。这只是糟糕的设计，我们已经多次解释过这个问题。您是嵌入式开发人员，因此就像一个人一样。

使用GNU是否只是占用了太多滞后于运营的资源？

没有。您可能没有意识到油门挡块的作用 - 它确保通过的样品的平均速率大约是设定的速率。然而，GNU Radio处理＆＃34; chunks＆＃34;中的样本，即源将始终填充尽可能多的缓冲区。现在，油门挡块一下子就说10,000个样品;因此，它计算它必须等待1 / 3.2秒，直到它从输入复制到输出。当节流阀阻止其操作时，一次又一次地要求源生成样品，尽可能快。这些样本会累积，直到开关源的输出缓冲区已满，这意味着在处理完第一块样本后会立即显示节流，接受大量样本，因此会等待很长时间，等等。

与此同时，您调用了接收块的work方法;在你的情况下，它消耗了这10,000个项目中的1个，然后立即再次调用9,999，依此类推。

你可以减少＆＃34;块大小＆＃34;通过在节流块上设置最大输出样本数。但是，这不会影响到1的粒度 - 这根本不是GNU Radio的设计目标。

如果您需要速率限制，则应在源用户或接收器中实现，或者在用户区或驱动程序中实现。节流阀实际上只是用于纯模拟的流程图的工具，没有硬件输入或输出限制速率。

与C实现相比，使用GNU Radio的I / O较慢

1 个答案: