[blackfin 21]

Будет напрягать его BGA и многослойка.

Меня не напрягает.. Мне нравится и BGA и многослойки..

С этим вообще справляется и трехсотмегагерцовый BF531..3,...

Да бога ради! :)

Ну поскольку вещь не крупносерийная, то универсальную железку LPC2378+FPGA тоже натянется :)

Да бога ради! :)

Но BF537 минус FPGA может оказаться дешевле.. :)

[zltigo 1]

Меня не напрягает.. Мне нравится и BGA и многослойки..

Да мне они не нравятся - я их просто ОБОЖАЮ! Только вот есть условия производства у заказчика, да и перечень используемых чипов расширять КРАЙНЕ не желательно - специфика :(.

Но BF537 минус FPGA может оказаться дешевле.. :)

Совсем минус не получится, например, коммутатор из BF не сделаешь - запаришся, да и SPORT-ов маловато. Памяти своей у него тоже маловато + загрузка - в общем обвеска набежит :( + стоимость многослойки....

[defunct 0]

По быстродействию, естественно. На объемы кода в подавляющем большинстве случаеев наплевать. Да и по обьему не обещанные 30% а около 15.

Ну дык для SAM7 не наплевать.

 

К сожалению пока не могу - я не измерял:) У меня не было такой задачи, чтоб выжать из стека все до микросекунды/байта на уровне приложения.

Мне было бы очень интересно посмотреть.

Т.к. мой драйвер основан на копировании и использует блоки не по 128, а в макс размер пакета. C RX стороны идет сбор и копирование пакета, на TX стороне - копирования нет, правится TX дескриптор и отправляется блок длиной в пакет. Почему так - потому что проще формировать. Цифры у меня получились такие (PHY в дуплексе):

 

214 байт/пакет:

с нулевым процентом потерянных пакетов -

8.2kpps прием и одновременно 16.4kpps передача.

с 10% потерь -

14.5kpps прием и одновременно 22kpps передача.

 

(kpps - K packets per sec)

 

1536 байт/пакет соответвенно

0% drop - 3.3k / 5.6k

10% - 4.6k / 5.6k

 

PS: Тест производился в IP forwarding режиме. Последний отправленный пакет дублировался до тех пор пока не придет новый пакет с RX стороны (поэтому TX трафик больше).

[AlexandrY 3]

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.

Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.

Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.

RTOS-ы .. OS-ы на таких скоростях только мешают.

 

Некоторое время назад я разрабатывал прошивку для этого процесора в которой была добавлена функциональность обмена данными по сети и USB. В качестве операционной системы использована FreeRTOS, TCP/IP стека - uIP. Сейчас потребовалось повысить скорость обработки событий устройством и оказалось, что по сети обмен данными идёт медленно. Так как я разбирался со всеми нюансами процесора и внутренностями сети самостоятельно, то мог пропустить какие-то важные моменты. Может кто увидит какие-то недостатки приведённого ниже алгоритма и подскажет как увеличить скорость работы устройства.

Итак, в устройство периодически по сети передаются данные блоком размером приблизительно в 16-20 кБ. Эти данные записываются в масив памяти и по таймеру процесора обрабатываются.

Когда я програмировал работу с сетью то передачу данных сделал блоками по 1500 Байт. Может я что-то не учёл, а может тогда вылезали другие ошибки, но при передачи блока большей длины у меня подвисал процесор (приёмный буфер установлен приблизительно на 2кБ), поэтому сделать так как в USB, когда я пишу в порт всё одним куском, на уровне USB контролера масив разбивается на части, а в процесоре я уже собираю данные (гарантированно доставленные), мне не удалось. Сейчас я смотрю, что похоже можно в обработчике прерываний от сети поставить свой код анализа входных данных и сделать похоже как в USB но не уверен - не буду ли я получать повреждённые даные, которые долго нужно будет перефрагментировать, проверять и т.д.

Сейчас у меня скорость передачи данных приблизительно 2Мб/с по 100 мегабитной сети. Выглядит это приблизительно так (результат теперешнего анализа с помощью Ethereal): отсылается пакет размером в 1500 байт в процесор, приблизительно через 4мс (время работы стека и моего копирования порции в нужное место памяти) процесор отсылает однобайтный пакет-подтверждения о приёме данных (чтобы внешняя программа не начала посылать данные пока я не обработал предыдущую порцию - правильно ли?), приблизительно через (дома забыл логи поэтому тут цыфру не помню) толи 1, толи 0,1мс, отсылается следующая порция данных. В результате 16кБ передаётся приблизительно за 50мс. Долго, было бы хорошо хотя бы в 2 раза быстрее. Можно ли улучшить скорость? Я смотрел, что при обработке стек копирует данные из буфера контролера в память, а потом я копирую куда мне нужно. Может можно сразу копировать без промежуточного буфера, но не будут ли проблемы с проверкой ошибок при передаче?

Может в стеке uIP можно убрать лишнюю обработку?

 

Пока что я в процессе анализа кода, может ещё что и сам найду, но за любые советы и предложения буду искренне благодарен.

[oleghmt 0]

Ну и темку же я поднял :)

 

Поделюсь результатами которые я успел получить. Разбирался, немного, с IwIP по примеру из FreeRTOS, тут пока, что грустно - стек хочет больше килобайт на 10-15 чем в примере с uIP, а я могу максимум 2кБ выделить. Сильно глубоко в дебри стека я пока не забрался, так что возможно в будущем что-то и выплывет.

Зато в моём коде начал играться с компиляцией отдельных файлов в ARM или Thumb. Так вот, когда-то я поставил весь стек (uIP) в ARM, а теперь, когда изменил на Thumb, у меня скорость передачи моих данных по сети возросла на треть.

Ещё сегодня попробую забрать копирование с буферов EMAC в буфер стека, а поставлю просто обмен указателями, тоже что-то подростёт, а дальше буду пробовать в стеке выбрасывать лишние вещи. На счёт обмена указателями, я думаю сделать так: как только пришёл пакет в EMAC буфера, все их пометить как использованые, поменять местами указатели и тогда обрабатывать данные, что-бы не нужно было делать менеджер памяти с переходом между отдельными 128 байтными кусками. Посмотрим, что выйдет

 

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.

Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.

Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.

RTOS-ы .. OS-ы на таких скоростях только мешают.

 

В данном проекте изменить процесор уже нельзя, да и без оси писать будет тяжело - много дополнительных задач, которые работают паралельно

[zltigo 1]

RTOS-ы .. OS-ы на таких скоростях только мешают.

:) А если вдувать в Ethernet пакеты со всей дури это не есть единственное предназначение устройства?

[AlexandrY 3]

Я ж не предлагаю отказаться от оси. Это ж святое!

В серьезных RTOS-ах есть фича как Raw IP и Zero Copy Interface

Но тут обсуждаются как бы возможности по интеграции отдельного недоразвитого пакета.

В принципе человек и пошел по пути сильной модернизации uIP и скорее всего придет к отказу от сервисов стека и RTOS чтобы увеличить скорость.

Применение uIP уже говорит, что дивайс явно не смартфоном будет, просто достался он вместе с RTOS

Пересылка этих пакетов в дивайсе чуть не единственная фича как можно понять.

Ближе к границе 90 Mbit, хорошая архитектура проца является очень важным моментом.

 

:) А если вдувать в Ethernet пакеты со всей дури это не есть единственное предназначение устройства?

[Rst7 5]

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.

 

Это классно конечно, но почему-то забывают про то, что заголовки не имеют фиксированной длинны - так что может оказаться, что граница заголовки/данные окажутся совсем не там, где настроенно для приема...

[AlexandrY 3]

Не забывают, а не договаривают. Ну не всеж сразу всем рассказывать.

Ладно, расскажу вам секрет.

Есть такой тэг VLAN, в MAC хидере. Используя его можно много чего придумать. B)

 

Это классно конечно, но почему-то забывают про то, что заголовки не имеют фиксированной длинны - так что может оказаться, что граница заголовки/данные окажутся совсем не там, где настроенно для приема...

[Rst7 5]

Есть такой тэг VLAN, в MAC хидере. Используя его можно много чего придумать.

 

Не совсем понятно, что же можно придумать с этим тегом на приемном конце? Тег-то приходит из сети, и есть он или нет - еще неизвестно (обычно, в конечном устройстве его надо просто стрипнуть). А я о том, что и в IP-заголовке, и в TCP-заголовке возможны дополнительные опции - например, при открытии сессии очень все любят сунуть опцию MTU. Хотя, с другой стороны, при передаче собственно данных обычно дополнительные заголовки не встречаются (нефиг оверхед гонять, и это правильно), но закладываться на это - себе дороже.

 

Хотя, конечно, это мои размышлизмы, может в мотороловской реализации мака уже и подумали за нас. Дайте, чтоли, ссылочку на даташит, почитаем, проникнемся :)

[AlexandrY 3]

Вообще-то я просто прикалывался, но была одна мелкая идея.

Вот цифровое телевидение например юзает тег VLAN

Если в хидере обнаруживается заданный тэг то все такие пакеты уводятся роутером совсем в другие буферы и на другие порты.

Freescale удобны тем что, что там можно организовать прерывание сразу по приему MAC хидера, определить че за VLAN и быстенько сконфигурить адрес для приемника пакета данных которые будут еще через байт 28 (2.24 мкс) в лучшем случае.

Описание FEC-а от Freescale можно найти в любом ихнем ColdFire-е или ARM-е с встроенным Ethermet-ом

 

А принцип всей системы таков:

Спокойно юзаете свою ОС-ь.

Делаете там ARP, DHCP, DNS.. все че положено.

В некоторый момент получаете из сети по служебному соединению инфу о том, что скоро пойдут VLAN пакеты.

Настраиваете перехватчик MAC хидеров и его отводной канал передачи данных.

Перехватчик не юзает сервисы OC-и, если че нужно - дает понять через генерацию программных прерываний.

Все из предположения, что юзер использует собственный софт на стороне PC

 

Не совсем понятно, что же можно придумать с этим тегом на приемном конце? Тег-то приходит из сети, и есть он или нет - еще неизвестно (обычно, в конечном устройстве его надо просто стрипнуть). А я о том, что и в IP-заголовке, и в TCP-заголовке возможны дополнительные опции - например, при открытии сессии очень все любят сунуть опцию MTU. Хотя, с другой стороны, при передаче собственно данных обычно дополнительные заголовки не встречаются (нефиг оверхед гонять, и это правильно), но закладываться на это - себе дороже.

 

Хотя, конечно, это мои размышлизмы, может в мотороловской реализации мака уже и подумали за нас. Дайте, чтоли, ссылочку на даташит, почитаем, проникнемся :)