Форум: Техническая поддержка

Все собирается в Slackware 14.2 с ядром 4.4.14. Работу с ARM проверил в дистрибутиве Armbian (armbian.com) на платочке OrangePI PC.

Здравствуйте! Проверялась ли возможность работы модуля Е20-10 на частоте АЦП 10 МГц с платами OrangePi? Я запускал на двух платах - Orange Pi Plus 2 и Orange Pi Zero Plus 2, впрочем обе на процессоре Н3, armbian, ядро 3.4.113. Плата работает, данные корректные, но на максимальной частоте через некоторое время (20-30 сек) после начала непрерывного сбора в данных появляется мусор - выпадают отдельные биты. Скорости USB хватать должно - могут до 35 МБ/сек.
Понижение частоты до 7,5 МГц вроде решает проблему, но хочется все 10 МГц. Размер буфера 2400000 слов, Pages 100, IrqStep - 24000. Какие возможны варианты?

А увеличить ещё irqstep? У меня в примерах он вроде 32k... Именно на 10 МГц не проверял.

Увеличивал, до 32к, 48к. Так же - спустя некоторое время данные портятся.

смотреть надо. а пишутся данные куда? или в осциллографическом режиме портятся?

Данные пишутся на EMMC, но сам факт записи на проблему не влияет. Программа непрерывно анализирует данные от АЦП и при превышении порога буфер записывается. Проблема так и проявилась - при отсутствии сигнала на входах АЦП в буфере появляются ложные данные, на которые программа реагирует. При просмотре файла выглядят как одиночные редкие "вплески" одинаковой амплитуды и повторяющиеся на некотором канале.

Если прошивка FPGA не слишком старая (последняя 2.00.10), если потеря данных  связана с переполнением буфера внутри E20-10 по причине опоздания откачки данных со стороны ПК, то E20-10 должен отбрасывать данные буфера по кускам на границах кадра, чтобы не допускать "ложных данных" и перепутывание каналов. При новой прошивке, если видите именно "ложные данные", а не вырезание ограниченных кусков данных во времени, то это именно сбой буферизации на программном уровне в ПК, а не опоздание ПК откачки данных.

Прошивка FPGA последняя. А о чём может говорить то, что когда данные собираются нормально - светодиод на модуле АЦП мигает отчётливо, когда начинаются описываемые сбои - горит практически непрерывно?

а если синус подать и писать непрерывно? всплески это одинокие точки или импульсы из нескольких точек.

А какая ревизия модуля Е20-10?
А после подключения модуля к USB шине каким цветом загорается светодиод: красным или зелёным?

Опять же каким цветом 'практически непрерывно' горит светодиод: красным или зелёным?
Или может быть присутствует некое моргание красно-зелёного типа?

Именно одиночные точки. По ссылке снимки с экрана (PowerGraph) и записанный  файл данных (4 канала, просто данные, без заголовка) https://cloud.mail.ru/public/5HfB/SoBhKFBNX 
С синусом сделаю запись.

Модуль ревизии В, 2008 года. При подключении загорается зелёным.

Горит непрерывно зелёным и если присмотреться, то есть ещё быстрое еле заметное моргание красным.

@ SergeyVN:
Очень странное поведение светодиода.
Неплохо бы проверить как ведёт себя этот модуль на обычном настольном компьютере на частоте сбора 10 МГц?
USB кабель иcпользуется штатный?

Кабель штатный. На обычном ПК всё работает нормально. Нашел более свежий модуль е2010 (ревизия В.01, 2017 год) - светодиод ведёт себя так же (через некоторое время начинает гореть постоянно зелёным и проблескивает красный), но артефактов в данных не появляется - видимо более корректно отбрасывает не выбранные данные.

по идее это наверное режим переполнения. В нормальном режиме должен ритмично мигать зеленый. Самый легкий режим для проверки это просто запустить сбор данных на модуле и ничего не вычитывать из буфера те только драйвер будет слать запросы модулю и складывать данные в циклический буфер. Светодиод должен моргать зеленым, если нет значит производительности платочки недостаточно для работы на такой частоте. Возможно какие-то сервисы надо убивать в Linux.

Так и запускал, процессор практически в простое (загрузка 5-10%), серверный вариант Armbian, без десктопа. Похоже нашлась причина странного поведения - величину dKadr ставил в 0, драйвер автоматически выставлял минимальную задержку в один отсчёт 1/dRate как 0,0001 для 10 МГц, на ПК работало нормально, на OrangePi - сбои. Если на OrangePi вручную задать dKadr больше времени одной выборки, например, 0,0002  для 10 МГц - светодиод мигает ритмично и не "залипает".

если кадр такой задать то поток считайте стал как 5МГц.  в кадре оцифруется с частотой 10, а частота кадров 5. на ПК под линукс как работает?

Да, я почему-то решил что dKadr это между IrqStep отсчётов. Вообще, написано dKadr интервал между кадрами, то есть это межкадровая задержка? Тогда он ведь должен быть равным 0 мс для максимальной частоты, а не 1/dRate?
На ПК под линукс работает нормально.

Тогда значит не тянет. ну она 0 если считать базовым объектом - отсчет+задержка

Вот это и не понятно, реальная скорость USB у платки - 33 МБ/сек, какие-либо настройки или оптимизации драйвера невозможны?

ну кроме увеличения irqstep ничего там не настроить. и еще вопрос в том кто и как скорость usb измерял. если есть флешка usb3.0, то сколько она показывает на чтение очень большого файла?

Флешка USB2.0, на своей плате:
time dd if=/mnt/out1G of=/dev/null
2048000+0 records in
2048000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 31.1417 s, 33.7 MB/s

При частоте 10 MГц  и скорости 20 Мбайт/c размера буфера E20-10 хватит на 0,4 с. Если переполнение буфера возникает при значительно большей средней пропускной  способности данного USB-порта, то значит, в данной программной среде  возникают асинхронные задержки откачки данных более 0,4 с.
Кстати, современная элементная база позволяет многократно увеличить объём памяти в проекте E20-10, и при наличии заказа можно это реализовать. С другой стороны, до сих пор считалось, что размера буфера АЦП на время 0,4 с вполне достаточно для непрерывного сбора данных (есть примеры других АЦП непрерывного сбора, где объёмы буферов значительно меньше в пересчёте на время записи).

Не похоже. Собрал RealTime ядро - результат ровно тот-же. Именно спустя несколько секунд (порядка 5) после начала сбора данных возникает переполнение буфера, то есть данные забираются из АЦП чуть медленнее, чем нужно. Видимо режим чтения USB-накопителей реализован как-то более оптимально, может с учётом специфики процессора.

скорей всего есть разница в алгоритмах. я ставлю запрос -(тут есть  задержка как в виде сбора данных так и прихода callback вызова)  ловлю callback готовности - забираю данные - ставлю запрос. при чтении с флешки можно ставить запросы не дожидаясь готовности. и будет безразрывный поток запросов на usb, а так видимо слабый проц плохо отрабатывает callback и копирование данных.