В общем дело так, заметил я некую странность еще со времен 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 )