[rsv2007 0]

проще, по моему, все таки ethernet сделать через жирную плисину. сейчас делаем плату обработки на virtex5 lx50t, так вот, пока железо еще не готово, мучаю отладку ml505. на ней, после некоторого бодания с софтом от xilinx вообще, и с ЕДК в частности удалось поднять web-сервер на микроблейзе со скоростью в 5 мегабайт в секунду (т е 10 мегабайт передавал за 2 с), и по моим прикидкам это пока еще не предел.

правда, конечно, возникает вопрос цены: около 1K$ за виртекс и печатная плата под bga слоев на 12-14

[kuzis 0]

Здравствуйте!

Добавлю своего мнения :)

 

Когда-то, очень давно я разрабатывал канал связи с похожим девайсом по USB. Разработку вели на вышеупомянутом CY7C68013. Как было справедливо замечено, очень удобная вещь. Проводили измерения скорости записи, которая (это наверное не вызовет сомнений) была ограничена сверху именно РСком. Так вот - получили 40 МБ/с. И это при использовании bulk точки.

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

Вопрос о замирании машины, при записи непрерывного потока существует. Но элементарно решается с помощью FIFO.

 

Так вот.

Канал получился очень удобным, быстрым, надежным.

 

Не так давно, при разработки нового изделия мои коллеги перешли на гигабитный ethernet. С протоколом tcp/ip. Мало того, что по сложности реализации это оказалось гораздо сложнее, так и менее устойчиво. Хотя скорость смогли увеличить раза в два.

 

ИМХО. Для ваших задач проще, лучше, дешевле использовать USB. И не забывайте и о том, что когда вы сделаете ethernet устройство, вам придется еще и решать проблему множественного доступа (с разных компов).

И не слушайте тех, кто говорит что USB это для быта.

[SM 0]

И не слушайте тех, кто говорит что USB это для быта.

+Много. Системы сбора, обработки и документирования данных с USB-интерфейсом успешно работают и в авиации, и в экстренных службах, и еще много где.

[zltigo 1]

не требующие написания дополнительного софта....

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы :(. Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP :( на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

И не слушайте тех, кто скажет, что запихать все УСБ (кроме трансивера) в ПЛИС проще, чем использовать готовый мост. Это провокация! Это гораздо сложнее, особенно когда дойдет до сертификации в USB-IF....

1. USB в даном случае нужно пихать не в FPGA а куда подальше...

2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.

3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

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

Вы хоть сами-то поняли что сказали? Если под "проблемой" понимается принципиальная возможность доступа из локальной сети, то ставите отдельный Ethernet контроллер в PC и получаете точка-точка.

 

 

 

 

+Много. Системы сбора, обработки и документирования данных с USB-интерфейсом успешно работают и в авиации, и в экстренных службах, и еще много где.

А Ethernet, типа, нигде не работает :) :) :) и вообще "покойник"

[SM 0]

В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP :( на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

Почему это я вдруг не отличаю? Я Wiznet лишь как пример привел, и ни разу не говорил, что обязательно используется TCP/IP, это лишь очередная Ваша фантазия. В нем удобные RAW-сокеты, он недорог, и он с PHY.

А Ethernet, типа, нигде не работает :) :) :) и вообще "покойник"

А я и нигде не говорил, что он не работает, или плох. Он просто сложнее в реализации. Если линк на УСБ мегабайт так 10-20 в секунду поднимается одним мизинцем левой руки с имеющимися красивыми и удобными мостами за час работы, то аналогичное с ethernet - повозиться придется с недельку. А чтобы было как с УСБ - "воткнул и работает везде и сразу без ручных настроек" - так и все пару недель.

не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.

Вот, наконец-то, чего я от Вас и добиваюсь. А теперь подробнее - какой именно, для примера. Чтобы был с PHY, чтобы прокачал 20 Мбайт/с в ФПГА, и чтобы стоил $5..6, как имеющиеся аналогичные по пропускной USB-мосты, и чтобы работы по поднятию этой связки было сравнимо с поднятием линка на USB.

[RobFPGA 27]

Приветствую!

 

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

 

С моей точки зрения Ethernet более универсальное решение. При сопоставимых с USB затратах на реализацию - возможностей значительно больше. Реализовать в FPGA MAC и заставить его слать пакеты на конкретную машину не сложнее чем через USB CY7C68013. Для этого стек TCP/IP не нужен.

 

Я не умаляю достоинств USB он имеет свои преимущества, НО это только ЛОКАЛЬНЫЙ интерфейс периферии компьютера, с небольшим расстоянием и отсутствием гальванической развязки.

 

Ethernet - СЕТЕВОЙ интерфейс не привязанным к конкретному компьютеру, система с Ethernet будет работать и на столе с рядом стоящим буком, и в 200 метрах, и в 20 км если надо БЕЗ изменения самой системы!

 

Писать же софт придется в любом случае. :smile3046:

 

Успехов! Rob.

[SM 0]

Реализовать в FPGA MAC и заставить его слать пакеты на конкретную машину не сложнее чем через USB CY7C68013.

Не согласен. Вот реализовать в FPGA MAC (с внешним PHY) не сложнее, чем реализовать в FPGA USB Device (с внешним ULPI-трансивером). Если есть в наличии готовая УСБ-корка и готовая МАК-корка разумеется. А вот погнать поток в 68013 - это автомат о 10-ти строчек.

 

Про софт - речь шла о embedded-софте и его количестве, PC-софт разумеется писать надо, и там согласен, совершенно фиолетово, eth, usb или незаслуженно тут забытый IEEE1394, как и SAS, SATA и старый добрый параллельный SCSI (который кстати физически простой LVDS). А вот про удаление куда-то от компа вопроса не стояло вообще.

[zltigo 1]

аналогичное с ethernet - повозиться придется с недельку.

Физика Ethernet, поднимается тем-же мизинцем ровно за такое-же время, причем жто время сопоставимо со временем поднятия физики и любого другого пакетного интерфейса. Стек протоколов не нужен, Все точно так-же, только нет жесткой завязки на конкретного производителя, его стеки, его драйвера....

А чтобы было как с УСБ - "воткнул и работает везде и сразу без ручных настроек"

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием :)

Вот, наконец-то, чего я от Вас и добиваюсь. А теперь подробнее - какой именно, для примера. Чтобы был с PHY, чтобы прокачал 20 Мбайт/с в ФПГА, и чтобы стоил $5..6,

А без PHY, типа уже совсем не годятся? Или за 6 долларов 50 центов тоже? Ой! А у Ethernet еще и "трансформатор"....Мы о чем разговариваем? Об штучной разработке, которая должна жить и развиваться и не умереть, напиример, по причине того, что фирма производящая "красивые USB мосты" не обеспечила совместимость с какой-нибудь операционкой, или о массовом бытовом устройстве со сроком морального старения в пару лет? "20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите :). Это только ограничение на стыке с FPGA. Дальше еще вмешивается собственно контроллер и все USBишное хозяйство на на стороне PC. Да тупо, но быстро гнать поток, если никто не мешает, у USB получается хорошо, но забывать, что USB периферийное устройство есть сугубо подчиненное и неравноправное :(.

P.S.

Ну а за 9-12-14 баксов, это уже какой-нибудь ARM9 c Ethernet (впрочем и USB :)) на борту и 8-16-32bit шиной.

[kuzis 0]

Вы хоть сами-то поняли что сказали? Если под "проблемой" понимается принципиальная возможность доступа из локальной сети, то ставите отдельный Ethernet контроллер в PC и получаете точка-точка.

 

Конечно понял. Вставка отдельной сетевухи, и РАЗРАБОТКА ПРАВИЛ ПОДКЛЮЧЕНИЯ, в которых пользователю будет сказано, не тыкай наш дивайс в коммутатор - один из путей решения этой проблемы.

 

Физика Ethernet, поднимается тем-же мизинцем ровно за такое-же время, причем жто время сопоставимо со временем поднятия физики и любого другого пакетного интерфейса. Стек протоколов не нужен, Все точно так-же, только нет жесткой завязки на конкретного производителя, его стеки, его драйвера....

 

Любительство в самом что ни наесть ярком своем представлении. Стек протоколов придуман людьми не от скуки, а чтобы придать каналу связи определенные характеристики. Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная. И лишь использование стандартных протоколов упрощает программирование.

 

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием :)

 

Если кто-то не смог сделать нормальный USB дивайс, то это не значит что у всех разработчиков руки кривые :)

 

 

"20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите :). Это только ограничение на стыке с FPGA.

 

Нет, я говорю - 40 мегабайт :).

 

 

Я не умаляю достоинств USB он имеет свои преимущества, НО это только ЛОКАЛЬНЫЙ интерфейс периферии компьютера, с небольшим расстоянием и отсутствием гальванической развязки.

 

Ethernet - СЕТЕВОЙ интерфейс не привязанным к конкретному компьютеру, система с Ethernet будет работать и на столе с рядом стоящим буком, и в 200 метрах, и в 20 км если надо БЕЗ изменения самой системы!

 

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

[zltigo 1]

Конечно понял. Вставка отдельной сетевухи, и РАЗРАБОТКА ПРАВИЛ ПОДКЛЮЧЕНИЯ, в которых пользователю будет сказано, не тыкай наш дивайс в коммутатор - один из путей решения этой проблемы.

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

Любительство в самом что ни наесть ярком своем представлении. Стек протоколов придуман людьми не от скуки, а чтобы придать каналу связи определенные характеристики.

IP стек? Одругих слышать не приходилось? А в пределах локальной сети используется масса других, и стандарты существуют. Я например, опираюсь на IEEE 802.3 IEEE 802.2.

Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная.

Ну тогда я Вас сейчас осчастливлю :) несколькими десятками строчек "для писюка". Вырезал из собственно проектика под Linux.

char  *device = "eth0";

int interface_init(void)
{
struct ifreq ifr;
int fd, flags = 0;
   if( ( fd = socket( PF_INET, SOCK_PACKET, htons(ETH_P_802_2) ) ) < 0 )
   {
	printf( "Cannot open RAW/SAP device socket\n" );
	return( -1 );
   }

   strcpy( ifr.ifr_name, device );

   if( ioctl( fd, SIOCGIFFLAGS, &ifr ) < 0 )
   {	printf( "Cannot get RAW/SAP interface flags\n" );
	return( -1 );
   }
   ifr.ifr_flags |= IFF_BROADCAST;
   if( ( flags = ioctl( fd, SIOCSIFFLAGS,  &ifr ) ) < 0 )
   {	printf( "Cannot set RAW/SAP interface flags\n" );
	return( -3 );
   }

   if( ioctl( fd, SIOCGIFHWADDR,  &ifr ) < 0 )
   {	printf( "Cannot get MAC Address\n" );
	return( -4 );
   }
.....

   return( fd );
}

int eth_send( uchar *buff, int len )
{
........
memcpy( eth_outbuff.body, buff, len );
mac_flush();
return( 0 );
}

uchar *readinterface( int fd, int *plen )
{
int cc = 0, from_len, readmore = 1;
struct sockaddr from;
   while( readmore )
   {	from_len = sizeof(from);
	if( ( cc = recvfrom( fd, (uchar *)&eth_inpbuff, PKT_MAX, 0, &from, &from_len ) ) < 0 )
	{
    	if( errno != EWOULDBLOCK )
			return( NULL );
	}
	if( strcmp( device, from.sa_data ) == 0 )
    	readmore = 0;
   }
   *plen = cc;
   return( (uchar *)&eth_inpbuff );
}

int mac_flush(void)
{
int retvalue = 0;
struct sockaddr to;
errno = 0;
int plen = ntohs( eth_outbuff.mac.len ) + sizeof(MAC_addr)*2 + sizeof(ushort);
int to_len = sizeof(to);

   strcpy( to.sa_data, device );

   if( (retvalue = sendto( rawsock, (uchar *)&eth_outbuff, plen, 0, (struct sockaddr *)&to, to_len )) < 0 )
   {
	printf( "RAW Sendto:%s\n", strerror(errno));
   }
   return( retvalue );
}

Вот и вся премудрость доступа к фрейму. Для Windows придется, запихтвать еще драйвера cтронних производителей, ибо RAW там поддерживаются условно, но написать в результате, придется примерно то-же самое.

И лишь использование стандартных протоколов упрощает программирование.

Не использование стандарнных, а использование стандарных КЕМ-ТО УЖЕ НАПИСАННЫХ протоколов. Да это упрощает, ибо делать ничего собственно и не надо :). Поэтому я вполне понимаю и разделяю Вашу радость от того, что повесив CYPRESS и Вам удалось решить Вашу задачу левым мизинцем.

Если кто-то не смог сделать нормальный USB дивайс, то это не значит что у всех разработчиков руки кривые :)

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

Нет, я говорю - 40 мегабайт :).

Говорть Вы можете что угодно, но если кроме русского языка владеете и арифметикой, то советую произвести пару операций деления над цифирями приведенными в мануале производителем для параллельного интерфейса и оценить результат.

[SM 0]

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием :)

Кривых разработок много, поэтому пользователи так к УСБ и относятся.

А без PHY, типа уже совсем не годятся? Или за 6 долларов 50 центов тоже? Ой! А у Ethernet еще и "трансформатор"....Мы о чем разговариваем?

Мы разговариваем о мосте, хоть чуть чуть приближающемся по параметрам к 68013. Но Eth. По этому не дороже 6$, это оптовая цена 68013. И с PHY, потому что 68013 содержит в себе PHY (трансивер точнее). А трансформатор можно выкинуть, если речь о линке PC-девайс (именно контроллер-в-PC-девайс), без него все будет работать не хуже, чем с ним, если соблюсти согласование.

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

Стандарт и сертификация для того и призваны, что если кто-то что-то делает, то это работает везде. Делаете свой девайс например с протоколом "Mass Storage Device" - и оно будет работать во всех операционках, в которых этот класс устройств работает. Или любой другой подходящий класс. И производитель моста тут вообще не причем, мост он туп.

"20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите :).

Вы опять занимаетесь целенаправленной дезинформацией, что не есть хорошо для человека, занимающего достаточно высокую "должность" в форуме. У всех CY7C68013, даже в 56-пин корпусе, шина 16 битная (Slave FIFO), синхронная, 48-мегагерцовая, что перекрывает пропускную самой шины УСБ почти в два раза. И передача данных УСБ-ПЛИС идет никак не касаясь его набортного процессора, суть которого - лишь выдавать дескрипторы, короче обслуживать control transfer.

Ну а за 9-12-14 баксов, это уже какой-нибудь ARM9 c Ethernet (впрочем и USB :)) на борту и 8-16-32bit шиной.

За 9-12-14 я и сам знаю. Но 1) Это дорого. 2) Софта в него писать придется не чета 68013-му, где VID-PID на свой поправить, и все. 3) вряд ли найдется решение в одном корпусе размером 5х5 милиметров (суффикс BAX у 68013).

 

 

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

Во первых - руки Cypress не причем. Они сделали "как бы MAC" только УСБ. Вроде как вполне безглючный. А остальная глюкавость зависит лишь от того, кто этот мост использует.

Во вторых - не нравится жить совместно с другими глючными девайсами - повесить на отдельный контроллер, как Вы предлагаете поступить с Eth. Причем с той же целью - гарантии пропускной со стороны PC и невмешательства в поток других девайсов.

Говорть Вы можете что угодно, но если кроме русского языка владеете и арифметикой, то советую произвести пару операций деления над цифирями приведенными в мануале производителем для параллельного интерфейса и оценить результат

Лехко. Имеем 16 бит и 48 мегагерц. На пересылку пакета в 512 байт затраты таковы - 1 такт - обнаружение флага наличия данных в FIFO и RD в ноль, второй такт - получение данного после RD, третий....258-й - считывание 256 слов. Добавлю еще два такта на возможные задержки из-за неуспевания выходов фпга и сетапов CY. Итого 260 тактов на 512 байт при 48 МГц, итого 5.42 мкс, итого 94 МБайт/с. При том, что USB (bulk) может обеспечить физически лишь 53 МБайт/с.

[zltigo 1]

Вы опять занимаетесь целенаправленной дезинформацией....

Так уж и целенаправленной :). Мануал смотрел мельком :( не заметил, что интерфейсов несколько. Виноват :(.

Мы разговариваем о мосте...

Простите, но это Вы упорно разговариваете о мосте, экономии 5 баксов и теперь еще о размерах 5x5 мм, а в теме речь идет о комплексном решении некой проблемы. Перечитайте первый пост.

[SM 0]

Простите, но это Вы упорно разговариваете о мосте, экономии 5 баксов и теперь еще о размерах 5x5 мм, а в теме речь идет о комплексном решении некой проблемы. Перечитайте первый пост.

Я разговариваю как раз о решении вопроса в целом. Что сводится к двум пунктам. 1) Обеспечить соответствие ТЗ (в данном случае пропускную). 2) Минимизировать затраты, а именно 2А - на разработку, 2Б - на себестоимость, ну и 2В) занять минимум лишнего места на плате. На мой взгляд использование моста оптимально решает первые два вопроса (2А, Б), минимально затрагивая третий (В), полностью решая пункт 1. Именно по этому я предлагаю найти другие варианты, которые позволят решить эту же задачу, но менее затратно (включая разработку и площадь места на плате). Пока предложений не было.

[zltigo 1]

Делаете свой девайс например с протоколом "Mass Storage Device" - и оно...

А кто тут утверждал, что достаточно только " где VID-PID на свой поправить, и все" а тут еще и делать что-то надо. Так надо или не надо используя "тупой мост" что-то делать?

как Вы предлагаете поступить с Eth. Причем с той же целью - гарантии пропускной со стороны PC и невмешательства в поток других девайсов.

Я этого НЕ предлагаю, это просто ответ на утверждение Вашего соратника на поминание "проблемы Ethernet" в работу которого могут вмешиваться другие компьютеры. Для решения поставленной автором топика задачи не имею нималейших возражений ни против использования отдельных контроллеров для чего-либо.

[SM 0]

А кто тут утверждал, что достаточно только " где VID-PID на свой поправить, и все" а тут еще и делать что-то надо. Так надо или не надо используя "тупой мост" что-то делать?

В софте для моста - именно поправить VID-PID-дескрипторы. Этого достаточно. После этого мост будет представляться девайсом с нужным VID-PID и гнать через FIFO данные по нужным bulk-трубам. Больше ничего в софте для моста делать не нужно. Ну в крайнем случае еще подкрутить полярности сигналов управления FIFO, если это важно.

А для соответствие дальнейшим стандартам, чтобы "во всех операционках вообще", разумеется придется еще поформатировать свои данные. Но это уже опция суперсовместимости, привязываясь к ОС - в любой винде можно ограничиться либо цайпресовским драйвером, либо микрософтовским bulkusb.sys, а в линуксе все проще, там хватит встроенного в линукс на все случаи жизни. И при этом гнать данные без какого либо дополнительного форматирования в ПЛИС.