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

[InsolentS]

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

[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

Смотри почту

[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

 

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

[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.

[zltigo]

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

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

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

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

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

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

[defunct]

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

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