-1

我在 Linaro 上制作了一个设备驱动程序，运行一个 zedboard 来控制 Linux 的开关和 LED。

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

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

我构建了 GNU Radio 模块（开关源和 LED 接收器）来从 GNU Radio 做同样的事情。它们通过 32k 采样节流阀连接。运行此设计时，它运行的时间越长，切换-> 照明的延迟就越长。

我的方法与使用 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
4

1 回答 1

1

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

会不会是使用 GNU 只是占用了太多落后于操作的资源？

不。你可能没有意识到节流块的作用——它确保通过的样本的平均速率大约是设定的速率。然而，GNU Radio 以“块”的形式处理样本，即源总是会尽可能多地填充缓冲区。现在，油门块被传递，假设一次有 10,000 个样本；因此它计算出它必须等待 1/3.2 秒才能将这些从输入复制到输出。当节流阀阻止其操作时，源被一次又一次地要求以尽可能快的速度产生样本。这些样本不断累积，直到您的切换源的输出缓冲区已满，这意味着油门在处理完您的第一块样本后立即进行，收到大量样本，因此等待很长时间，依此类推。

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

您可以通过在节流块上设置最大输出样本数来减小“块大小”。然而，这不会降低到 1 的粒度——这根本不是 GNU Radio 的设计目的。

如果您需要速率限制，您应该在源或接收器或两者中实现它，无论是在用户空间还是在驱动程序中。Throttle 实际上只是一个纯模拟流程图的工具，没有硬件输入或输出限制速率。

于 2016-05-07T19:58:46.783 回答