Особенности at90usb162 - USB HID feature Get репорт. Опции

[QuickWitted]

Здравствуйте.

Не подскажет ли доброуважаемый Алл
куда физически приходит запрос на feature Get репорт в at90usb162?
(Что теоретически он в нулевой едпоинт приходит - знаю).

пред история:

Я разрабатываю очередной не коммерческий USB девайс на at90usb162
(для общего пользования)

Потребовалось ввести report_feature в приложение. Раньше на меге8
и асме я легко ее вводил - там юсб софтовый и если написано что он
приходит в 0 ендпоинт, оно туда и приходит...

а точнее он приходил в 0 ендпоинте в блок установки адреса устройства,
вот сюда
.def MyUpdatedAddress =R14 ;my USB address for update
.def MyAddress =R15 ;my USB address

Тот мой проект работает до сих пор ( http://mindrunway.ru/SUps2.html )

Но с аппаратным USB на at90usb162 возникли небольшие грабли...
Для простоты я решил полностью повторить софтовый проект и отладить обмен.
(т.е. дескриптор правильный и софт с ним работает)

В общем, отправить содержимое Get репорта без запроса - я могу...
Set репорт приходит в мой асмовый аналог сишной usb_process_request() и нормально отлавливается.
но вот отловить запрос, по которому надо ШТАТНО отправить Get репорт - у меня не получается.
(в аппаратном юсб адрес выставляется без участия программы пользователя и наработки софтового
юсб немного не применимы)

т.е. проблема в том, что Get репорт не меняет содержимое UEINTX у нулевого ендпоинта
(повторюсь Set репорт меняет там бит RXSTPI и отлавливается)...
(повторюсь в софтовом варианте Гет приходит в 0 ендпоинт в процедуру установки адреса устройства)

В енете долго и упорно искал - с нулевым результатом...

Точнее из готовых примеров на feature репорт есть только пример входа в бут блок.
(это тот же Set репорт только с ошибкой в подтверждении приема данных для компа,
но для бут блока это не важно, получил команду и в бут...)

[hd44780]

Родственная беда. На AVR-Obdev как часы, а на PDIUSBD12D те же дескрипторы не фурычат.
Решения так и не нашёл . Равно как и примеров реализации USB HID устройств. Натыкался только на CDC и Mass Storage, но это не то ...

[QuickWitted]

Родственная беда. На AVR-Obdev как часы, а на PDIUSBD12D те же дескрипторы не фурычат.

вот с дескриптором В МОЕЙ ЗАДАЧЕ проблем нету...

Решения так и не нашёл . Равно как и примеров реализации USB HID устройств.
Натыкался только на CDC и Mass Storage, но это не то ...

Чего?

если сменить дескриптор и пару обработчиков, то CDC сам собой преобразуется в HID
На ат9юсб162 с перекурами и припаиванием мах232 для дебагинга
(к плате моего же проекта Twinkling Plug) занимает 5 часов.
вместе с отладкой в юсблизере и написанием тестового софта на дэльфи.

откуда знаю - вчера проверил...


Только мне Гет репорта хочется - хотя и не фатально я через Джеди могу и обычные репорты ловить...


Сообщение отредактировал QuickWitted - Jul 19 2012, 07:57

[vgo1]

Если не ошибаюсь, до того как послать Get Report, host посылает Setup Set Configuration, в ответ на что device включает ту конфигурацию которая была указана в Configuration Descriptor-е, то есть активирует какой то отличающийся от нулевого INPUT Endpoint. Навено туда и должен поступать запрос Get Report. Попробуйте прочесть UEINTX етого Endpoint-а, может там увидите RXSTPI.

[QuickWitted]

Если не ошибаюсь, до того как послать Get Report, host посылает Setup Set Configuration, в ответ на что device включает ту конфигурацию которая была указана в Configuration Descriptor-е,
то есть активирует какой то отличающийся от нулевого INPUT Endpoint.

Да, но там одна конфигурация. прикладываю дескриптор  Fu.rar ( 3.23 килобайт ) Кол-во скачиваний: 81

(повторюсь софтовый вариант с этими же настройками (ну кроме юсб2,0) работает....)

и в аппаратном варианте оно работает, если бы на этом этапе не прошло, то я бы не проинитил ендпоинт...
а он инитится и без ГЕТ я могу заслать через него пакет от МК в ПК...

Навено туда и должен поступать запрос Get Report. Попробуйте прочесть UEINTX етого Endpoint-а, может там увидите RXSTPI.

Этот путь я проверял - 3 бит равен нулю - см ниже.

Код

;STALLEDI (1 бит) флаг прерывания STALLEDI
;Устанавливается аппаратно для указания, что был послан ответ STALL или обнаружена ошибка CRC для
;OUT изохронной конечной точки. Должен быть сброшен программно.

;RXSTPI (3 бит) флаг прерывания при получении SETUP
;Устанавливается аппаратно для указания, что текущий банк содержит достоверный SETUP пакет.
;Возникает прерывание (EPINTx) (если разрешено). Должен быть сброшен программно для подтверждения
;получения прерывания. Этот бит не активен (сброшен) для IN конечных точек.

Отдельно замечу
Этот бит не активен (сброшен) для IN конечных точек.

На Out - от компа (нулевой) - UEINTX были замечены след значения
;0x53 = 01010011
;0x47 = 01000111
RXSTPI - тут мониторится и сбрасывается по генерации стандартных запросов
Гет не вызывает изменения значения UEINTX

;IN - в комп (первый) - UEINTX были замечены след значения
;0xA1 = 10100001 - готов к приему
;0xE1 = 11100001 - передержали
RXSTPI - тут не ставится
Гет не вызывает изменения значения UEINTX

В енете нашел вот это описание (пока малопонятное и не факт что правдивое)

Код

т.е. приходят данные от кома (вместе с Set Report) и запросы (на выдачу репорта Get Report)
в control-in (токен STALL...), а выгружается запрошенное через первый ендпоинт (Get Report)...

Хотя STALLEDI в регистре UEINTX - отвечает за STALL... но я пробовал его сбрасывать в 0 ендпоинте
при гет он не появляется и я не уверен что я правильно его сбрасываю (что еще требуется изменить до
или после изменения этого бита?)

Сообщение отредактировал QuickWitted - Jul 20 2012, 02:37

[vgo1]

Я STALL посылаю когда получаю такой SETUP, на который мой прибор не может ответить. Делаю это установкой бита STALLRQ в UECONX. По даташиту после этого прибор должен STALL-ом ответить на все последующие SETUP-ы, но я этого не замечал. Мое устройство после этого получает новые SETUP-ы и я их обрабатываю. Бит
STALLEDI устанавливается после посылки STALL. Я его стираю простым обнулением во время handshake фазы в Status Stage-е, вместе с RXSTPI, при следующем трансфере. Вроде больше ничего не надо.

[QuickWitted]

Вроде больше ничего не надо.

Для работы без Гет репортов больше ничего не надо, оно и так работает...

Но вопрос остается в силе. Для удобства разделю по пунктам:
1) Кто нибудь работал с Гет запросами?
2) Если не работали, то хоть теоретически на какой ендпоинт (0 OUT или 1 IN) должен приходить запрос на Гет?
3) в виде чего (какого состояния на шине) он должен приходить?

Я его стираю простым обнулением во время handshake фазы

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

ИМХО преимущества Гет запроса перед СДС и обычным ХИД
1) данные в отличии от СДС идут пакетами и винда их временами не теряет.
(на сдс приходилось отлавливать не полные пакеты)
2) в отличии от обычного ХИД данные идут не вообще нагружая мк и комп, а
так же как и в СДС только по требованию алгоритма обмена.
3) проще писать головное приложение распределяющее данные по клиентам.

Сообщение отредактировал QuickWitted - Jul 20 2012, 15:55

[QuickWitted]

Я STALL посылаю когда получаю такой SETUP, на который мой прибор не может ответить.

Просто мысли в слух.
Если никто не знает как отловить Feature Report запрос метода Get на ендпоинт (предположительно нулевой) класса Interrupt
(для посылки через 1 ендпоинт пакета), может Interrupt в описании дескриптора первого ендпоинта на что нибудь поменять?

Бывают еще Bulk и Isochronous. Их не легче будет отловить?

Кто с ними работал? куда они приходят?

И приходят ли вообще/совместимы ли с Гет?
Т.е. комп запрашивает у девайса репорт через метод Гет, а девайс должен ответить...
с Interrupt я завяз - ищу другие варианты.

Сообщение отредактировал QuickWitted - Jul 27 2012, 02:32