[zltigo 2]

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

Ой! "А мужики-то и не знают" :).

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

[defunct 0]

Ой! "А мужики-то и не знают" :).

Заменяет, когда может, а гогда 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 2]

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

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

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

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

 

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 0]

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 0]

Немного в сторону от полемики...

Для 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 2]

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

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

 

 

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

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

Пока у себы сделал 'по собственному' разумению и обложил отладочными сообщениями.

CRC Eror просто игнориуется пакет, если конечно не стабильно непрерывно повторяющася ошибка.

Для остальных железных переинициализируется толко железо. Разборки с целостностью софтовых буферов исключены :) (зато добавлен дополнительный контроль за формированием тех-же

header.NextPacketPointer ). Ошибок в логах не встречал.

 

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

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

[Dimmy 0]

А вот еще один порт 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 0]

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

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

[zltigo 2]

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

Для общего развития, еще об одной проблеме с взятием невыровненных адресов. Правда, может уже и поправили - не знаю, ибо просто я так не пишу :).

http://electronix.ru/forum/index.php?showt...=15808&st=0

 

 

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

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

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

[Dimmy 0]

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

[zltigo 2]

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

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

[lebiga 0]

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

для KEIL RTL-TCPNET говорят

я так, глянул по быстрому

может кому нужно

вот отсюда

http://www.keil.com/forum/docs/thread10418.asp

VehCntr.zip

[zltigo 2]

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

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

[Yra 4]

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

[cpl 0]

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

исходниками не поделитесь ?

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