Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Нет прерываний от модуля Ethernet.
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
Oleg_IT
Продолжение работы, которая обсуждалась здесь
Демо плата SK-MLPC2478, приложение EMAC. Отдельный вход Ethernet для этой платы. Формирую ARP запрос, по WireShark вижу, что сообщение в PC приходит и формируется ответ, но прерывания в ARM-е, по приходу данных, нет, прерывания возникают только по отправке данных, данные отправлены, буфер пуст. Где, что посмотреть, проверить почему нет прерываний?
Golikov A.
мак адрес в емаке есть? задали? правильный?
Oleg_IT
Цитата(Golikov A. @ Oct 8 2013, 13:14) *
мак адрес в емаке есть? задали? правильный?

А что значит правильный? Он у меня из примера остался.
В приложении скриншоты с WireShark
сарматъ
а айпи адреса правильно обрабатываются?маска сети какая?
Oleg_IT
Маска 255.255.0.0. Попробывал другие варианты прерываний нет.
сарматъ
для начала можно попробывать разрешить прием всех пакетов не зависимо от мак адреса и посмотреть вообще что то приходит или нет
Oleg_IT
Цитата(сарматъ @ Oct 9 2013, 09:29) *
для начала можно попробывать разрешить прием всех пакетов не зависимо от мак адреса и посмотреть вообще что то приходит или нет

А я не запрещал. Где разрешить/запретить прописывается?
Я сейчас без библиотеки работаю, всё сам делаю, и пакеты генерю и на выход их посылаю.
сарматъ
для каждого процессора периферия настраивается по своему думаю в мануале по процессору должен быть описан порядок работы с мак-контроллером в частности правила фильтрации пакетов

ну и конечно сами прерывания должны быть разрешены явно а не просто "не запрещены"

еще такой момент вы подсоединяете плату чрез маршрутизатор? хорошо было бы убедиться что маршрутизатор отправляет пакеты на соотв порт
Oleg_IT
Цитата(сарматъ @ Oct 9 2013, 11:05) *
для каждого процессора периферия настраивается по своему думаю в мануале по процессору должен быть описан порядок работы с мак-контроллером в частности правила фильтрации пакетов

ну и конечно сами прерывания должны быть разрешены явно а не просто "не запрещены"

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

Нет, соединение точка-точка. Провода целые, не рваные, проверял.
По первым двум советам проверю.
Oleg_IT
Проблема банальна. При формировании запроса у меня один порядок байтов в MAC адресе был, а при инициализации MAC в PHY обратный.

Тогда другой вопрос. В PC одно направление байтов в SUN и в ARM другое. Как определяется из какой системы пришёл пакет?
Golikov A.
Цитата(Oleg_IT @ Oct 9 2013, 15:40) *
Проблема банальна. При формировании запроса у меня один порядок байтов в MAC адресе был, а при инициализации MAC в PHY обратный.

Тогда другой вопрос. В PC одно направление байтов в SUN и в ARM другое. Как определяется из какой системы пришёл пакет?


езернет весь BIG Endian, что РС, что Юникс, что Макинтош...
а ARMы разные бывают, обычно Little Endian
Oleg_IT
При компиляции можно определить какая система BIG или Little Endian?
Golikov A.
скорее всего на этапе создания проекта. У некоторых сред и армов можно выбрать в свойствах проекта. В "софтварных" плисовых процессорах можно выбрать на уровне создания проца.

Только я бы не стал менять Little Endian процессор на Big, ибо для процессора удобнее и быстрее быть Little
сарматъ
Цитата(Golikov A. @ Oct 11 2013, 11:47) *
для процессора удобнее и быстрее быть Little

а почему так?
Golikov A.
потому для чего этот формат придумали

к примеру
Код
logn int BigData = 128.
void *p = (void *)&BigData;


это все сработает правильно
Код
char ch_data = *p;
short int m_data = *p;
int mm_data = *p;
long int l_data = *p;


потому что в адресах памяти самый младший байт лежим первым, и взяв его в чаровский указатель вы получите верное 8 битное число.
Запихав в 16 бит, вы опять же получите верное 16 битное число и так далее...

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

Код
short int Data = 232443;
void *p = (void *)&Data;

long int b_data = *p;
b_data &= 0x0000FFFF;


в формате Big Endian младшая часть числа всегда лежит на разном расстоянии от начала в зависимости от размерности числа, и чтобы получить правильное число из памяти надо знать и учитывать размерность числа записанного и приемника, это несколько осложняет процесс....

сарматъ
понял спасибо
Oleg_IT
Потому и нужны какие-то дефайны, по которым определяется нужно делать swap или нет.
Тут ещё сложность не только в порядке байт, но и в порядке бит в битовых полях.
Golikov A.
Цитата(Oleg_IT @ Oct 11 2013, 13:25) *
Потому и нужны какие-то дефайны, по которым определяется нужно делать swap или нет.
Тут ещё сложность не только в порядке байт, но и в порядке бит в битовых полях.


нет... Big и Litlle меняет только порядок байт. Битовые поля не могу разворачиваться. Возможно среда ставить какой то дефайн при выборе байт ордера, только вопрос, а вам то оно зачем? Вы пишите универсальный модуль или просто все время забываете какой порядок вы используетеsm.gif?

Если модуль универсальный - то сделайте свой дефайн, в случае которого вы переводите все в Big, а по умолчанию делайте в Little как более популярном...

П.С. повернутый порядок бит - это очень странно, у вас нет никаких рукописных UART на пути следования данных, потому что только они имеют тенденцию биты поворачивать. Если нет, остается проверить стандарты езернет, нет ли какого флажка в заголовках по этому поводу, но очень маловероятно, так как даже этот флажок фиг найдешь если он все время в разных местах... Вообщем про поворот порядка бит я озадачен...
Oleg_IT
Цитата(Golikov A. @ Oct 11 2013, 13:58) *
нет... Big и Litlle меняет только порядок байт. Битовые поля не могу разворачиваться. Возможно среда ставить какой то дефайн при выборе байт ордера, только вопрос, а вам то оно зачем? Вы пишите универсальный модуль или просто все время забываете какой порядок вы используетеsm.gif?

Если модуль универсальный - то сделайте свой дефайн, в случае которого вы переводите все в Big, а по умолчанию делайте в Little как более популярном...

П.С. повернутый порядок бит - это очень странно, у вас нет никаких рукописных UART на пути следования данных, потому что только они имеют тенденцию биты поворачивать. Если нет, остается проверить стандарты езернет, нет ли какого флажка в заголовках по этому поводу, но очень маловероятно, так как даже этот флажок фиг найдешь если он все время в разных местах... Вообщем про поворот порядка бит я озадачен...

Я теже озадачен, но по факту так
Код
typedef struct TCP_Head_tag {
    uint16_t SRC_Port;         // Порт отправителя
    uint16_t DST_Port;         // Порт получателя
    uint32_t SeqNum;           // Sequence Number
    uint32_t AckNum;           // Acknowledgment Number
    union {
        struct {
            uint16_t FIN        : 1;    // No more data from sender
            uint16_t SYN        : 1;    // Synchronize sequence numbers
            uint16_t RST        : 1;    // Reset the connection
            uint16_t PSH        : 1;    // Push Function
            uint16_t ACK        : 1;    // Acknowledgment field significant
            uint16_t URG        : 1;    // Urgent Pointer field significant
            uint16_t Res1       : 6;    //: 4;    // Reserved - 0
            uint16_t DOff       : 4;    // Data Offset - 5
        };
        uint16_t L1;
    };
/*
    union {
        struct {
            uint16_t DOff       : 4;    // Data Offset - 5
            uint16_t Res1       : 6;    //: 4;    // Reserved - 0
            uint16_t URG        : 1;    // Urgent Pointer field significant
            uint16_t ACK        : 1;    // Acknowledgment field significant
            uint16_t PSH        : 1;    // Push Function
            uint16_t RST        : 1;    // Reset the connection
            uint16_t SYN        : 1;    // Synchronize sequence numbers
            uint16_t FIN        : 1;    // No more data from sender
        };
        uint16_t L1;
    };
*/
    uint16_t Window;              // Window - -
    uint16_t Checksum;            // Checksum
    uint16_t UrgPoint;            // Urgent Pointer
} TCP_Head;

Закомментированное по стандарту, а рабочее, что бы на стороне PC все правильно воспринималось, не закомментированное. И ещё swap на L1 нужен. Может я в чём-то ошибаюсь. Поправьте.
Golikov A.
меня немного беспокоит слово заголовка в котором лежат флаги.

после 32 бит AckNum
должно идти 16 битное слово, в старших битах которого длина заголовка, а в младших биты - флаги. У вас наоборот. Может потому вам и надо инвертировать. То есть это просто совпадение. инвертированная длина попала в флаги, а инвертированные флаги в длину?

Опять же длина, L1 я так понимаю, не 16 бит.
6 бит флаги
6 бит пустое поле
остается 4 бита длинна вроде как...
Oleg_IT
По количеству бит там всё правильно 4 длина+6 пусто+6*1 флаги, итого 16.
А вот по порядку, правильно, по стандарту, закомментированный union ниже, а не правильный порядок оказывается правильным по факту. Я такие чудеса не понимаю, но в WireShark всё правильно отображается. Если swap на правильный по стандарту union сделать WireShark выдаёт ошибку.
Golikov A.
union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};


Л1 - 16 бит это че? Сразу после флагов же окно идет uint16_t Window;
а у вас оно идет через какие то 16 бит Л1. Плюс еще вопрос как структура с 1 битными полями в памяти раскладывается... Выравнивание может сыграть злую шутку...
alx2
Цитата(Oleg_IT @ Oct 11 2013, 15:29) *
Закомментированное по стандарту, а рабочее, что бы на стороне PC все правильно воспринималось, не закомментированное.

Расположение битовых полей в объединении определяется реализацией компилятора. Вы уверены, что ваш компилятор располагает битовые поля именно в порядке от старшего бита к младшему (как у Вас в закомментаренном фрагменте), а не наоборот (как в раскомментаренном)?

И, надеюсь, Вы понимаете, что из-за того что Вы закладываетесь на определенную реализацию компилятора, Ваш код становится непереносимым?
Oleg_IT
Цитата(alx2 @ Oct 12 2013, 15:05) *
Расположение битовых полей в объединении определяется реализацией компилятора. Вы уверены, что ваш компилятор располагает битовые поля именно в порядке от старшего бита к младшему (как у Вас в закомментаренном фрагменте), а не наоборот (как в раскомментаренном)?

И, надеюсь, Вы понимаете, что из-за того что Вы закладываетесь на определенную реализацию компилятора, Ваш код становится непереносимым?

Догадываюсь, потому и хочу разграничить версии соответствующими дефайнами.

Цитата(Golikov A. @ Oct 11 2013, 15:42) *
union {
struct {
uint16_t FIN : 1; // No more data from sender
uint16_t SYN : 1; // Synchronize sequence numbers
uint16_t RST : 1; // Reset the connection
uint16_t PSH : 1; // Push Function
uint16_t ACK : 1; // Acknowledgment field significant
uint16_t URG : 1; // Urgent Pointer field significant
uint16_t Res1 : 6; //: 4; // Reserved - 0
uint16_t DOff : 4; // Data Offset - 5
};
uint16_t L1;
};


Л1 - 16 бит это че? Сразу после флагов же окно идет uint16_t Window;
а у вас оно идет через какие то 16 бит Л1. Плюс еще вопрос как структура с 1 битными полями в памяти раскладывается... Выравнивание может сыграть злую шутку...

Так это же юнион, struct и L1 это два инени оного и того же куска пямяти размером два байта.
А про выравнивание я не сказал, пользуюсь
Код
#pragma push
#pragma pack(1)
……………………
#pragma pop
Golikov A.
ИМХО лучше сделать поле 16 бит,
и дефайны с флагами, чем структуру...

Цитата(Oleg_IT @ Oct 14 2013, 09:58) *
Так это же юнион, struct и L1 это два инени оного и того же куска пямяти размером два байта.


да,... это я чего то объединение не разглядел....
Oleg_IT
Цитата(Golikov A. @ Oct 14 2013, 22:43) *
ИМХО лучше сделать поле 16 бит,
и дефайны с флагами, чем структуру...

Так порядок бит, задаваемый этими дефайнами всё равно как-то учитывать нужно.
Golikov A.
да тут вроде как мы все ходим вокруг одного и того же.
порядок бит НЕ МЕНЯЕТСЯ, иначе во всем мире во всем интернете что на езернете построен был бы полный АД!

у вас все изменилось из-за представлений вашего компилятора о том как надо раскладывать битовые поля, потому и рекомендую избавится от зависимости компилятора, и не использовать потенциально опасные конструкции в виде битовых полей.
Oleg_IT
Я вас сходу по флажкам не понял. Переделал, работает.
Но вопрос нужен swap или нет остался. Может я опять простого решения не вижуsm.gif
Golikov A.
во всех системах Big Enadian не нужен
во всех системах Litle Endian нужен.

потому делаете дефайн


Код
#define LITTLE_ENDIAN_MODE 1


и везде в вашем коде пишете
Код
#ifdef LITTLE_ENDIAN_MODE
  swap
#elseif
  not_swap
#endif


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


причем этот дефайн можно тянуть не по всему тексту а сделать функцию swap_if_need, и в ней дефайн проверить, и сваповать если надо.
Oleg_IT
Самому определять это понятно, а в компиляторе такой информации нет?
mdmitry
Цитата(Oleg_IT @ Oct 15 2013, 16:33) *
Самому определять это понятно, а в компиляторе такой информации нет?

Есть. Для GCC есть предопределенные макро, например, для arm-none-eabi-gcc (arm-none-eabi-g++)
Код
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_PDP_ENDIAN__ 3412
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__

DmitryM
Цитата(Oleg_IT @ Oct 15 2013, 16:33) *
Самому определять это понятно, а в компиляторе такой информации нет?


Цитата
The common predefined macros are GNU C extensions. They are available with the same meanings regardless of the machine or operating system on which you are using GNU C or GNU Fortran. Their names all start with double underscores

__BYTE_ORDER__
__ORDER_LITTLE_ENDIAN__
__ORDER_BIG_ENDIAN__
__ORDER_PDP_ENDIAN__
__BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.
You should use these macros for testing like this:

/* Test for a little-endian machine */
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__

Common-Predefined-Macros.html


Oleg_IT
Спасибо
Oleg_IT
Цитата(Oleg_IT @ Oct 15 2013, 12:32) *
Я вас сходу по флажкам не понял. Переделал, работает.

Поторопился я радоватся, что битовый массив, что
Код
#define FLAG_1     1

........................
Flags |= (1 << FLAG_1);

одно и тоже.
Oleg_IT
Цитата(Dron_Gus @ Oct 16 2013, 17:57) *

Интересно. Спасибо за ссылочки.
alx2
Цитата(Oleg_IT @ Oct 16 2013, 16:12) *
Поторопился я радоватся, что битовый массив,
Что такое "битовый массив"?

Цитата(Oleg_IT @ Oct 16 2013, 16:12) *
что
Код
#define FLAG_1     1

........................
Flags |= (1 << FLAG_1);

одно и тоже.

Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.
Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...
Oleg_IT
Цитата(alx2 @ Oct 17 2013, 11:25) *
Что такое "битовый массив"?

Ошибся, битовое поле.

Цитата(alx2 @ Oct 17 2013, 11:25) *
Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.
Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...

Если я битовом поле
Код
   union {
        struct {
            uint16_t FIN        : 1;    // No more data from sender
            uint16_t SYN        : 1;    // Synchronize sequence numbers
            uint16_t RST        : 1;    // Reset the connection
            uint16_t PSH        : 1;    // Push Function
            uint16_t ACK        : 1;    // Acknowledgment field significant
            uint16_t URG        : 1;    // Urgent Pointer field significant
            uint16_t Res1       : 6;    //: 4;    // Reserved - 0
            uint16_t DOff       : 4;    // Data Offset - 5
        };
        uint16_t L1;
    };

бит SYN, первый бит, ставлю в 1, то это будет тоже сомое, что
Код
L1 |= (1 << 1)

Проверено.
Golikov A.
Цитата(Oleg_IT @ Oct 17 2013, 12:18) *
Проверено.


и что?
ну значит ваш компилятор переворачивает битовые поля в другой порядок.
Смысл то как раз избавить от этого и всю структуру битовых полей выкинут нафиг, заменить ее обычным 16 битным числом, куда честно ставить флаги, на те места где они должны быть, однозначно, независимо от компилятора...
Oleg_IT
Так ни битовые поля, ни работа с флагами задачу не решают. Функции по ссылке http://www.opennet.ru/man.shtml?topic=hton...3&russian=0 только помогут, они специально для этого сделаны.
Golikov A.
что - то я видать не понимаю.

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

Что не так то?
Oleg_IT
По факту получается не так, и порядок байт и порядок бит разный. А ставить эти биты так или иначе не имеет значения ини будут на одном и том же места и это правильно и понятно.

Скорей всего мы друг друга недопонимаемsm.gif
Golikov A.
да.

порядок байт в интернете биг ендиан.
порядок бит как у всех младший бит нулевой.

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

порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...
alx2
Цитата(Oleg_IT @ Oct 18 2013, 10:20) *
Так ни битовые поля, ни работа с флагами задачу не решают.

Вы по-моему не понимаете, что имеете дело с двумя разными проблемами:
1. Проблема порядка байт с ловах (Big/Little endianness). Она решается использованием стандартных функций htonl/ntohl/htons/ntohs.
2. Проблема порядка расплоложения битовых полей в структуре/объединении. Она решается отказом от использования битовых полей в данном случае.
Я говорил исключительно о второй проблеме. И обратил Ваше внимание на то, что код Flags |= TCP_FLAG_SYN; переносим, а код Flags.SYN = 1; - нет, так как порядок следования битовых полей может быть разным в разных компиляторах.
Цитата(Golikov A. @ Oct 18 2013, 15:18) *
порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...

Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...
Oleg_IT
Кажется начинаю понимать обстановку. Без дефайнов не обойтись. Но всё равно не понятности остались, например в протоколе есть поле размером 13 бит, это байт и ещё немножко. Как в этом случае работает htnl/nthl?
Golikov A.
нет там такого поля 13 бит
есть поле 16 бит, и 3 бита в резерве....


дефайны наше все! Мы же работает на железном уровне, а не кнопки в бездушных программках рисуем%)

Цитата(alx2 @ Oct 18 2013, 15:40) *
Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...


а как они кстати тип хоста узнают? все равно же какой то дефайн ест, или они при инициализации тест делают чтение - записьsm.gif?
alx2
Цитата(Golikov A. @ Oct 19 2013, 01:50) *
а как они кстати тип хоста узнают? все равно же какой то дефайн ест, или они при инициализации тест делают чтение - записьsm.gif?

В случае нативной сборки (без кросс-компиляции) такие вещи можно узнать на этапе конфигурации (при выполнении скрипта configure). Например в autoconf есть макрос AC_C_BIGENDIAN, который при обнаружении big-endian хоста генерирует дефайн WORDS_BIGENDIAN.

В случае кросс-компиляции, наверное, для каждой target-архитектуры есть набор предопределенных дефайнов (если их не определяет сам компилятор). Можно, наверное, посмотреть, как это сделано, например, в glibc. Сам я специально этим не интересовался.

То есть да, какой-то дефайн наверняка все равно где-то есть, но главное, что это проблема библиотеки (и ее авторов), а не программиста, эту библиотеку использующего. Я как пользователь просто пишу в своем коде ntohl(), и могу не задумываться о том, как оно в коде библиотеки устроено, а могу сосредоточиться на своем собственном коде.

Конечно, если в библиотеке нет htonl/ntohl - тогда да, придется самому делать соответствующие дефайны и потом заботиться об их переопределении в случае смены целевой архитектуры...
Oleg_IT
Цитата(Golikov A. @ Oct 19 2013, 00:50) *
нет там такого поля 13 бит

Не правда Ваша, по ссылке пункт 3.1 "Fragment Offset"
Golikov A.
Цитата(Oleg_IT @ Oct 19 2013, 22:22) *
Не правда Ваша, по ссылке пункт 3.1 "Fragment Offset"


моя правда
это 13 бит от общего служебного поля
Флаги + офсет, в сумме которое 16 бит.

надеюсь версию вы не считает 4 битным полем?

http://securos.org.ua/potencialno-uyazvimy...rotokole-tcpip/
Думаю самое правильное воспринимать заголовки
как 32 или 2 по 16, либо комбинация 2 по 8 и 16 бит.
Все более мелкие разделения должны входить в эти группы.
Oleg_IT
Цитата(Golikov A. @ Oct 20 2013, 09:06) *
Думаю самое правильное воспринимать заголовки
как 32 или 2 по 16, либо комбинация 2 по 8 и 16 бит.
Все более мелкие разделения должны входить в эти группы.

С этим спорить не буду, там более, что заголовки так и задумывались как 32 битные. Думаю, что к заголовкам вообще ни какие свапы применять нельзя, они, заголовки, должны изначально строится под конкретную архитектуру, пусть с дефайнами. А htonl/ntohl и пр... применимы только к данным.
По поводу данных. Кто мне помешает ради экономии памяти сделать поля 13 и 3 бита а 16 битном слове. Как в этом случае быть с htonl/ntohl?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.