Медленный ввод / вывод с GNU Radio по сравнению с реализацией C
Я сделал драйвер устройства на Linaro, работающий на zedboard, для управления переключателями и светодиодами из Linux.
Они монтируются как /proc/zedLeds и /proc/zedSwitches
При итеративном чтении и записи в соответствующие драйверы из программы, сгенерированной на языке C, задержки практически нет. При переключении переключателя соответствующий светодиод загорается немедленно.
Я создал модули GNU Radio (переключение источника и приемника), чтобы сделать то же самое из GNU Radio. Они связаны дросселем образца 32 КБ. При работе этой конструкции, чем дольше она работает, тем дольше задерживается переключение -> подсветка.
Мой метод по сути такой же, как и метод 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
1 ответ
Как обычно, откройте файл один раз, сохраните дескриптор файла как закрытый член вашего блока impl и используйте его. Мы обсуждали это в каждом вопросе, который вы задавали. Я не очень понимаю, почему ты все еще делаешь это. Я думаю, что это будет последний вопрос, связанный с GR, на который я отвечу, и вы будете следовать этой схеме. Это просто плохой дизайн, и мы объясняли это много раз. Вы разработчик встраиваемых систем, так что ведите себя как один.
Может ли быть так, что использование GNU просто отнимает слишком много ресурсов, задерживая операции?
Нет. Вы, вероятно, не понимаете, что делает блок дроссельной заслонки - он гарантирует, что средняя скорость проходящих выборок примерно равна установленной скорости. Однако GNU Radio обрабатывает сэмплы в "порциях", то есть источник всегда будет заполнять столько буфера, сколько сможет. Теперь дроссельный блок раздается, скажем, 10000 образцов одновременно; поэтому он рассчитывает, что ему придется ждать 1/3,2 с, пока он не скопирует их с выхода. Пока дроссель блокирует свою работу, источнику снова и снова предлагается производить выборки как можно быстрее. Эти сэмплы накапливаются до тех пор, пока выходной буфер источника коммутатора не заполнится, что означает, что дроссель сразу после обработки вашего первого куска сэмплов встречается с большим количеством сэмплов, следовательно, ожидает в течение длительного времени и так далее.
А пока ты мойка work метод вызывается; в вашем случае он потребляет 1 из этих 10000 предметов, а затем немедленно вызывается снова с 9999 и так далее.
Вы можете уменьшить "размер куска", установив максимальное количество выходных выборок на блоке газа. Однако это не сработает до степени детализации 1 - это просто не то, для чего было разработано GNU Radio.
Если вам нужно ограничение скорости, вы должны реализовать это в своем источнике, или приемнике, или в обоих, либо в пользовательском пространстве, либо в драйвере. Throttle на самом деле просто инструмент для потоковых графиков, которые являются чисто симуляциями, без аппаратного ввода или вывода, ограничивающего скорости.