Jump to content

    
Sign in to follow this  
pil123456789

100Mb Ethernet

Recommended Posts

Понадобилось прогонять через систему 100Мб, видимо UDP пакетами.

От контроллера нужно лишь наличие мощи, чтоб переваривать 100Мб и отправлять в некий другой интерфейс.

 

Чем иp ARM минимально можно обойтись?

Работал тока с младшими stm32 и аналогичными LPC, они явно не тянут.

Share this post


Link to post
Share on other sites

Что это по вашему не тянут? и 100Мб это скорость или объём? Скорость не та? Потеря пакетов? Младший это 107 как я понимаю. И какой Phy используете?

Share this post


Link to post
Share on other sites
Что это по вашему не тянут? и 100Мб это скорость или объём? Скорость не та? Потеря пакетов? Младший это 107 как я понимаю. И какой Phy используете?

 

100Мб - это поток(вероятно UDP пакеты), реально будет меньше ~30-50Мбод, но запас это хорошо. Суть девайса парсить этот поток и выплевывать информацию в 16 последовательных интерфейсов ~3-5Мбод.

 

По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4?

Интересует ваш опыт работы с загруженным Ethernet 100.

 

Непонятно зачем конкретизировать физ. уровень, я пока выбираю контроллер.

 

Share this post


Link to post
Share on other sites
По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4?

Интересует ваш опыт работы с загруженным Ethernet 100.

Подобный поток (80+Мбит/с) вполне нормально перелопачивался даже на SAM7X. А вот 16 последовательных интерфейсов придется окучивать внешней логикой.

Share this post


Link to post
Share on other sites

... отправлять в некий другой интерфейс. Это как? Как только какая мало-мальская обработка (5-8 команд) потока, то приплыли.

Не тот проц для этого выбрали. Cortex_ы любые, не причем. Сразу FPGA выбирайте.

Share this post


Link to post
Share on other sites

Спасибо всем за ответы.

Варианты значит такие:

1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов

2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD

 

А какого уровня FPGA смотреть/пробовать? (уже не та ветка форума похоже)

Share this post


Link to post
Share on other sites
Варианты значит такие:

На самом деле надо много считать.

1. Ethernet - как будет выполнен? Соединение точка-точка? Тогда реально можно получить суммарно 80-90Мбит.

Какого размера будут передаваемые блоки данных? Ethernet-фрейм в стандарте по минимуму содержит 26-28 байт

служебных. Если у вас блоки данных будут по 2 байта, то требуемые 50Мбит вы не получите. Вы упомянули UTP.

Там служебной информации еще больше. Если же не точка-точка, а в локалке еще есть кто-то живой, то скорость

передачи становится вообще не подлежащей расчету.

2. Следующее узкое место - передача данных из буферов Ethernet на последовательный интерфейс. Ладно бы один.

Тогда DMA и все в порядке. У вас 16. Значит что-то внешнее. Но во что-то внешнее, в ту же FPGA, тоже надо передать,

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

контроллер с Ethernet и FPGA.

 

Share this post


Link to post
Share on other sites

... 1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов

3-й цыклон, 2 помедленнее, но может вас и устроит.

 

2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD

... выбор зависит от протоколов ваших интерфейсов.

Share this post


Link to post
Share on other sites
Это где вы их наберете? Столько-то. Как то вам надо бы поближе к реальности.

Не-не, Сашка! Тут можно хитро-вывернуться, если собрать четыре одинаковых независимых девайса и соединить их параллельно в Ethernet.

Каждый из девайсов имеет один ethernet-вход и четыре USART-выхода. Девайсы имеют один и тот же IP адрес и принимают UDP-поток на одинаковый номер порта (например 12345). Приняв UDP-пакет каждый девайс выделяет из него свою порцию данных для _своих_ четырех последовательных портов. Собственно, здесь эти четыре девайса и будут различаться.

 

Share this post


Link to post
Share on other sites
Тут можно хитро-вывернуться, если собрать четыре одинаковых независимых девайса и соединить их параллельно в Ethernet...

И кто им раздаст один и тот же поток? Разве что налепить за одним PHY четыре процессора, но этот вариант явно хуже, чем одна FPGA или один процессор + CPLD/FPGA.

Share this post


Link to post
Share on other sites
Не-не, Сашка! Тут можно хитро-вывернуться

Да, можно и так. Особенно если FPGA для тебя (точнее для меня :) ) темный лес. Но блин

затратно наверное. Но исходить все равно надо из начальных условий, о которых я и

написал. Если в сети будет еще кто-то живой - забудь о 100 Мбитах, и даже о 50. Если у

тебя пакеты в которых данных по 2 байта - забудь тоже. Да и ТС не говорит, что за

последовательные каналы ему нужны. Может SPI. Столько тоже нет. Хотя может у каких-нибудь

чипов и есть 4 SPI, не в курсе, не пользовал.

 

 

Share this post


Link to post
Share on other sites
И кто им раздаст один и тот же поток? Разве что налепить за одним PHY четыре процессора, но этот вариант явно хуже, чем одна FPGA или один процессор + CPLD/FPGA.

Возможно мы говорим о разном. Я имею ввиду -- UDP-поток, ну или свой какой-нибудь "доморощенный" (не стандартный). Источнику достаточно "вещать" в сеть, а заботиться о том, принимается ли поток -- не обязательно. Так сказать симплекс-передача без обратной связи. Его задача -- выплюнуть в сеть информацию, а уж поймали ли ее, и сколько девайсов поймало -- не его дело.

 

"С моей стороны проблем нет. Пули из ствола ушли. Проблемы на вашей стороне." (с)исадмин на службе.

 

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

 

Да, и самое главное, наверно тут не следует поднимать стандартные библиотеки для работы с сетевыми протоколами. Я бы написал свою реализацию. Собственно, я как-то давно так и делал, еще на ENC28J60 + MEGA8/16. Особо сложного тут ничего нет. Сложности только в маршрутизации этого нестандартного потока. Если потребуется маршрутизация, то можно же на одном из четырех девайсов поднять частично ICMP, ARP-протоколы. Пусть один за четырех отдувается. Не проблема.

 

Я не знаю. Я бы делал так, как описываю. Я не знаком с технологией FPGA, поэтому мне проще поставить четыре копеечных STM32 и не затягивать разработку. Мое рабочее время стоит на много дороже. Устройство вряд-ли будет производится серийно. Поэтому разница в 1000 рублей (четыре МК, вместо одного, округленно) -- никак не скажется на конечной стоимости изделия, цена которого вряд-ли будет ниже 10-20 труб.

 

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

 

Извините за оффтоп.

 

Если в сети будет еще кто-то живой - забудь о 100 Мбитах, и даже о 50. Если у

тебя пакеты в которых данных по 2 байта - забудь тоже.

Ага. Все так.

Да уж... поколение молодых разработчиков. Привыкли, понимаешь, мыслить на уровне кубиков библиотечных функций и программировать мышкой. Надеются на то, что мощный проц всё вытащит. Глубоко не копают. Зачем? Лего-разработчики, мать их! (Это я не о ТС. Это я по старчески, по доброму. В воздух.)

 

Share this post


Link to post
Share on other sites
Варианты значит такие:

1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов

2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD

а какой именно последовательный интерфейс, если только в одну сторону надо, то можно попробовать из 16-ти разрядного параллельного порта (как у блэкфинов, например) сделать 16 последовательных интерфейсов типа SPI.

ну или из внешней шины памяти,

а если без запаса, ~40мБит езернета устроит, то можно вообще сделать на ADSP-BF592 + KSZ8851SNL.

 

Share this post


Link to post
Share on other sites
Возможно мы говорим о разном. Я имею ввиду -- UDP-поток, ну или свой какой-нибудь "доморощенный" (не стандартный). Источнику достаточно "вещать" в сеть, а заботиться о том, принимается ли поток -- не обязательно. Так сказать симплекс-передача без обратной связи. Его задача -- выплюнуть в сеть информацию, а уж поймали ли ее, и сколько девайсов поймало -- не его дело.

Только источнику придется вещать в broadcast или multicast режиме, иначе до всех не дойдет.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this