WinAVR 2006, Компилятор полностью игнорирует циклы Опции

[Freeze Anti]

Здравствуйте.

У меня появилась такая проблема... компилятор полностью пропускает циклы... то есть вот пример...

на Си я пишу

Код

SetLCDPosition(2, 0);
for(short i = 0; i == 23; i++)
    ucTemp += sCurrentTemp[i];
ucTemp /= 24;
sprintf(sBuffer, "%3d", ucTemp / 2);

а в ассемблере получается

Код

181:              SetLCDPosition(2, 0);
+000002B3:   2F61        MOV     R22,R17          Copy register
+000002B4:   E082        LDI     R24,0x02         Load immediate
+000002B5:   940E0113    CALL    0x00000113       Call subroutine

185:              sprintf(sBuffer, "%3d", ucTemp / 2);
+000002B7:   921F        PUSH    R1               Push register on stack
+000002B8:   921F        PUSH    R1               Push register on stack
+000002B9:   E682        LDI     R24,0x62         Load immediate
+000002BA:   E090        LDI     R25,0x00         Load immediate
+000002BB:   939F        PUSH    R25              Push register on stack
+000002BC:   938F        PUSH    R24              Push register on stack
+000002BD:   92FF        PUSH    R15              Push register on stack
+000002BE:   92EF        PUSH    R14              Push register on stack
+000002BF:   940E03CE    CALL    0x000003CE       Call subroutine

моего цикла for(...) {...} нет совсем... так в нескольких местах программы (везде, где встречаются циклы)

пробовал при уровнях компиляции 0, 1, 3, s. При нулевом уровне у меня программа не вылазиит из прерывания по АЦП. То есть сразу после окончания обработки прерывания сбрасывается на начало прерывания... А при остальных - проглатываются циклы... может, кто сталкивался с подобной проблемой... подскажите пожалуйста, что можно сделать... везде в программе писать такое количество операторов это уж слишком загромоздит код (циклов ожидается достаточно большое количество)...

[zltigo]

И еще "short i" - ни к селу ни к городу - для 8bit это работа с чрезмерно большим 16bit значением, а для
32 ARM - с исскуственно ограниченным.
Если пользоватся минимальным набором типов, то для 8bit "unsigned char" , а для 16/32 соответствено "int".
Поскольку на 8bit int обычно "традиционно" 16bit, на 16bit - уже обычно логичный соразмерный, ну и на 32bit-овиках вообще все правильно.

[Сергей Борщ]

Если пользоватся минимальным набором типов, то для 8bit "unsigned char" , а для 16/32 соответствено "int".

или uint_least8_t, uint_fast8_t из stdint.h - оптимальное для архитектуры значение подставится "само".

[zltigo]

или uint_least8_t, uint_fast8_t из stdint.h - оптимальное для архитектуры значение подставится "само".

Я говорил о минимальном наборе типов. Я по простоте душевной тоже за такой подход агитировал достаточно долго, пока не наступил на непонятки в IAR ARMc int_least8_t - в сложных выражениях не int , int_fast8_t там ведет себя похожим на int. Ну, короче я свой ручкаи завел bint (base int) для такого.