[Rst7 5]

Надо сказать, что QNAP все исходники выложил, и техподдержка нормальноая - если что, можно и их попинать.

 

Как Вам там хотели? "Покрутить лицо ногами"? Я думаю, самое оно именно так "попинать" :)

[prottoss 0]

Допилил свой стек до Release.

В THUMB показывает в среднем на нескольких прогонах 10000 кбит/сек. Интересно, на сколько производительней кортекс, и конкретно STM32 по сравнению с ARM7 и конкретно AT91SAM7.

 

Сразу предупреждаю, что не хочу открывать вторую линию фронта по поводу атмелов, стм-ов, кортексов и арм-ов. Вопрос только к Rst7. Есть ли возможность потестить на AT91SAM7 Ваш стек. Я, честно, говоря, не сильно смотрел Ваше произведение - только одним глазком. И не сравнивал - своими мыслями голова забита.

 

...Есть ли возможность...

Наверное фигню сморозил - проще, может быть, портировать самому Ваш стек на свою платку :rolleyes:

 

Как нить возьмусь. Просто, ради интереса :)

[Rst7 5]

Наверное фигню сморозил - проще, может быть, портировать самому Ваш стек на свою платку

 

Если мне не изменяет память, то там придется потрудиться, ибо в Atmel'овском EMAC'е по 128 байт кусочки пакетов. Но решаемо, в принципе, тоже без копирования.

 

Кроме того, рекомендую собирать в ARM-режиме, будет эффективнее. Единственный минус - довольно накладная процедура переворота байт в длинном слове, которая htonl/ntohl. Однако, ее необходимо инлайнить в любом случае, иначе будет плохо.

 

У меня, к сожалению, нет подходящей железки для порта. Кроме того, рекомендую подождать чуть-чуть, я таки сделаю вынос работы с железом и добавлю возможность отложенных обработок колбеков в менее приоритетных задачах.

[prottoss 0]

Если мне не изменяет память, то там придется потрудиться, ибо в Atmel'овском EMAC'е по 128 байт кусочки пакетов. Но решаемо, в принципе, тоже без копирования.

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

 

Кроме того, рекомендую собирать в ARM-режиме, будет эффективнее. Единственный минус - довольно накладная процедура переворота байт в длинном слове, которая htonl/ntohl. Однако, ее необходимо инлайнить в любом случае, иначе будет плохо.

Интересно, но в ARM-режиме производительность немного ниже чем в THUMB.

Для организации переворота :rolleyes: пользуюсь макросами

#define MAKEUINT16(byte_h, byte_l)    ((UINT16)((((UINT16)(byte_h)) << 8)|(UINT16)(byte_l)))
#define HIBYTE(word)                ((UINT8)(((UINT16)(word)) >> 8))
#define LOBYTE(word)                ((UINT8)(word))

#define MAKEUINT32(word_h, word_l)    ((UINT32)((((UINT32)(word_h)) << 16)|(UINT32)(word_l)))
#define HIWORD(dword)                ((UINT16)(((UINT32)(dword)) >> 16))
#define LOWORD(dword)                ((UINT16)(dword))

#define SWAP16(word)                (MAKEUINT16(LOBYTE(word), HIBYTE(word)))
#define SWAP32(dword)                (MAKEUINT32(SWAP16(LOWORD(dword)), SWAP16(HIWORD(dword))))

 

...рекомендую подождать чуть-чуть...

Да я и не спешу :)

[Rst7 5]

Интересно, но в ARM-режиме производительность немного ниже чем в THUMB.

 

Я проверял, код намного более эффективный в данном случае.

 

Для организации переворота пользуюсь макросами

 

Есть намного более оптимальный проворот 32хбитного числа.

[prottoss 0]

Есть намного более оптимальный проворот 32хбитного числа.

Не сомневаюсь услышать это от Вас. Поделитесь секретной информацией? :)

[zltigo 2]

Не сомневаюсь услышать это от Вас. Поделитесь секретной информацией? :)

Например:

     19          __arm ulong htonl( ulong n )
     20          {
     21          ulong t;
     22          
     23                t = n ^ ( (n << 16) | (n >> 16) );
     24                t &= ~0x00FF0000;
     25               n = ( n << 24 )|( n >> 8 );
     26                n ^= ( t >> 8 );
     27          
     28              return( n );
   \                     htonl:
   \   00000000   601820E0           EOR      R1,R0,R0, ROR #+16
   \   00000004   FF18C1E3           BIC      R1,R1,#0xFF0000
   \   00000008   2114A0E1           LSR      R1,R1,#+8
   \   0000000C   600421E0           EOR      R0,R1,R0, ROR #+8
   \   00000010   0EF0A0E1           MOV      PC,LR           ;; return
     29          }

Заинлайнить само собой тоже можно.

[Rst7 5]

Например:

 

Оно самое. В контексте рассматриваемого стека инлайнить их обязательно. Иначе появятся стековые переменные, код превращается в неприятное глазу унылое гуано.

[prottoss 0]

zltigo, Rst7

Поднял производительность на целыx полтора килобита :rolleyes:

В общем нуно потестить стек от Rst7.

[zltigo 2]

Поднял производительность на целыx полтора килобита :rolleyes:

 

Дежавю :) http://electronix.ru/forum/index.php?showtopic=41413

 

[Rst7 5]

Дежавю

 

О блин, плохо дело с портом на SAM7. Это придется все структуры в невыровненном режиме хранить. Ну или копировать к себе заголовки. Пока не готов сказать, какой способ будет эффективнее. Надо все-таки покурить даташит. Но выглядит это очень уныло.

[VslavX 0]

О блин, плохо дело с портом на SAM7. Это придется все структуры в невыровненном режиме хранить.

Можно хранить и в выравненном - для SAM7X можно задать начальное смещение по приему - например в 2 байта и все будет OK.

Upd: судя по моим исходникам - в EMAC_NCFGR - поле RBOF (блин, смотрю на свои тексты как баран - давно дело было)

 

[Rst7 5]

Можно хранить и в выравненном - для SAM7X можно задать начальное смещение по приему - например в 2 байта и все будет OK.

 

Это радует, я уж думал - зопа :)

 

[prottoss 0]

Дежавю :) http://electronix.ru/forum/index.php?showtopic=41413

Даааа.... Тока в 2008 все заработало Млин. А я уже забыл. Это был первый опыт одновременного освоения ARM7, RTOS (ucOS-II) и сетевых протоколов... Брррр...

[igneous 0]

Собрал версию 1318 на LPC1769 @ 100 Mhz.

Тест скорости показывает 91929...94360 Kbit/s. На более ранних версиях (1315 например) такой стабильности не было - скорость плясала от 40000 до 90000 Kbit/s практически случайным образом. EMAC: LAN8720A-CP.