[VslavX 0]

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

А передача по 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 будет повторен.

[sonycman 0]

А передача по 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 вроде этой проблемы можно избежать...

[VslavX 0]

Хост отправляет токен OUT, затем передаёт пакет данных, и только потом получает NAK? Будет ли он сразу же повторять этот OUT снова?

В любом случае, OUT и затем NAK это совершенно пустая трата времени и уменьшение пропускной способности шины.

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

[sonycman 0]

Думаю, да, будет повторять...

Спасибо!

 

Ещё вот хотел задать вопрос по работе хоста.

Имеется Mass Storage девайс, и хост, при чтении с него данных, использует команду SCSI_READ10.

При этом максимальный размер запрашиваемого блока данных равен 65536 байт.

Что весьма мало, так как ему приходится использовать много таких запросов для чтения объёмных данных.

 

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

 

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