与C实现相比，GNU无线电的I/O速度较慢

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

它们安装为/proc/zedLeds和/proc/zedLeds开关

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

我构建了GNU无线电模块（开关源和led接收器），以便在GNU无线电上做同样的事情。它们由一个32k样品节流阀连接。运行此设计时，它运行的时间越长，切换-->照明的延迟就越长

我的方法基本上与使用C方法相同，因此我不确定极端延迟来自何处。我试过有油门和没有油门

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

---

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

结构：

├── 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

---

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

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

不知道。你可能还没有意识到节流阀块的作用–它确保样本通过的平均速率与设定速率接近。然而，GNU无线电以“块”的形式处理样本，即源总是尽可能多地填充缓冲区。现在，节流块被递上了，比如说，一次有10000个样品；因此，它计算必须等待1/3.2秒，直到它将这些从输入复制到输出。当节流阀阻止其运行时，源会一次又一次地被要求以尽可能快的速度生产样品。这些样本不断累积，直到开关源的输出缓冲区已满，这意味着在处理第一个样本块之后，节流阀会立即收到大量样本，因此会等待很长时间，以此类推

同时，调用sink block的

work

方法；在您的情况下，它消耗了这10000项中的1项，然后立即用9999再次调用，以此类推

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

---

如果您需要速率限制，您应该在源或接收器中实现，或者在userland或在驱动程序中同时实现。油门实际上只是纯粹模拟流量图的工具，没有限制速度的硬件输入或输出。

我认为问题最有可能是我必须打开和关闭相应驱动程序的频率。。。我不知道从GNU广播块的上下文中了解这一点。你不应该把这个添加到注释中，而是改进你的代码。马库斯，我把你的责骂放在心上，花了几天时间通过C++的速成课程，熟悉了课程。我以前所做的一切都是试图在C++中实现这一点，但这并不是有效的。我创建了类构造函数和解构器函数，以使驱动程序在整个流期间保持打开状态。它当前正在读取/写入第一个值，然后每个后续值都会得到一个全零输出。不管怎么说，我只是想对之前的帮助和艰难的爱表示感谢；这有帮助。还在努力。