В общем дело так, заметил я некую странность еще со времен 2148 - если запретить прерывание по используемой IN ep (необработке его до следующего кадра?), то больше оно не возникает. Прерывание сбрасывается только путем установки бита USBEPINTCLR. Пришлось обрабатывать всегда, даже если нет данных в направлении хоста.

Теперь существующие наработки пытаюсь перенести в 2388 и сделать все под OS: при открытии полученного виртуального COM порта пропадает прерывание IN ep!
Если в обработчике сбрасывать прерывание путем команды "Select Endpoint/Clear Interrupt ", то прерывание почему-то не сбрасывается, обработчик зацикливается.
Если же сброс прерывания осуществлять и путем выполнения команды, и установкой бита в USBEPINTCLR - то все работает замечательно.

Как то реальность расходится с опсанием процесса:

Выходит, эти 2 действия не равнозначны?

А зачем его запрещать? Оно вроде как и не возникает без повода (при отсутствии передачи в хост)...
ЗЫ: Я тоже использую оба действия: в начале обработчика - команду, в конце - сбрасываю бит. Почему? Так получилось...

Возникает.

Возможно можно обойтись и без прервания по NAK, но я то переделывал IARовский HID когда только-только начинал разбираться с USB. И передача организовал так, что данные отправляются из кольцевого буфера в прерывании по IN ep.
Хотел запрещать прерывания если нет данных и вновь разрешать при отправке данных. Не получилось

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

Они как раз возникают часто - когда хост читает пустой буфер (если нет данных или не успели поместить данные в endpoint). Хост хочет читать - присылает IN, а в ответ ему NAK (нету у нас пока ничего) - тут то и возникает это прерывание. Другое дело что без этих NAK-ных прерываний следует обходиться - как раз из-за того что они частые.
А вопрос топикстартер поднял интересный - у самого прерывание по команде SelectEP не сбрасывается (приходится дополнительно регистром пользоваться), тоже не отказался бы узнать в чем тут дело.

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

Ну да, я тут лопухнулся чуток... Сейчас проверил - запретил NAK-прерывания от IN ендпоинта - полет нормальный.

Это если endpoint типа interrupt. А если bulk?

Если Interrupt - то реже. Если булка - то каждый фрейм. Если точка сказала NAK - то более в текущем фрейме к ней обращения нет. Чтобы понять мехаинизм передачи получше, надо понять как устроен USB хост!

Хотя про безобидность - я поспешил. Если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!!

**** По теме *****
В общем методом научного тыка было установлено, что если выполнить
USB_Cmd(CMD_USB_SET_MODE, INAK_BI | INAK_BO);
то при сбросе прерывания IN ep только битом они более не возникают. При разрешении только INAK_BI или вообще запрете NAK прерываний - все работает отлично.
Все сказанное относится к BULK точке

То есть я правильно понял, в документации союз "or" неверно отражает ситуацию? В строчке "This command may be invoked by using the USBCmdCode and USBCmdData registers, or by setting the corresponding bit in USBEpIntClr."

Да, такое ощущение, что эти 2 действия происходят по разному. CmdCode и USBEpIntClr обрабатываются по разному.
CmdCode не сбрасывает (не всегда?) бит прерывания, а USBEpIntClr не всегда сбрасывает триггер установки флага прерывания EP

А можете это ссылкой на соответствующее место в стандарте подтвердить? А то мне кажется, что для bulk отдается вся свободная полоса, и IN соответственно может быть не один, невзирая на полученный ранее NAK.

А я сейчас как раз хост пишу - OHCI на LPC2388. И нету там в дескрипторах бита типа "вот в этом фрейме у нас был NAK, больше IN не делать", соответсвенно bulk/contol list обрабатываются многократно - пока фрейм не закончится (или список) - и IN-ов может быть во фрейме много. Для EP типа interrupt - согласен - periodic list обрабатывается один раз за фрейм - соответственно IN будет только один.

Ну дык, неудивительно - при пустом буфере IN/NAK происходят в течение фрейма многократно, а не один раз. Измерьте частоту прерываний и убедитесь.

А я хост уже написал!
Так вот, как я понял, есть список связанных ED к которым прилинкованы TD (bulk + control и отдельно изохорный). Этот список прогоняется с началом каждого фрейма. Если у ED несколько TD, то они все обрабатываются, пока идет успешная обработка. Как только передача по EP прекратилась, присупаем к обработке следующего ED.
Таким образом NAK многократно в течении фрейма просто не может возникнуть, список обрабатывается один раз за фрейм!

Хм, если таким образом NAK многократно в течении фрейма просто не может возникнуть, список обрабатывается один раз за фрейм!, то почему тогда если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!!?

Мда.... Посмотрел... Порядка 15 000 !!! прерываний в секунду..
Ничего не понимаю.. Как тогда быть с тем, что для исключения ED из списка надо поставить ему бит sKip, и дождаться начала фрейма (по OHCI )

А передача по EP прекращается после успешного/ошибочного OUT или результативного IN. NAK на IN не считается ни ошибкой ни результативным, поэтому такой вводной TD не изменяется и остается в списке ED.

Как работает хост - есть Periodic List - это interrupt + isochronous (строго говоря это группа из 32 пересекающихся списков), и есть два списка Bulk List и Control List. Сначала хост обрабатывает Bulk+Control, при достижении времени фрейма некоторого программируемого порога (Periodic Limit) начинается однократная обработка Periodic List. Когда периодический список закончился снова начинается обработка bulk+control. Когда эти списки заканчиваются - их обработка начинается снова/сначала (если не пустые) - и так до самого конца фрейма. Где это явно написано в OHCI-спецификации я не нашел, но фактически это так - иначе оставшуюся bandwidth использовать не получится. Поэтому, если в bulk/control endpoint есть запрос на IN и на него получен NAK - то это не считатся ошибкой, трансфер дескриптор не изменяется и при следующем заходе на список (возможно, в этом же фрейме) IN будет повторен.

Ну с IN`ами вроде разобрались - если девайс занят и данных на передачу нет - сразу после отправки токена IN хост получает токен NAK и повторяет запрос снова. То есть имеем минимальный обмен данными на шине.

А как обстоят дела с OUT транзакциями?
Хост отправляет токен OUT, затем передаёт пакет данных, и только потом получает NAK? Будет ли он сразу же повторять этот OUT снова?
В любом случае, OUT и затем NAK это совершенно пустая трата времени и уменьшение пропускной способности шины.

Это относится к Full Speed USB.
В High Speed вроде этой проблемы можно избежать...

Думаю, да, будет повторять - после того как список EP закончится и начнется новая обработка списка сначала. Если список содержит несколько EP - то до нового OUT для NAK-нутой EP очередь подойдет спустя какое-то время - устройство может успеть выгребсти буфер и вероятность нового NAK снижается. Если же EP единственная в списке - то вся полоса в ее распоряжении - жалеть про бесполезные OUT/NAK особо не стоит, ИМХО.

Спасибо!

Ещё вот хотел задать вопрос по работе хоста.
Имеется Mass Storage девайс, и хост, при чтении с него данных, использует команду SCSI_READ10.
При этом максимальный размер запрашиваемого блока данных равен 65536 байт.
Что весьма мало, так как ему приходится использовать много таких запросов для чтения объёмных данных.

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

Тут, наверное, надо разбираться с драйвером Mass Storage. Возможно, определённым образом отвечая на запросы SCSI_MODE_SENSE можно заставить драйвер увеличить размер буфера?