Пишу загрузчик для AT90CAN128 и столкнулся с проблемой. Далее привожу часть кода, которая вызывает ошибку.
__C_task main(void)
{
// обявил переменную sum
union {
unsigned char b[4];
unsigned int w[2];
unsigned long dw;
}sum;
unsigned long data32;
sum.dw = (unsigned long)0x00011278;
// далее посыдаю побайтно sum.b[0], sum.b[1],sum.b[2],sum.b[3] в CAN
data32 = (unsigned long)0x00011278;
// далее посыдаю побайтно (unsigned char)data32, (unsigned char)(data32>>8),
// (unsigned char)(data32>>16),(unsigned char)(data32>>24) в CAN
}

В результате вижу по CAN:
1-ая посылка: 0x78, 0x12, 0x12, 0x00
2-ая: 0x78, 0x12, 0x01, 0x00
В чем глюк понять не могу. Это клюк компилятора или я что-то не так делаю? Уровень оптимизации стоит максимальный по объему кода.
P.S. Скомпилировал проект под IAR AVR 5.20 все работает нормально. Подтвердите, это глюк компилятора?

А в чем глук? у тебя все правильно работает.
А где sum.b ты присваиваешь?

Сообщение отредактировал Sanya_kv - Jun 18 2009, 06:17

1. Глюк в том, что получаю 0x78,0x12,0x12,0x00 ВМЕСТО 0x78,0x12,0x01,0x00.
2. А зачем sum.b присваивать? Я уже присвоил: sum.dw = (unsigned long)0x00011278;

Если текст один и тот же, сравните листинги и всё станет ясно.

Очень давно, в IAR3.хх с похожим столкнулся. Компилятор некорректно сдвигал вправо на большое значение кратное 8-ми. Сейчас не вспомню, с локальными или глобальными это было.
Поборол делением (data32 / 16) (data32 / 24). Что примечательно, иар не обращался к процедуре деления, а брал нужный байт как при сдвиге. Оптимизация полностью отключена.
Потом, все сдвиги заменил макросами. С ними проблем не возникало. Посмотрите, может у Вас что то похожее.

Можно об этом подробнее?
KSN: показывайте листинги.

Прилагаю файлы iar430a.7z и iar520.7z
В первом листинг, map, файл исходника с функцией main.c и *.xcl файл.
Во втором только листинг и map.  Iar430a.7z ( 28.07 килобайт ) Кол-во скачиваний: 130
 Iar520.7z ( 24.56 килобайт ) Кол-во скачиваний: 156

Покажите исходник TX_SET8, возможно проблема в нем. Пока видно вот что:

Во глюканул, но это я хорошо разделил
Делить нужно, соответственно, на 256, 65536, 16777216

TX_SET8 это макрос, вот его код

#define TX_SET8(a,b,c,d,e,f,g,h,i,j) Can_Tx.cmd = a; Can_Tx.id.ext = (Uint32)(; Can_Tx.ctrl.ide = 1;\
Can_Tx.dlc = 8; Can_Tx.data[0] = c; Can_Tx.data[1] = d;\
Can_Tx.data[2] = e; Can_Tx.data[3] = f; Can_Tx.data[4] = g;\
Can_Tx.data[5] = h; Can_Tx.data[6] = i; Can_Tx.data[7] = j;
Заодно привожу и описание Can_Tx:

typedef enum {
CMD_NONE,
CMD_TX,
CMD_TX_DATA,
CMD_TX_REMOTE,
CMD_TX_INT,
CMD_TX_DATA_INT,
CMD_TX_REMOTE_INT,
CMD_RX,
CMD_RX_DATA,
CMD_RX_REMOTE,
CMD_RX_MASKED,
CMD_RX_DATA_MASKED,
CMD_RX_REMOTE_MASKED,
CMD_RX_INT,
CMD_RX_DATA_INT,
CMD_RX_REMOTE_INT,
CMD_RX_MASKED_INT,
CMD_RX_DATA_MASKED_INT,
CMD_RX_REMOTE_MASKED_INT,
CMD_REPLY,
CMD_REPLY_MASKED,
CMD_REPLY_INT,
CMD_REPLY_MASKED_INT,
CMD_ABORT
} can_cmd_t;

// ----------
typedef union{
Uint32 ext;
Uint16 std;
Uint8 tab[4];
} can_id_t;

// ----------
typedef struct{
Bool rtr;
Bool ide;
} can_ctrl_t;

typedef struct{
Uint8 handle;
can_cmd_t cmd;
can_id_t id;
can_id_t mask;
Uint8 dlc;
// Uint8* pt_data;
Uint8 status;
can_ctrl_t ctrl;
Uint8 data[8];
} st_cmd_t;

Да, в таком виде это очень похоже на баг компилятора. А можно попросить еще вывод препроцессора (Project->Options->Compiler->Preprocessor->Preprocessor output to file)?

Я правильно понял, это то что Вы просили?
 OPTIONS.bmp ( 22.95 килобайт ) Кол-во скачиваний: 38
 bootloader.7z ( 19.32 килобайт ) Кол-во скачиваний: 108

Да, совершенно правильно.
Вот во что препроцессор развернул макрос (я вставил переводы строки для читаемости):Очевидно, что компилятор получил правильные данные. Значит - таки да, бага.
Совет: во избежание неожиданностей в ситуациях типа if(...) TX_SET8; оберните тело TX_SET8 и подобных в do { ... } while(0)