Neekeetos

Допустим xc7a100t на отладочной плате, опорный генератор 125мгц, pll создает из этого 1000мгц затем эта частота делится на два и используется для захвата входного сигнала (50мгц с кварцевого генератора). линия имеет длину чуть менее 2нс, один отвод линии соотв порядка 10пс. На графике выведен номер отвода где был зарегистрирован фронт входного сигнала. Понятно, что джиттер который зарегистрирован, связан с шумом плл, а не входного генератора. Даже видно выбросы - наводки по питанию плис от импульсного источника, с размахом 200пс. PS график "линейный" потому что входная и частота захвата взаимно кратны и лишь слегка отличаются по частоте. Плата на спартан 6, примерно похожие условия(чуть меньше частота захвата линии и больше ее длина), pll с узкой полосой: с широкой:

https://www.eevblog.com/forum/testgear/hantek-6254bd-250mhz-1gsas-pcusb-dso/msg2758360/#msg2758360 Вместе с инструкцией по прошивке. К сожалению нашел что оригинальная прошивка имеет баги. К примеру вход управления фифо настроен как выход у китайцев. Так что я сделал из кипарисовского примера прошивку с аналогичной конфигурацией эндпоинтов.

Использовать в качестве модели коллектив почты России Для этого 1) собрать статистику по работе одного из отделений для каждого работника, включающую время отдельных операций и показатели эффективности 2) обучить нейронную сеть-классификатор по полученным данным, в качестве выходных параметров используя эффективность работы группы сотрудников 3) полученную модель использовать для моделирования совместно с моделью для роботов для выяснения целевых показателей Если серьезно, то, по моему, задержка линии связи не должна влиять на результат если частота выполнения отдельных операций координации роботов (ака события синхронизации) больше (чем эта задержка).

Я так понимаю они в лучшую сторону отличаются? Если такие жесткие спецификации может купить прибор который им удовлетворяет а не играть в угадайку? Достоверность измерений все равно будет не лучше указаных в дш.

Так намного понятнее! Что помешало поглядеть в даташит приборов и сравнить указаные там величины?

Чем дальше в лес тем толще партизаны. Я предлагаю превратить изначально бесполезный эксперимент обмера SMU без нагрузки в более интересный, измерив стабильность выходного напряжения в каждом из 4 квадрантов под нагрузкой. Думаю это само по себе будет увлекательным упражнением.

Я вижу там быстрые установки на приборе выбираются, для тех кто не понимает что такое SMU :) Инженеры кейтли подозревали что такие найдутся...

Не знаю, мне просто стало любопытно зачем понадобилось измерять блок питания внутри прибора. Если нужно измерить стабильность выходного напряжения , то почему так и не написать? Внутренняя кухня по идее и нужна для того чтобы не называть выход SMU блоком питания?

Тут наверно закралась ошибка, выходное напряжение SMU это не напряжение его блока питания. Но допустим были выведены наружу напряжения "блоков питания", их несколько и их стабильность на параметры прибора особо сильно не влияет. Допустим имелась в виду стабильность выходного напряжения , а попытка была измерить внутренний ИОН прибора. Тогда это некорректное измерение по другим причинам - выходное напряжение зависит от многих факторов, например от нагрузки, которой на фото не заметно.

А если сделать буфер 256к , то процесс нормализуется, скорость примерно достигает 42МБ/с. Интересно что будет если применить асинхронные вызовы libusb...

Я и не меняю, он уже не является стандартным в связи с вышеуказанными обстоятельствами :) PS Так, чтото зашевелилось :). Без каких либо оптимизаций получилось в районе 30мб/с из кипариса в компутер . Просто синхронные вызовы libusb. Флажок загрузки fifo на графиках , примерно показывает загрузку юсб. При детальном разглядывании видно паузу в передаче с частотой синхропакетов USB - 125мкс . Также видно что надо оптимизировать работу с юсб, данные не успевают считываться, интервалы считывания нерегулярные.

Тут стало понятно что сварщик то я ненастоящий. Устройство - это самоделка, оно в единственном экземпляре и является макетом на котором я учусь чтото делать с плис. Саму прошивку для кипариса я взял от юсб осцилографа, в котором хочу использовать ацп , и в перспективе придется перекачивать данные с него, так что может получится убить двух зайцев, ну или как обычно ни одного :). Отладка драйвера вроде как не требуется, просто он не ставится без сертификата.

Так я с этого и начал, драйвер при смене пид/вид требует подписи под 10кой. Соотв так просто нельзя его поставить на произвольное юсб устройство. Мне это важно поскольку я прошивку кипариса использую готовую, где фифо настроено нужным образом. Я напрямую его не использую, через libusb. По скорости смогу сказать только когда попробую. В libusb асинхронные передачи реализованы, по идее они должны транслироваться в цепочки буферов и соответствующие вызовы winusb, но это неточно. В любом случае у меня задача прикладная, хочется малой кровью организовать передачу данных с плис, сильно углубляться в общение с драйверами не хотелось бы.

Может я конечно не разобрался, но они предлагают два пути. 1) IOCTL напрямую с драйвером , примеров нету 2) CyUSB.dll , длл которая экспортирует интерфейс в виде классов дотнета . Все примеры работают через нее. Соотв (1) представляется довольно проблемным вариантом. (2) собирается только в студии. В новом SDK FX3 уже примеры с libusb , поэтому я подумал что это вариант предпочтительнее. Он еще удобен тем, что я могу поставить драйвер WinUSB на любое устройство в отличие от нативного.

Я сейчас пришел к тому, что оригинальный драйвер не буду использовать тк он завязан на дотнет. Текущий вариант поставить универсальный драйвер WinUSB на кипарис и через него с помощью libUSB 1.0 что-то делать. Сейчас сделал программку для винды, теперь надо с обратной стороны тестовую заглушку для плис сделать, чтобы в фифо лить непрерывно данные и смотреть что там за скорость получается.