подскажите хороший tcp/ip стек, кроме uIP Опции

[InsolentS]

Здравствуйте! Мне нужно добавить ethernet в мой девайс на AT91SAM7X256, но не знаю какую реализацию стека для этого выбрать. С осями тоже не хочется заморачиваться, по крайней-мере не с FreeRTOS. Мне всего-то надо отправлять с компа на девайс 64-битные посылки. Можно ли реализовать простенький стек самому? Насколько это сложно?

[AlexandrY]

OpenTCP отлично работает без осей и понятно написан (типа коммерческий раньше был).

Здравствуйте! Мне нужно добавить ethernet в мой девайс на AT91SAM7X256, но не знаю какую реализацию стека для этого выбрать. С осями тоже не хочется заморачиваться, по крайней-мере не с FreeRTOS. Мне всего-то надо отправлять с компа на девайс 64-битные посылки. Можно ли реализовать простенький стек самому? Насколько это сложно?

[InsolentS]

OpenTCP отлично работает без осей и понятно написан (типа коммерческий раньше был).

Класс!! То что надо!! У вас случайно нету версии под ARM7 для IAR? А то их сайт
(www.opentcp.org) under construction...

[zltigo]

А то их сайт
(www.opentcp.org) under construction...

Их сайт:
http://sourceforge.net/projects/opentcp/
или мы о чем-то разном?

[InsolentS]

Их сайт:
http://sourceforge.net/projects/opentcp/
или мы о чем-то разном?

Спасибо!!

а может быть у кого-нибудь завалялся примерчик OpenTCP, портированный под ИАР?
простите уж меня ламмера...

[zltigo]

.. OpenTCP, портированный под ИАР?

Там нечего портировать куда либо - чистый, как слеза 'C'. Скормите компилятору и все.

[InsolentS]

Там нечего портировать куда либо - чистый, как слеза 'C'. Скормите компилятору и все.

а привязка к конкретному PHY, регистрам?

[zltigo]

а привязка к конкретному PHY, регистрам?

Тяжелый случай . Полагаете это "ИАР" для IP стека обеспечивает ??
Нет, это будете писать сами, когда выберите желаемый MAC и PHY, и подключите MAC желаемым способом к желаемому контроллеру.

[InsolentS]

Тяжелый случай . Полагаете это "ИАР" для IP стека обеспечивает ??
Нет, это будете писать сами, когда выберите желаемый MAC и PHY, и подключите MAC желаемым способом к желаемому контроллеру.

Самому за себя стыдно Ладно, буду разбираться. Спасибо большое!!

[spf]

Есть еще TINET , developed at Tomakomai National College of Technology Department of Computer Science & Engineering, is a compact TCP/IP protocol stack based on the ITRON TCP/IP API specification. Because TINET is based on the FreeBSD code, for usage the TOPPERS license and FreeBSD license conditions needs to be followed.

[lebiga]

Здравствуйте! Мне нужно добавить ethernet в мой девайс на AT91SAM7X256, но не знаю какую реализацию стека для этого выбрать. С осями тоже не хочется заморачиваться, по крайней-мере не с FreeRTOS. Мне всего-то надо отправлять с компа на девайс 64-битные посылки. Можно ли реализовать простенький стек самому? Насколько это сложно?

Я переделал микрочиповский стек (PIC18, dsPIC) для АРМа. Подкупили полные исходники всех модулей. Работает устойчиво, правда делал только веб управление, телнет и фтп. Еще подкупил драйвер для микрочиповской же микросхемы 28J60 (SPI-ETHERNET, 5$ в Киеве). Есть драйвера универсальные типа NE2000
Конечно, SAM7X имеет уже МАС, но у меня идут LPC лучше, чем атмел, да и PHY искать не надо. Кому интересно - могу более подробно.

[viael]

Я переделал микрочиповский стек (PIC18, dsPIC) для АРМа. Подкупили полные исходники всех модулей. Работает устойчиво, правда делал только веб управление, телнет и фтп. Еще подкупил драйвер для микрочиповской же микросхемы 28J60 (SPI-ETHERNET, 5$ в Киеве). Есть драйвера универсальные типа NE2000
Конечно, SAM7X имеет уже МАС, но у меня идут LPC лучше, чем атмел, да и PHY искать не надо. Кому интересно - могу более подробно.

Мне оооочень интересно.Сам собирался пойти этим путем, да все никак не соберусь.Если порт не "коммерческий секрет" может поделитесь
nebula2@mail.ru

[lebiga]

Мне оооочень интересно.Сам собирался пойти этим путем, да все никак не соберусь.Если порт не "коммерческий секрет" может поделитесь
nebula2@mail.ru

Смотри почту

[viael]

Смотри почту

[Annuta]

и мне можно примерчик ... тоже очень нуно.. Спасибо!
koran2005@mail.ru

[zuy]

Смотри почту

Ну если это не секрет, может для всех выложите?
Или на FTP залейте пожалуйста.

[lebiga]

Ну если это не секрет, может для всех выложите?
Или на FTP залейте пожалуйста.

Выкладываю
Господа, только не обессудьте! Я выкладываю предыдущую рабочую версию моего проекта. Ничего в главном файле c main не удалял. Версия для ИАР, когда-то компилировалась и в Кейле, но там были проблемы с #PRAGMA PACK(1) (еще carm). В новом Кейл МДК этой опции нет, надо везде прописывать __packed.
Главный документ из микрочипа AN833b.pdf

Исходники можно найти на микрочипе. Ищите mstkv220401.zip (пик18) предыд версия, есть RTL8019 драйвер. Но скорее всего это файл на вебе уже нет.

tcpip stack v3.6.zip(пик18) - добавлен драйвер ENC28J60

dsPIC_Stack_v.90.EXE - для dsPIC, интересен более ANSI написанием, добавлены новые функции

Могу выложить на FTP - расскажите как

Прикрепленные файлы

 tcpip_microchip_to_arm.rar ( 152.19 килобайт ) Кол-во скачиваний: 377

 

[lebiga]

Тут посмотрел стек от uIP - был ошарашен сложностью и заумностью формирования веб страниц - какие-то скрипты в виде букв в каждой строчке - да и преобразование в си файл потом - не понимаю, зачем так сложно. В микрочиповском я пишу веб страницу в обыкнованном веб редакторе - в нем и смотрю. Потом ужимается все хтмл файлы совместно в бин и по фтп (или через гипертерминал по сом) отправляю в атмеловскую флешку AT45 и все! Вообще-то ужатие в бин тоже можно переписать и отправлять чистые исходники, но мне влом было разбираться.

Особенности переменных, выводимых в веб страницу - начинается с %, типа %12 - нттр во время выдачи страницы при получении % заменяет 12 (12h) на переменную, которую я сам определил - или число, или строку. Если в веб странице надо написать % - я заменяю на % - единственное неудобство, да и то это нужно делать в cgi файлах, html идут так. Да вообще-то смотрите примеры - более информативно. Естественно пример вырезан - остальное коммерчески используется.

Прикрепленные файлы

 web_mchip_to_arm.rar ( 52.52 килобайт ) Кол-во скачиваний: 219

 

[zltigo]

Выкладываю

Вполне "механический" порт на ARM и так не выдающегося творения Microchip. Сам стек не расматривал, но "драйвер ENC28J60" смотрел пару месяцев назад очень внимательно - произвел неприятное впечатление . Стиль написания обсуждать не буду, но практически полное отсутствие обработки нештатных ситуаций "впечатлило" . Практически единственное место, где что-то обозначено в этом направлении заканчивается "блестящим" выходом их положения - перезагрузкой!!! контроллера.
А при портировании даже этот фиговый листок был убран . При механическом переносе на 32bit платформу не сочли нужным убрать фатальные warnings "Use of address of unaligned structure member" Как оно работает???

[lebiga]

Вполне "механический" порт на ARM и так не выдающегося творения Microchip. Сам стек не расматривал, но "драйвер ENC28J60" смотрел пару месяцев назад очень внимательно - произвел неприятное впечатление . Стиль написания обсуждать не буду, но практически полное отсутствие обработки нештатных ситуаций "впечатлило" . Практически единственное место, где что-то обозначено в этом направлении заканчивается "блестящим" выходом их положения - перезагрузкой!!! контроллера.
А при портировании даже этот фиговый листок был убран . При механическом переносе на 32bit платформу не сочли нужным убрать фатальные warnings "Use of address of unaligned structure member" Как оно работает???

Системы эксплуатируются уже год, рестарта из-за ошибок при приеме заголовков не замечал. Use of address of unaligned structure member - работаем с __packed или #pragma pack - все ок. Ничего не мешает перенести обработку некоторых нештатных ситуаций из других драйверов микрочипа или дописать свое. Для меня главное преимущество этого стека - полные исходники и см. пред. сообщение!

Сообщение отредактировал lebiga - May 6 2007, 11:16

Прикрепленные файлы

 lan_driver.rar ( 43 килобайт ) Кол-во скачиваний: 222

 

[zltigo]

Системы эксплуатируются уже год, рестарта из-за ошибок при приеме заголовков не замечал.

Естественно. Вы даже его выбросили.

Код

    // Validate the data returned from the ENC28J60.  Random data corruption,
    // such as if a single SPI bit error occurs while communicating or a
    // momentary power glitch could cause this to occur in rare circumstances.
    if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)(&header.NextPacketPointer))->bits.b0 ||
       header.StatusVector.bits.Zero ||
       header.StatusVector.bits.CRCError ||
       header.StatusVector.bits.ByteCount > 1518 ||
       !header.StatusVector.bits.ReceiveOk)
    {
;//Reset();
    }

Забыли

Use of address of unaligned structure member - работаем с __packed или #pragma pack - все ок.

Паковка это из "другой оперы".

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

Не мешает, но Microchip этого не сделал и в документации, между прочим, тоже не посчитал нужным поделиться информацией. Ну те кто это запихивает не глядя куда-то и потом мотивируют "год работает" поступают неправильно.
Я сейчас тоже буду использовать этот контроллер для быстрой модификации устройства, но информацию о поведении и разрешении проблем приходится добывать или эмпирическим путем, либо обильно стелить соломку

[lebiga]

Не мешает, но Microchip этого не сделал и в документации, между прочим, тоже не посчитал нужным поделиться информацией. Ну те кто это запихивает не глядя куда-то и потом мотивируют "год работает" поступают неправильно.
Я сейчас тоже буду использовать этот контроллер для быстрой модификации устройства, но информацию о поведении и разрешении проблем приходится добывать или эмпирическим путем, либо обильно стелить соломку

Только что глянул - у микрочипа вышла новая версия 4.02 от 11 апреля. Обработку ошибок так и не сделали, зато добавили вкусностей - TCPPerformanceTest, UDPPerformanceTest, netbios, telnet намного лучше, dns клиент и т.д. Буду разбираться и что-то апгрейдить в своих проектах.
А о соломке - предлагаю обмен информацией, тем более, что у меня есть кому собирать баги при эксплуатации.

[zltigo]

Только что глянул - у микрочипа вышла новая версия 4.02 от 11 апреля.

Странно, но я вижу только V3.6
http://www.microchip.com/stellent/idcplg?I...sUserText=28j60

А о соломке - предлагаю обмен информацией, тем более, что у меня есть кому собирать баги при эксплуатации.

Стек меня не интересует в принципе - свой наработан. На баги в эксплуатации я права не имею . Ну на счет того что получится на железном уровне для 28J60 - подумаю, возможно выложу.

[lebiga]

Странно, но я вижу только V3.6

http://ww1.microchip.com/downloads/en/Devi...tack%204.02.zip

ссылки находятся по поиску документа с ключевым словом TCP

Сообщение отредактировал lebiga - May 6 2007, 12:30

[zltigo]

Обработку ошибок так и не сделали,

Ну инициализацию подправили для мягких перезагрузок теперь корректнее, баг в MACGetHeader() c порчей текущего банка при одном из выходов неуклюже залатали. Убрали зависание в MACFlush(). Какая-то совершенно дурацкая заплатка в MACGetArry() для указателя на буфер равного 1. C бодуна похоже Добавили кучку установок 0 банка. Выкинули тест памяти (наверное догадались его два раза подряд запустить и насладиться результатом). Передатчик стали тупо (вне зависимости от успешности окончания передачи) сбрасывать перед каждой новой активизации передачи - настораживает!
И очень плохое - похерили несколько буферов передачи - типа нет функции - нет проблем
Если это действительно у них такая "борьба с багами" при использовании нескольких буферов, то очень тоскливо

зато добавили вкусностей....

Лучше-бы "фундамент" не латали, а нормальный сделали: (. Если у них и "вкусности" так написаны, то я лучше на хлебе и воде посижу

[lebiga]

Ну инициализацию подправили для мягких перезагрузок теперь корректнее, баг в MACGetHeader() c порчей текущего банка при одном из выходов неуклюже залатали. Убрали зависание в MACFlush(). Какая-то совершенно дурацкая заплатка в MACGetArry() для указателя на буфер равного 1. C бодуна похоже Добавили кучку установок 0 банка. Выкинули тест памяти (наверное догадались его два раза подряд запустить и насладиться результатом). Передатчик стали тупо (вне зависимости от успешности окончания передачи) сбрасывать перед каждой новой активизации передачи - настораживает!
И очень плохое - похерили несколько буферов передачи - типа нет функции - нет проблем
Если это действительно у них такая "борьба с багами" при использовании нескольких буферов, то очень тоскливо

Лучше-бы "фундамент" не латали, а нормальный сделали: (. Если у них и "вкусности" так написаны, то я лучше на хлебе и воде посижу

Вот поискал - оказывается народ писал драйвера, причем писал сразу под арм

http://www.embeddedrelated.com/groups/lpc2000/show/12049.php
http://hubbard.engr.scu.edu/avr/avrlib/doc...__enc28j60.html
или см файл

Прикрепленные файлы

 enc28j60_driver.zip ( 194.65 килобайт ) Кол-во скачиваний: 213

 

[zltigo]

Вот поискал - оказывается народ писал драйвера, причем писал сразу под арм

Народ могое что "писал", переписывыал и "выкладывал", только толковое среди всего выкладываемого встречается крайне редко . Кто-же хорошее выкладывает . Ничего удивительного, если даже производители с именем и деньгами обычно выкладывают более чем сомнительного качества исходники . Похоже ниша сэмплописательства плотно оккупирована студентами или в лучшем случае восточными программистами. Поискоим информации по 28j60 занимался очень плотно. Из многих зол Микрочиповский "драйвер" пожалуй наименьшее. Большая часть на нем и базируется.

[lebiga]

Вот прицепил стек 4.02 микрочипа в свое устройство...
Первое впечатление - работает намного устойчивее 3 версии, http страница от долгого пассивного висения тормозить не начинает. Телнет наворочен слишком, искать пароля и юзера прямо в памяти ENC - долго, а потом освобождать буффер чтением в NULL - плохо(это просто не работает - запись по адресу 0 вызывает abort).

Драйвер ENC28J60 более оптимизирован - приемный буффер и передающие на каждый tcp сокет организованы прямо в памяти ENC. Но это привело к тому, что нужно было уменьшить величину передающих буфферов и уменьшить длину строк в телнете.

Нашел ошибку, скорее из-за компилятора ИАР, в MCC18 проблем нет(8-бит!)

typedef unsigned long DWORD; // 32-bit unsigned

из tcpipconfig.h:
#define MAX_TCP_SOCKETS (8ul)
#define TCP_TX_FIFO_SIZE (200ul)
#define TCP_RX_FIFO_SIZE (200ul)

из tcp.h:
typedef struct _TCB
{
NODE_INFO remote;
WORD_VAL remotePort;
WORD_VAL localPort;

WORD txUnackedTail;
WORD remoteWindow;
DWORD MySEQ;
DWORD RemoteSEQ;
BYTE retryCount;
TICK retryInterval;
SHORT sHoleSize;
WORD wFutureDataSize;
} TCB;
#define RESERVED_TCP_MEMORY ((DWORD)MAX_TCP_SOCKETS*((DWORD) (TCP_TX_FIFO_SIZE+1)+(DWORD)TCP_RX_FIFO_SIZE+(DWORD)sizeof(TCB)))

и в mac.h
// MAC RAM definitions
#define RAMSIZE 8192ul
#define TXSTART ((RAMSIZE-1ul) - (1ul+1514ul+7ul) - RESERVED_TCP_MEMORY)

Буфферы налазили друг на друга, причина - ошибка вычисления RESERVED_TCP_MEMORY, компилятор иар 4.41, устранил так:

#define RESERVED_TCP_MEMORY (MAX_TCP_SOCKETS*( (TCP_TX_FIFO_SIZE+1)+TCP_RX_FIFO_SIZE+sizeof(TCB)))

Вот хочу спросить:
для максимальной надежности в системе с http и telnet управлением - лучше работать с пакетами какой длины - 100-200 байт или 1000 байт? Строка get у меня длинная (много параметров) - до 1000 байт.
Если в http используются 2 фрейма - сколько минимум http (а соответственно и tcp) сокетов нужно открыть, чтобы страницы грузились побыстрее. IE6 вроде открывает не более 4х.
FTP требует 2 tcp сокета для управления и данных - это я уже выяснил экспериментально.

[zltigo]

#define RESERVED_TCP_MEMORY ((DWORD)MAX_TCP_SOCKETS*((DWORD) (TCP_TX_FIFO_SIZE+1)+(DWORD)TCP_RX_FIFO_SIZE+(DWORD)sizeof(TCB)))

с преобразованиями (DWORD) - дурь однозначная - выбрасываь везде, тем более, что константы UL описаны.

для максимальной надежности в системе с http и telnet управлением - лучше работать с пакетами какой длины - 100-200 байт или 1000 байт?

Что такое 'надежнось' и каков канал связи.... Если это то, что я понимаю, то лучше мелкими.

.. сокетов нужно открыть, чтобы страницы грузились побыстрее.

Думаю открывайте по минимуму, иначе контролер на облуживании сокетов будет слабейшим звеном.

[defunct]

Паковка это из "другой оперы".

Паковка из "той оперы", т.к. заменяет все LDR/STR(W) на эквиваленты LDR/STR( B ) в случае невыровнянных полей.

[zltigo]

Паковка из "той оперы", т.к. заменяет все LDR/STR(W) на эквиваленты LDR/STR( B ) в случае невыровнянных полей.

Ой! "А мужики-то и не знают" .
Заменяет, когда может, а гогда Warning? тогда, простите, не смогли заменить, ибо чего предупреждать, если все в порядке. Ну а почему в вышеупомянутом случае работает - это IAR, при обнаружении #pragma pack сразу зарание снимает с себя ответственость, даже если на самом деле все пакуется идеально. Багофича у него такая .

[defunct]

Ой! "А мужики-то и не знают" .
Заменяет, когда может, а гогда Warning? тогда, простите, не смогли заменить, ибо чего предупреждать, если все в порядке.

Warning - потому что производительность упадет.
Но с выполнением все действительно в порядке.

У меня была диллема c RFC2198 (хидер нечетной длины!) копировать содержимое блоков на выровненный адрес, обрабатывать и пихать обратно в пакет, либо применить указатель на __packet структуру.
Дык, второе (смотрел по асм листингу - обращения через LDRB/STRB) получилось работает быстрее.

Ну а почему в вышеупомянутом случае работает - это IAR.
...
Багофича у него такая .

Работает и с RVCT и с STD251..
Нет багофичи там..


Пример, "С" код:

Код

typedef __packed struct tagTest
{
    U32 x;
} TTST_STRUCT, *PTST_STRUCT;

U8 a[ sizeof( TTST_STRUCT ) + 1 ];

void main(void)
{
    PTST_STRUCT pTstStruct = (PTST_STRUCT)&a[1];

    pTstStruct->x = 11223344;

asm listing:

Код

   164: void main(void)
   165: {
0x00001420  E92D4000  STMDB     R13!,{R14}
0x00001424  E24DD004  SUB       R13,R13,#0x00000004
   166:
   167:         PTST_STRUCT pTstStruct = (PTST_STRUCT)&a[1];
   168:  
0x00001430  E59F4238  LDR       R4,[PC,#0x0238]
   169:         pTstStruct->x = 11223344;
   170:  
0x00001434  E59F3238  LDR       R3,[PC,#0x0238]
0x00001438  E1A00004  MOV       R0,R4
0x0000143C  E5C03000  STRB      R3,[R0]
0x00001440  E1A03423  MOV       R3,R3,LSR #8
0x00001444  E5C03001  STRB      R3,[R0,#0x0001]
0x00001448  E1A03423  MOV       R3,R3,LSR #8
0x0000144C  E5C03002  STRB      R3,[R0,#0x0002]
0x00001450  E1A03423  MOV       R3,R3,LSR #8
0x00001454  E5C03003  STRB      R3,[R0,#0x0003]

[zltigo]

Но с выполнением все действительно в порядке.

Совсем не обязательно.

У меня была диллема...

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

1. Берете выложенные исходники.

2. Находите там строчку, о которй шла речь (она там одна одинешенька во всем проекте с таким Warning) в моем посте:

if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)(&header.NextPacketPointer))->bits.b0 ||
header.StatusVector.bits.Zero ||
header.StatusVector.bits.CRCError ||
header.StatusVector.bits.ByteCount > 1518 ||
!header.StatusVector.bits.ReceiveOk)
{
;//Reset();
}

На нее IAR ругается.

Warning[Pa039]: use of address of unaligned structure member D:\ARM_WORK\TCP_IP_M\ENC28J60.c 650

Теперь жду объяснений ПОЧЕМУ он ругается, если header.NextPacketPointer является первым элементом структуры и не может быть не выровнен вне всякой зависимости от паковки структуры.

3. А в том, как это НЕ ПРАВИЛЬНО работает в случае, если адрес реально не будет выровнен на 4, рекомендую попробовать написать пару строк и ткнуться лбом.

[defunct]

1. Берете выложенные исходники.

Взял, посмотрел. Три места с таким варнингом.
IP.c
ICMP.c
и тот что Вы привели.

Теперь жду объяснений ПОЧЕМУ он ругается

Warning выдается тупо на &header.NextPacketPointer.
IAR вполне справедливо считает, что указатель может быть не выровнeнным. Но он упускает из виду приведение типа к указателю на упакованный union.

Более того выдается такой же Warning, на безобидную конструкцию:
pChar = (char *)&header.NextPacketPointer;

Поэтому все три Warning'а здесь - "левые"

Конструкции ((BYTE_VAL*)(&header.NextPacketPointer))->bits.b0 безопасна где б ни располагался NextPacketPointer.

[lebiga]

Немного в сторону от полемики...
Для zltigo
Подскажите, как лучше всего обработать эту ситуацию, кроме резета - сбросит ENC и провести опять инициализацию стека или как-то по другому:

if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)(&header.NextPacketPointer))->bits.b0 ||
header.StatusVector.bits.Zero ||
header.StatusVector.bits.CRCError ||
header.StatusVector.bits.ByteCount > 1518 ||
!header.StatusVector.bits.ReceiveOk)
{
;//Reset();
}

Да и второй вопрос - программный сброс как лучше делать - "b 0" - или еще нужно запретить прерывания(это для другой задачи)?

[zltigo]

IAR вполне справедливо считает, что указатель может быть не выровнeнным. Но он упускает из виду приведение типа к указателю на упакованный union.

Вот "упускает из виду" это и есть IAR баг, которого, как кто-то утверждал ренее, - "там нет".

Подскажите, как лучше всего обработать эту ситуацию, кроме резета - сбросит ENC и провести опять инициализацию стека или как-то по другому:

Как минимум по разному для разных ситуаций а не один 'выход' для всех ). Эти вопросы надо задавать производителю чипа, но после такого "примера работы" совсем бесполезно, похоже.
Пока у себы сделал 'по собственному' разумению и обложил отладочными сообщениями.
CRC Eror просто игнориуется пакет, если конечно не стабильно непрерывно повторяющася ошибка.
Для остальных железных переинициализируется толко железо. Разборки с целостностью софтовых буферов исключены (зато добавлен дополнительный контроль за формированием тех-же
header.NextPacketPointer ). Ошибок в логах не встречал.

Да и второй вопрос - программный сброс как лучше делать - "b 0" - или еще нужно запретить прерывания(это для другой задачи)?

Есть только один правильный "программый" сброс - через Watchdog, все остальные в той или иной степени вызывают проблемы, например, если инициализация железа улетела, или просто банально во время такого сброса Вы по P0.14 штатно нолик записали - улетите в загрузчик по такому ресету. Провокацию LPC на 'мгновенную' выдачу Reaet сделать легко, принудительно в любой момент нарушив 55-AA.

[Dimmy]

А вот еще один порт TCP/IP.
h__://www.modtronix.com/product_info.php?cPath=1_36&products_id=196
Есть все исходники + схемы. Постоянно действует форум. Писан, правда, для PIC18 + RTL8019, но адаптировать под ARM не составит труда.
Пользуюсь около года - доволен. Есть HTTP, FTP, PPP(через COM), поддержка DHCP и netBIOS, работа с сокетами.

[defunct]

Вот "упускает из виду" это и есть IAR баг, которого, как кто-то утверждал ренее, - "там нет".

Ок, забираю свои слова обратно насчет "багофичи", не разобрался в проблеме.

[zltigo]

насчет "багофичи"....

Для общего развития, еще об одной проблеме с взятием невыровненных адресов. Правда, может уже и поправили - не знаю, ибо просто я так не пишу .
http://electronix.ru/forum/index.php?showt...=15808&st=0

Пользуюсь около года - доволен.

Ну то, что работает - понятно, что джентельменский набор фич присутствует, тоже понятно. А чем он лично Вас привлек по сравнениию прочими? В каких условиях используете?
Мне, тут видимо вскоре придется один проект с исходниками заказчику выдавать, так вот свой собственный лелеямый стек как-то и жалковато отдавать в чужие руки, да и с точки зрения "компетентных органов", пусть лучше будет из общедоступных источников взят, нежели специально написаннный. Вот и тоже озадачился, какой взять....

[Dimmy]

Скажем так - особо сравнивать не с чем было, разве что с кривой Rabbit-овской реализацией для контроллеров серии Rabbit 3000 (Rabbitsemiconductor.com + модуль RCM3365). Но для рэббитов изначально диалект языка кривой - некий Dynamic C. А реализацию стека от Modtronix юзаю с фирменным модулем SBC68EC. Устраивает то, что РАБОТАЕТ + есть примеры. Гибкие простые настройки - простыми #define в хидере подключаются/отключаются необходимые модули. Так, в последнем проекте за ненадобностью отключил netBIOS, DHCP, HTTP. Пожалуй и все...

[zltigo]

Скажем так...

При самом поверносном рассмотрении упомянутый стек оказался ранее поминаемым микрочиповским. Естествено с какими-то своими нюансами....

[lebiga]

а вот ребята кинули мне на почту драйвер ENC28J60
для KEIL RTL-TCPNET говорят
я так, глянул по быстрому
может кому нужно
вот отсюда
http://www.keil.com/forum/docs/thread10418.asp

Прикрепленные файлы

 VehCntr.zip ( 7.6 килобайт ) Кол-во скачиваний: 130

 

[zltigo]

а вот ребята кинули мне на почту драйвер ENC28J60

Он просто "никакой" - что-то порезаннное из "родного" микрочиповского с максимально тупо (SPI 1 с FIFO! используется с тупым сканированием после каждого байта, на котором теряется добрая пловина скорости) прикрученным LPC SPI.

[Yra]

а что никто тут не упомянул про Lw/IP - стек? Я его вроде прикрутил + СS8900 - хелло ворд заработал (скомпильнулся правда на 60 килобайт кода) В чём его особенности по сравнению с остальными? (то что там нет ftp и http я уже понял)

[cpl]

а что никто тут не упомянул про Lw/IP - стек? Я его вроде прикрутил + СS8900 - хелло ворд заработал (скомпильнулся правда на 60 килобайт кода) В чём его особенности по сравнению с остальными? (то что там нет ftp и http я уже понял)

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

[MALLOY2]

я сейчас узаю lwip 1.2.0 на STR912F, результатми очень доволен, на тесте типа заполняем масив через memset и отпраляет получил на TCP 30.1 mbit/s на UDP до 60 mbit/s, с приемом немного хуже на UDP не измерял, а на TCP 19.8 mbit/s.

[etoja]

Как на lwip сделать FTP клиента?
Или другими словами: как выглядит С программа в приборе со стеком lwip, чтобы прибор мог активно открыть на удалённом сервере два разных порта одновременно?

[MALLOY2]

да как все делают, а открыть можно скок угодно портов, все зависит от того скоко у вас памяти и какая нужна производительность, у меня на данный момент работает 2 порта сервера, и 1 порт клиента TCP и 1 UDP порт. Использую метод Callback но кому нравятся сокеты можно и их использовать.

1 порт сервера под telnet может подключатся только 1 клиент. и 1 порт под http может подключатся до 4 клиентов одновременно.

[e-yes]

LWIP, At91RM9200, GCC 4.1.2. HTTP-клиент. Скорость скачивания файлов - 5.7 Мбайт в секунду.
Интересно, а сколько вообще предел для этого процессора в скорости передачи (интересует траф входящий, с точки зрения железки)?

Сообщение отредактировал e-yes - Sep 21 2007, 12:22

[Yra]

Насчёт где достать исходники LwIP: на сайте freertos.org скачиваете архив исходников операционки с примерами. Среди примеров- порт данного стека (и заодно uIP) под эту операционку. Существует также порт LwIP стека под uC/OSII (гдето на sourceforge.net - если надо могу уточнить но в поисковике ищется). Эти файлы и взял за основу когда прикручивал LwIP к uC/OSII.

Кто может дать сравнительный анализ uIP и LwIP по размеру кода и функциональности? Ато сомнения гложут...

[Velund]

Кстати, о птицах...

А emBetter кто нибудь реально пробовал?

http://www.stzedn.de/index.php?id=6&L=1

Расписано красиво... А как на деле?

[etoja]

emBetter - неизвестный продукт неизвестной фирмы.
Лучше взять TCP/IP стек от фирмы CMX:
http://www.cmx.com/tcpstacks.htm
Он стоит 9500USD и свободно нигде не лежит.

[scifi]

Кто может дать сравнительный анализ uIP и LwIP по размеру кода и функциональности? Ато сомнения гложут...

Лучше автора никто не сравнит:
http://www.sics.se/~adam/mobisys2003.pdf

[e-yes]

Надо добавить, что сейчас LwIP свободно "доразрабатывается" на нонгну: savannah.nongnu.org/projects/lwip/
Пофиксено немало багов и функциональности добавлено.

Сообщение отредактировал e-yes - Sep 25 2007, 11:45

[MALLOY2]

После отимизаций стека LwIP на STR912FA получил скорость TCP 5.6 метра в секунду .

[Waso]

После отимизаций стека LwIP на STR912FA получил скорость TCP 5.6 метра в секунду .

Весьма интересно в чем заключались эти оптимизации. Хотябы в общих словах.
Кстати у меня при попытке увеличить TCP_SND_BUF выше TCP_MSS сразу пропадала связь и на аки он отвечал ресетами. Неужели у at91sam7x256 ему памяти не хватает... А так скорость 300килоБАЙТ в секунду уверенно.

[MALLOY2]

1) 8- битные и 16 битные переменные полей которые работали как счетчки или как переменные хранящие длинну, также все локальные счетчики счетчики были сделаны 32 битным типом.

2) критичные функции типа CRC перенесены в ОЗУ (в итоге программа в ОЗУ сьела 8к )

3) драйвер MAC буфиризирован.

4) в входном буфере нет копирования, тобиш выделяется место в PBUF под максимальную длинну пакета и в DMA подсовывается адресс, выделение происходит на опереженеие то есть раньше чем принят пакет, это сьедает больше памяти так как выделяется всегда на максимальный пакет, но колосально подымает производительность. В дальнейшем пакет никгде не копируется а по ходу продвижения по стеку разбирается.

5) естественно заменен алгоритм CRC на более быстрый, он кстати идет вместе с стеком но почемуто не включен в него.

6) выкинуты функции memcpy библиотечные и заменены на более быстрые.

7) ну и естественно выбраны оптимальные настройки памяти стека.

8) по итогу код стека во флеш. ~22К, в ОЗУ 8К, использовано памяти под кучу и другую фигню ~60к


Ну приблизительно вот.

Вот мои настройки стека
 lwipopts.zip ( 3.27 килобайт ) Кол-во скачиваний: 232

[ig_z]

3) драйвер MAC буфиризирован.

Что это значит? можно подробнее?

4) в входном буфере нет копирования, тобиш выделяется место в PBUF под максимальную длинну пакета и в DMA подсовывается адресс, выделение происходит на опереженеие то есть раньше чем принят пакет, это сьедает больше памяти так как выделяется всегда на максимальный пакет, но колосально подымает производительность. В дальнейшем пакет никгде не копируется а по ходу продвижения по стеку разбирается.

Т.е. вы реализовали то, что в лвип-шной конфе называют зеро сайз копи? Я тоже думал над реализацией чего либо подобного, но меня затерзали "мутные сомнения". Если ядро работает с езернет памятью, то захватывает шину и емак должен дождаться освобождения ресурса. Мы получаем выигрыш от отсутствия копирования память-память, но получаем блокировку емак-а.
В ином варианте мы тратим время на копирование, но дальше работают оба банка памяти. Один с ядром, а другой с емасом.

Я так понимаю, вы проводили какое-то тестирование. Можно ли подробнее узнать:
1 насколько этот механизм увеличил пропускную способность стека
2 есть ли пропадание пакетов из-за блокировки емак-а
3 Я понял что исходящие пакеты вы обрабатываете "по старому". Почему здесь не применяете зеро сайз копи?

[MALLOY2]

Код

Если ядро работает с езернет памятью

У STR912 нету езернет памяти, есть токо фифо которое в принципе скрыто от юзера, между фифо и озу стоит DMA.

Смысл буферизации заключается в том что б как можно меньше терять пакеты. Если не запустить DMA пакет не будет принят. Работает следующим как токо принят пакет, выделяется новый pbuf размером на макс пакет (1520 байт) и запускается DMA и так пока не кончатся pbuf , приложения следит за этими pbuf и когда надо передвает в стек.

Код

1 насколько этот механизм увеличил пропускную способность стека

намного как при передачи так и при приеме. изначально при первом старете получил 13 mbit/s передача и 5-6 mbit/s прием, на данный момент 40-46 mbit/s передача, 25-30 прием

Код

2 есть ли пропадание пакетов из-за блокировки емак-а

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

Код

3 Я понял что исходящие пакеты вы обрабатываете "по старому". Почему здесь не применяете зеро сайз копи?

Да по старому, вся проблема в STR DMA, он требует выравнивание адреса 4, а payload pbuf не имеет выравнивания и приемущественно расположен на границе 2 из-за 6 байтового MAC адресса. В дальнейшем можно будет переписать управление PBUF так чтобы выходные пакеты имели выравниваение, но это потом.... сейчас меня такие параметры устраивают, а времени в обрез

[ig_z]

У STR912 нету езернет памяти, есть токо фифо которое в принципе скрыто от юзера, между фифо и озу стоит DMA.

Моя ошибка - невнимательно прочитал тред, я почему то был уверен, что вы используете лпс2300. Но в информация по любому очень интересная, большое спасибо

[i.cf]

Возвращаясь к теме подскажите хороший tcp/ip стек, кроме uIP:
Кто-нибудь использовал Keil'овский RL-TCPnet?
Как он по скорости, в сравнении с теми же uIP/lwIP?

[toweroff]

Возвращаясь к теме подскажите хороший tcp/ip стек, кроме uIP:
Кто-нибудь использовал Keil'овский RL-TCPnet?
Как он по скорости, в сравнении с теми же uIP/lwIP?

вот здесь Keil выкладывает тесты скорости (опять же - как тестировали, какие еще задачи"болтались" и т.д. - непонятно)

[i.cf]

вот здесь Keil выкладывает тесты скорости (опять же - как тестировали, какие еще задачи"болтались" и т.д. - непонятно)

Да видел я это... KB/s - это килобит или килобайт?

NXP LPC2368 at 48MHz 3,350 UDP, 1,718 TCP/IP

если килобит, то получается для TCP 1.8Мбитт/сек - маловато...

Просто сейчас стоит задача организовать передачу данных в ПК с максимальной скоростью. Скорость чем больше - тем лучше. Процессор - LPC2468 (в будущем планируется заменить на LPC3250 или около того, но пока LPC2468). Протокол TCP (данные терять и путать нельзя - там длинные куски по 2 - 100Кбайт).
Тем по uIP/lwIP на форуме много, а вот по кейловскому стеку я ничего не нашел, вот и хотелось узнать о нем мнение, что лучше выбрать?

[aaarrr]

Да видел я это... KB/s - это килобит или килобайт?

если килобит, то получается для TCP 1.8Мбитт/сек - маловато...

Надо думать, все же килобайт. Но все равно маловато. Обратите еще внимание на одинаковую скорость TCP на разных платформах для 1400 байт - что-то в консерватории явно не так.

Протокол TCP (данные терять и путать нельзя - там длинные куски по 2 - 100Кбайт).

Ну, чтобы обеспечить целостность данных вовсе не обязательно использовать именно TCP.

[i.cf]

Обратите еще внимание на одинаковую скорость TCP на разных платформах для 1400 байт - что-то в консерватории явно не так.

Да, и к тому же в предпоследней строчке TCP быстрее UDP... Будем считать это банальная опечатка - скопировался результат с предыдущей платформы

Ну, чтобы обеспечить целостность данных вовсе не обязательно использовать именно TCP.

Согласен, можно прописывать в начало пакета номер и использовать UDP и самому отправлять квитанции. Если квитанций нет какое-то время - отправлять повторно. Но получается почти тот-же TCP, только заголовок проще... Вот я и решил сразу TCP и использовать.

Сообщение отредактировал i.cf - Aug 29 2009, 18:39

[dch]

Мне всего-то надо отправлять с компа на девайс 64-битные посылки.

Если устраиват UDP - дейтаграмные посылки, а не собираетесь использовать TCP, то нет нужды заморачиваться особенно со стеком - на сайте у атмела должны быть тесты типа BasicEthernet

[i.cf]

Мне всего-то надо отправлять с компа на девайс 64-битные посылки.

Это писал не я и два года назад. Писавший это уже получил ответы на свои вопросы.

Если устраиват UDP - дейтаграмные посылки, а не собираетесь использовать TCP, то нет нужды заморачиваться особенно со стеком

Та в том-то и дело, что не совсем устраивает (см. мой предыдущий пост). И использовать собираюсь я использовать именно TCP!

Что-то так и не встретились пользователи RL-TCPnet, что немного настораживает...

Сообщение отредактировал i.cf - Aug 30 2009, 07:52

[goodwin]

На вот такой платке: http://www.starterkit.ru/html/index.php?na...p=view&id=9 ,
TCP/IP стэк кейловский (RTL), при частоте тактирования контроллера 72 МГц, в thumb mode (ибо библиотека там только для thumb),
удалось пропихнуть в сторону компа
~20000 коротких (18 байт) UDP пакетов в секунду...

[lebiga]

На вот такой платке: http://www.starterkit.ru/html/index.php?na...p=view&id=9 ,
TCP/IP стэк кейловский (RTL), при частоте тактирования контроллера 72 МГц, в thumb mode (ибо библиотека там только для thumb),
удалось пропихнуть в сторону компа
~20000 коротких (18 байт) UDP пакетов в секунду...

К сравнению - у меня lwip, TCP, пакеты по 1024 байта, функции RAW API tcp_write() - 1638400 байта в сек поток работает отлично. Разработанная система - восьмиканальный анализатор. Только нужно комп брать многоядерный и выделить поток независимый на прием. Плата - та-же, стартеркита, на LPC2368, 64 МГЦ тактовая, ARM-mode

[aaarrr]

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

Многоядерный для приема 1600 кБайт/с? Или какая-то обработка все же делается?

[lebiga]

Многоядерный для приема 1600 кБайт/с? Или какая-то обработка все же делается?

Спектральная обработка в реальном времени, конечно. А отдельный поток на прием для того, чтобы не делать очень длинный буффер передачи (да и ограничение по памяти). А винда имеет особенность иногда отвлекаться на что-то и происходит переполнение. Да и замирание данных на экране не приветствуется...

[goodwin]

К сравнению - у меня lwip, TCP, пакеты по 1024 байта, функции RAW API tcp_write() - 1638400 байта в сек поток работает отлично. Разработанная система - восьмиканальный анализатор. Только нужно комп брать многоядерный и выделить поток независимый на прием. Плата - та-же, стартеркита, на LPC2368, 64 МГЦ тактовая, ARM-mode

Ну у меня масштабы попроще
Полный мониторинг одновременно двух CAN шин.
Достигнутой скорострельности вполне достаточно для этого.
Без лишних заморочек с буферизацией и пр.
Один udp пакетик - для каждого CAN сообщения. Многое упрощает..
Оврхед UDP не нарягает...

[i.cf]

TCP/IP стэк кейловский (RTL), при частоте тактирования контроллера 72 МГц, в thumb mode (ибо библиотека там только для thumb), удалось пропихнуть в сторону компа ~20000 коротких (18 байт) UDP пакетов в секунду...

Это получается 0,34Мбайт/с, а если учесть (основываясь на все той же же кейловской RL-TCPnet Performance) что при увеличении пакета в 140 раз скорость увеличилась раз так в 30, то для большого пакета должно быть около 10Мбайт/с. Или около 5Мбайт/с для TCP.

К сравнению - у меня lwip, TCP, пакеты по 1024 байта, функции RAW API tcp_write() - 1638400 байта в сек поток работает отлично. Разработанная система - восьмиканальный анализатор. Только нужно комп брать многоядерный и выделить поток независимый на прием. Плата - та-же, стартеркита, на LPC2368, 64 МГЦ тактовая, ARM-mode

1638400байт/сек = 1,56Мбайт/сек - это максимальная скорость, или просто быстрее передавать не было необходимости?

[dch]

1,56Мбайт/сек

На pc на 10Мбитном интефейсе реально получить 8 мегабит на длинных пакетах, а на 100Мбитном 60.

[blackfin]

На pc на 10Мбитном интефейсе реально получить 8 мегабит на длинных пакетах, а на 100Мбитном 60.

PC-шки, они же разные..

На Marvel'е, на 100-Мбитном линке можно и 100:
[attachment=35834:Ethereal.jpg]

[lebiga]

1638400байт/сек = 1,56Мбайт/сек - это максимальная скорость, или просто быстрее передавать не было необходимости?

нет необходимости...