[Alex_N 0]

Посоветуйте, пожалуйста, TCP стек и FTP сервер для ADSP-BF518F. Среда разработки VisualDSP++5.0 Update 8. Пробовал пользоваться lwIP из комплекта поставки VDSP. Установил tinyFTP. Работает плоховато. При чтении файлов с FTP сервера в цикле send приходится ставить задержку, а иначе все залипает. Работает только на 10base. На 100base чтение фалов идет медленно(единицы килобайт) и ненадежно. При записи фалов на FTP сервер ситуация обратная. На 10base программа залипает на втором-третьем вызовах recv с ошибкой __cplb_miss_without_replacement или Undefined instruction, а на 100base работает с невысокой скоростью около 100кбайт/с. Пробовал выделять побольше памяти для lwIP, менять размер буферов чтения записи.

[fontp 0]

Посоветуйте, пожалуйста, TCP стек и FTP сервер для ADSP-BF518F. Среда разработки VisualDSP++5.0 Update 8. Пробовал пользоваться lwIP из комплекта поставки VDSP. Установил tinyFTP. Работает плоховато. При чтении файлов с FTP сервера в цикле send приходится ставить задержку, а иначе все залипает. Работает только на 10base. На 100base чтение фалов идет медленно(единицы килобайт) и ненадежно. При записи фалов на FTP сервер ситуация обратная. На 10base программа залипает на втором-третьем вызовах recv с ошибкой __cplb_miss_without_replacement или Undefined instruction, а на 100base работает с невысокой скоростью около 100кбайт/с. Пробовал выделять побольше памяти для lwIP, менять размер буферов чтения записи.

 

Вообще-то lwip работает очень надежно. Не знаю как работает tinyFTP. Естественно, если send делать слишком часто (больше 10 мбит/c для 10) то будет залипать.

Правда на 100 мбит/c lwip работает только если включить кеш программ и кеш данных. Иначе скорость будет меньше чем на 10

Поищите, на форуме обсуждалось как их включать (по слову lwip)

Кроме того скорость высокая по TCP/IP только на длинных передаваемых блоках (не по 100 байт). По UDP этого эффекта нет. При размере блока > 1500 байт у меня (BF537) достигается скорость 80 мбит/c на TCP/IP (что соответствует AN EE312 у AD) и работает месяцами . Правда сигнал real-time с PPI поэтому приходится держать огромные буфера ввода-вывода для выравнивания при ретрансмит

 

 

Альтернатива ucos со встроеным стеком. тоже с некоторых пор (релизов кристаллов) работает хорошо, здесь в форуме обсуждалось. Там были релизы под 533, 537, но в общем случае вообще-то платно

[fontp 0]

Альтернатива ucos со встроеным стеком. тоже с некоторых пор (релизов кристаллов) работает хорошо, здесь в форуме обсуждалось. Там были релизы под 533, 537, но в общем случае вообще-то платно

 

518 тоже есть

http://micrium.com/page/downloads/ports/analog_devices

[Alex_N 0]

518 тоже есть

http://micrium.com/page/downloads/ports/analog_devices

Спасибо за ответ. А с lwIP + VDK такая фигня творится!!! При приеме данных с FTP клиента беспроблемно можно принять файл не более 1800байт. Если размер больше, то программа залипает на очередном recv - вызывается исключение __cplb_miss_without_replacement. Введение задержек между вызовами recv немного улучшает ситуацию - на 2-3 вызова recv программа работает дольше. При просмотре в окне Call stack можно видеть, что сбой проиcходит в основном в tcp_thread при обращении к несуществующему адресу. Также портятся данные не имеющие никакого отношения к lwIP. У меня сложилось впечатление, что в программе не происходит освобождение динамически выделяемой памяти, т.е. количество вызовов malloc больше количества вызовов free. Только почему это происходит?

[fontp 0]

Спасибо за ответ. А с lwIP + VDK такая фигня творится!!! При приеме данных с FTP клиента беспроблемно можно принять файл не более 1800байт. Если размер больше, то программа залипает на очередном recv - вызывается исключение __cplb_miss_without_replacement. Введение задержек между вызовами recv немного улучшает ситуацию - на 2-3 вызова recv программа работает дольше. При просмотре в окне Call stack можно видеть, что сбой проиcходит в основном в tcp_thread при обращении к несуществующему адресу. Также портятся данные не имеющие никакого отношения к lwIP. У меня сложилось впечатление, что в программе не происходит освобождение динамически выделяемой памяти, т.е. количество вызовов malloc больше количества вызовов free. Только почему это происходит?

 

 

__cplb_miss_without_replacement как правило означает, что неправильно настоен кеш

 

 

Возьмите для начала пример "эхо сервера" и добейтесь надежной работы с кешами

Подключение кеша данных требует кой-каких усилий - кеш данных нельзя включить просто так, но в lwip для BF есть кой какая поддержка

http://electronix.ru/forum/index.php?showt...517&hl=lwip

[Alex_N 0]

__cplb_miss_without_replacement как правило означает, что неправильно настоен кеш

 

 

Возьмите для начала пример "эхо сервера" и добейтесь надежной работы с кешами

Подключение кеша данных требует кой-каких усилий - кеш данных нельзя включить просто так, но в lwip для BF есть кой какая поддержка

http://electronix.ru/forum/index.php?showt...517&hl=lwip

При отключенных кеше данных и кеше кода при многократном recv вываливается в UserExceptionHandler из функции tcpip_thread в строке msg->msg.cb.f(msg->msg.cb.ctx);

 

А еще у меня PHY DP83848I подключен не по MII а по RMII. Драйвер от AD пришлось переписать, поменять конфигурацию некоторых пинов и значения регистров. Не кроется ли ошибка в драйвере? Интересно, если проходишь по шагам цикл с вызовами recv, то принять данные удается!

[Alex_N 0]

Я случайно заметил, что у меня в программе не установлен бит CDPRIO - приоритет DMA над ядром. Проверить свою догадку смогу только в понедельник. Строчка с установкой бита CDPRIO была закомментирована мной из за горького опыта с файловой системой ADI_FSS и RSI. Установка CDPRIO приводила с недетерминированному времени реакции на внешние прерывания - т.е. иногда прерывания приходили с задержкой на 10мкс и более. Вектора и обработчики были размещены во внутренней памяти L1. Ждем понедельника...