lwIP + FreeRTOS + lpc23xx (24xx) Опции

[slabnoff]

В общем осваивая lpc2388 решил разобраться с Ehternet. uIP идущий в комплекте с FreeRTOS успешно доковырял для того чтобы все заработало (там работы было на пару часов - инициализация PHY и IAR вместо Rowley). Но общее впечатление от uIP не очень хорошее - не место ему в ARM с операционкой - больше он все-таки подходит для однозадачки и слабых процов, ну или в тех случаях, когда всего функционала - простенький Web-сервер.

Почитал про lwIP, вспомнил что как-то слил отсюда чей-то пример портирования lwIP 1.3.0 как раз под нужный мне девайс + FreeRTOS (к сожалению вспомнить чье не могу). Подцепил все это к своему проекту, добился соединения и работы простенькой задачки - Web-сервер из примеров по lwIP и начал разбираться дальше. Т.к. меня прежде всего интересует передача по UDP делал несколько экспериментов и натолкнулся на баг - при посылке UDP-пакета большего размера, чем влезает в один Ethernet-кадр и соответственно пакет должен быть побит на два Ethernet-кадра приходит только второй кадр (видно в т.ч. по Ethereal). Сначала думал, что баг связан с неправильной работой с netif->mtu, даже его нашел и исправил, но по большому счету это ситуацию не исправило.
В общем уже голову сломал. Данный порт судя по содержимому EMAC.c/EMAC_ISR.c сделан из порта uIP и что выглядит не сильно красиво (хотя автору и за то что есть большое спасибо). Готов уже делать порт самостоятельно, но к сожалению начальство начало поджимать и времени на это есть совсем не много. В общем может быть кто-то чем-то сможет помочь? Если готовым портом не поделитесь, то хотя бы общие советы может какие по портированию дадите?

Нашел откуда порт брал - http://electronix.ru/forum/index.php?showt...st&p=435397.

[slabnoff]

Мдя... Накопал, что баг явно в процедуре IP-фрагментации (ну и еще несколько багов явно есть при портировании). В итоге созрел на свой порт. Немного поисследовал, поразбирался с emac... Для начала заменил копирование по-байтно в цикле банальным memcpy() - в итоге около 2 Мбайт/с вместо 1 Мбайт/с (UDP, максимальный размер пакета влезающий в один Ethernet-фрейм). Однако emac умеет отсылать пакеты из любой области памяти, в то время как все просмотренные мной порты lwIP и uIP зачем-то копируют эти пакеты в буфер EMAC'а. Предварительный (имитационный) код показывает 3 МБайт/с (с включенной оптимизацие компилятора - 4 МБайт/c). Странно, что портов с таким подходом нет.

[zltigo]

Для начала заменил копирование по-байтно в цикле банальным memcpy()

Ну нормальное memcpy() совсем не банально Ну а все эти lw да u в общем-то поделки и не думаю, что их можно без огромных затрат довести до ума и стабильной работы в произвольном окружении

Однако emac умеет отсылать пакеты из любой области памяти, в то время как....

Только вот при этом будет заниматься не преферийная шина AHB а шина памяти контроллера и ядро будет бить баклуши. Иногда очень удобно использовать USBишную память с ней по DMA можно с внешней шины пересылать и MAC по DMA доступ имеет.

Ну а стек протоколов бескомпромисный - смотрите BSD порт Юрия Темкина - он тут несколько раз уже ссылки постил, даже сегодня
http://www.tnkernel.com

[slabnoff]

Только вот при этом будет заниматься не преферийная шина AHB а шина памяти контроллера и ядро будет бить баклуши. Иногда очень удобно использовать USBишную память с ней по DMA можно с внешней шины пересылать и MAC по DMA доступ имеет.

В общем сделал nocopy алгоритм, забирающий данные из внутреннего ОЗУ, запустил - Wireshark принимает пакеты со сплошными 0x55. Прочитал внимательнее документацию - емаковский DMA умеет брать данные только с устройств на AHB1/AHB2 - т.е. внутреннее ОЗУ не доступно. Обидно, мне под результаты измерений надо буфер в 32 КБайт...

[zltigo]

Прочитал внимательнее документацию - емаковский DMA умеет брать данные только с устройств на AHB1/AHB2 - т.е. внутреннее ОЗУ не доступно.

Насколько мне помнится - нет - он является мастером по отношению к обеим шинам и ему доступно все. Для GPDMA AHB c MAC и его памятью действительно не доступны. Других ограничений не помню. А ошибки инициализации и работы DMA надо по любому обрабатывать а не судить по "0x55"

Обидно, мне под результаты измерений надо буфер в 32 КБайт...

??? И что именно его Вы хотите ОДНИМ UDP пакетом заслать? Очень э.... неразумно. Заполняйте буфер и разгружайте его поэтапно.

[slabnoff]

Насколько мне помнится - нет - он является мастером по отношению к обеим шинам и ему доступно все. Для GPDMA AHB c MAC и его памятью действительно не доступны. Других ограничений не помню. А ошибки инициализации и работы DMA надо по любому обрабатывать а не судить по "0x55"

lpc23xx user manual (Rev. 02 — 11 February 2009) / Chapter 11: LPC23XX Ethernet / 3. Introduction (страница 186)


The Ethernet block and the CPU share a dedicated AHB subsystem (AHB2) that is used
to access the Ethernet SRAM for Ethernet data, control, and status information. All other
AHB traffic in the LPC2300 takes place on a different AHB subsystem, effectively
separating Ethernet activity from the rest of the system. The Ethernet DMA can also
access off-chip memory via the External Memory Controller, as well as the SRAM located
on AHB1, if is not being used by the USB block.


Здесь ни слова про внутреннюю память, которая по структуре подключена непосредственно к ядру (через свой контроллер конечно). Хотя явных слов о том, что внутренняя память эзернетовскому ДМА не доступна тоже нет. Но из памяти USB тот же код работает.

??? И что именно его Вы хотите ОДНИМ UDP пакетом заслать? Очень э.... неразумно. Заполняйте буфер и разгружайте его поэтапно.

Предполагается, что пакет с результатами измерений имеет размер 1 КБайт, а т.к. используется свой протокол поверх UDP с возможностью ретрейна, необходимо некоторое количество пакетов держать в буфере (по прикидкам хватит 20 пакетов, с запасом я хотел выделить 32). Соответственно повторная отсылка при использовании EMAC DMA требует небольших накладных расходов.