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

[A. Fig Lee]

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

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

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

[A. Fig Lee]

Вернулся из отпуска.
Почитал последние постинги.
"Для тех, кто не слышал, повторяем": основная задача это форвард радио пакетов в ethernet.
Так что на чисто ethernet остается не так много времени.
Это STM32F107 @ 72 MHz.
Да, в прерывании идет копирование пакета.

Получил плату с 2х ядерным кортексом. Буду пробовать.

[jcxz]

Да, в прерывании идет копирование пакета.

Ну вот.... А ведь Вас предупреждали...
Если у Вас весь код так построен, то ничего удивительного, что он не успевает UDP-пакеты разгребать...

[A. Fig Lee]

Ну вот.... А ведь Вас предупреждали...
Если у Вас весь код так построен, то ничего удивительного, что он не успевает UDP-пакеты разгребать...

A как надо? В прерывании производить всю обработку? Или оставить и ждатъ пока следующий пакет затрет предыдущий?
Проблема не в этом. Там без граблей не обойтись. А грабли не наш метод.

[jcxz]

A как надо? В прерывании производить всю обработку? Или оставить и ждатъ пока следующий пакет затрет предыдущий?
Проблема не в этом. Там без граблей не обойтись. А грабли не наш метод.

Я конечно не знаком с Ethernet-контроллером STM, но в LPC-шном RX-часть Ethernet-контроллера аппаратно поддерживает очередь доступных для заполнения
буферов: ПО заполняет очередь дескрипторами буферов; кадр принимается в очередной буфер; ПО извлекает дескриптор заполненного буфера из очереди;
приём после этого не останаливается и ничего не затирает - он идёт в след. буфер в очереди.
А в это время кадр в принятом буфере обрабатывается (хоть в ISR хоть в фоновом процессе). И эта обработка проводится прямо в этом-же самом буфере без каких-либо копирований.
Приём может приостановиться только после исчерпания всех буферов в очереди доступных. Но это может произойти только если ПО не успевает обработать поток кадров в течение длительного времени.
К кратковременным задержкам в обработке кадров такой алгоритм работы устойчив - этому помогает глубина очереди доступных для заполнения буферов.
И строить обработку нужно с минимумом копирований, раз у вас проблемы с быстродействием.