Передать информацию по USB от одного устройства к другому напрямую

FPGA думаю решит эту задачу

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

Тут нужен посредник, который будет эмулировать USB host для обоих устройств, и перенаправлять пакеты через свой буфер. Реально, наверное, только на FPGA.

Поднимай на одном из устройств USB OTG.

несжатое видео высокого разрешения с камеры

Там всего лишь USB 2.0 HighSpeed? (У меня внешний винчестер даёт макс. 34 МБайт/с.)

без прокачки через память компьютера

А почему без? Ведь уже очень давно есть DMA: через память, конечно, но без участия процессора.

Ого! Чтобы спроксировать данные с одного USB на другой дешёвый 32-битный микроконтроллер с двумя HighSpeed USB 2.0 не проще будет?

Ну если обязательно надо без прокачки через память, то наверное только FPGA

Две китайские usb сетевые карты.

Вы так активно топите за FPGA, но если не секрет - КАК? Реализовать некий упрощенный или даже полный протокол? Модифицировать прошивки на стороне всех устройств? Не ясно.

На кой черт париться с этими плисинами дурацкими, если можно взять какой-нибудь дешевый Cortex-M4 и старше (лишь бы 2 USB2.0 было) и на его основе сделать «прокси»?

Вот только запарится ТС такой прокси делать, потому как наверняка эти обе железяки общаются совершенно по-разному.

Самый дешевый вариант - купить «малинку» и набросать по-быстрому программку-проксификатор.

Реализовать некий упрощенный или даже полный протокол?

Реализовать в плисине два USB хоста, и чтоб плисина читала из одного хоста данные с камеры, минимально бы это дело перепаковывала и сразу же отправляла на другое устройство

На кой черт париться с этими плисинами дурацкими, если можно взять какой-нибудь дешевый Cortex-M4 и старше (лишь бы 2 USB2.0 было) и на его основе сделать «прокси»?

Конечно же так проще, только вот тс зачем-то хочет «без прокачки через память»

ТС просто не в курсе, как работает USB, и что хотя бы с мегабайт буферной памяти не помешало бы…

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

Причем подобный сценарий на такой шине как PCI-E делается довольно просто, а вот USB...

SZT

Реализовать в плисине два USB хоста, и чтоб плисина читала из одного хоста данные с камеры, минимально бы это дело перепаковывала и сразу же отправляла на другое устройство

Реализовать в плисине или подключить к ней? Есть что-то хотя бы частично готовое для плисины или придётся реализовывать хост-контроллер с нуля?

SZT

Ну если обязательно надо без прокачки через память, то наверное только FPGA

А, я понял вашу шутку, я имел в виду основную память компьютера, к которому подключаются два устройства, а не вообще любую память.

Ну допустим прокси на микроконтроллере или малинке я сделаю, но мне кажется, что производительность в таком случае будет меньше, чем в случае прокачки через основную память «большого» компьютера. Цель того, что я хочу сделать — повышение производительности и снижение нагрузки на основную память компьютера, причём первое приоритетнее, чем второе. Если данные пойдут в обход памяти, но при этом снизится производительность, то такой вариант неприемлем или приемлем только в том случае, когда производительности памяти будет не хватать.

Мне бы всё-таки хотелось знать, можно ли это сделать на уровне технологии USB?

curufinwe

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

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

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

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

curufinwe

И заставить одно устройство слать пакет на адрес другого устройства, а не хоста

Так мне подходит и вариант доставки до хоста, главное, чтобы в память ничего не лилось.

Или в USB-контроллеры намертво зашита передача пакетов только в направлениях хост → устройство и устройство → хост, и на программном уровне здесь ничего не сделать?

I-Love-Microsoft

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

Хост-прокси-устройство или хост-контроллер? В последнем случае это делается драйвером хост-контроллера/устройства?

gag

Там всего лишь USB 2.0 HighSpeed?

USB 3.0 SuperSpeed на полной скорости, и таких камер несколько.

gag

уже очень давно есть DMA: через память, конечно, но без участия процессора

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

anonymous

Две китайские usb сетевые карты.

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

На шине usb только один хост, и у него нет адреса. Адресуются только устройства. У разветвителей (hub) один аплинк порт и несколько даунлинк портов. Разветвители не передают данные между двумя даунлинк портами, только между аплинком и даунлинком. В usb контроллере корневой разветвитель, аплинк порт которого как-бы подключен к шине pci.

Вообще пропускная способность ddr4-2133 равна 17 гбайт/с. Этой пропускной способности достаточно, чтобы полностью заполнить 27 usb 3.0 портов. Поэтому непонятен страх перегрузить память хоста.

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

Прокси в режиме ядра будет работать быстрее, чем в режиме пользователя?

Вообще пропускная способность ddr4-2133 равна 17 гбайт/с.

У меня ddr2-667. Так что либо более производительный компьютер, либо меньшее разрешение видео и количество камер.

Вообще пропускная способность ddr4-2133 равна 17 гбайт/с.

А бутылочное горлышко, кстати, будет не на памяти, а на PCI Express, у меня, например, PCI Express 1.0.

Реализовать в плисине или подключить к ней? Есть что-то хотя бы частично готовое для плисины или придётся реализовывать хост-контроллер с нуля?

За деньги точно есть готовое.

И кстати, некоторые веб-камеры отдают по USB закодированный видеопоток, см. https://en.wikipedia.org/wiki/List_of_cameras_with_onboard_video_compression. Это если говорить о качественной компрессии. А так, довольно много камер отдают какой-нибудь mpeg. Например, вот https://en.wikipedia.org/wiki/USB_video_device_class#Formats.

Video stream formats like MPEG-2 TS, H.264, MPEG-4 SL, SMPTE VC1, VP8 and MJPEG

Т.е. если надо чтоб на другое устройство подавалось именно несжатое видео, а сама камера отдает видео в каком-нибудь H.264, нужно будет это дело еще перевести в несжатый (сырой) вид перед отправкой