Посоветуйте микроконтроллер, для 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 вольтовой цепи и все.

[jcxz]

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

Не знаю - весь тред не читал, но из первого сообщения ТС это не следует.

2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Не знаю как так можно занять Cortex, чтобы он не успевал не свои кадры отсеивать.. %-)
Сейчас как раз занимаюсь Ethernet в устройстве на LPC1768 (100МГц). Оно включено тоже в корпоративную сеть с неск. сотнями устройств.
Если включить встроенный снифер, то получаю непрерывный большой поток широковещательных (и не только) ARP-, IP/UDP-кадров,
и некоторых других типов кадров.
Загрузка CPU при этом (в целом, там почти ничего нет только uCOS крутится, да снифер инфу о потоке в UART выводит) составляет 0.8 ... 1.0 %.
И где я не прав?
И то это у меня драйвер проверяет каждый пакет, а не только свои (валидность заголовков Ethernet/ARP/IP/TCP/..., контрольные суммы считает).
А если отбрасывать сразу не свои по какому-то признаку, то загрузки тут вообще практически никакой не должно быть.
Если, как пишет ТС, кадры идут с периодом 10мкс, и работает Ethernet-DMA, то на все действия в ISR Ehternet хватит с лихвой ~100тактов.

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

Это Вы так поняли. И это совсем не следует из вопроса ТС.
Вменяемые чужие устройства даже в большой сети, не генерят столько широковещательного траффика.
Я прямо сейчас смотрю в лог сниффера, который выводит моё устройство на LPC1768 находящееся в достаточно большой корпоративной сети.

[AlexandrY]

Загрузка CPU при этом (в целом, там почти ничего нет только uCOS крутится, да снифер инфу о потоке в UART выводит) составляет 0.8 ... 1.0 %.
И где я не прав?

Я прямо сейчас смотрю в лог сниффера, который выводит моё устройство на LPC1768 находящееся в достаточно большой корпоративной сети.

Ну вы сравнили.
uCOS это совсем другое дело!
Это самый быстрый и правильный стек из всех доступных для мелких контроллеров.

Да и снифер скорее всего не в сегменте устройства, а небось отделен свитчером. Так что картину показывает скорее всего искаженную.
Опыты со снифером Wireshark показывают, что доверять ему можно только частично, и надо еще смотреть настройки сетевого драйвера PC.

[jcxz]

Ну вы сравнили.
uCOS это совсем другое дело!
Это самый быстрый и правильный стек из всех доступных для мелких контроллеров.

Нет, Вы не поняли
Только ОС - uCOS. Стек к сожалению свой, не uCOS-кий.

Да и снифер скорее всего не в сегменте устройства, а небось отделен свитчером. Так что картину показывает скорее всего искаженную.

Сниффер у меня - это часть моего ПО на LPC, которая выводит в лог поток всех кадров, которые лезут с RMII.