АРМами только начинаю заниматься. Необходимо связать железяку с РС по коаксил. кабелю ~500м. Планирую использовать сетевые Ethernet-адаптеры, т.к. по кабелю будет идти питание. Нужно забирать данные (поток порядка 300КБайт/с) из внутренней памяти ADSP2185. Есть ряд вопросов:

1. стоит ли использовать TCP/IP или лучше ограничиться UDP
2. потянет ли такой поток связка например LPC2124-CS8900A ( за основу стека планирую взять пример slaa137a для MSP430. Правда там пишут, что скорость порядка нескольких килобайт/с, если переработать этот софт под АРМ насколько увеличится скорость?)
3. если п.2 проходит, что проще и лучше использовать W3100 или CS8900
4. какой лучше использовать АРМ чип (филипс или тексас). В душе тяготею к LPC так как существуют достаточно простые чипы для начального освоения + книга по работе в Keil, но умом понимаю, что TMS470R1B с его DMA-контроллером был бы лучше, т.к. DMA-контроллер очень полезен для связки с ДСП, но что-то кажется черезчур сложен для начинания тексовский чип. В принципе АРМ ничем другим кроме перекачки по Ethernet заниматься не будет, может DMA особо и не нужен?

Наверняка кто-нибудь уже сталкивался с подобной задачей. Был бы очень признателен за советы.

Можно ограничиться UDP, но тогда целостность данных придется обеспечивать
вручную. Правда, и скорость получится выше.


Не очень понятно, чем обоснован выбор кристалла: внешней шины нет и медленные GPIO - может и
не потянуть...


Проще, наверное, W3100 - не придется свой стек наворачивать.
Только надо проверить, сможет ли он обеспечить требуемый поток.


Учитывая п.2 тексас выглядит гораздо привлекательнее. Но не проще ли будет
прикрутить тот же W3100 непосредственно к ADSP?

P.S. Как планируется связывать ARM с ADSP?

А если сразу применить BlakFin с ядром МАС?

Не совсем понятен выбор ARMа. как справедливо заметил aaarrr можно подключить W3100 (а лучше W3150) непосредственно к ADSP. Если выбор сделан, что бы легче реализовать стек, тогда еще лучше взять 100 мипсовый 51 C8051F133 от SiLabs, для него практически без доработки пойдет стек, который в исходниках дает сам Wiznet.

Блэкфин я не знаю. Поскольку времени на изучение особо нет, приходится ориентироваться на то, что знаю- ADSP2185- старый и медленный по современным меркам процессор, ему с обработкой справиться бы, хотя я рассматривал вариант прикрутить прямо к ДСП Визнет, но будут сложности с загрузкой программы в ДСП, придется писать загрузчик, довольно проблемная задача.


Выбор для себя обосновывал простотой освоения контроллера, т.к. первые LPC21хх попроще других (ИМХО). Рассматриваю как вариант TMS470. Из плюсов за тексас наличие оценочной платы для начальных экспериментов, но предварительное чтение доков показывает, что посложнее будет этот чип, хотя преимущества его очевидны за счет внешней шины. Может быть следует остановиться на LPC2292. Как он по сравнению с TMS470R1B? Atmel не хочу применять, есть предубеждение против него.


Планирую обращаться к внутренней памяти ДСП через его IDMA-интерфейс, было бы здорово использовать для этих целей армовский ДМА-контроллер (ИМХО). Возможно его можно было бы задействовать для обращения и к Визнету.

Почему остановился на АРМ -контроллере? Просто решил совместить давнее желание освоить эту архитектуру и текущую задачу

А 500м ethernet по коаксиалу работать будет?

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

Если ограничиться только UDP (небольшая потеря данных некритична) потянет ли 300кбайт/с связка АРМ-CS8900 ? Может кто подскажет где можно глянуть исходники для подобного примера.
Какую максимальную скорость удавалось получить при реализации программного TCP/IP стека на ARM_CS8900 ?

Если имеется ввиду "тонкий" коаксиал, то смею Вас заверить, что Вы вступаете в область шаманства.


Если со стороны PC Ваш софт и не предусматриыается по пути никаих других сегментов сети, то вообще можете ограничиться работой практически голым Etherhet фреймом.
Ну разве только сформировать в нем фрейм IEEE 802.3 (Не пересекается с более массово используемым DIX/Ethernet II).
UDP в данном случае никаих преимуществ не даст - только затраты ресурсов на поддержку. Со стороны PC работа через RAW Socket.

Даже LPC Армы разные бывают...
1. LPC21(0..3)x чеплять к нему на порты CS8980 и эмулировать ногодрыгательством шину - это
будет не освоение а выживание.
2. LPC214x - уже лучше по эмуляции шины, да и и что-то типа SPI-Etherntet (хотя опять - коаксиал вылезает :-( )повесить можно.
3. LPC22xx - ну там внешняя шина родная, все без проблем, но разводка.....

Хотя рассматриваемую систему можно оправдать только этим:

На связке AT91R40008 и CS8900 получалась скорость около 600кбайт/с для TCP.
Но атмел заметно побыстрее и с внешней шиной.

Планируется использовать стальной кабель-трос КГ-1

Если сравнивать LPC2294 и TMS470R1B, оба с внешней шиной, какой выглядит предпочтительней?


А какие варианты лучше? В ближайшей перспективе планируем переходить на Тексовские ДСП, может в связи с этим сразу осваивать под эту задачу OMAP5912?

пример реализации на x51...
at8951rc1+cs8900a+32кб ОЗУ
ARP, ICMP, IP, UDP на пингах около 20 кб в сек.


с уважением
(круглый)

Тогда осваивайте сразу TMS320DM642, у него в одном "флаконе" мощнючий DSP и Ethernet 10/100 Мбит/с. И стек, если мне не изменяет память, есть, поставляется для эвалюэйшон-платы EVMDM642.

Если интересует, есть девайс состоит из adsp2181, альтеры и at91rm9200 (альтера для сопряжения уровней и организации обмена через IDMA). На девайс спортирован Линукс 2.6, написан драйвер для работы с DSP. Кроме этого на устройстве поднят Ethernet. Через него осуществляется съем данных и изменение прошивки для дсп. Если заинтересовало - обращайтесь.

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

И ещё один момент - была названа требуемая пропускная способность - 300Кбайт/с - но не указано предполагаемое кол-во пакетов в единицу времени. Если пакеты будут мелкие, но их будет много, контроллер имеет шанс захлебнуться.

c W3100 получалось до 8 мбит/с

Предполагается, что ДСП будет непрерывно накапливать данные поочередно в двух буферах, пока один копится из другого контроллер забирает данные и отправляет по езернету, потом наоборот. Размер каждого буфера не менее 10 КБайт, т.е пакеты можно сделать максимально возможными.

Про TMS320DM642 почитаю.


Спасибо за предложение. Вариант хороший. Но с RTOS не работал, хотя и есть большое желание освоить в будущем. Если появятся вопросы, обязательно напишу в личку.

Такая скорость получена под РТОС? Судя по спецификации, AT91R40008 должен быть сравним по скорости с LPC2294 , TMS470R1B. Может подскажите, где в инете найти примеры реализации TCP\IP для связки ARM7 (типа LPC22xx)- CS8900A/RTL8019AS желательно без РТОС.

Нет, без RTOS, под самописным TCP стыком.
Примеры драйверов были в свое время на сайте цирруса (под VxWorks и, кажется,
еще подо что-то). В принципе, можно взять какой-нибудь open-source TCP/IP и
портировать его на нужную платформу без использования RTOS.

Делали мы плату на DM642 с поддержкой Ethernet. Правда стека не реализовывали, слали голый Ethernet (на PC использовали библиотеку WinPcap). Есть несколько моментов:
1) На поднятие обмена у нашего лид-программера ушло несколько дней -- как-то заморочно немного там все организовано.
2) Стек TCP/IP есть в виде XDAS-алгоритма за несколько кило$$. Что касается диска EVMDM642, там есть NDK. В данное время пытаемся портировать стек, но с этим NDK все не так просто, возможно не хватает каких-то исходников. Хотя если сделать железо аналогично с эво-модулем, может легче будет.
3) Raw Ethernet при пакетах максимальной длины удалось разогнать мегабит до 60-80.
4) А сам проц -- сила, не спорю, Техас рулит

Скачал с Сируса, попробую поизучать примеры драйверов.
Может подскажете еще ссылки на примеры исходников TCP стека, по которым можно было бы разобраться начинающему в построении стека для cs8900 + ARM7(желательно 16-разр. режим доступа к памяти)


20 кб в сек это 20кбит или 20кбайт в сек?

Тут нужно мух от котлет отделить:
1. Связка CS8900 + ARM7. Приличных исходников для 16 бит режима,
кроме драйверов от цирруса, я не встречал. Скорее всего, Вам придется
написать свой. Ничего хитрого в этом нет, только стоит обратить внимание на то,
что CS8900 очень не любит медленное обслуживание со стороны хоста.

2. IP/UDP/TCP. Если нужна связь с одной машиной, и достаточно только UDP,
то не составит труда написать все самостоятельно. Если же нужен TCP -
смотрите open-source проекты, например LwIP: http://savannah.nongnu.org/projects/lwip/

Спасибо за советы.

В этом архиве http://www.rowley.co.uk/arm/uip-e2124.zip есть работающий порт для
платы Olimex.
Программирование CS8900 выполняется через порты ввода/вывода и расписано достаточно подробно.

простите, да килобайт.
и ышо маленьчкое замечание...
те стэки которые встречались в инете реализованы без внешней памяти (возможно я ошибаюсь, возможно не все). посему в реальных условиях - они мало пригодны. Да сообщения "хэйлохты мир" прокатит, но не более.. Например реальная разбивка и сборка на IP уровне (1500 байт - один пакет, пропускают свитчи по умолчанию) - уже меняет картину не не очень радужную...

с уважением
(круглый)

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

В том же lwip есть возможность настротить максимальный размер пакета, с которым
будет работать программа. Файл с настройками называется, если не ошибаюсь,
opt.h .

Разве в НДК нет реализации стека? Собственно, например, вот из ug322.pdf:
The NDK was designed to provide a full TCP/IP functional environment, with or without routing, in a small memory footprint.
Фактически, по-моему там даже хттп сервер есть. Исходников, впрочем, действительно нет, только либы. Или я ошибаюсь, и там нет заявленной функциональности?
Что же касается стека в виде xdais алгоритма, то не возникнет ли с ним проблем, xdais компоненты по-хорошему не должны иметь прямого доступа к железу, только через аппликацию. И как этот момент обруливается?

я правильно Вас понимаю, что для запуска существующих стэков, нужно переписать IP уровень (и нафига такой, простите "стэк") ? :)
Или по другому... Данный уровень работает ТОЛЬКО с внешней памятью (к сожалению не встречалось, может и плохо смотрел - хз..) ?


с уважением
(круглый)

Ничего переписывать не надо. Стек ТCP/IP будет работать с любым типом памяти: хоть внутренней, хоть внешней. Просто этой самой памяти ему надо достаточно много. А имеющиеся кристаллы эту потребность удовлетворить, как правило, не могут. Вот и приходится ставить внешнюю память.

Пробовал разные варианты:

LPC-2214+Rtl8019AS - использовал стек OpenTCP + FreeRTOS(это совсем не обязательно), в том варианте, который я в итоге сделал удалось добиться скорости порядка 800 Кб/с по UDP (прошелся по стеку и постарался прооптимизировать под ARM) на пакетах по 1 Кб, вариант, работающий с прерываниями и использующий преимущества многозадачности к сожалению так и не доделал, но по расчетам на 900 Кб/с можно было выйти. Могу выслать исходники тестового проекта. Вашу задачу должно покрыть полностью, без внешней памяти можно вполне обойтись, внутренних 16 Кб должно хватить, если делать только мост .

Сейчас использую LPC-2214+W3100a, на данных из внешней памяти (16 бит 55 нс) удалось получить суммарный поток туда-обратно порядка 1.4 Мб/с (UDP). Если просто слать снизу - 1 Мб/с вполне реально. Исходники к сожалению выслать не могу - коммерческий проект, хотя какие-то куски могу выдрать (правда у меня очень сильно на FreeRTOS завязано). Единственная проблема - поделка от корейских ПТУшников из WizNet имеет большой комплект странностей, типа невозможности ответить на другой IP, нежели чем при инициализации сокета и т.п.. Еще более простой вариант с точки зрения программирования, но более неприятный в плане потенциальных глюков, которые могут возникнуть. В принципе можно прикрутить прямо к ADSP - ничего сложного нет, по себе оценил бы в три недели работы максимум + неделю на разработку протокола обмена и несложного отладочного ПО, это если совершенно никуда не спешить, плотненько все по-исследовать, отладить. Единственная проблема - сделать так, чтобы не мешать задачам сбора и обработки в ADSP.

С уважением, Андрей Слабнов.

Так чтобы сразу взять и прикрутить -- нету. "designed to provide" -- это значит он помогает в этом, насколько я понимаю.

Xdais я и сам не люблю Да и нет желания платить такую сумму за непрофильный алгоритм (у нас сеть в качестве вспомогательного интерфейса для удаленного управления встраиваемой системой). Поэтому про него ничего сказать не могу. Описание его здесь.

desined to provide во-первых всё-таки обеспечивает. И какие возникли проблемы с прикручиванием? Просто либо техасы написали в доке на ндк полную чушь, либо одно из двух. До текущего момента вопиющих косяков в документации от техасов я не встречал.

Кстати, с евмной бордой есть отчетливые примеры, демонстрирующие работу со стеком. Причем работающие. Какие могут возникнуть проблемы с прикручиванием, если говорить о референсной борде? Единственный вариант что я могу представить это то что вы либу не смогли портануть на свое железо, оказались нужны сырцы, так? Но как у вас получился такой дизайн мне слабо представляется :-)

Да, имеется в виду своя борда. Какие именно проблемы конкретно, не могу сказать, не я этим занимаюсь. Причина в том, что HAL не доступен в source'ах, а есть он только в porting kit. Ну а дизайн у всех разный

Был бы признателен за исходники. Если не трудно вышлите, пожалуйста на max_kh@inbox.ru