Alechek 0 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба В общем дело так, заметил я некую странность еще со времен 2148 - если запретить прерывание по используемой IN ep (необработке его до следующего кадра?), то больше оно не возникает. Прерывание сбрасывается только путем установки бита USBEPINTCLR. Пришлось обрабатывать всегда, даже если нет данных в направлении хоста. Теперь существующие наработки пытаюсь перенести в 2388 и сделать все под OS: при открытии полученного виртуального COM порта пропадает прерывание IN ep! Если в обработчике сбрасывать прерывание путем команды "Select Endpoint/Clear Interrupt ", то прерывание почему-то не сбрасывается, обработчик зацикливается. Если же сброс прерывания осуществлять и путем выполнения команды, и установкой бита в USBEPINTCLR - то все работает замечательно. Как то реальность расходится с опсанием процесса: 12.11 Select Endpoint/Clear Interrupt (Command: 0x40 - 0x5F, Data: read 1 byte) ..... Remark: This command may be invoked by using the USBCmdCode and USBCmdData registers, or by setting the corresponding bit in USBEpIntClr. For ease of use, using the USBEpIntClr register is recommended. Выходит, эти 2 действия не равнозначны? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба В общем дело так, заметил я некую странность еще со времен 2148 - если запретить прерывание по используемой IN ep (необработке его до следующего кадра?), то больше оно не возникает. Прерывание сбрасывается только путем установки бита USBEPINTCLR. Пришлось обрабатывать всегда, даже если нет данных в направлении хоста. А зачем его запрещать? Оно вроде как и не возникает без повода (при отсутствии передачи в хост)... ЗЫ: Я тоже использую оба действия: в начале обработчика - команду, в конце - сбрасываю бит. Почему? Так получилось... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба А зачем его запрещать? Оно вроде как и не возникает без повода (при отсутствии передачи в хост)... Возникает. 10.4.1 USB Endpoint Interrupt Status register All non-isochronous IN endpoints generate an interrupt when a packet is successfully transmitted, or when a NAK handshake is sent on the bus and the interrupt on NAK feature is enabled (see Section 13–12.3 “Set Mode (Command: 0xF3, Data: write 1 byte)” on page 352). Возможно можно обойтись и без прервания по NAK, но я то переделывал IARовский HID когда только-только начинал разбираться с USB. И передача организовал так, что данные отправляются из кольцевого буфера в прерывании по IN ep. Хотел запрещать прерывания если нет данных и вновь разрешать при отправке данных. Не получилось Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба ...Возможно можно обойтись и без прервания по NAK... Так они же возникают редко, только в случае неприятностей, при неприеме хостом пакета и предполагают обработку дисконнекта т.е. не надо без них. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба Так они же возникают редко, только в случае неприятностей, при неприеме хостом пакета и предполагают обработку дисконнекта т.е. не надо без них. Они как раз возникают часто - когда хост читает пустой буфер (если нет данных или не успели поместить данные в endpoint). Хост хочет читать - присылает IN, а в ответ ему NAK (нету у нас пока ничего) - тут то и возникает это прерывание. Другое дело что без этих NAK-ных прерываний следует обходиться - как раз из-за того что они частые. А вопрос топикстартер поднял интересный - у самого прерывание по команде SelectEP не сбрасывается (приходится дополнительно регистром пользоваться), тоже не отказался бы узнать в чем тут дело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 30 июня, 2009 Опубликовано 30 июня, 2009 · Жалоба Другое дело что без этих NAK-ных прерываний следует обходиться - как раз из-за того что они частые. Ну частые они не настолько, чтобы их боятся - возникают каждый фрейм, то есть с частотой 1000Гц. Так что их наличие без дела - вопрос чисто психологический :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 30 июня, 2009 Опубликовано 30 июня, 2009 · Жалоба Ну частые они не настолько, чтобы их боятся - возникают каждый фрейм, то есть с частотой 1000Гц. Так что их наличие без дела - вопрос чисто психологический :laughing: Ну да, я тут лопухнулся чуток... Сейчас проверил - запретил NAK-прерывания от IN ендпоинта - полет нормальный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 30 июня, 2009 Опубликовано 30 июня, 2009 · Жалоба Ну частые они не настолько, чтобы их боятся - возникают каждый фрейм, то есть с частотой 1000Гц. Так что их наличие без дела - вопрос чисто психологический :laughing: Это если endpoint типа interrupt. А если bulk? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба Это если endpoint типа interrupt. А если bulk? Если Interrupt - то реже. Если булка - то каждый фрейм. Если точка сказала NAK - то более в текущем фрейме к ней обращения нет. Чтобы понять мехаинизм передачи получше, надо понять как устроен USB хост! ;) Хотя про безобидность - я поспешил. Если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!! **** По теме ***** В общем методом научного тыка было установлено, что если выполнить USB_Cmd(CMD_USB_SET_MODE, INAK_BI | INAK_BO); то при сбросе прерывания IN ep только битом они более не возникают. При разрешении только INAK_BI или вообще запрете NAK прерываний - все работает отлично. Все сказанное относится к BULK точке Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shahr 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба Выходит, эти 2 действия не равнозначны? То есть я правильно понял, в документации союз "or" неверно отражает ситуацию? В строчке "This command may be invoked by using the USBCmdCode and USBCmdData registers, or by setting the corresponding bit in USBEpIntClr." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба То есть я правильно понял, в документации союз "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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба Если Interrupt - то реже. Если булка - то каждый фрейм. Если точка сказала NAK - то более в текущем фрейме к ней обращения нет. А можете это ссылкой на соответствующее место в стандарте подтвердить? А то мне кажется, что для bulk отдается вся свободная полоса, и IN соответственно может быть не один, невзирая на полученный ранее NAK. Чтобы понять мехаинизм передачи получше, надо понять как устроен USB хост! ;) А я сейчас как раз хост пишу - OHCI на LPC2388. И нету там в дескрипторах бита типа "вот в этом фрейме у нас был NAK, больше IN не делать", соответсвенно bulk/contol list обрабатываются многократно - пока фрейм не закончится (или список) - и IN-ов может быть во фрейме много. Для EP типа interrupt - согласен - periodic list обрабатывается один раз за фрейм - соответственно IN будет только один. Хотя про безобидность - я поспешил. Если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!! Ну дык, неудивительно - при пустом буфере IN/NAK происходят в течение фрейма многократно, а не один раз. Измерьте частоту прерываний и убедитесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба А я сейчас как раз хост пишу - OHCI на LPC2388. И нету там в дескрипторах бита типа "вот в этом фрейме у нас был NAK, больше IN не делать", соответсвенно bulk/contol list обрабатываются многократно - пока фрейм не закончится (или список) - и IN-ов может быть во фрейме много. Для EP типа interrupt - согласен - periodic list обрабатывается один раз за фрейм - соответственно IN будет только один. Ну дык, неудивительно - при пустом буфере IN/NAK происходят в течение фрейма многократно, а не один раз. Измерьте частоту прерываний и убедитесь. А я хост уже написал! ;) Так вот, как я понял, есть список связанных ED к которым прилинкованы TD (bulk + control и отдельно изохорный). Этот список прогоняется с началом каждого фрейма. Если у ED несколько TD, то они все обрабатываются, пока идет успешная обработка. Как только передача по EP прекратилась, присупаем к обработке следующего ED. Таким образом NAK многократно в течении фрейма просто не может возникнуть, список обрабатывается один раз за фрейм! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба Хм, если таким образом NAK многократно в течении фрейма просто не может возникнуть, список обрабатывается один раз за фрейм!, то почему тогда если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!!? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 1 июля, 2009 Опубликовано 1 июля, 2009 · Жалоба Хм, если таким образом NAK многократно в течении фрейма просто не может возникнуть, список обрабатывается один раз за фрейм!, то почему тогда если разрешть прерывания по NAK - то загрузка проца у меня возрастает до 95 процентов!!? Мда.... Посмотрел... Порядка 15 000 !!! прерываний в секунду.. :cranky: Ничего не понимаю.. Как тогда быть с тем, что для исключения ED из списка надо поставить ему бит sKip, и дождаться начала фрейма (по OHCI ) :smile3046: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
