[slabnoff 0]

В общем осваивая 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 0]

Так, пока докопался до того, что первая часть пакета (первый Ethernet-фрейм) не долетает до ПК судя по тому, что его вообще не видит Wireshark, хотя в EMAC данные на отправку помещаются.

[slabnoff 0]

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

[zltigo 2]

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

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

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

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

 

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

http://www.tnkernel.com

[slabnoff 0]

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

Меня устроит и стабильная работа в фиксированом окружении. В любом случае после куска кала под названием Wiznet W3100 - lwIP просто идеал.

 

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

Бесплатных пирожных не бывает. По минимуму надо хотя бы тогда иметь выделение памяти под пакет сразу в памяти EMAC'а (что как оказалось умеет порт Темкина).

 

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

http://www.tnkernel.com

Спасибо! Похоже это то, что мне нужно.

 

Я на пару лет вообще из жизни форума практически выпал (да и вообще, стыдно сказать, не очень отслеживал современные тенденции) - был ряд очень длительных специфичных работ, поглотивших все время.

[slabnoff 0]

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

http://www.tnkernel.com

 

Посмотрел - в принципе практически то, что нужно. За исключением того, что это все под TNKernel сделано, так что чтобы воспользоваться придется обточить напильником. Вроде и не сложно, но не интересно. В lwIP я уже хорошо "погрузился", так что попробую продолжить с ним развлекаться, благо на это сейчас время нашлось.

[slabnoff 0]

Продолжаю эксперименты с lwIP (1.3.1).

 

1) Переключил алгоритм подсчета КС с 1-го на 3-й (добавил #define LWIP_CHKSUM_ALGORITHM 3 в файле lwiopts.h). Без оптимизации компилятора пиковая скорость выдачи уже 3 МБайт/с на UDP (на максимальном размере пакета, влезающем во фрейм; lpc2388 на 72 МГц). С оптимизациями - чуть больше 4.5 МБайт/с.

2) Вчерне попробовал алгоритм без копирования - с алгоритмом подсчета КС №3 получается уже 5 и 6.7 МБайт/с, соответственно без оптимизации и с оптимизацией. На мой взгляд очень приличные цифры

[slabnoff 0]

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

 

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

[zltigo 2]

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

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

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

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

[slabnoff 0]

Насколько мне помнится - нет - он является мастером по отношению к обеим шинам и ему доступно все. Для 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 2]

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

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

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

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

[slabnoff 0]

Ну и что? Ключевой вопрос с какой скоростью накапливаются результаты и упираются-ли они в производительность 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.

[Quasar 20]

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)

 

Запустил eCos на LPC2478, в eCos родной EMAC драйвер использует у меня для передачи пакетов, внешнюю SRAM память, при передачи наблюдается Underrun ошибка, если поиграться с инициализацией SRAM, то получается добиться улучшения картины, но все равно, передача хоть и идет, но очень медленно. Плата используется starterkit.ru MLPC2478. Шина памяти инититься так:

       volatile cyg_uint32   regval; 

       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMC_CTRL, CYGARC_HAL_LPC24XX_REG_EMC_CTRL_EN);
       hal_lpc_set_power(CYNUM_HAL_LPC24XX_PCONP_EMC, 1);
    
       HAL_WRITE_UINT32(PIN_BASE + CYGARC_HAL_LPC24XX_REG_PINSEL8, 0x55555555);
       HAL_READ_UINT32( PIN_BASE + CYGARC_HAL_LPC24XX_REG_PINSEL9, regval);
       regval &= 0xCFCCFFC0;
       HAL_WRITE_UINT32(PIN_BASE + CYGARC_HAL_LPC24XX_REG_PINSEL9, (regval | 0x10110015));
  
       HAL_READ_UINT32( PIN_BASE + CYGARC_HAL_LPC24XX_REG_PINSEL6, regval);
       regval &= 0xFFFF0000;
       HAL_WRITE_UINT32(PIN_BASE + CYGARC_HAL_LPC24XX_REG_PINSEL6, ( regval | 0x00005555 ));

       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITW_EN0, 0x00);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITO_EN0, 0x00);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITRD0,   0x01);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITPAGE0, 0x00);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITWR0,   0x00);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_WAITTURN0, 0x00);
       HAL_WRITE_UINT32(EMC_BASE + CYGARC_HAL_LPC24XX_REG_EMCS_CONFIG0,   0x00000000);

Если вести передачу из Ethernet RAM то ни каких проблем нет, но хочется все-таки разобраться с работой из SRAM.