Комментарии 12
2) Драйвер вы загружаете при старте ОС или как службу? Надо бы его выгружать и все хуки отключать в нём даже при аварийном завершении приложения.
3) А чтобы с буферами и FIFO не было переполнений, то там же флаги есть, они аппаратно рулят и могут просигналить/тормознуть при заполнении или GPIF настроить (не помню).
При этом упомянуть существование CyUSB (и CyAPI) было нужно. Вдруг кто-то решит, что ему это подходит и дальше разберётся по документации? Во времена FX2LP я сам только так и работал.
2) Хоть WinUsb, хоть CyUSB, хоть UsbDK по умолчанию грузятся при старте ОС обычно. Если дадите ссылку на описание Вашего варианта, чтобы было ясно, как настроить и как действовать — будет полезно.
3) Конечная цель цикла — разработка анализатора с потоковой передачей данных, без буферизации на самой плате. Верхний предел скорости известен. ULPI тактируется частотой 60 МГц. Голова выдаёт 16 разрядные данные. Итого 120 миллионов байт в секунду. Если бы система не прогоняла через себя такой поток — дальше в неё играть было бы бесполезно. Вариант с буферным SDRAM уже есть, он описывался в нескольких статьях предыдущего цикла про Redd, а прогнать из SDRAM в PC можно и через USB 2.0. Так что надо было или 120, или нисколько. К счастью, всё прокачалось без потерь. Правда, с данными, которые могут то начать течь, то остановиться — есть ещё одна весёлость, о ней я расскажу отдельно.
«Проще взять драйвер, который будет работать с любым чипом.»Не так много контроллеров с поддержкой USB 3.0+. Я кроме Fx3 не знаю ничего доступного. Ну, а если ограничиться USB 2.0, то согласен с вами.
2) Посмотрите этот пример от Microsoft.
Что же до примера — мне почему-то кажется, что правильно спроектированный драйвер USB должен все зачистки производить по событию «отключилось приложение». Мало того, при выдёргивании-то уж из разъёма, сама система всё должна зачистить. Так что мне кажется, что этот вариант — уже излишество. Как минимум — никто же в жизни так не делает. Или, по крайней мере, мне не известно, чтобы делал. Всегда Windows даже если узнает устройство в новом разъёме — стремится установить его драйвер. Жёлтые восклицательные знаки в диспетчере устройств Windows — скорее исключение, чем правило, значит, драйвер старается быть установленным. Хотя, здесь всё это — не догма. Если окажется, что кто-то так делает — я сначала пощупаю на практике, а потом уже буду какие-то выводы для себя делать. Но пока не встречал именно для USB.
Что же до фильтра UsbDK- скорее всего, виновато именно то, что он хранит свои собственные списки, поэтому выдёргивание-вставка устройства и не помогает. Причём исходники у него открытые, наверняка всё можно поправить. Но внутри он достаточно сложен, поэтому на разбирательство нет времени.
Жду следующую часть!
На всякий случай: у libusb тоже (как и у WinUSB/CyUSB) есть асинхронное API (libusb_submit_transfer и компания). В случае с чтением одиночного куска разницы нет, а вот при длинных передачах разница в скорости между вызовом синхронной функции в цикле и поддержанием очереди из нескольких асинхронных транзакций может быть значительной.
Спасибо за ремарку!
Вызывать libusb_handle_events() чётко к моменту завершения каждой транзакции не обязательно, главное — "в среднем" успевать забирать данные в нужном темпе, а одиночные отклонения как раз сгладятся данным механизмом. Делаем submit сразу нескольким транзакциям (количество подбирали экспериментально), драйвер обрабатывает их по очереди и каждой сигналит завершение. Если в какой-то момент не успели поймать очередное завершение до того как произойдут следующие — не беда, следующий вызов handle_events() просигналит их все одно за другим.
Чтобы не "застревать" в ожидании событий есть libusb_handle_events_timeout(), которой можно задавать даже нулевой таймаут, обрабатывать только уже завершённые к моменту вызова транзакции (если есть) и сразу выходить.
Пример (несколько запутанный, но со всеми деталями вроде отмены транзакций): https://github.com/sigrokproject/libsigrok/blob/master/src/hardware/hantek-4032l/protocol.c
У Cypress что-то подобное по смыслу ещё в примерах к FX2 было (AppNote "как выжать 52МБ/с" и РС-часть Screamer demo).
120046706 Bytes / Sec
Это не из разряда «146%». Как я отмечал в тексте, на выходе ULPI чуть больше шестидесяти мегагерц осциллограф видит. Отсюда и набег.
Большое спасибо!
В целом — классно, а в частности — как исследую все детали, так опишу. Я собирался описывать это в плане большой и красивой кнопки Cancel, отображения процентов полученного буфера и т.п.
Добрый день, я, так получилось, сейчас разбираюсь с fx2lp и дошел до состояния мне нужна программа на ПК для связи с МК. Вы упомянули работу с ioctl напрямую с драйвером cy, не подскажете что это и как именно искать?
Учимся работать с USB-устройством и испытываем систему, сделанную на базе контроллера FX3