В данный момент встала задача создания спутникового модема с Ethernet интрефейсом. Необходимо чтоб он мог передавать данные со скоростью в 2 Мбит/с. Требуется присутствие массы протоколов, поэтому присматриваюсь к lwIP стеку.
Есть ли смысл строить Ethernet часть на AT91SAM7X512 + ENC28J60(либо KS8721)?? И вообще, какой ARM брать??
Прошу совета, ибо такой разработкой занимаюсь впервые.

ENC28J60 - это MAC+PHY, вам он не нужен. Если будете использовать SAM7X, то выбирайте любой PHY с MII интерфейсом.


С потоком 2Мбит/с справится по большому счету любой. Как планируете организовать связь модема с процессором?

2 Мбит/с - не так уж и много. Чтобы меньше волноваться по поводу быстродействия, можно подобрать МК с продвинутым Ethernet+DMA, чтобы при необходимости можно было сделать zero-copy receive (lwip это позволяет), а может быть и zero-copy transmit. В качестве PHY у меня, к примеру, стоит KSZ8041TL (TQFP). Если не смущает QFN, то есть KSZ8041NL (подешевле).
По поводу множества протоколов: надо оценить требования к объёму ОЗУ, да и ПЗУ тоже. TCP для скорости порядка 2 Мбит/с при небыстром пинге потребует буферы объёмом десятки Кбайт. Ну а непростая функциональность типа продвинутого веб-сервера требует десятки килобайт ПЗУ.

Как будет организована связь с модемной частью пока не ясно, ибо человек занимающийся спутниковой частью пока дальше матлабовской модели не ушел. Искренне надеюсь что буду подсовывать побитово последовательность бит (IP пакет) который будет кодироваться спутниковой частью и отправляться в эфир.
Протоколов мне надо действительно много, от ARP до Telnet, при этом должна ещё существовать вебморда модема, т.е. веб сервер тоже нужен.
Непосредственно с АРМы ещё будет организован RS-232/422 интерфейс. но это думаю легко осуществимо через USART.
В разработках оборудования мой уровень знаний низок, читаю литературу как могу, но пока мало что проясняется. Поэтому прошу помощи.

Тогда начните с составления списка требований и написания ТЗ. Платформу выбрать еще успеете.

ТЗ уже существует, и к сожалению его не я придумал. Вот выдержка из него

Модем должен обеспечивать организацию следующих типов каналов:
- для цифровых сигналов со скоростями 48; 64; 128; 144 кбит/с по интерфейсу RS-232
- для цифровых сигналов со скоростями 32…512 кбит/с по интерфейсам RS-422, RS-530;
- для цифровых сигналов со скоростями 1.2…2048 кбит/с по интерфейсу Ethernet (100BASE-T)
Модем должен иметь управление
- через интерфейс Ethernet по средствам SNMP, Telnet, HTTP, возможность обновления по FTP
Требуемые IP протоколы:
ARP
UDP
TCP
ICMP
HTTP сервер
DHCP
Network Address Translation
SNMP
Ping, Traceroute, Discovery Protocol
Поддержка VPN
Telnet

Ещё вопрос. Не подскажите, T1/E1 канал возможно организовать с применением ARM??

Значит ENC28J60 не подойдёт, поскольку обеспечивает только 10 Мегабит в секунду.
А вообще купите линукс-плату за 100 долларов.

Хм, любопытно будет посмотреть как такое на основе LwIP-а будет делаться. ИМХО, проще сразу в цирковое училище поступить.

Нас тут целая клоунская команда тогда будет.
Я думаю что пару требований из ТЗ выкинуть мы сможем. Просто наша прекрасная организация сказала "хотим свой модем, чтоб был не хуже чем другие зарубежные". ТЗ писалось на скорую руку, смотря одним глазом на зарубежные модемы (comtech например).
И это при том, что сетевое оборудование организацией не делалось ни разу.

Тут есть принципиальная разница при выборе железа - очень сильно оно зависит от того что Вы в итоге хотите получить.
A. Если модем будет всего лишь перекладывать IP пакеты из одного интерфейса в другой без всякой обработки (типа бридж) + простенький Веб-сервер для управления - это одно. SAM7X для 2Мбпс должно хватить, но я бы вместо него взял LPC17xx - памяти хоть и меньше, но сам процессор быстрее существеннее.
B. Если же цель - полностью то что у Вас в ТЗ написано, то надо строить систему с объемом памяти в несколько МБайт минимум. Это значит внешняя РАМ. Тут уже выбор процессоров очень широкий. Начиная LPC24xx и заканчивая четырехядерными MPC836xx. Лично я бы выбрал Intel IXP42x или даже MPC83xx - у меня просто с ними опыт достаточно большой и цены на них стартуют от $10. Из массового/относительно простого - LPC24xx, но при развитии продукта можете сильно упереться в производительность.
По софту тоже нюансы. Если вариант A, то LwIP-а должно хватить, если B то можно уже и о Линуксе подумать. Для железа варианта B можно предложить софтовый вариант C - сначала сделать A на LwIP и потом его же "допиливать" до B. По разработке вариант C - самый интересный, но требует хорошей квалификации и много времени (хотя, тут от размера/способностей команды зависит). Впрочем, грамотно и качественно сделать B на Линуксе - тоже время и квалификация понадобяться.

+1 к предыдущему оратору. Весь список из ТЗ не влезет в 128 Кбайт ОЗУ, ИМХО. А значит - однокристаллки отменяются, требуется внешняя память, а тут и Linux можно запускать. Возможно, целесообразно для этого просто купить процессорную плату, как уже предлагали выше.

Тут работы на месяц-два. Имеется опыт такой разработки для спутникового канала, но только еще более толстого.
Все перечисленные протоколы во на этой плате поддерживаются уже начальным загрузчиком:
http://www.alylab.eu/OpenProjects/ARMUltimator2/ARMU2.htm







Есть куча RTOS от Micrium-а до VxWorks и ThreadX которые вполне поместятся в такую RAM. Тут линукс совершенно неуместен.
Тем более, что в линуксе даже c SPI можно получить большие проблемы.

чуть встряну,- для инфо - ixp42x уже EOL, посему на него лучше не закладываться.
если смотреть проц такого уровня __^^^^, то в качестве ОС - можно и линукс, - там уже многое реализовано и доступно, правда с затачиванием под свои нужды прийдеться побороться, но это все же лучше чем катать с полунуля .

Вопрос такой - NAT там тоже реализован? Ручками? (не на базе Линукса/WinCE?)

Да, NAT там реализован тоже. Для FTP, для HTTP и модуль кастомизации под любой другой протокол.

Ну... Надо признать - реально круто.

Не думаю что потянем допиливание линуха, а требование NAT и VPN можно пока временно и забыть.
И всё таки, какой МК брать? Интересует в основном что-то от Atmel и с широким диапазоном температур. Но и потенциал тоже важен, вдруг захотим ещё куда такую ячейку интерфейсов сунуть.

Рабочий релиз VxWorks лежит в местном хранилище, там есть практически все что надо.

Если вы делаете серьезную штуку с гарантированным максимальным уровнем потерь то вам обязательно нужны средства дополнительной диагностики Ethernet интерфейса. Это есть из доступных только у микроконтроллеров от Freescale.
У них есть куча диагностических счетчиков физического и MAC уровня совместимых со стандартами SNMP.
Поэтому либо iMX-ы либо ColdFire либо ждать их новых кинетиков.



Какая нафик у вас сетевая безопасность если ваш закрытый ключ лижит во внешней Flash всем на показ, не смешите.
Или вы делаете индивидуальные прошивки для каждого пользователя - еще смешнее.

В серьезных дивайсах используют по нескольку осей. Даже в мобилах по три-четыре оси нынче в среднем.
Так что то, что cisco использует только ios априори абсурдно. Поищите получше на их сайте.

Если хочется Атмел, то я бы глянул на SAM9XE. Корпус есть TQFP - первая макетка будет дешевой, начать можно типа как c однокристалки. Потом, по мере необходимости, добавите внешней SDRAM, поставите NAND для внутреннего диска. 926-ое ядро на 200МГц + внутренняя матрица - вполне ничего себе. Индустриальный диапазон вроде бы есть. По-крайней мере, шанс умереть на неправильно сделанной DDR или плате с мелкошариковым BGA при отстутствии опыта будет небольшим.
А как спутниковую часть цеплять думаете, по какому интерфейсу? Выбран какой-то чипсет или как?

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

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

AlexandrY - доступ к хранилищу, это конечно хорошо, но мне до доступа к нему ещё расти и расти....
А iMX-ы от freescale мне казались чисто мультимедийными деталями. Мы всё таки не телефон делаем.

VslavX - На SAM9XE глянул, мне кажется ROM маловат будет. Что про AT91SAM9263 скажете??

Однако самый раскрученый демо проект на iMX27 это WEВ камера без дисплея, а не смартфон какой-нибудь.
Мультимедия в современных понятиях это обозначение способности одновременной работы с разными физическими каналами на большой скорости.
Так это то что вы ищите.
Кстати эта WEB камера почти один в один повторяет ваше задание, только вместо камеры подключить спутниковый тюнер. И все готово.
Но к сожалению сделано на линуксе.

От ROM-а у Атмела обычно ни жарко ни холодно - там загрузчик и некоторые обычно бесполезные процедуры и таблицы данных. А вот внутренний FLASH, в которую можно записать свою программу - есть только у SAM9XE. Все SAM92xx - безфлешевые, то есть уже самый простой однокристальный вариант не получится - нужна внешняя флэшка для хранения программы. А почему 9263? Вам ни дисплей ни SD-карточка не нужны, тогда уже 9260 - он кстати по пинам совместим с SAM9XE. Собственно, 9XE это и есть 9260+флешка.

Применить AT91SAM9263, imho, - неплохое решение.
Стек IP в полном объёме в спутниковом модеме, imho, лишее.
Собственно модем (программная реализация) потребует гораздо больше вычислительных ресурсов, чем IP стек.
Не имея опыта разработки подобных устройств лучше заложить более "толстое" железо.
Не используйте Linux: медленнее работает, лишняя функциональность.

А мы и на MPC линукс пускали - производительность стека тоже ~100Мбит. При этом не 100% загрузка проца а гораздо меньше.
Если "не умеете готовить" линукс это не значит что линукс ни на что не годится.
Я не против собственных и доморощенных ОС/РТОС. Только надо отдавать себе отчёт, что придётся везде изобретать свой глючный велосипед.

Это очень интересно - я давно пытаюсь узнать сетевую производительность MPC под Линуксом.
Какой именно MPC - модель и частота? Я имел ввиду MPC8347 - у него гигабитные MAC-и, и достигнуто 70 мегабайт а не мегабит. А на сотке 8347 даже пауз между пакетами не оставляет - только минимальные вставки по стандарту. Загрузки проца сейчас не помню, но даже при 70Мбайт она была далеко не 100%. BTW, на 8347 есть глючок с отправкой пакетов - там на гигабите пауза значительно больше чем по стандарту - это тоже на скорость влияет.

MPC8314@400Mhz

И всего 100 мегабит? Или у Вас в предыдущем посте опечатка? Спасибо за ответ.

Физика использовалась 100 мегабитная (не стоит задачи использовать гигабитку)

Moderator: Тему почистил. Следующая чистка этой темы (или любой другой темы раздела по такому же поводу) будет непременно сопровождена раздачей "подарков".

Спасибо)))
Моё сообщение жаль удалили, повторюсь. Возможен ли вывод данных с ARM на шину WME и по средствам чего это осуществить??

По поводу выбора контроллера посмотрите линейку ARMов Luminary от Texas, там есть контроллеры, где Ethernet и DMA на борту, включая PHY. Что касается E1 посмотрите у Lantiq линейку Falc.

E1/T1 посмотрел у IDT. остановился на IDT82P2281.
поправьте ,пожалуйста, если не так рассуждаю
Насколько я понимаю в данном случае идет преобразование битовой последовательности поступающей скажем с ПЛИС или DSP в сигналы для E1/T1, при этом управление осуществляется по SPI интерфейсу с ARM.
Эта же последовательность с ПЛИС поступает на ARM, где посредствам поднятых протоколов преобразуется в фрейм, который выводится на MII и поступает в чип PHY уровня (KSZ8041TL в моём случае) и уходит в розетку rj-45 через трансы.
А так же эта последовательность выводится на USART и уходит на преобразователь уровней для RS-232/422 (AD7306)
Остается вопрос, необходимо чтоб ARM общался со спутниковой частью через VME шину. Есть возможность такой реализации??

Неужели никто с VMEbus не сталкивался?????

Если я ничего не путаю, то VME - это достаточно древняя асинхронная шина, поэтому маловероятно что Вам удастся найти ARM со встроенным интерфейсом VME. Как вариант решения проблемы - взять ARM с хостом PCI (желательно чтобы были арбитр + мастер + тагет "в одном флаконе") и прикрутить туда мост PCI-VME и уже через него общаться с Вашим VME-контроллером.

VslavX, ничего не путаете, она древняя как мамонт, и кроме военных извращенцев никому не нужная совершенно.
Не подскажите по поводу ARM с PCI для обрисованных мною задач??
И если можно, охарактеризуйте пожалуйста логику построения, которую описал выше.

С хостом PCI и с архитектурой ARM контроллеров достаточно много, те же упомянутые IXP420 (вероятно, следует уже смотреть на 430-ые, раз 420-ые уходят). Мост VME-PCI - я с ними не работал, но слышал красивое название "Tundra" - попробуйте покопать в этом направлении. Еще момент - с PCI чип 99% будет BGA, так что платы будут 4-х слойными минимум и класса так 4-5.

Увы, про E1/T1 ничего не знаю, компетентно посоветовать ничего не могу

Спасибо. Посмотрел на Интел IXP430 (и даже скорее на IXP455, потому что там два UART) - очень даже. и интерфейс для подключения E1/T1 трансивера имеется. Правда с трудом представляю как одновременно вещать поток и на Ethernet и на E1\T1 и на RS-232, RS-422, а главное какую ОС-неОС ставить на проц. Но ничего, время терпит пока, читаем маны и курим гугл.
Тундра как оказалось больше не существует, но их Universe II PCI-VME мосты клепают IDT.
Насколько я понимаю интеловцы уже выбиваются из стандартной ARM926EJ-S архитектуры и так просто RTOS туда не прикрутишь?

Проц с шиной VME скорей всего не найти. Мы сделали много систем на основе VME, во всех случаях шина формировалась на ПЛИС. ресурсов требует ничтожно мало! Так что лучше всего добавить в проект самую маленькую ПЛИС чтобы влез PCI интерфейс (можно скачать с opensource) и VME.