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 требует небольших накладных расходов.

[zltigo]

Предполагается, что пакет с результатами измерений имеет размер 1 КБайт...

Ну и что? Ключевой вопрос с какой скоростью накапливаются результаты и упираются-ли они в производительность MAC.

необходимо некоторое количество пакетов держать в буфере по прикидкам хватит 20 пакетов

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

[slabnoff]

Ну и что? Ключевой вопрос с какой скоростью накапливаются результаты и упираются-ли они в производительность MAC.

Ключевой вопрос в том, чтобы максимально разгрузить процессор, т.к. хочется реализовать максимально возможную матобработку результатов измерений. Сам МAC вполне может обеспечить несколько МБайт/с (практически близко к максимуму Ethernet 100 Мбит/c) и в него никто не упирается. Упираемся в подсчет КС IP/UDP/TCP и в необходимость копировать данные, на что тратится очень немало драгоценного процессорного времени (ну не охота мне обратно на связку ARM+DSP возвращаться без серьезной необходимости).

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

Что-то посоветуете? TCP - в текущем применении подходит, но при росте потока данных (развитие текущей задачи) быстро перестает хватать (про оптимизации с подтверждениями я в курсе); чистый UDP - не обеспечивает целостность; UDT - слишком сложно (хотя может быть я просто не разобрался). Пока получается, что для управления устройством сверху использую TCP (команды не часты и время реакции не очень важно, а вот результаты измерений могут идти неслабым потоком), выдача результатов измерений - инициативно снизу по UDP, с возможностью сверху переспросить "битые" пакеты из FIFO-буфера, а т.к. клиент под Виндой буфер минимум на 100 мс (луше 200 мс) вынь да положь.

P.S. Пока конечно некоторый "сумбур" в голове - по сути сейчас пока еще НИР (т.е. накопление, систематизация, анализ информации + некоторые практические опыты), а не непосредственно реализация, так что потенциально есть свобода даже процессор сменить (на это правда всего 2 недели - дальше уже схему в разводку отдадут), а уж о программной части и говорить нечего.
P.P.S. По поводу ограничений Ethernet DMA - AN10576_1.pdf/Section 5 - про контроллеры DMA и их ограничения:
The Ethernet DMA has direct access to the 16kB of Ethernet SRAM. In addition to this memory, it can also access the 8kB of general purpose SRAM and the memory on the external memory bus (applies only for the LPC2378 and LPC24xx family). Both these memories are on the AHB2 bus.
Ну и соответственно там же картинка "Ethernet memory access", на которой явным образом обозначено какую память можно использовать - внутреннее ОЗУ/ПЗУ Ethernet DMA не доступно.
А в самом конце описания DMA engines:
Please note that none of the above DMA engines can access the memory on the ARM7 local bus. The memory on the local bus is only accessible by the ARM7 CPU.