Про 3.0 пока слухи, но там у хоста будет возможность прям линию питания отрубить. То есть будет прям физическое выключение. Я вот тоже думаю если сигнал суспенд игнорировать, всмысле никаких действий прибором не делать, так как если управления по усб нет то чего ему работать, а так прям за потребление меньше 0.5 ма не биться, то и нормально... Очень уж не охото всю перефирию глушить, а потом при пробуждении обратно инитить...

УРА за АКАло.. Может кому то будет полезно...

Регистр USBCTRL в котором устанавливается режим чтения и записи. Эти биты снимаются если при записи записал все байты, или при чтении все прочитал. Но если эти биты оставить (получить длину пакета и выйти, или выйти с ошибкой до окончания чтения), ЛПЦ генерит при запросах какие-то ошибки и мигом происходит Ресет шины.

Команда Сет адрес действительно для насильной установке адреса требует двойного вызова. Потому как при одинарном вызове адрес присвоится только после удачной статус фазы сетап запроса. Что гарантирует ответ АСК по старому адресу и только после этого смену адреса как требует стандарт.

Последний вопрос который меня еще терзает, это очистка клеар регистров. Кто может внести ясность?
вот из мануала

For example, if VICSoftInt = 0x0000 0005 and bit 0 has to be
cleared, VICSoftIntClear = 0x0000 0001 will accomplish this. Before the new clear
operation on the same bit in VICSoftInt using writing into VICSoftIntClear is performed in
the future, VICSoftIntClear = 0x0000 0000 must be assigned. Therefore writing 1 to any
bit in Clear register will have one-time-effect in the destination register

Это верно только про этот регистр, или любой клиар регистр надо очищать, то есть делать вот так

DEVINTCLR = (USB_DEV_CDFULL|USB_DEV_CCEMPT); //clear all command int bits
DEVINTCLR = 0x00; //restore clr register
DEVINTCLR = (USB_DEV_CDFULL|USB_DEV_CCEMPT); //clear all command int bits

иначе повторный вызов не произведет никакой очистки...

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

П.С Всем спасибо кто учувствовал в дискуссии...

В текст пока не вникал, но хотелось-бы увидеть дескрипторы для начала.

Зачем?

Почему когда спрашиваешь как в ЛПЦ задать адрес, тебе расказывают что в стандарте усб есть команда сет адрес. Почему когда спрашиваешь как организована функция отсулки данных, тебя спрашивают а дескрипторы правильные?


С этой темой разобрались уже.

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

Пока не понял почему конечные точки находятся в состояние сталлед, хотя обмен дескрипторами идет уже нормальный.

И еще не выяснено как контролировать успешность отсылки данных хосту, просто флаг загружености буфера конечной точки не подходит, если начинать посылку сразу как убрался этот флаг, данные уходят неправильные...


А дескрипторы тут совершенно непричем...

Всем привет!

Извеняюсь с выбором подфорума, наверное сюда...

Кто реализовал усб на ЛПЦ2148 или подобных. Как вы реализовывали реакцию на запрос CLEAR_FEATURE?

Что то у меня часто ресет выходит...

Сам нашел ответ. может кому пригодится

При ресете нашине УСБ, ЛПЦ переходит в ресетное состояние. Сбрасывает релайзы на точках, очищает буферы, делает 0 адрес, и переходит в неконфигурированное состояние. Это кристал делает сам, а не просит от разработчика. Только флаги разрешения прерываний не трогает.
В итоге я терял пару конечных точку, потому и клиар фича появлялся, и АСКать на него не давало.