Посоветуйте микроконтроллер, для IP (UDP) filtering Опции

[A. Fig Lee]

В общем, в одной ethernet сети по производственной необходимости оказалось наше устройство на STM32F107 и
много других, которые шлют UDP broadcast.
Так как это ethernet broadcast, приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам.
В итоге периодически затыкается контроллер, так как есть и другие задачи.

Хочу разбить на 2: один микроконтроллер с ethernet будет фильтровать IP пакеты, другой делать другие задачи.
Как бы его и так хватает, это чисто раутер с 802.15.4 250 килобит на IP.
Если бы не затыкался. Какой взять не очень большой микроконтроллер с ethernet?
Хорошо бы еще канал пошире для обмена с другим микроконтролером, но это вряд ли.
Наверное, обычный SPI.

Думал поставить Wiz5100 для фильтра бродкаст пакетов, но он же, наверное, пропустит UDP бродкаст пакет?

[Golikov A.]

Я понимаю что на 90% целью форума является загнобить человека, для этого надо найти единомышленика, не понять задачу, и начать кидать шапками.

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.

Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

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

П.С. Сети бывают разные, у нас есть сеть приборов компьютер и несколько девайсов. Она отрезана от внешнего мира, а внутри происходит полная вакханалия, но это сделано осознано, потому что так она лучше масштабируется и управляется. Ее можно было сделать вообще на сыром Ethernet без IP, но это неудобно для компьютера, потому в ней ТСР/IP. Но сеть изначально предполагалась выделенной, чтобы в ней никого другого не было.

Это примерно как вилка на 12 вольтовом приборе, которую можно в 220 запихать. Наличие такой вилки не означает что ее надо пихать в 220, это означает что человек хотел использовать стандартные розетки, в своей 12 вольтовой цепи и все.

[A. Fig Lee]

Я понимаю что на 90% целью форума является загнобить человека, для этого надо найти единомышленика, не понять задачу, и начать кидать шапками.

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.

Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

Вот! Спасибо. Похоже единственный человек, кто понял задачу.

У меня далеко не 70Мбит.
Скорость ограничивается ПО на компе, которое принимает и передаёт данные. Оно тормозное - устройство периодически успевает заполнить его приёмное окно
и постоянно из-за этого идут приостановки потока на приёмном конце (tcp.window == 0).
Скорость там всего = неск. килобайт/сек.

Бьюсь об заклад, что у вас траффик намного слабее. Во вторых процессор в 1.5 раза быстрее.
Мой тоже успевает. Почти. Но гдето раз в сутки в итоге очередь таки заполняется.
Попробуйте устроить в лупе с нескольких машин UDP бродкаст корокими пакетами и проверьте, получится, ли.

Да, должно, но для этого надо потратить время и деньги. И можно говорить о кривости и несовместимости тех остальных девайсов. И если не указать на ошибки, то broadcast так и будет использоваться для передачи огромного потока данных, а другие будут этот поток фильтровать и не расскажут остальным - КАК?!


Да ну!

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

[doom13]

Молодежь!

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

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

Из Ваших слов следует, что Вы сами являетесь стороннником возможности использования broadcast для отправки данных (массивных данных), следовательно сами и создаёте себе проблемы. Была указана грубейшая ошибка с которой многие не согласились, и Вы в их числе. Ну и способы решения предложены так же, но это временное решение. Если то, о чём вы утверждаете, соответствует стандартам, - всегда найдутся "умельцы", которые отправят broadcast-ом ещё больший поток, что тогда будете делать? Придуманное Вами решение уже не будет работать, и тогда....
А может быть уволят тех, кто создал тот мега-девайс , с которым другие нормальные устройства совместно не могут работать.