Почему USB-прерывание не управляется?

В чем смысл создания USB-механизма опроса, а не прерывания? Ответы, на которые я могу ответить, - это:

  • Оставьте управление эффективностью обработки и детализацией ОС, а не самим устройством.
  • Предотвратите "прерывистые штормы" с помощью неисправных устройств.

Некоторые объяснения в сети, которые я нашел, говорят, что это в основном из-за природы USB-устройств. Они в основном представляют собой системы на базе микроконтроллеров, которые не могут ставить в очередь большие передачи, поэтому требуют коротких интервалов прерываний, и такие короткие интервалы прерываний могут быть не самыми эффективными. Это правда?

Могут ли быть другие причины?

ОТВЕТЫ

Ответ 1

Главной предпосылкой развития USB было "дешевые чипы". Это было сделано с помощью опроса, что уменьшает необходимость в более высоком протоколе арбитража.

Firewire, который допускал прерывания от устройств и даже DMA, был намного дороже. Таким образом, USB выиграл в недорогом поле и FireWire в области low-latency/low-overhead/.... Из-за истории USB более или менее выиграл.

Ответ 2

Какое обоснование заключается в том, чтобы заставить USB использовать механизм опроса, а не прерывать?

Кажется, это анти-USB FUD (как в Fear-Uncertainy-Doubt).

Причина в том, что это значительно упрощает работу на уровне harware - например, больше никаких столкновений. USB является полудуплексным, чтобы уменьшить количество проводов в кабеле, поэтому можно говорить в любом случае.

Пока USB использует опрос на проводе, как только вы его используете в программном обеспечении, вы заметите, что у вас есть прерывания на USB. Единственная проблема заключается в небольшом увеличении латентности - пренебрежимом в большинстве случаев использования. Поскольку опрос обычно реализуется на аппаратном IIRC, программное обеспечение получает уведомление только в случае появления новых данных.

На программном уровне есть так называемые "конечные точки прерывания" - и угадайте, что, каждый HID-устройство использует их: Mice, Keyboard и Josticks HID.

Ответ 3

Я вижу большую аналогию между USB и протоколом I2C, с которыми я больше знаком. Понятно, что они оба являются архитектурой master-slave, где несколько устройств делят дешевую 1-битную шину (полудуплекс). подчиненные устройства не могут инициировать связь (например, сгенерировать прерывание), иначе будут конфликты. Поэтому ведущий (USB-хост) должен говорить 1-й (опрос), а подчиненный отвечает только при обращении.

Но действительно ли USB - это огромная 1-битная шина, используемая до 127 устройств? Разве нагрузка на вождение 127 устройств не станет невероятно медленной? Я немного смущен, потому что, по некоторым данным, USB не является 1 шиной, а коммутационной сетью с топологией звезд, поэтому устраняет проблему загрузки большой шины. Но если он переключится, то столкновения не произойдет правильно? (просто буферируйте пакеты и отправляйте их, когда выходной порт свободен), почему они все еще используют архитектуру ведущий-ведомый?