| |
 Пересылка данных с ДСП в РС через Ethernet, Нужен совет по выбору архитектуры |
|
|
|
|
 Apr 20 2006, 02:34
|
Участник
Группа: Новичок
Сообщений: 21
Регистрация: 14-04-06
Пользователь №: 16 128
|
Цитата(Edmundo @ Apr 19 2006, 21:32)  Цитата(scum @ Apr 18 2006, 11:53) Разве в НДК нет реализации стека? Собственно, например, вот из 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 компоненты по-хорошему не должны иметь прямого доступа к железу, только через аппликацию. И как этот момент обруливается? Так чтобы сразу взять и прикрутить -- нету. "designed to provide" -- это значит он помогает в этом, насколько я понимаю. Xdais я и сам не люблю :) Да и нет желания платить такую сумму за непрофильный алгоритм (у нас сеть в качестве вспомогательного интерфейса для удаленного управления встраиваемой системой). Поэтому про него ничего сказать не могу. Описание его здесь. desined to provide во-первых всё-таки обеспечивает. И какие возникли проблемы с прикручиванием? Просто либо техасы написали в доке на ндк полную чушь, либо одно из двух. До текущего момента вопиющих косяков в документации от техасов я не встречал.
|
|
|
|
|
|
|
|
Apr 20 2006, 03:22
|
Участник
Группа: Новичок
Сообщений: 21
Регистрация: 14-04-06
Пользователь №: 16 128
|
Цитата(scum @ Apr 20 2006, 09:34) Цитата(Edmundo @ Apr 19 2006, 21:32) Цитата(scum @ Apr 18 2006, 11:53) Разве в НДК нет реализации стека? Собственно, например, вот из 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 компоненты по-хорошему не должны иметь прямого доступа к железу, только через аппликацию. И как этот момент обруливается? Так чтобы сразу взять и прикрутить -- нету. "designed to provide" -- это значит он помогает в этом, насколько я понимаю. Xdais я и сам не люблю  Да и нет желания платить такую сумму за непрофильный алгоритм (у нас сеть в качестве вспомогательного интерфейса для удаленного управления встраиваемой системой). Поэтому про него ничего сказать не могу. Описание его здесь. desined to provide во-первых всё-таки обеспечивает. И какие возникли проблемы с прикручиванием? Просто либо техасы написали в доке на ндк полную чушь, либо одно из двух. До текущего момента вопиющих косяков в документации от техасов я не встречал. Кстати, с евмной бордой есть отчетливые примеры, демонстрирующие работу со стеком. Причем работающие. Какие могут возникнуть проблемы с прикручиванием, если говорить о референсной борде? Единственный вариант что я могу представить это то что вы либу не смогли портануть на свое железо, оказались нужны сырцы, так? Но как у вас получился такой дизайн мне слабо представляется :-)
|
|
|
|
|
|
|
|
Apr 24 2006, 02:35
|
Участник
Группа: Новичок
Сообщений: 31
Регистрация: 20-12-05
Пользователь №: 12 440
|
Цитата(slabnoff @ Apr 19 2006, 15:25) Пробовал разные варианты:
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.
С уважением, Андрей Слабнов. Был бы признателен за исходники. Если не трудно вышлите, пожалуйста на max_kh@inbox.ru
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
