Предполагается, что ДСП будет непрерывно накапливать данные поочередно в двух буферах, пока один копится из другого контроллер забирает данные и отправляет по езернету, потом наоборот. Размер каждого буфера не менее 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/

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

Сообщение отредактировал maxut - Apr 16 2006, 02:28

В этом архиве 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 я и сам не люблю Да и нет желания платить такую сумму за непрофильный алгоритм (у нас сеть в качестве вспомогательного интерфейса для удаленного управления встраиваемой системой). Поэтому про него ничего сказать не могу. Описание его здесь.