[Golikov 0]

потому что фаст наверняка 32 битный, и при сдвиге на 1 - 2 - 3 байта все равно попадает в 0 байт. А этот почему то честно отработал...

[billidean 0]

Я тоже так подумал, но вот искать истину пока некогда. Хотя всегда считал, что вне зависимости от типа проца. он всегда 32-хбитный. Надо почитать описание поточнее.

[billidean 0]

Посмотрел доку "Implementation Details" на НИОС (n2cpu_nii51015.pdf), не нашел про изменение работы с памятью (32-хбитное обращение или 8-мибитное) для разных версий проца.

[Kuzmi4 0]

2 billidean

вставьте в С-код выравнивание, откоментируйте это и забудьте ;)

[Golikov 0]

а шина везде одна и таже?

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

В ксалинксе так, дешевый мак считает суммы алгоритмически, а дорогой железом.

[alexadmin 0]

а шина везде одна и таже?

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

 

Нет, базовая архитектура всех ниосов одинакова.

[billidean 0]

Вот моя структура пакета в .h-файле

typedef struct UDP_str
{
    char macDst[6];
    char macSrc[6];
    char type[2];
    char ver_lenIP;
    char all00;
    char len_28plus[2];
    char id_pack[2];
    char fl_4000[2];
    char time_l_80;
    char type_UDP_11;
    char crc16_IPhead[2];
    char ipSrc[4];
    char ipDst[4];
    char portSrc[2];
    char portDst[2];
    char lenUDP_8plus[2];
    char crc16_UDP[2];
    // до этого ... длина равна 42 байта
    char data[UDP_DATA_MAX_SIZE];
} __attribute__((__packed__)) UDP_str;

Вот код в .c-файле

volatile UDP_str udp_send_s __attribute__ ((aligned (1)));
volatile UDP_str udp_take_s __attribute__ ((aligned (1)));

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

Расчет CRC для IP-заголовка должен начинаться с поля ver_lenIP, и просчитывать 20 байт, а я указал (ошибочно), чтобы начинался расчет с поля all00, т.е. сдвинул на один байт вправо. При этом НИОС/Фаст все нормально расчитывал, а вот НИОС/Эконом выдавал кривую CRC, из-за чего я и обнаружил свой косяк в указании начального адреса расчета CRC.

Поэтому и началось обсуждение типов НИОСов и их обращение к памяти.

[Golikov 0]

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

[billidean 0]

Если шина 32-хбитная, и мы указываем на 2-ой или 3-тий байт ячейки, то эта ячейка будет задействована полностью, начиная с 1-го байта, т.о. будем иметь сдвиг по адресу влево, в сторону уменьшения.

Если посмотреть на шину Авалон, то эта ситуация очень видна, НО в этой шине все (имею в виду побайтовое обращение) разруливается доп.сигналами byteenable.

[Serhiy_UA 1]

Вот моя структура пакета в .h-файле

У меня структура UDP-пакетов несколько схожая, но отличается служебными словами PACKED, у них тоже была своя роль...

//------------------- UDPFRAME

typedef struct udphdr { //8 bytes

u_short uh_sport PACKED; /*!< \brief Source port */

u_short uh_dport PACKED; /*!< \brief Destination port */

u_short uh_ulen PACKED; /*!< \brief UDP length */

u_short uh_sum PACKED; /*!< \brief UDP checksum */

} UDPHDR;

 

struct UDPFRAME {

ETHERHDR eth_hdr PACKED; //14 bytes

IPHDR ip_hdr PACKED; //20 bytes

UDPHDR udp_hdr PACKED; // 8 bytes

u_char md[1472] PACKED; // + (22..1476) bytes

};