GNUラジオでのI/Oの遅さがCの実装と比較されました

Question

LinuxからスイッチとLEDを制御するために、Linaroでzedboardを実行するデバイスドライバを作成しました。反復読み取り、C-生成プログラムから各ドライバに書き込むときには/ proc/zedLeds及び/ PROC/zedSwitches

として実装されている

は遅延なしに次があります。スイッチが反転すると、関連するLEDがすぐに点灯します。

私はGNU Radioから同じことをするためにGNU Radioモジュール（スイッチソースとLEDシンク）を構築しました。それらは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 

Answer 1

、一度ファイルを開いて、あなたのブロックのimplのプライベートメンバーとしてファイルハンドルを保存し、それを使用しています。私たちはあなたが尋ねたすべての質問でこれについて議論しました私はあなたがまだこれをやっている理由を本当に理解していません。私はこれがあなたがこのパターンに従うことを含む、私が答えた最後のGR関連の質問になると思います。それは単に悪いデザインであり、我々はこれを複数回説明した。あなたは組込み開発者なので、同じように行動します。

GNUを使用すると、処理に時間がかかり過ぎるリソースが多すぎるかもしれませんか？あなたはおそらく実現していない

号は、スロットルブロックを有する何 - それは通過してサンプルの平均レートが設定レートについてであることを確認します。しかし、GNU Radioはサンプルを "チャンク"で処理します。つまり、ソースは常にできるだけ多くのバッファを満たします。さて、スロットルブロックが手渡され、一度に10,000個のサンプルが聞こえます。したがって、これらをインからアウトプットにコピーするまで1/3.2秒待たなければならないと計算されます。スロットルが動作をブロックしている間、音源はサンプルをできるだけ早く生成するように繰り返し求められます。これらのサンプルは、スイッチソースの出力バッファがいっぱいになるまで蓄積されます。つまり、最初のサンプルチャンクを処理した直後にスロットルがあり、多くのサンプルが歓迎され、長い時間待つなどです。

その間、シンクブロックのworkメソッドが呼び出されます。あなたのケースでは、これらの10,000個のアイテムのうちの1個を消費し、すぐに9,999などで直ちに呼び出されます。

スロットルブロックに出力サンプルの最大数を設定することで、「チャンクサイズ」を小さくすることができます。しかし、これはGNU Radioが設計されたものではなく、1の細かさまでは機能しません。

レート制限が必要な場合は、ユーザーランドまたはドライバのいずれかで、ソース、シンク、またはその両方に実装する必要があります。スロットルは実際には純粋なシミュレーションであり、速度を制限するハードウェア入出力がないフローグラフのツールに過ぎません。