Спасибо.
Я вот думаю, не проще ли взять 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-адреса? Никак не могу понять смысл данного решения? Какие в нём могут быть преимущества и в чём же такая необходимость?