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

На разработку - бабущка надвое сказала - Вы утверждаете, что с помощью моста и "VID-PID на свой поправить, и все" решили проблемы, я смею утверждать, что не имею нималейщих проблем в написании считанных десятков строчек для поддержки физического уровня Ethernet. На себестоимость - слово Автору топика "Т.к. изделия не серийные, то можно использовать компоненты (в т.ч. ПЛИС) ценой в несколько тысяч рублей."

Опять Автор - "с местом проблем нет"

Ну если хотите считать, что "не было", считайте,что не было.

То, что нет проблем с местом на плате, и то, что можно использовать компоненты в тыщи баксов совсем не означает того, что 5 долларов с девайса в карман это плохо и не нужно, и то, что (грубо) замена компонента за 1000 на компонент за 900 это лишнее. Имхо минимизация затрат - непременный атрибут любой разработки, и не серийной тоже.

В общем ситуация с софтом для "просто гнать данные" совершенно одного уровня сложности, что для USB, что для ETH. Только для Ethernet при этом еще и нет завязки на конкретного производителя моста и его софт - полная свобода выбора и действий

P.S.
Тем не менее "мост" иметь ввиду - случаи в жизни они разные бывают.

Причем я об этом сказал значительно раньше http://electronix.ru/forum/index.php?showt...st&p=562417



Что касается завязки на софт производителя моста - этого на самом деле нет. Производитель дает лишь примеры софта, и никто не заставляет завязываться на них, а не например на софт для УСБ от микрософта (bulkusb), который точно так же, как и ezusb.sys, позволяет тупо гнать данные. Про линукс я уже сказал - там все еще проще - там драйвер контроллера USB сразу предоставляет необходимый доступ к любому девайсу через /proc/bus/usb/.... И никаких лишних драйверов не нужно вообще, открывай и юзай.

Завязка на железо - все равно есть - либо завязка на конкретного производителя внешнего MAC, либо PHY. ТОЧНО также, как либо на производителя моста УСБ, или УСБ-трансивера (если УСБ-контроллер пихать в ПЛИС, что околоодинаково и по ресурсам ПЛИС, и по затратам времени с MAC в ПЛИС).

ЗЫ. Я вот сейчас как раз занимаюсь УСБ high speed в ПЛИС без моста. Так как на мост к сожалению не хватило ни места, ни питания, а трансивер с размером корпуса 3.5х3.5 мм влез. Поэтому и знаю про затраты....

Не вижу, на что конкретно ссылаететесь.... Но о том, что работа с Ethernet, причем с любым ГОЛЫМ MAC контроллером проста как лом, написал в первом-же своем посте. В ответ услышал от некоторых участников:

Работать с мостом от CYPRESS слегка правя имеющийся софт от CYPRESS тоже просто - очень рад. Взял на заметку, хотя с вероянностью 99% у это будет делаться на встроенном в какой-нибудь 32битник USB контроллер, нежели прицепленный к его параллельной шине 51 с USB и сторонним софтом на борту.

На "Сообщение #22", вторая его половина.


Ну разумеется, если уже есть 32-битник, то лучше взять его сразу с УСБ, чем цеплять к нему что-то снаружи. Речь-то все таки о FPGA, а не о 32-битнике, а это совсем другая тема.

Ну вы нас в натуре за лохов-то не держите



Этого недостаточно. А где механизм обеспечения целостности передачи?



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



Честно говоря, не вижу смысла дальше спорить. Я не ярый сторонник USB или Ethernet.
Просто, как я уже сказал, у нас в организации было разработано и то, и то.
И все сходятся во мнении, что для подобных задач реализация на USB - лучше. Даже те, кто разрабатывал Ethernet интерфейс.
И я, как пользователь этих каналов. Человек, которому этими интерфейсами приходится пользоваться постоянно.

А на вкус и цвет, товарищей нет

Это Вы писали:

То, что Вы назвали нетривиальной задачей, то и выложил.
Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста? ) при этом нумерация принятых переданных и контроль факта пропадания есть само-собой всегда. Вcе это, кстати, за счет реального времени и пропускной способности. Представляет собой вариации на тему IEEE 802.2, писалось лет так 12 назад, работает у меня далеко не только через Ethernet и содержит ровно 378 строчек на C. Вот такая нетривиальная задача.

Это Вы писали:

То, что Вы назвали нетривиальной задачей, то и выложил.
Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста? ) при этом нумерация принятых переданных и контроль факта пропадания есть само-собой всегда. Вcе это, кстати, за счет реального времени и пропускной способности. Представляет собой вариации на тему IEEE 802.2, писалось лет так 12 назад, работает у меня далеко не только через Ethernet и содержит ровно 378 строчек на C. Вот такая нетривиальная задача.



Вы же сами сказали, что MAC уровни, тем более, что брать готовые корки в FPGA одинаковы по трудоемкости, софт, для тупой передачи потока, как выяснилось, - тоже одного порядка. Дальше что? На моей стороне равноправные партнеры, а не опрашивемое переферийное устройство, удаление на сотни метров, гальваническая развязка, возможность гигабита. На ваше стороне, "5 баксов" и "5x5 миллиметров", да и то только в случае выбора между мостом USB и контроллером MAC. Есть выбор. Я ничего не упустил?

у USB моста это все встроено, и работает. Достаточно лишь выбрать вид передачи BULK
А чтобы уместить все это в 378 строчек, нужно быть хорошим программистом.

Как где? В спецификации УСБ, главы 8.5...8.7. Любой УСБ девайс, коим является и мост, обязан это обеспечивать.

Упустили главное. Засовывание и отладка корки, что УСБ, что МАК, одинаковый геморрой недели на две, особенно если впервые, а поднятие передачи с мостом - вопрос получаса. Плюс, если впервые, еще работа по откручиванию всяких там вишбонов, ahb, amba и прочего нахрен не нужного хлама, пока до локальной шины не доберешься. Выигрышь в стоимости разработки при применении моста виден сразу.

Осталось взять все доступные мосты, а именно MACи внешние и УСБ-мосты, и сравнить их по параметрам, как то цена, занимаемое место, жрачка. Ну и сравнить их же с решением вкрячивания корки в ПЛИС с использованием внешнего PHY, предполагая, что она займет для УСБ ~2800 LE / 8 M4K (можно обкастрировать где-то до 2100) и для Eth 10/100 3800 LE / 9 M4K (можно обкастрировать где то до 1500, но потом за счет контроля целостности и ретрансмитов оно разростется обратно думаю до объема как раз USB). Объемы приведены примеро для корок от CAST под FPGA Cyclone-II.

Если свести все в единую таблицу, где учесть время на разработку, учесть стоимость компонентов, учесть площадь платы, переведя все эти составляющие в деньги, то решения с USB-мостами окажутся порядочно впереди Eth-решений с внешними макамию, а решения с УСБ-корками незначительно дешевле, чем с МАК-корками (при условии, что трансформатор можно по ТЗ выкинуть, разница за счет цен на PHY и занимаемой площади ими на плате). По крайней мере так было полтора года назад, когда я эту работу проводил. Из чего напрямую следует, что если применим по ТЗ и тот, и этот интерфейсы, то наиболее быстро реализуемое решение, при этом самое дешовое - будет именно USB мост.

Что касается 5х5 мм - то найдите хотя бы Eth PHY такой При том, что USB PHY имеют размер 3.5х3.5 мм

Понял, добавляем очень очень очень быстрый старт. Я правда предпочитаю быстрому старту долгую жизнь и возможности развития. Осталось после всего этого выслушать Автора топика.
P.S.
Все, я уезжаю на недельку по делам, наверное будет не до electronix

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

Тут уже много чего сказано, но можно добавить, что USB вполне применим при условии, что достаточно потока 40 КБайт/сек. Выше практически не реализуемо. Я не работал с предлагаемым CY кристаллом, но на других (филипс) потоки порядка 30-35 КБайт/сек вполне получались даже при медленном контроллере в управлении. И еще. Для сбора данных не нужно использовать изохронную передачу. По двум причинам. Во-первых, это негарантированная доставка, а во-вторых - скорость меньше, особенно если посмотреть на ошибки микрософта в реализации hub-драйвера в этом режиме. Что касается замираний, то они есть, но небольшие. Проблема вполне решается установкой буфера размером 2-10 КБ для этих скоростей.

Только не КБайт, а МБайт! А выше действительно сложно и не на каждой машине (физический предел 53-54 МБайт/с)

Фуххх... Вернулся из 2 дневной командировки.


После предварительного согласования параметров системы сбора данных с соратниками, выяснилось, что необходима длина кабеля для передачи данных до 30-40 метров с обязательным наличием гальванической (или оптической) развязки, предельный поток данных получается около 15 MByte/s (или 120 MBit/s - так точнее) (к сожалению "сладкое будущее" стало тоскливой реальностью). Поэтому USB отпадает, насколько мне известно он не работает на такое расстояние и не имеет развязки. А жаль, первоначально предполагалось (мною), что удастся ограничиться один метром интерфейсного кабеля.

Естественно с таким потоком Ethernet-100 не справиться, соответственно прийдется использовать Gigabit Ethernet.
Теперь вопросы:
1. С чего лучше начать знакомство с Ethernet ?
2. Что лучше использовать чистый Ethernet или еще реализовывать и TCP/IP (в чем достоинства/недостатки обоих решений) ?
3. Исходя из 2, какие микросхемы/сборки лучше использовать ?

Еще раз повторю особенности этой разработки:
1. Данные необходимо гарантированно доставлять (т.к. у меня - система сбора данных).
2. Необходимо иметь возможность в будущем увеличить поток в 2 (или 2.5) раза, т.е. до 240Mbit/s (или 300Mbit/s - это крайняя цифра, выше неё прыгать не собираемся).
3. Очень важно минимизировать время разработки.
4. Место для аппаратного решения - 1дм2, можно и 1.5дм2 (да, так спроектировал систему - место есть).
5. Желательно чтобы суммарная цена копонентов не превышала десятка киборублей (не килодолларов !).
6. Программа приема данных на компьютере будет работать под Windows XP 32bit (тоже желательно позаботиться о программисте - дабы не сильно пух от проблем с голым Ethernet, или проблем как раз с Windows XP нет ?).

Пока видел 2 предложеных решения:
1. FPGA + ARM9 (как я понял, поддержку TCP/IP в ARM9 прийдётся делать самому, али есть готовое и доступное решение ?).
2. V4 Ethernet MAC (+ MicroBlase with LwIP - для поддержки TCP/IP).
Может еще какие предложения есть ?

Пока, второе предложение кажется более близким т.к. работаю с ISE давно и очень плотно (есть надежда, что и с EDK очень долго разбираться не прийдется), а вот про ARM только приходилось иногда слышать...