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

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

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

Что это за устройства такие, что broadcast-ами загадили всю сеть? И кто это придумал слать UDP с broadcast MAC-адресом?

А какой мак адрес должен быть в UDP запросе, который должен быть получен несколькими адресатами?

Для этого используется IP multicast (для передачи сообщения нескольким адресатам). MAC-адрес в этом случае формируется по определённым правилам, а тут описано по каким.

Broadcast MAC-адрес используется только в ARP-запросах, но они-то точно не должны вешать сеть.

правильнее сказать должен быть использован....

В общем, использование для отправки какой-либо информации UDP с broadcast MAC-адресом - неправильное решение, поэтому и вопрос был - почему так сделано. При таком подходе и большом потоке данных можно заглушить половину устройств в сети, что и имеем. Ни один MAC-контроллер не умеет фильтровать пакеты с broadcast MAC-адресами, а вот при использовании multicast есть такое понятие как hash table. Данная hash table и используется MAC-контроллером для пропуска необходимых multicast MAC-адресов (тех что в ней прописаны) и фильтрации всех остальных.

"В жизни все не так как на самом деле"

Спасибо, интересная теория. Моя задача не найти "кто прав, кто виноват", а придумать решение.
Имеем устройства, без которых нам не жить, и которые посылают именно UDP broadcast с MAC broadcast.
Это данность.

Не верю, что это нельзя решить в прошивке. Верю, что может не хватить знаний/опыта/времени, и второй МК как костыль тогда вполне годное решение при условии, что уж для него знания/опыт/время есть. А вот это как раз не просматривается.
Может быть, тупо приладить дешёвый домашний маршрутизатор и настроить его на фильтрование?

В какой "прошивке"? Можно решить. И решается. Но времени больше ни на что не остается.
100 байтовый пакет занимает 10 микросекунд обработка. За столько же приходит следующий.

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

То была не теория, а элементарные правила, как должна осушествляться передача одной информации несколькии адресатам при использовании ethernet. Раз уж так сделано, то решение - только более мощный процессор, т.к. если бы использовались пакеты с multicast, их можно было бы фильтровать на уровне MAC железно, Вам же придётся задействовать ресурс процессора.

пока Вы не локализуете узкое место - говорить об направлении решения проблемы, мягко говоря не профессионально.
где затык то? обработка пдп, сборка на IP уровне, или где?

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

Лечить, естественно, нужно корень, в меру возможности доступа к его авторам, но пока можно приделать костыли.
(Анекдот на эту тему слышал об эмблеме софтверной компании: сверху перечёркнутый красным жук, в центре велик, внизу грабли, всё на фоне перекрещенных костылей
Если даташиты все есть, в прерывании от Eth можно узнать первые байты пришедшего пакета и выкинуть его, если FF. Без проходов по официальным слоям стека это может занять 1 мкс.
Также вдруг в железке есть свойство запретить к приёму какие-то MAC-адреса совсем, от особо шумящих...
API своё надо прошерстить на предмет как можно более низких запретов.

Говорят, костыль нужен, как должно быть неважно.


Какие-то запретить можно, но broadcast mac нет, его примут все устройства.

Да както некузяво. И так 100 ножковый СТМ32 стоит. Еще один 100 ножковый ради ethernet только.
2. Красиво не получится. Как они будут соединятся, в том же сегменте?
Там фишка же в том, что UDP broadcast приходит в пакете ethernet broadcast. То есть 2й, где UDP выключено, все равно будет принимать весь поток так как вунужден принимать ethernet broadcast - вдруг там ARP? и анализировать.


Какой имеено процессор рекомендуете? Все они, как правило, уже более навороченные. Не ставить же А8 для простого раутера?


Не верю!
Вот документ:
http://tools.ietf.org/html/rfc1122#page-66


Все нормально: UDP бродкасты посылаются с MAC бродкастами

Чему именно не верите, что broadcast не используется для передачи данных, а используется в ограниченном числе протоколов? Тогда Google в помощь.


Broadcast используется в основном для служебной информации или для передачи другой исключительно узкополосной информации. Если Вы начнёте бомбить данные при помощи broadcast - заглушите все устройства в сети, что и произошло.

При чем здесь "ограниченное число протоколов"? Бродакст используется там, где он оправдан, а не там, где "гугл разрешил".
Не верю тому, что "неправильно посылать UDP broadcast с MAC broadcast".
Все законно.
Бывает, что надо и данные передавать при помощи бродкаст, как видим.
То, что Вам такая ситуация не попадалась, ни о чем не говорит. С опытом прийдет.

Не для роутера, а для всего проекта в целом на одном CPU. Можно и A8, почему нет, если окажется удобно и по цене пройдет. Можно ARM9 какой нибудь. Вообще, для того, чтобы роутер не был узким местом, их обычно делают именно на A8 или сопоставимых MIPS, и при этом часто они все равно узким местом остаются. Можно, кстати, эту часть разгребалки сделать и на FPGA, если там действительно загрузка по самые помидоры.

Это слишком большие расходы на разработку. Проще поставить 2 контроллера М3 и связать по SPI.
А8 надо операционку и т.д. слишком громоздко.

При том, что broadcast используется только в ARP, DHCP (может быть где-то ещё), т.е. в протоколах которым не требуется широкая полоса, где нет большого потока информации.


Вы можете не верить, но это так. Вашему устройству нет необходимости принимать тот "ненужный" поток информации. Оно должно было находясь в данной сети выполнять какие-то другие функции. Вот если бы при передаче данных по UDP использовался не broadcast а multicast, Вы бы смогли легко фильтрануть все ненужные Вам пакеты и не ломали бы голову, как же устранить данную проблему. С другой стороны узлы, которым необходима данная информация её бы и принимали, только настроить их надо было бы правильно - на приём мультикаста (выше написано как).


Как видим, передача при помощи broadcast добавила Вам лишних проблем, которых могло бы и не быть если разобраться с multicast.
Скорее всего с опытом к Вам придёт понимание того, что в данной ситуации нужно было использовать групповой IP-адрес, а не строить "костыль" для выхода из ситуации.

Ерунда. У меня используется.


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


Честно говоря своим нравоучительством начинаете раздражать.
Объясняю для тех, кто не понял: ЭТО НЕ МОЙ КОД, НЕ МОЕ УСТРОЙСТВО, СДЕЛАТЬ ТАМ НИЧЕГО НЕ МОГУ.
ВОПРОС НЕ О ТОМ.

Вовсе не обязательно, код пишется точно так же, как и для M, компилятор тот же, и периферия там очень похожая по сути, регистрам, прерываниям, и т.д., а всякие там механизмы трансляции страниц, защит, и т.п. много-задачно-пользовательскую шнягу, просто не надо включать и трогать, забыть о них, и все. Будет "как-бы М", но А.

Какой именно контроллер посоветуете для начала "посмотреть"?

А какая периферия-то нужна, кроме ethernet?

Ничего особенного, USB device, I2C, SPI, GPIO с десяток, может немного больше..
Flash и RAM наружной нет.

Аргумент!!!


Позвольте переадресовать данное пожелание Вам, глядишь, проблемы сами собой устранятся.

Я только в TI ориентируюсь, там не знаю таких A, чтобы не надо было им внешней Flash, так что им придется добавить SPI-флешку для хранения в ней кода, и (возможно) SDRAM-ку. Посмотреть бы для начала советовал на всякие там AM1705, AM1808, и т.п., это даже не А, это АРМ-9, но, думаю, должно хватить.

Еще, на сколько я знаю, атмел делает MCU на базе Cortex-A5, и на ARM9 тоже. Всякие там SAMA5, SAM9
Freescale A5 делает.

Если надо 1GbE, то AM335x

Спасибо, гляну..

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

Спасибо.
Я вот думаю, не проще ли взять beaglebone black и добавить к нему cape который бы принимал 802.15.4

"Все уже придумано до нас"

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

Ну а если захочется туда сделать софт без ОС, в принципе, тоже никаких проблем (как я говорил, "забить" на все лишнее в процессоре, что для ОСей нужно).

Также можете взять за основу любой готовый модуль на AM3xxx или AM18xx (они обычно в формате SODIMM), удобно для встраивания в свою систему.

Не верю. Наверняка можно организовать раннюю фильтрацию кадров, чтобы было не 10 мкс, а 1 мкс, как было уже сказано выше.

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

В моем варианте "красиво" все таки получиться, ваш первый проц все знает про второй проц, и никакие ARP, DHCP и прочее второму принимать не надо, Может вообще на сыром уровне езернет остаться, даже без IP. Сеть подзагадит. но мы же ради "красиво"

А еще из "дельных" советов, может вам взять какую-то LPC с 2 ядрами, типа
http://www.nxp.com/products/microcontrolle...tex_m4/lpc4300/
пусть одно ядро езернет разгребает, и со вторым связь быстрая, которое всю работу будет делать...

вроде я как-то выбирал в свое время был в корпусе с лапками для удобной пайки...

Можно. Прям в интеррапте поставить "костыли" - сделать раннюю фильтрацию кадров.
Не делаю по 2м причинам:
1) Сейчас собираемся делать версию 2, и есть возможность поменять хард, потом будет сложно. Стараюсь переложить на хард как можно больше,
софт всегда успею пригрузить.
2) Есть мысль в следующих версиях пользовать самому UDP бродкаст для автоматического нахождения своих устройств в сети.
Придется в эти костыли ставить еще костыли, в общем чем дальше, тем страшнее

+1. Там и тактовая 204 МГц против 72 МГц у STM32F107. Может оказаться, что только за счёт тактовой проблема отпадёт.

Хмм.. Надо будет обдумать, действительно, можно будет запретить бродкасты на 2м, наверное. Спасибо.
А вот я как раз тоже нашел 2х ядерный LPC4337 и его рассматриваю.
На эту замену согласятся проще всего. Радио часть у нас уже разведена, и проходить опять всякие американские FCC сертификации начальство боится как огня.
Так что с биглбон может и невыгореть..
Сегодня последний день, вернусь из отпуска буду 2х ядерный щупать..

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

это как заплатка-костыль к текущему варианту. поставить 2 одинаковые платы и поправить софт. Как боевое решение переход на 2 ядерный, который ТС и смотрит. 4300 - это шустрые, 4000 были 2 ядерные чуть проще, может дешевле, если вдруг...

плодить процы в системе - это путь который до добра не доводит 2 ядра все таки уже живут вместе, без сюрпризов внутри чипа

И зачем делать заплатку, когда можно просто умощнить текущий вариант, перейдя на ядро с нужным запасом производительности?

Слишком мощный пока пугает, надо добавлять ему флаши и прочее. Будет запасной вариант после LPC4337.
Уже заказал LPC4337

Значит либо не применяете, либо неправильно применяете RTOS.
И почему у вас MAC не может послать Pause frame если поток слишком плотный?
STM-ы это уже как бы давно могут.

Применяем. Значит, неправильно. А как правильно?
2. Эту опцию не ковырял. А она поможет? Данные то нужные, другой вопрос, что предназначены не мне.
Ну заткну я источник этой опцией, а получатель данных куковать без них будет? Время поступления данных критично.
Пересылать их не нужно, слишком поздно.

Сомневаюсь что-то. Сеть 100BASE-T не разрабатывалась для реального времени.
Если кто-то ее загрузил под 100% значит заведомо уже работает не в реалтайме и с потерями.

Pause frame работает до первого свитчера. Так, что всю сеть не затормозит.

В RTOS нужно правильно настроить планировщик.
А как именно, не скажу.
Во первых надо знать возможности планировщика, во вторых надо знать весь состав задач и их время выполнения.
А потом уже раскидать по приоритетам и кольцам.

Может я где-то что-то упустил, но я не понимаю какой "UDP бродкаст" Вы хотите использовать для определения устройств в сети. Для определения адресов устройств в сети (сопоставления IP и MAC нужного устройства, формирования ARP-таблицы) используется ARP (запрос-ответ) далее качество приёма-передачи проверяет ICMP. Если пингануть какое-то устройство (какой-то IP), то увидим именно эти протоколы.
Кто такой "UDP broadcast", откуда Вы взяли это понятие?



Каким образом можно запретить бродкасты?


Поясните пожалуйста, что за данные предаются по UDP с использованием broadcast MAC-адреса? Никак не могу понять смысл данного решения? Какие в нём могут быть преимущества и в чём же такая необходимость?

Объясняю. ARP это не то, это когда известен IP и нужно определить MAC. А когда IP неизвестен?
Посылается бродкаст UDP пакет на определенный порт с информацией "я Вася Пупкин, ищу брата Федю, отзовись, мой IP a.b.c.d"
Программа узнает пакет и отвечает по IP.
"Откуда взял", не помню, я уж больше 15и лет со всем этим хозяйством. Да хоть RFC почитайте, я ссылку приводил.
Посмотрите как Apple свои устройства в сети определяет.



Виноват, не точен. Можно запретить прием бродкастов/мултикастов на уровне ethernet controllera.

Данные реального времени, идет поток с датчиков. О другой части, кто принимает эти сигналы, они ничего не знают.
Поэтому и UDP broadcast.

Только вот беда-то - как-же другим устройствам жить??? Которым не посчастливилось оказаться в одной сети с этим говорливым поделием...
Ведь оно завалит теперь всех в сети своими броадкастами...
Если в этой организации в сети имеются и другие изделия на маломощных CPU, их разработчикам тоже прикажете заменять CPU на более мощный чтоб в чужом кале не утонуть?


Не обязательно. ARP может использоваться и для других целей.
Например у себя в изделии я использую его для проверки занятости IP-адреса. Это ещё одна возможность ARP.
Достаточно поставить IP-источника = 0.
Не знаю, но наверное можно и адрес назначения поставить в 0, тогда никто случайный на Ваши ARP-кадры не ответит.
А когда IP неизвестен, для этого есть другой протокол: RARP. Почитайте про него.


За 15 лет Вы могли-бы найти время и прочитать про ARP/RARP всё

Я понимаю что на 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 вольтовой цепи и все.

Вот это (нигде, правда, не встречал) может быть применимо. Тут нет потока данных с broadcast, которые глушат всё остальное. Послали/приняли пару broadcast сообщений и перешли в нормальный режим. Никого не повесили.

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

Тут ещё раз расскажите, что значит "на уровне ethernet controllera"? На уровне PHY? На уровне MAC?
На сколько известно мне - приём broadcast запретить нельзя!!!


тут наверно имелось ввиду - посчастливилось, они ведь должны быть безумно счастливы приёму кучи ненужного broadcasta

Да ну!

А как вам там с ШИМ-ом получается?
Удалось застабилизировать spread spectrum?

Лучше читайте документацию!