Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Страницы 1
Здравствуйте, Алексей.
Разобрался с проблемой. Как говорится "дело было не в бобине...". Проблема с приёмом данных возникала в буфере USB HUB, драйвер dwc_otg по умолчанию использует быстрые прерывания (fiq) и обработчик fiq_fsm. Который, как раз и теряет буфер хаба. Чтобы избавится от данной проблемы нужно в "/boot/cmdline.txt" добавить несколько параметров старта ядра:
dwc_otg.fiq_enable=0 -для отключения использования fiq
dwc_otg.fiq_fsm_enable=0 -если не отключить fiq_fsm то kernell всё равно запустит fiq а следом и fiq_fsm.
dwc_otg.nak_holoff=0 -для отключения задержки между повторными прерываниями.
И всё работает, уже в течении суток.
Алексей, благодарю за помощь. Всего наилучшего.
Здравствуйте, Алексей.
А можно несколько примеров возвращаемого значения функцией Recv, когда оно не совпадает с запрошенным 131072 (в примере значение переменной rcv_size), чтобы понять порядок отличия. И это различие всегда разное?
READ_BLOCK_SIZE = 131072 -- rcv_size =12367
READ_BLOCK_SIZE = 131072 -- rcv_size =131070
Из проведённых тестов могу сказать что всегда разное, один раз попалось отличие в один отсчет.
Частота АЦП у Вас при этом 2 МГц?
Да частота выставлена 2 МГц.
Ну 600 мс не такой большой таймаут, визуально задержку одного Recv на это время может быть не так просто заметить, или как Вы проверяете, что таймаут не истек? Можете программно засечь время выполнения Recv, а то что-то не вижу способа выйти из этой функции, кроме как по ошибке, таймауту или приему всех данных.
Вы абсолютно правы, Алексей. Измерение выполнения функции Recv(), подтвердило выход по тайм ауту.
Т.е., если при нормальном выполнении функции время колеблется в пределах 440 - 460 мс, то при ошибке равно тайм ауту. Увеличил тайм аут до 1000.
время выполнения функции составило 914 мс.
READ_BLOCK_SIZE = 131072 -- rcv_size =131072
ОШИБКА -140, по прежнему на месте.
Думал что симптомы похожи на отключения портов при нехватке питания но замена блока питания на 5V 3.5 А не помогла. Всё по прежнему.
И ещё просмотр логов системы не дал ни каких результатов.
Здравствуйте, Алексей. Постараюсь ответить на все вопросы.
В смысле Recv вернул меньше, чем запрашивали? При этом именно на том блоке, где ошибка (или сперва блок меньше размером, а в следующем ошибка)?
Параметры READ_BLOCK_SIZE=131072 и READ_TIMEOUT=600. Как я понял размер буфера возвращаемого Recv() равен 131072 значений, при этом функция вернёт эти данные не дожидаясь таймаута, согласно руководству программиста. Далее. Да, функция возвращает блок меньшим размером чем запрашиваемый и соответственно последующий вызов функции ProcessData() возвращает ошибку.
Cбой последовательности при этом именно в принятой части (т.е. в отсчетах с номером до того, что вернула Recv())? Время выполнения функции при этом соответствует таймауту? Т.е. Recv именно подвисает на время таймаута, что Вы задали, или по каким то причинам выходит раньше?
Сбой последовательности отсчетов именно в середине последнего принятого блока. Время выполнения функции Recv() при этом меньше установленного таймаута также как и в предыдущих вызовах данной функции, т. е. как я понимаю драйвер считает что он принял все отсчеты правильно.
Если после этого сделать еще Recv(), несмотря на ошибку, то данные какие-то придут или после этого вообще прием останавливается?
Если же проигнорировать ошибку и вызвать ещё раз Recv(), то программа продолжает работать. Т.е. как вариант решения данной проблемы. Но хотелось бы не терять ни одного отсчета. В L-Card Measurment Studio такая же ситуация, выдаёт ошибку -140 и продолжает показывать графики пока не закроешь окно об ошибке, только после этого сбор данных с ацп прекращается.
Если перед Recv() буфер явно обнулить все данные, то на данные это как-то повлияет на выходе (т.е. это именно разрыв в новых данных или может он по каким-то причинам не заполнил часть буфера и это остались данные от старого цикла в буфере)?
Обнуление буфера перед вызовом Recv() не дало эффекта, в данных также имеются разрывы, самое обидное это когда пропущен отсчет в по каналу в последнем кадре.
И это реальный пример, что разрыв по сути 2 раза через одно слово (нет D0 перед D1 и D2 после D1)?
Да это реальный пример. Только разрывы носят произвольный характер, может быть пропущен один отсчет в самом последнем кадре буфера.
Здравствуйте Алексей. Потерю отсчетов выявил просматривая проблемную часть буфера, оказалась нарушена последовательность нумерации каналов. Также мне пришлось немного переписать код. (-- -- 00 D0 -- -- 00 D1 -- -- 00 D2 -- -- 00 D3 -- -- 00 D1 -- -- 00 D3). Плюс размер буфера был меньше заданного (timout установил заведомо большим). Отключение цифровых входов и изменение частоты не как не влияет на возникновение данной ошибки. Что как мне кажется указывает на причастность OS к данной проблеме.
При просмотре сохраненного буфера, выяснилось что потеряна часть отсчетов. В OS Ubuntu 16.04 такой проблемы нет, от слова совсем. Тестировал в течении трёх недель. Я так понимаю данная проблема связана с самой OS Raspbian. Подскажите пожалуйста как с этим справиться.
Добрый день.
Для начала на всякий случай проверьте версии прошивок ARM (последняя 1.0.20) и ПЛИС (из последнего sdk с сайта). По крайней мере на последних версиях такого быть не должно.Если обновление не поможет, тогда видимо нужно будет сохранять в файл поток из Recv до ProcessData, чтобы увидеть, как выглядит нарушение данных. Работаете по USB или Ethernet? В примере сами настройки сбора данных изменяли или вообще никаких правок не было?
Какой дистрибутив Linux используете?
Алексей, здравствуйте.
Версии прошивок: fpga=0.14, plda=2,mcu_firmware=1.0.20.0.
АЦП подключен по USB. В примере никаких настроек не менял. Изменил цикл с for на while. Для написания программ пользуюсь Code::Blocks IDE.
OS Raspbian 9.
Здравствуйте. Подскажите пожалуйста, почему возникает ошибка -140 при вызове функции X502_ProcessData(), при чем характер возникновения, не регулярный. Т. е. может обработать 1 блок и выдать ошибку, а может и 12к блоков обработать. Исходный код взят из примера x502_stream_read без изменений.
Страницы 1
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск