Протокол USB

Чтобы пропускную способность обеспечить. Хост может заранее распланировать обращение ко всем устройствам, что позволяет достичь 100% использовани шины.

И этот алгоритм планирования далеко не тривиален.

А что ты хочешь от интерфейса подключения всяких там мышек, клавок и принтеров?

К одному порту юсб можно одновременно подключить туеву кучу устройств, и все они будут работать. Чтобы это достигнуть, процессом общения с ними заведует только хост.

USB это не то что старый добрый самый лучший интерфейс в мире.

https://goo.gl/photos/zXpPr4YCrZe8Vfjx9

В том самом добром супер-интерфейсе тоже можно было аж до 8 одновременно подключить. Эх были времена!

У тебя что-то ностальгическое потекло =) Вытри :-D

А вот если серьёзно, логики в твоём сообщении не нашел. Ну пусти часы по дополнительному проводу и пусть все устройства по ним синхронизируются и работают в full duplex. На этапе проектировки можно было бы заложить такую возможность, по идеи.

*идее

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

То есть каждое устройство должно синхронизироваться по часам, ловить свою очередь по ним и вещать хосту? Или они все одновременно будут засерать ему шину своими «я принтер, я чепятаю», «координаты мыши 123123143», «светодиод горит!» и так далее? Откуда устройству знать, что кто-то выше него не орет уже хосту какую-то инфу? Когда опрос инициирует сам хост - все решается гораздо проще и быстрее. Не говоря уже про габариты - все обходится четырьмя проводами.

Однако и при текущем стандарте USB такая конструкция не заработает.

Еще как заработает, только при условии, что суммарный поток данных с этих 10 веб-камер не превышает пропускной способности USB.

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

выстраивает их в очередь и отправляет на хост по одному.

И сколько памяти нужно в хабе для выстранивания запросов от нескольких видеокамер, пытающихся отправить катринку?

Да еще не известно хвати-ли пропусконй способности. В текущей реализации, если для устройства нет места, оно не пройдет энумерацию, но не поломает уже рабочие.

И этот алгоритм планирования далеко не тривиален.

в линуксе? :) в винде судя по переполнению шины... нудаладно

Я не знаю как в винде. В линуксе - это одна из самых занимательных частей для чтения под чай с печеньками.

Имеется ввиду, что можно через разветвитель воткнуть в один порт принтер и пару флешек и винтов, и все это взлетит.

Зачем они так?

Чтобы не делать человеческий Ethernet с питанием и без проблем с подключаемой периферией, а запилить этот сраный ублюдочный велосипед с квадратными колёсами под названием USB.

Вообще, USB устройство таки может пнуть хост по собственной инициативе. Можно отключить и подключить обратно pull-up резистор, тогда хост увидит отключившееся и снова подключившееся устройство. Увы, накладные расходы на сей процесс будут весьма велики, ибо хост займётся энумерацией и чтением дескрипторов по-новой, и только после этого устройство окажется доступно.

Чтобы не делать человеческий Ethernet с питанием и без проблем

посчитай количество проводков на своем изернете пока даже без питания, потом посмотри количество драйверов для различных реализаций EMAC

http://lxr.free-electrons.com/source/drivers/net/ethernet/

это типа универсальный интерфейс ? для сравнения EHCI-совместимый хост и в африке такой - достаточно одного драйвера и вендор-специфичной инициализации.

Вообще-то на момент создания USB у Ethernet был фактически единственный драйвер - NE2000. И куча разных производителей выпускала микрухи под этот стандарт де-факто. Никто не мешал принять его де-юре и не высирать говённый USB.

Что до количества проводков - то лучше 6 проводов, 100 метров, IP протокол и куча выпускаемых дешевейших мелких малоногих микроконтроллеров с Ethernet для клепания хостов, чем 4 провода, ублюдочный протокол, 1.5 метра и сотни дурацких несовместимых реализаций USB-device периферии в микроконтроллерах.

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

Ого. А теперь посиди минутку и представь, как это должно выглядеть в виде развертки потенциалов от времени на паре несчастных сигнальных проводков. И сколько дополнительных ограничений и проблем принесла бы такая ошибка на этапе проектирования.

на паре несчастных сигнальных проводков

Тащемта на паре сигнальных проводков висит два девайса по одному с каждой стороны. В чем проблема?

В том, что я мощно тупанул, сорри.

USB это шина. Предположим, что устройтво А захотело передать байт по шине, оно устанавливет на шине значение первого бита, пусть это будет 1, дальше оно устанавливет значение второго бита, например это 0. В этот момент устройство Б тоже решает отправить данные по шине. Оно устанавливает на шине значение своего первого бита, пусть будет 1. Что мы видим на шине? Кашу. Непонятно кто ведет передачу, что передается и как это разгребать. А когда всем управляет мастер, это все легко решается.

И куча разных производителей выпускала микрухи под этот стандарт де-факто

потребляющие как кипятильник и величиной с кирпич

Что до количества проводков - то лучше 6 проводов, 100 метров

у USB есть HSIC где все те же 2 проводка

http://www.edaboard.com/thread265355.html

у EMAC на этом уровне в лучшем случае RGMII

https://ru.wikipedia.org/wiki/RGMII

потребляющие как кипятильник и величиной с кирпич

Первые HCI потребляли ещё больше и занимали места никак не меньше, потому как требуха USB посложнее будет.

HSIC RGMII

А при чём тут межблочные соединения? Они внутри микроконтроллера и на их количество в общем-то насрать.

Зачем они так?

Вопрос: могут ли абоненты сети LTE излучать тогда когда им заблагорассудится? А почему? А в какой момент они всё же могут (аналогия с резистором на шине USB)? Аналогично с USB, может я очень ошибаюсь, но аналогия как-то слишком похожая. И в обоих случая это решение кажется единственно верным.

CSMA/CA? CSMA/CD?

Они внутри микроконтроллера

какого еще микроконтроллера - где ты видел микроконтроллеры с всроенным физическим уровнем для изернета ?

на их количество в общем-то насрать

я смотрю тебе на все насрать кроме своего недалекого мнения.

Тогда CAN получиться. :)

какого еще микроконтроллера - где ты видел микроконтроллеры с всроенным физическим уровнем для изернета ?

Да полно их. Только все огромные, 100-ногие обычно. А если бы USB не был высрат мерзким кагалом во главе с мелкософтом, то было бы полно всяких мелких AVR'ов PIC'ов и прочих 8051 c Ethernet на борту. Новомодный Internet of Things уже десятилетия был бы чем-то совершенно обыденным. Более того, в каждом компе был бы свитч портов так на 8 с PoE. И в ОС не требовалась бы целая дурацкая подсистема, обеспечивающая работу USB. А у клавиатур и мышей был бы IP адрес. И, возможно, Bluetooth бы не родился, а был бы нормальный low power WiFi, что опять же сильно бы упростило жизнь. Поди фигово, когда у тебя наушники - просто IP куда надо стримить звук.

я смотрю тебе на все насрать кроме своего недалекого мнения.

И уж тем более мне насрать на мнение какого-то безграмотного анонимуса.

было бы полно всяких AVR'ов PIC'ов и прочих 8051 c Ethernet на борту

их и так полно, но там только EMAC без PHY и тем более без тансфоматора, вместе это уже никак не микро и по размерам и по потреблению

нормальный low power WiFi

влажные фантазии. Почитай про ZigBee

Ага, только в USB «эфире» всего два абонента, в отличие от.

Что мы видим на шине? Кашу.

Кашу мы видим в другом месте, а на проводе может быть только два устройства.

А какая связь между «проводом» и USB?

их и так полно, но там только EMAC без PHY

Ну приведи пример хоть одного МК о 16 ногах с EMAC пусть и без PHY. Всё веселье начинается исключительно с QFP64 и нехилых спецификаций нафиг не нужных для банальной IP периферии типа датчиков, простых исполнительных устройств и всякого прочего ВВ.

и тем более без тансфоматора,

Трансформатор на небольших расстояниях вообще нафиг не нужен. Особенно для периферии типа мышей и клав с флешками.

вместе это уже никак не микро и по размерам и по потреблению

Да откуда этот бред про потребление и размеры? Сравни реализацию USB-device и eth для какого-нибудь FPGA.

влажные фантазии. Почитай про ZigBee

ZigBee точно так же не совместим с WiFi как и Bluetooth.

Беспроводной USB?

Так много ж хранить данных не надо. Обычно если идёт большой поток данных по USB, то он постоянный (условно, если юзер включил камеру и она шлёт видео с битрейтом N мегабит, то он вряд ли будет особо меняться, пока юзер камеру не отключит, никаких временных затиший не будет). А значит если у нас в очереди сотни пакетов и мы не успеваем их отправлять, значит пропускной способности всё равно не хватит, поэтому можно дропнуть лишние пакеты. Нет смысла хранить слишком много пакетов, которые всё равно не успеют никогда уйти. Кстати, USB умеет перепосылку пакетов при сбоях. Так что по сути такой алгоритм будет работать как шейпер. Если скорости хватает всем девайсам (суммарный поток от всех девайсов не превышает пропускную способность канала от хаба до компа), то всё ок. Если нет, то скорость падает, идёт потеря кадров и т. д. В обычном USB, кстати, будет похожая ситуация - магии не бывает и возможна ситуация, когда хост не сможет спланировать все транзакции, которые захотел юзер.

Хабу хватит памяти для того, чтобы вместить все пакеты от всех устройств, пришедшие в течении, скажем, 1 миллисекунды. Контрольные посылки если дропнутся не страшно - переотправятся. А мультимедиа-потоки, если не влезают в шину в течении одной миллисекунды, значит никогда не влезут, пока юзер не изменит конфигурацию оборудования.

С текущим USB хост легко может решить кем пренебречь, а кем нет. Но если девайсы смогут отправлять без спросу, то это лего регулировать тем же xon/xoff. Таки не понятно.

Ага. В стандарт можно заложить команды, которые будут приказывать девайсу заткнуться. Ну а от кривых девайсов и текущая реализация USB сильно страдает. Например, если девайс перегрузит порт по питанию, а у хаба нет внешнего питания или хотя бы ограничителя тока (последнего нет у 95% хабов), то все девайсы отключатся. Если девайс криво определяется, то это опять же замедляет работу всей шины USB. Например, когда моя прошивка для МК зависает в ходе енумерации, то другие девайсы в этом порту (через хаб) определяются далеко не сразу.

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

В общем ты прав :) Всего два. Даже если это хаб а за ним еще 50 устройств, но на отдельных веточках всего два абонента - хост/хаб и девайс...

Кхм. На шине USB всегда 2 устройства - хост и девайс. Никогда не может быть больше. Устройства нельзя соединять параллельно. Хочешь подключить несколько - используй хаб, который имеет встроенный контроллер и является самостоятельным устройством. С точки зрения компа это device, с точки зрения девайсов это host. И хаб пересылает пакеты от хоста на указанный порт, прикидываясь хостом. При этом в хаб могут даже быть воткнуты устройства, работающие на разной скорости. При этом задача хаба согласовать всё.

потребляющие как кипятильник и величиной с кирпич

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

Абонентов много. А связь по USB типа точка-точка. Одно устройство host, другое device. Никаких проблем нет.

Я сомневаюсь, что физический уровень USB чем-то принципиально отличается по сложности от Ethernet. И там и там витая пара и сопоставимые скорости. Если не нужен гигабит (а USB High Speed на 480 мбит/сек тоже есть только в очень жирных МК, а уж Super Speed не у каждого SoC есть, не то что микроконтроллера - а причина проста, микроконтроллер просто не осилит столько данных обрабатывать), а 10 мбит (сопостовимо с 12 мбит/сек USB Full Speed) и не нужна дальность в километры, то PHY для Ethernet никак не может сложнее быть.

А трансформатор можно опять же выкинуть. Ибо не нужен он для мышек и клавиатур, к котором провод всего несколько метров длиной.

Именно. Так что аналогия с радиоэфиром некорректна. А хаб вполне может обеспечить, чтобы пакеты пришедшие одновременно на его разные порты ушли к хосту по очереди.

Посмотри сколько стоят самые тупые Ethernet-хабы (для альтернативы USB не нужен нафиг NAT, файервол и т. д. - надо просто доставить пакет от хоста девайсу и обратно) - не особо то дороже USB-хабов. А разница в цене полностью обусловлена массовостью - на USB-хабы спрос больше. Был бы такой спрос на Ethernet-хабы их бы китайцы тоже клепали по 100 рублей/кг. Начинка Ethernet-хаба даже примитивнее. Почитай спецификацию USB. Там хаб дофига всего должен уметь (в том числе, кстати, он имеет очереди пакетов, ибо некоторые девайсы могут быть low speed и им надо всё передавать медленее, чем идёт связь с хостом).

Спасибо за ликбез. Всегда думал, что USB на физическом уровне организована как шина.

Если бы это было так, то китайцы продавали бы хабы по цене USB-шнурков. А нет, туда таки приходится микросхемы пихать.

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

Изохронные и interrupt точки имеют гаранитированную пропускную способность. Если нет возможности ее обеспечить, то устройство не пройдет энумерацию. Bulk планируются по остаточному принципу.

Это не возможно обеспечить если все шлют что попало.

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

в usb 3.0 не так

Если нет возможности ее обеспечить, то устройство не пройдет энумерацию.

ЯННП

Например я воткнул в хаб флешку и начинаю закачку которая сожрала 100% порта. В это время я включаю еще одну такую же. Что будет?